Negative numbers allowed for duct air film coefficient (dsExH)

[nathancoliver]

It appears that dsExH is able to take negative numbers as an input. More context can be found here.

I would expect that a negative dsExH would produce an error, since the CSE documentation states that only positive numbers can be used as inputs, but the simulation does not throw an error.

[chipbarnaby]

I think dsExH >= 0 should be allowed.

Step 1 is to review all uses to see if there is the possibility of divide-by-0. I ran one case with dsExH=0 with no problem but that is not conclusive.

Assuming 0 is safe: 1) change cnrecs.def type to FLOAT_GEZ; 2) change documentation.

[spahrenk]

There seem to be checks to prevent divide-by-zero for all uses of this value. The dsExH surface convective coefficient data member of a DUCTSEG object corresponds to the sb_hxa member variable of the SBCBASE class inherited by the DBC struct of the ds_sbc0 member variable in the corresponding instance of a DUCTSEG class. When not entered explicitly, sb_hxa is calculated based on the thermal conditions assumed at the exterior surface of the duct. sb_hxa appears in the sum

sb_hxtot = sb_hxa + sb_hxr; // frequently used sum

where sb_hxr is the surface radiative coefficient. This sum is used to evaluate the temperature at the exterior surface of the duct as a weighted average of ambient and radiant temperatures, as follows:

// adjacent environmental temp sb_txe = sb_hxtot > 0. ? (sb_txa*sb_hxa + sb_txr*sb_hxr) / sb_hxtot : 0.f;

The existing test sb_hxtot > 0. ? already prevents division by zero (though a temp of 0 °F would be applied if the condition were not met.)

I will commit a code change to enforce dsExH ≥ 0 (i.e., FLOAT_GEZ) and a document change specifying the legal range as x ≥ 0.