Skip to main content

SWWH014-09: Workaround for NR and NC permutations sharing the same load shape

Feedback2026Impact Profiles & Load Shapes

As a Measure Developer, I want a supported way to use the same modeled load shape data across Existing and New vintages, so that CET can successfully run impact profiles where the modeled energy results are intentionally the same across vintages.

Sophiya reported an issue with SWWH014-09 Heat Pump Water Heater, Residential. The CET run failed because an Impact Profile ID was not available for the New vintage for some measures.

Following further clarification, the issue is not that the base and measure case use the same load shape.

For SWWH014-09:

  • Normal Replacement (NR / Existing) and New Construction (NC / New) have the same modeled savings and load shapes.

  • eTRM permutations include both Existing (Ex) and New (New) vintages, resulting in expected Load Shape / Impact Profile IDs for both.

  • The underlying modeling was only run for the NR / Existing building configuration. The NR energy results were then also used for the NC permutations in eTRM because the water heating measure was not expected to be affected by differences between the building vintages.

  • As a result, the generated 8760 files only contain Load Shape IDs associated with the Existing (Ex) vintage.

  • The corresponding New (New) vintage Load Shape IDs are therefore not included in the uploaded load shape files.

  • CET fails when processing the NC permutations because the expected New vintage Impact Profiles cannot be generated from the uploaded data.

Note we have a ticket in the backlog to Allow measure packages to share load shapes

Select the module in CEDARS
Posted by cedars team ·
Status: Completed4 comments

Log in to comment and vote

Comments4

  • cedars team

    Team•

    Aug 25

    I’d like to confirm Option 1 as the resolution for SWWH014-09.

    In summary, the New vintage permutations were failing because no load shapes were uploaded for New. Only the Ex vintage was modeled and uploaded, so CET couldn't generate Impact Profile IDs for New from data that didn't exist. This is expected behavior.

    New vintage permutations should instead reference the Ex vintage Impact Profile IDs directly.

    In eTRM, hard-code "Ex" into the electric impact profile formula for the New vintage permutations of SWWH014-09.

    Can everyone confirm they're aligned with Option 1 as the resolution here? Once we have consensus, we'll close the ticket.

    Thanks,

    Sonja

  • nfette

    •

    Aug 20

    My suggestion:

    • Option 1: You do not need a separate set of load shapes and impact profiles for New vintage. Rather, in eTRM, just hard-code “Ex” into the electric impact profile formula.

    • Option 2: If you have different permutations for New and Ex due to exclusions, then option 1 would fail to generate all needed permutations during validation. For this scenario, I would suggest using a script to create a copy of the “Ex” load shapes, replacing the vintage column with “New”. Solaris Technical team could share some examples of how we do this via a Python script, “clean_loadshapes.py”.

  • sepidehs

    •

    Aug 20

    The updated SWWH014-09 ticket says the CET run failed because an Impact Profile ID was missing when the base and measure case use the same load shape. Can you confirm the exact cause of the missing Impact Profile ID?

    Specifically, is CEDARS currently:

    1. skipping impact-profile generation when the baseline and measure load-shape IDs are identical;

    2. subtracting the two unitized load shapes before applying UECs; or

    3. generating the profile but failing to publish/map it to the avoided-cost combo/CET input?

    For same-load-shape cases where the baseline and measure UECs differ, the expected derived impact profile should equal the shared load shape:

    UECb​×Shape−UECm​×Shape=(UECb​−UECm​)×Shape

    and normalizing by delta UEC returns the same shape. Can CEDARS confirm that the fix will generate an Impact Profile ID and avoided-cost combo in this case?

    Separately, is the 0/0 condition limited to cases where the baseline and measure UECs are also equal, such as future load-shifting cases?

    Is CEDARS skipping the profile because the shape IDs match, or is the formula implementation treating identical unitized shapes as zero before applying UECs?

    • cedars team

      Team•

      Aug 25

      Hi @sepidehs,

      Digging into the exact mechanics of how Cedars handles identical load shapes with differing UECs (and the 0/0 edge case) deserves its own thread, so I've created a dedicated ticket for it: Confirm impact profile generation logic for identical load shapes


      This SWWH014-09 ticket will remain focused on the New vintage Impact Profile ID fix, with Option 1 (per Nicholas's comment) as the path forward, so I wanted to make sure your questions have a home and aren't lost when we close this one out.

      Could you please move any remaining questions to the new ticket so we can handle the details there?

      Thanks,

      Sonja