ZeroDivisionError: float division by zero in Python UWG code about uwg

[saeranv]

@canafarci the latent heat of evaporation is a constant, so it shouldn't be changing.

Can you provide the epw and input files you are using so I can try to reproduce it on my end?

[canafarci]

Of course,

EPW i have used is here, it is from Ankara, Turkey

and the scipt i have used is this, , on my end i receive the above mentioned error on day 87

[saeranv]

@canafarci

The problem does lie with the indoor_hum, but it's not because of the latent heat of evaporation which is in fact constant through everything. It's because the calculated latent impact of dehumidification gets larger at every timestep during the cooling season because the cooling airflow rate is maxed out. In turn, this is because:

1. The sensible cooling demand is larger then the cooling capacity of your hvac system
2. The sensible cooling demand is calculated for an indoor air temperature below the cooling supply air temperature.

(2) itself causes an interesting dynamic, where the calculated airflow rate is negative (since T_indoor is less than the supply air temperature), but the change in humidity is also negative (since 'indoor_hum' is less than the supply air humidity), so the dehumidification demand (airflow rate x density x latent heat of evaporation x delta humidity) is a large positive number, that dwarfs latent energy gains and so continually dries out the indoor air until it hits zero.

And the culprit behind the maxed out cooling demand is the schedules you're defining in your script for the cooling and heating setpoints:

    default_week = [[0.15] * 24] * 3
    
    schdef1 = SchDef(elec=default_week, gas=default_week, light=default_week,
                     occ=default_week, cool=default_week, heat=default_week,
                     swh=default_week, q_elec=18.9, q_gas=3.2, q_light=18.9,
                     n_occ=0.12, vent=0.0013, v_swh=0.2846, bldtype='midriseapartment',
                     builtera='new')

According to this, the cooling and heating setpoints are 0.15C. Both heating and cooling seasons thus attempt to mechanically condition the indoor air to an extremely low temperature. This isn't a problem during the heating season since UWG simply adds the appropriate (efficiency-adjusted) heat energy to the zone thermal balance and ignores any energy associated with dehumidification. But once the cooling season starts (day 87), the dehumidification demand is calculated and conflicts with the way the UWG models cooling via an HVAC air system. Basically, the UWG attempts to calculate a supply airflow rate that can meet the cooling demand, and incorporates the dehumidification energy into the evolution of the indoor humidity, which is why we eventually get the error with the psychrometric calculations.

On your end, you can fix this simply be fixing your setpoint temperatures (in Celsius) in your schedule. I realize this was likely copied from an example script I made, so fyi those values are dummy values for testing and aren't meant to represent real values. You can find real representative values in the DOE reference buildings include in UWG.

I'm also going to add some checks in the code to make sure this doesn't happen again. I've already a numerical range check to the setpoint schedules, but I think I'll also raise an exception if the indoor temperature ever goes below the supply air temperature during the cooling demand calculations, since that breaks UWG's assumption that mechanical cooling is only used when indoor temperatures are above the supply air temperature (i.e. below that you get negative airflow rates, and humidity ratios), and there are a bunch of user-exposed parameters in the cooling demand calculation that can cause this behaviour again. I can't think of a similar threshold to use for the heating season, even though a ~0C heating setpoint doesn't make sense, technically nothing breaks the underlying physics assumptions, so I'll leave it as is.

I also realize now that the indoor temp/humidity parameters in the building object aren't set with the getter/setter pattern, which is why the physically impossible condition of negative humidity didn't throw a setter exception, which is an easy fix.