AWHP cooling logic #111

[urwahah]

per #111:

• added new awhp_sizing_priority input to choose load that drives AWHP sizing
• added logic to size AWHP for cooling or larger of heating and cooling
  • revised the AWHP_NUM_H variables to just AWHP_NUM since the same number is used for both. AWHP_NUM_C is still kept to track the units actually used in cooling, per below
• revised AWHP operation to allow simultaneous heating and cooling operation
  • heating is assumed to take priority. the available AWHP cooling capacity is calculated using the number of AWHP compressors not used to serve heating load in any given hour

[urwahah]

this section from the AWHP cooling phase had to be moved up to the AWHP heating phase for the sizing calculations

[t-kramer]

Thanks for working on this, @urwahah!

I had a quick look and found no major issues. I added some comments/questions. Please go through them if you have time. Below some more points from an AI reviewer. Might be worth checking them.

---

1. Potential NameError for sizing_priority == "larger" + sizing_mode == "fixed_num_units" (src/energy.py)

The "larger" branch only executes for integer_sizing_peak_load / fractional_sizing_peak_load. If a scenario somehow reaches the "Determine number of units" block with sizing_priority == "larger" and sizing_mode == "fixed_num_units", neither sizing_load nor cap_ref will have been set, crashing with a NameError. The UI disables the dropdown in this case, but there is no guard in the calculation code itself.

2. Division-by-zero in compressor allocation (src/energy.py ~Phase 5)

num_compressors_h = np.ceil(
    (df[Col.AWHP_HHW_W.value] / df[Col.AWHP_CAP_H_W.value]) * num_compressors
)

AWHP_CAP_H_W can be zero in hours where the unit has no capacity (e.g. extreme outdoor temperatures), producing NaN / Inf that propagates into num_compressors_c and awhp_num_c. The old code used an explicit mask for zero-heating hours.

3. num_compressors_c can go negative

If the heating load in an hour exceeds the unit's rated capacity (AWHP_HHW_W > AWHP_CAP_H_W), num_compressors_h > num_compressors, so num_compressors_c becomes negative. This silently produces negative cooling capacity and served cooling load.

4. _awhp_reference_capacity ignores its performance parameter for the actual lookup (src/energy.py)

The function accepts performance: PerformanceCurves, uses it only for the isinstance check, then re-fetches the same data via e.performance[load_type]. The parameter is redundant and the inconsistency is confusing — either use the passed-in object for the lookup too, or remove the parameter.

[t-kramer]

It looks like this assumption is central to the new simultaneous H+C logic and should be at minimum a named constant? Maybe even a configurable field on Equipment?

[t-kramer]

Can this be removed?

[t-kramer]

Could be not use_cooling

[t-kramer]

Can you check if this causes any problems downstream, e.g. export files that try to reference the old column names?