Hi @chris
It seems there is a bug in the dragonfly component “create EPW”. The created EPW have global horizontal radiation values looking like illuminance values in lux :
It seems to be because of this line in the code :
I don’t know how the wea function works but the createEPW function assigns an illuminance value to a radiation value.
Do you know how I can fix this ?
Hi @VincentLugherini ,
That line of code that you pointed out is correct. Wea’s always store data in irradiance (W/m2) and not illuminance (lux). And, when you have an hourly format like EPW, the solar irradiance (W/m2) is essentially the same thing as solar radiation (Wh/m2).
I am guessing that you got an EPW like this by plugging in some really high values to the _direct_normal_rad_ and _diffuse_horiz_rad_ inputs of the Dragonfly “Create EPW” component:
Can you verify that what you plugged in here is actually radiation/irradiance and not illuminance?
Ah, wait. there is a bug. It’s just on a different line:
That should be glogbal_horizonal_illuminance on that last line. Let me push a fix now.
Fix has been merged:
You should be able to get it with the LB Versioner in ~20 minutes.
Thanks a lot ! It does work properly now. I will now be able to simulate heat waves summer now.
I have something like 20 values of global_horizontal_rad that are negative values (-14 for the lowest, all hapening at the begining of the day), but it doesn’t seem to be a problem for EP. I guess it replaces them by 0 if needed.
One more thing, if anyone reads this, make sure to plug into the component create EPW a “base_EPW”, as it might help solve problems of dates of the year (I had a 31st of june in my created EPW until I plugged a base_EPW into it).
Cheers
