Welcome to the CEDARS feedback portal

Using our feedback portal, you can:

  • Share feedback to help us improve CEDARS and the CET

  • Request new features

  • Submit bug reports

  • Ask questions not covered in the user guide

Use the modeled load shapes from one Measure Package for a non-modeled measure package

Background PG&E wants to reuse the Measure Case load shape from SWCR015 (Glassdoor-LED refrigerated cases) as both the Measure Case and Base Case load shape for SWCR018 (standard-efficiency → high-efficiency refrigerator/freezer replacement). Why SWCR015's ACC/load shape pair models "always-open case" (base) vs. "glass door installed" (measure) — a door-addition measure. SWCR018 is an efficiency-upgrade measure where both base and measure cases have doors; only unit efficiency changes. Applying SWCR015's shapes as-is to SWCR018 would incorrectly bake in the "doors vs. no doors" load shape difference, which doesn't reflect SWCR018's actual measure logic. Proposed workaround Set both the "Measure Tech ID" and "Standard Tech ID" fields in the eTRM permutation to the identical value (NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond), differing only in UEC. This was tested locally and confirmed to work — CEDARS generates the impact profile fine as long as a permutation exists with matching Tech IDs on both sides and differing UEC values. Confirmed technically CEDARS has no structural issue generating an impact profile where Measure Tech ID = Standard Tech ID, provided the permutation is synced from eTRM with that configuration and UECs differ. Resulting ACC/Impact Profile ID: GroExAny | NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond | NE-Ref_Storage-VertDisplay-Glassdoor-LED-AirCond Questions Precedent/policy question: Is reusing a measure-case load shape as both base and measure case an approach that should require sign-off from the broader load shapes group, given it's a workaround rather than a standard/intended use. Downstream clarity/misleading risk: When someone else (analyst, auditor, future CPUC reviewer) encounters an impact profile with identical Tech IDs on both the measure and base side, will they understand why? Scope/generalizability: Is this specific to SWCR018, or should we anticipate other measure packages with a similar "shape doesn't match base/measure logic" mismatch making the same request? If so, should we document a standard process/guidance for this pattern rather than a one-off answer?

cedars team about 6 hours ago

📨

Feedback

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.

sepidehs about 16 hours ago

💡

Feature Request