Fix issues with electrical panel upgrade cost assignment and add unit test #577
Conversation
jtlangevin
commented
Jan 15, 2026
jtlangevin
commented
- Correct issues identified in Issues with electrical panel upgrade cost assignment #575.
- Add a unit test that ensures panel upgrade costs are properly assessed in accordance with user settings (Unit test for panel upgrade cost adjustment #569).
- Ensure that shares of homes requiring a panel upgrade are actually assessed when that option is provided. - Remove any dependencies of cost data pre-incentives on subsequent incentive calculations. - Handle primary/secondary keys for fuel type when pulling in panel upgrade shares data. - Ensure that linked cooling equipment costs are properly assigned when processing a panel upgrade subsegment/technology name.
The unit test ensures that settings for panel upgrade share calculations are correctly read in and translated through the fill_mkts function to the measure's output data.
| and (self.technology_type == "demand" or ( | ||
| self.technology_type != "demand" and not all([( | ||
| (x in y) or ("all" in y)) for x, y in zip([ | ||
| "heating", "single family home", "existing"], |
There was a problem hiding this comment.
Why are only heating upgrade technologies considered when allocating panel upgrade cost shares? Secondary heating, cooling, water heating, cooking, and drying may also trigger the need for a panel upgrade. In Line 4076 , secondary heating and cooling are already included in the panel upgrade determination. I suggest including secondary heating, cooling, water heating, cooking, and drying for there and Line 4076 at this stage. As future work, we can determine the relative contribution of each technology to the need for a panel upgrade. ResStock can now directly predict whether a home requires a panel upgrade, and this capability can be leveraged here.
There was a problem hiding this comment.
Thanks @yingli-NREL. For simplicity we assume that heating upgrades are the end use that triggers a panel upgrade, and therefore assign costs to heating end use segments in a measure. In making these calculations, we create 3 sub-segments of the original heating segments (panel, no panel, no panel w mgmt). What you see on line 4076 w/ secondary heating and cooling ensures that any segments from these end uses that are linked with the original heating segment for the purposes of stock turnover calculations will remain linked to those new sub-segment copies for heating.
Ideally we would be able to package together the end uses you mention and determine which of them actually triggers the upgrade, but the structure to do so doesn't exist in Scout, which does not have a concept of how segments are bundled or related per home. In the underlying work, they did consider these multiple end use upgrades to predict whether a given home requires a panel upgrade. But there was no indication of which end use in those packages actually triggered the upgrade. So we are taking those data and assigning any upgrade costs to heating measures, which is likely going to be the lion's share of the reason for the panel upgrade need when compared to other end use load requirements.
| user_master_mseg | ||
| ) | ||
|
|
||
| def test_elec_upgrade_costs(self): |
There was a problem hiding this comment.
A general comments for the test. Add clearer documentation of expected cost calculations at the beginning of the code funtion. For example,
Expected costs breakdown:
Base ASHP cost: $14,000
Panel replacement cost: $1,500
Panel management cost: $500
Scenario 1 (ignore): $14,000 (no panel cost)
Scenario 2 (all): $14,000 + $1,500 = $15,500
Scenario 3 (shares): $14,000 + (0.8 * $1,500 + 0.1 * $500) = $14,000 + $1,250
I think the unit tests should focus on verifying the core functionality of the code. For example, ensuring that panel upgrade costs are correctly added or excluded, base equipment costs remain unchanged. If we want to use specific data as test inputs, I suggest storing that data in a separate data file (e.g., a pickle file). We can discuss the overall testing structure further, as this is also related to the ongoing ecm_prep_test refactor work.
There was a problem hiding this comment.
Good suggestion on the documentation. I added this in the notes for the test_elec_upgrade_costs function in the tests (see commit). It doesn't reference the specific numbers, but rather the relevant variables in the tests, to avoid a case where numbers are changed later.
Agree about the focus of the unit test, I think we can handle the structure you propose via the other PR.
2 participants
