@AbrahamYezioro ,
Thanks for testing and letting me know that the Weather Converter tool does not fix the issue as I had hoped. In light of this, let me lay out the issue, describe how we addressed it in legacy, explain why I think the legacy solution was not ideal, and propose some possible ways to address this in the new plugins.
What the issue is
Nearly all EnergyPlus simulations that we run from honeybee require design day information in order to size the heating/cooling system before the “real” simulation runs. While it’s possible to get away with not having sizing information in the case of a completely unconditioned model or for a model where fixed sizes are specified for all HVAC equipment, this really isn’t the best practice since there’s usually a chance that you want to autosize something further along in the design process.
How we addressed the issue in legacy
To get around this issue in legacy, I did something very implicit, which I have come to regret in hindsight because it involved me making some assumptions that I think even expert users like yourself might not be aware of. Most of the DDY files distributed by the DoE and OneBuilding are based on the same multi-year weather data set as the EPWs and are statistically derived from analysis of this whole data set. Typically they use percentiles where “only 1% or 0.4% of the time in the multi-year period is warmer than the conditions in the cooling design day,” for example. So, in the event that the legacy openstudio component found no design days in a DDY file, it would parse the EPW file and attempt to determine these percentiles from the 8760 values within the EPW file. Testing this method against the DDYs that were distributed by the DoE, I found that the temperature values of the design day could be off by a 1-4 degrees depending on how “unstable” the hottest and coldest hours of the TMY file were. But it was relatively close and it kept things quiet on the forums so I left it in place even though I knew I was making some assumptions here that I should make users aware of.
How we could address the issue in the new plugins
In the new plugins, I would like to at least make people aware of this assumption if it is applied. If I were to implement a solution exactly as it was in legacy, I think I would have the OpenStudio exporter component give a warning (orange component) if it tries to derive this sizing information from the EPW just to ensure that users are aware of the assumption being made here and the error associated with it. This way, they at least know that they might want to use a different weather data set that includes design day information if it’s available.
At the other extreme is a method that you can actually try out with the components you have right now, which is to make your own DDY file from Grasshopper. Under the Dragonfly “Alternative Weather” tab, there are components that let you create design days from a set of criteria you specify and then write these design day objects into a DDY that you can hook up to your energy simulation like so:
create_ddy_file.gh (31.0 KB)
While this method gives maximal control of the design day criteria and user-awareness of what’s going on, I realize this is a lot of work and requires some expertise about design days. So I have doubts as to whether any of our users except HVAC engineers who size systems for a living will be able to use this method to yield more accurate results than the simple automatic generation of the DDY based on the EPW values.
Yet another method in between these two extremes is just to introduce a component that takes the EPW file and spits out a DDY file with a cooling + heating design day that can be plugged into sizing information of the energy Simulation Parameters. This way, we can avoid all orange components but, because users will have to drag/drop these components on the canvas, they will at least be aware of what’s going on and they can read the component description to understand the assumptions that are made when deriving a DDY from EPW values.
Or I could do some combination of these methods. If you let me know your thoughts, @AbrahamYezioro , we can come to a decision about this and I’ll start implementing it.
