In IBPSA.BoundaryConditions.WeatherData.ReaderTMY3, if a user specifies dry bulb temperature and relative humidity as inputs to the model, then the dew point temperature will still be the one from the weather data file. Hence, results can be inconsistent because the dew point temperature depends on dry bulb temperature and relative humidity.
The underlying reason is that the TMY3 data specifies all three variables, but only two are independent.
As a fix, it probably would be best to disable specification of TDewPoi by an input or parameter, and overwrite the value from the weather data file whenever a user prescribes TDryBul or relHum. Using TDryBul or relHum, rather than TDewPoi, as an input has also the advantage that any combination of TDryBul or 0 <= relHum <= 1 is always well defined.
Sounds good. An alternative would be to add asserts that checks invalid combinations. That way the user is better informed of the internal workings/overrides, which would now be happening without notice.
In
IBPSA.BoundaryConditions.WeatherData.ReaderTMY3
, if a user specifies dry bulb temperature and relative humidity as inputs to the model, then the dew point temperature will still be the one from the weather data file. Hence, results can be inconsistent because the dew point temperature depends on dry bulb temperature and relative humidity.The underlying reason is that the TMY3 data specifies all three variables, but only two are independent.
As a fix, it probably would be best to disable specification of
TDewPoi
by an input or parameter, and overwrite the value from the weather data file whenever a user prescribesTDryBul
orrelHum
. UsingTDryBul
orrelHum
, rather thanTDewPoi
, as an input has also the advantage that any combination ofTDryBul
or0 <= relHum <= 1
is always well defined.