Electric panel (NEC calculations)

[joseph-robertson]

Pull Request Description

Support electric panel NEC calculations.

Related to: hpxmlwg/hpxml#420 and hpxmlwg/hpxml#435.

Checklist:

• Rename Watts under ServiceFeeder to something else; Power? Capacity? Decided on PowerRating.
• Move all system-prefixed arguments to panel-prefixed, so new electric_panel_xxx arguments section maps more directly to ElectricPanels HPXML section
• Make "Mech Vent" its own panel load type for ventilation fans (i.e., any load that can reference a system ID has its own load type)
• Create catchall argument for covering "Other" loads like garage door opener, garbage disposal, microwave (i.e., anything that doesn't reference a system ID)
• Separate arguments for controlling 83 and 87 outputs?
  • We may not want 87 for resstock -- can't we just ignore them?
• Comments/suggestions from Scott:
  • Meter-based total can change based on use of stochastic schedules and/or timestep.
  • Move HPXML class input capacity methods to HVAC resource file so they are only used for panel loads (and we can ignore fuel systems)
  • Separate results_panel.csv (unit reporting?) which is output from translator measure and then overwritten (with Meter-based) from reporting measure. See results_design_load_details.csv as an example.
  • Start discussion on adopting new extension elements: Subpanels, circuits, breakers/slots, smart features, etc on ElectricPanel hpxmlwg/hpxml#422 (comment)
  • Electric panel should be opt-in using new build measure argument for panel scenario types.
• Handle the new backup_heating_capacity input for HPWH; assume no simultaneous operation and so take max(heating_capacity, backup_heating_capacity)? Can the 120V HPWH have backup?
• Pool and permanent spa
  • There is no pump type arguments -- build measure defaults to Unknown; add new arguments? Update: we default based on a 2 HP pump capacity.
• Default watts based on input capacity and not output capacity
  • Divide output capacity by seasonal COP (e.g., SEER, HSPF) or by rated COP (e.g., additional_properties.heat_rated_cops, additional_properties.cool_rated_cops)?
  • For HeatingSystem, CoolingSystem, HeatPump: add heating_input_capacity, cooling_input_capacity, and backup_heating_input_capacity methods to hpxml.rb
  • For WaterHeatingSystem: add heating_input_capacity and backup_heating_input_capacity methods to hpxml.rb (additional_properties.cop set by Waterheater.set_heat_pump_cop)
• Get alternative/better defaults:
  • Replace regressions:
    • DX coil compressor power rating from rated capacity
      • Yingli is looking at correlation with EER2 (not strong); going back to using rated capacity as the input
      • will be updating the work plan with new equations
    • Air handler / wall furnace fan: fan_watts_per_cfm * xxx_airflow_cfm? Yes.
    • Pump: electric_auxiliary_energy / 2.08? Yes.
  • Clothes dryer
    • How to determine HP or not? Let's just use vented/ventless as the switch -- probably the best option at this point in time.
  • Mechanical ventilation:
    • Use count and fan_power? Yes.
    • Should local ventilation (i.e., kitchen and bath fans) really occupy at most 1 breaker space? Yes.
• The "2023 Existing Dwelling Meter-Based" meter-based calculation is really only valuable in evaluating upgrades. It should use the baseline peak electricity simulated output -- not the peak electricity for the upgraded building. We should expose a "existing peak electricity" argument, and store the value alongside the "2023 Existing Dwelling Meter-Based" calculation type in the HPXML header. The meter-based calculation can therefore be populated in the in.xml file alongside outputs for "2023 Existing Dwelling Load-Based".

Checklist

Not all may apply:

• Schematron validator (EPvalidator.xml) has been updated
• Sample files have been added/updated (openstudio tasks.rb update_hpxmls)
• Tests have been added/updated (e.g., HPXMLtoOpenStudio/tests/test*.rb and/or workflow/tests/test*.rb)
• Documentation has been updated
• Changelog has been updated
• openstudio tasks.rb update_measures has been run
• No unexpected changes to simulation results of sample files

[joseph-robertson]

A large question is how useful this is going to be for actual HPXML users. Based on entered information, will they get warnings? Will they get invalid outputs?

• BranchCircuits. Allow all of Total/Occupied/Headroom to be entered? If the numbers don't add up, provide warnings?
• What happens if, e.g., there is gas dryer and something else on a certain breaker? What happens in the outputs? Do we need the category breakout for Breaker Spaces?
• Should defaulting of ServiceFeeders be all or none? Are these really inputs that should be exposed? How does someone performing an NEC calculation determine, e.g., power rating values?
• How do we go from BranchCircuits to output categories? Need more error checking on, e.g., a component shared across multiple service feeders or branch circuits. Need more real-word example cases; preventing/warnings may be acceptable here.
• Are there entered power rating values which may make the NEC calculation invalid? E.g., lighting.
• Perhaps add more "real world" test cases/examples to the real_homes folder.
• BranchCircuits will only be created when doing NEC calc(s) (i.e., when ServiceFeeders are present). Otherwise, we'll assume that BranchCircuits is "complete" if any BranchCircuits are present (output will only contain breaker space information; we'll need to think about how to categorize Breaker Spaces).
• When doing NEC calc(s) and BranchCircuits are present, throw a warning that BranchCircuits is not empty (this can happen when the Build measure writes HP, WH, CD, etc. voltage). Otherwise, branch circuits (i.e., air handler) may be double counted.
• Kitchen (or laundry) service feeder can be greater than 3000 (or 1500), in increments of 1500; throw a warning if greater than 3000 and/or not a multiple of 1500.
• Lighting service feeder must be equal to 3 times CFA; throw a warning if it isn't.

[lixiliu]

A large question is how useful this is going to be for actual HPXML users. Based on entered information, will they get warnings? Will they get invalid outputs?

• BranchCircuits. Allow all of Total/Occupied/Headroom to be entered? If the numbers don't add up, provide warnings?
• What happens if, e.g., there is gas dryer and something else on a certain breaker? What happens in the outputs? Do we need the category breakout for Breaker Spaces?
• Should defaulting of ServiceFeeders be all or none? Are these really inputs that should be exposed? How does someone performing an NEC calculation determine, e.g., power rating values?

• BranchCircuits - good idea. Can we allow headroom to be negative, as this can be the case for some upgrade xmls for ResStock.
• The purpose of the breaker space breakout over large end uses is because this information is useful for analyzing the breaker space requirement of upgrade technologies and their wiring costs or the cost of alternative solution to make everything fit. Admittedly we don't have a good way to show that an appliance is on a shared circuit with other loads (Joe and I discussed and may have a solution forward on this). The breaker space requirement for most appliances is easy to back out except for HVAC. I do think we should have some kind of breakout so the users can back out how the breaker space allocation changes from the baseline to the upgrade. Is there a better way to break it out than by load type?
• See 220.83 table for categories of inputs. The main categories are lighting/receptacles, kitchen branch circuits, laundry branch circuits, heating, cooling, water heating, dryer, range/oven, and other connected loads. We are lumping lighting/receptacles/kitchen/laundry branch circuits as part of "others" because their values are straight-forward. We are breaking out the connected loads into more end uses so that a user may use this information to assess potential for circuit-pausing or circuit sharing. The HPXML schema description contains explanation of what values to use in the NEC. The power rating often comes from product labels and represent the power requirement at full operating condition.

[lixiliu]

It's difficult to make the schema perfect for the space and capacity calculations. I think the difficulty stems from two places:

[1] An NEC calculation cannot be done by someone taking a picture of their panel alone. While the panel has some essential information like the max current rating, open breaker spaces, and the number of laundry/kitchen circuits, the majority of the data needed come from the product stickers on individual appliances. So maybe it does make sense IN THE FUTURE to:

• allow the power rating information to be entered next to the input appliances/building systems and then autogenerate the ServiceFeeders object
  o If a user doesn’t enter in the power info, then default values are used.
  o This allows a mix of user input and default values (and could resolve the “all/none” requirement)
  o If BranchCircuits provided, use it to get the number of kitchen / laundry circuits (while maintaining that min 3 branches combined required)

[2] A person filling out the BranchCircuits schema would have solved any space problem simply by the process of filling it out, because of the need to balance the math between occupied, headroom, and rated total spaces

• Today, a person stubbing out a BranchCircuit object based on their current panel doesn't get answer to the question “does my panel have enough spaces to replace X with Y”. Instead, they would have to have the math worked out for the upgrade before they can even enter it into the BranchCircuits. And OS-HPXML simply validates whether or not the math checks out. This would be one use case for a HPXML user today. The BranchCircuits structure provides other benefits, like load control sims, but that's beyond the scope of this project.