New review team file download
Request from Peter B’s team.
New impact profile file for download that includes:
a. Impact Profile ID / E3MeaElecEndUseShape
b. PA / IOU
c. E3TargetSector
d. E3ClimateZone
e. avoided-cost version
f. avoided-cost combination ID / AC Elec Key
g. BldgType
h. BldgVint
i. BldgHVAC
j. Measure TechID
k. Baseline TechID
l. TechGroup and TechType, where applicable
m. first-baseline vs second-baseline indicator, if applicable
n. source year/calendar used, e.g. 2009 non-leap Thursday-start
o. baseline load-shape ID used
p. measure load-shape ID used
q. baseline annual UEC used
r. measure annual UEC used
s. denominator/savings used in the impact formula
t. validation status/results
u. generation timestamp
v. eTRM measure package ID
w. eTRM permutation ID
x. eTRM source snapshot/extract timestamp
And also provides additional files containing:
1. baseline load-shape 8760 csv
2. measure load-shape 8760 csv
Please give files descriptive names that include the Impact Profile ID or AC Elec Key.
- Select the module in CEDARS
- Select user type
Log in to comment and vote
Comments4
Derya Gumustel
Oct 19
Hi @sepidehs, I just wanted to share a progress update on this ticket.
We’re currently working on a design for a dedicated measure package page that we hope will be useful to reviewers and measure developers alike. We should be ready to gather feedback on the design later this week.
In the interim, I’m working on backfilling the permutation data for the impact profiles that have been generated in CEDARS so far. I want to give you a heads up that the majority of load-shape-derived impact profiles in CEDARS do not have an exact 1 to 1 match with permutations in eTRM using solely the fields that CEDARS pulls from eTRM. For many impact profiles, there are permutations that are duplicated across a field in eTRM that is not pulled into CEDARS. As a result, retroactively identifying the exact permutation that was used to calculate an impact profile is ambiguous for most of the profiles, as there are several permutations that would produce the same impact profile. We are also seeing a small number of impact profiles that do not possess a current eTRM permutation that would have produced the impact profile. This indicates that permutations were remade or new load shapes were uploaded after the impact profile was calculated in CEDARS, which I wanted to flag.
For now, we only intend to backfill the CEDARS database with metadata for impact profiles that have an exact 1 to 1 match with eTRM permutations. To support your work, we will be generating a report for you that clearly states the validation outcome of every load-shape-derived impact profile in CEDARS: whether we were able to match it to one permutation, to multiple permutations, or to no permutations. In the cases of multiple permutations, we will include a list of the permutation IDs and the UEC values from these permutations.
If you have any questions, concerns, or additional feedback please let me know. We’ll be looking forward to getting your feedback on the measure package page design. Thank you!
sepidehs
Oct 22
Hi @Derya Gumustel thank you for explaining these. An impact profile can legitimately be associated with several permutations. it would be great if going forward we can retain a record connecting:
Exact eTRM MP/version and permutation/source record, as retrieved at that time —> actual baseline and measure load-shape versions and annual UECs used —> generated Impact Profile ID.
I think the underlying source data also need to remain recoverable—not just IDs pointing to files or records that may subsequently change. Does it make sense to preserve these calculation inputs even if eTRM records or load shapes subsequently change?
So basically, when an impact profile is generated, retain the exact eTRM MP/version and permutation/source record used, its source snapshot (?), the baseline and measure load-shape IDs/versions, and the annual UECs actually used. These should be linked to the resulting Impact Profile ID, climate zone, and baseline type (for AR, both generated baseline-specific profiles should remain identifiable separately from the profile actually selected for CE).
Derya Gumustel
Oct 8
Hi @sepidehs, I’ve begun working on this ticket and would like to get a better understanding about how this data might best be organized for you and your team.
Currently, users can download impact profiles at an individual scale from the Impact Profile Library. Given the volume of load-shape-derived impact profiles in CEDARS (currently around 20,000), it isn’t practical for reviewers to download this data for individual impact profiles one by one.
Would it be helpful for reviewers if we added a page to download all impact profiles, plus the metadata described in this ticket, for a full measure package? If you had something else in mind, please let me know. Thank you!
sepidehs
Oct 8
Thank you @Derya Gumustel . Yes, I think a review package for an entire measure package would be extremely helpful and would solve a major practical problem we have encountered.
For example, during review of SWWH031, there were on the order of 800 generated impact profiles. Under the current workflow, even if we can identify profiles through library searches such as TechID, reviewers still have to download individual Impact Profile IDs one by one. That is not practical from an ex ante review perspective.
I also wanted to clarify that the measure-package review package would be complementary to, rather than a replacement for, the original metadata request in this ticket.
1. Measure-package review package
Ideally, reviewers should be able to select a measure package, and version if applicable, and download a complete review package containing all generated impact profiles for that measure package.
It would also be helpful if the same bulk-download concept could apply to filtered/search results, such as all impact profiles associated with a TechID or other source attribute.
2. Audit metadata
Whether downloading a single impact profile or a full measure-package review package, we would still need the additional metadata requested in this ticket so that every generated impact profile can be traced back to its source. This includes items such as:
Impact Profile ID / E3MeaElecEndUseShape, as applicable
eTRM measure package and version
eTRM permutation ID or other unique source record identifier
PA / IOU
target sector
climate zone
building type, vintage, and HVAC type
source baseline and measure load-shape IDs
baseline and measure TechIDs
baseline and measure annual UECs used in the calculation
denominator / savings value used in the impact-profile calculation
avoided-cost combination ID / AC Elec Key
avoided-cost version
first- or second-baseline indicator, where applicable
generation timestamp, code/version reference, and CEDARS run/job ID if applicable
validation results
This metadata could be included in a manifest file or another format that accompanies the review download.
3. Source load shapes
For complete auditability, it would also be very helpful if the review package included, or provided direct links to, the source baseline and measure load shapes used to generate each impact profile. That would allow reviewers to independently verify the impact-profile calculation from the original inputs.
4. Discoverability and naming
The download should also clearly identify the measure package and version it belongs to. Current individual downloads do not clearly identify the source measure package, so it is difficult to manage files once downloaded. Including the measure package, version, Impact Profile ID, and/or AC Elec Key in the manifest and file naming would help.
Thank you again for working on this.