Skip to main content

Allow users to reference load shapes in their CET input data instead of impact profiles

This would eliminate the need to pre-calculate impact profiles for every possible combination of load shapes in advance.

This would also allow dual baseline measures to use the correct impact profile for the early retirement phase and the above standard phase of their measure, instead of having to use one impact profile for both baselines as the CET works currently.

Select the module in CEDARS
Select user type
5 comments

Log in to comment and vote

Comments5

  • Lake Casco

    •

    Jul 28

    How I imagine the process to work. Load shapes are uploaded without the need to validate against an existing measure package because the load shapes would be able to be used across any measure package. This would remove much of the complexity with having to validate things like TechType and TechGroup, as well as requiring each version of the permutations to be synced between eTRM and CEDARS. The load shapes are measure package agnostic and validated for use only based on things like building type, climate zone, vintage, and HVAC type. Perhaps, pending load shapes can be tagged with a specific measure package while they are waiting for CPUC approval, though.

    When running the CET, CEDARS would take the specific UEC values from the CET input file and the load shapes and calculate the impacts directly in the run. This would remove the preprocessing requirements of the impact profiles that we currently have. Conceivably, this would increase CET run time, but it sounds like the CEDARS team has various means to speed up processing times on their side.

    One question that we would need to answer is how adopting load shapes would occur if they are of a different building type, climate zone, vintage, or HVAC type. Right now, those are concatenated into the impact profile; that may not be the case for the load shapes unless fields get added to the CET input that handle a concatenated load shape with those parameters, similar to the current impact profile.

    • nfette

      •

      Jul 30

      If I understand correctly, the idea is to skip some of the validation steps now happening during pre-processing, and switch to lazy validation as part of the CET run. So, validation feedback would be provided in the CET validation output file rather than in the load shapes upload file.

      Would this have implications for loadshapes approval via the measure package approval or other side effects from the pre-processing run that happens now? My understanding of the pre-processing outputs and side-effects are (1) validation that each loadshape matches a permutation in eTRM; (2) validation that each permutation in eTRM has a corresponding load shape; (3) store the data for load shape preview; and (4) compute the values for electric benefits lookup tables. However, I don’t have a clear picture of what happens following measure package approval. Would we still need validation that each load shape entry is “used” in a measure?

  • rachel.murray@dnv.com

    •

    Jul 27

    I’m sold! This is a lot closer to my original vision. I didn’t want to get in the way of the beeline to MVP, though.

    • nfette

      •

      Jul 30

      This is an interesting idea. I also had not imagined there would be a pre-processing validation step.

  • cedars team

    Team•

    Jul 27

    @rachel.murray@dnv.com and @Lake Casco please add any additional detail or context, and upvote if you’d like to be updated as this ticket progresses. Thanks