Extend Equipment and System Summary Tables - Air Heat Recovery, Air Terminals, and Fans#11138
Extend Equipment and System Summary Tables - Air Heat Recovery, Air Terminals, and Fans#11138
Conversation
|
|
|
|
@JasonGlazer Some examples of the new Air Heat Recovery Table columns. DOAToUnitarySystem OutdoorAirUnit |
|
@JasonGlazer Some examples of the new PIU Air Terminal columns PIUAuto - The PIU heating control type only applies with VariableSpeed fan. It's blank now for constant speed fan. Would you prefer "n/a"? 5ZoneAirCooledConvCoef_VSFan |
|
|
@JasonGlazer Some example for the new Fans columns. Fans/FanCoilAutoSize_MultiSpeedFan 5ZoneAirCooledConvCoef_VSFan For the PIU fans, Airloop Name is "N/A" - is that expected or a bug? |
|
|
|
A couple of samples of the new System Summary Report, Fan Operation subtable. 5ZoneAirCooledConvCoef_VSFan-Annual |
|
Generally, I prefer "n/a" over a blank since it means that it wasn't just overlooked but actively reported. |
Probably a bug.. |
Ok, "n/a" added, but the two PIU columns will be left blank for non-PIU terminal units. |
|
Here's an example of the air terminals subtable. |
Fixed here. |
|
| airLoopNum = state.dataSize->CurSysNum; | ||
| if (state.dataSize->CurSysNum > 0) { | ||
| airLoopNum = state.dataSize->CurSysNum; | ||
| } |
There was a problem hiding this comment.
I don't understand why this is needed. For this->fan, why is checking for CurSysNum > 0 necessary? If this fan is in the air loop, OA sys, or DOAS, then airloopNum > 0, otherwise it's 0. So what did you find that required this check?
There was a problem hiding this comment.
I don't understand why this is needed. For
this->fan, why is checking for CurSysNum > 0 necessary? If this fan is in the air loop, OA sys, or DOAS, then airloopNum > 0, otherwise it's 0. So what did you find that required this check?
Because the fan is in the PIU terminal unit, it gets simulated as zone equipment, so CurSysNum is 0 here for the PIU fans. But the terminal unit is ultimately connected to an airloop, so the check here avoids stomping on the fan's airLoopNum which is now set by the PIU terminal unit init. Maybe I should add a comment here?
There was a problem hiding this comment.
But the fan in the PIU will never see CurSysNum > 0, will it? Does it make sense for a zone equipment fan to know that information? The PIU unit knows what air loop it is attached to here (line 967). Maybe something similar to this for zone equiuipment?
int const AirLoopNum = state.dataZoneEquip->ZoneEquipConfig(thisPIU.CtrlZoneNum).InletNodeAirLoopNum(thisPIU.ctrlZoneInNodeIndex);
There was a problem hiding this comment.
OK, I see your point with "is now set by the PIU terminal unit type" although I don't see where that happens. I didn't realize parent equipment set that variable but that does make sense. So your check here is valid.
| thisPIU.AirLoopNum = state.dataZoneEquip->ZoneEquipConfig(thisPIU.CtrlZoneNum).InletNodeAirLoopNum(thisPIU.ctrlZoneInNodeIndex); | ||
| state.dataDefineEquipment->AirDistUnit(thisPIU.ADUNum).AirLoopNum = thisPIU.AirLoopNum; | ||
| // Set the airloopnum for the PIU fan | ||
| state.dataFans->fans(thisPIU.Fan_Index)->airLoopNum = thisPIU.AirLoopNum; |
There was a problem hiding this comment.
Ahh, right here. That's what "is now set" means.
|
@JasonGlazer This new table only reports for airloop systems, not for zone systems such as fancoils. Is that adequate?
|
|
|
It is probably adequate, but there might be some cases that I'm not thinking of. How difficult would it be to support zone systems like fancoils? |
Not sure, the current accumulations are done at the airloop level. It could be added to a zone level reporting struct. I'm going to merge this PR as-is and add a new item to the RPD task list. |
|
@rraustad Has looked at this previously. CI is happy, diffs as expected. Merging. |
Pull request overview
Pull Request Author
Reviewer