Weather files and DDY files

This section was taken from this topic.

For some of the weather files complains that no ddy file exists. As a result the simulation is not running.
The DDY exists, the thing is that it is not populated with usable data.

@chris answer was:

There’s no design days and so EnergyPlus cannot do the sizing calculation at the start of the simulation. The easiest way to solve the issue is to just use a location that has design days. If one is not available, then this post on unmethours notes how you can do this with the EnergyPlus Weather Converter Tool. If you have more questions about this, I recommend opening a separate topic.

The Weather tool doesn’t help on this one. It creates the same DDY as the downloaded ones.

I understand that the new [+] requires now this file, while the Legacy doesn’t. I’m trying to maintain the same work capabilities with [+]. The alternative of taking a close location and use it’s DDY is not so feasible since the climate conditions are different. This happens with all DOE files for my country, but one, which is weird.
Using the files solve the situation for me. All of them have a full set of data.

One funny thing that happens is that just openning the file for simulation the ModelToOSM component complains about this issue. But when i run a “good” location (ddy working) and get back to the “bad” one it runs fine and doesn’t complain about the missing ddy.

FYI only, since i’m not sure this can be solved with the new structure.


@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: (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.

Hi @chris,
Full explanation and now i understand the dilemmas.
I don’t really know how often in the whole world the DDY is missing or is not populated with the necessary data. For now i know that the DOE source files for my country provide just one right location. Saying that the OneBuilding source is fine. I didn’t check the differences for the same location but i can assume they are not really significant (i will check though). The solution i was thinking, before your above response, is copying the DDY from OneBuilding to the DOEs.
After your explanations and alternatives i think that the last option (creating a component to create the DDY) is the best. The reason is that users will be aware the original data is missing. Saying that, for most users the automatic DDY creation will be te preferable one. In such case i will also add the warning explaining what was done.
This 2 will cover, i think, both ends of the bridge: general users - more “experts” ones.

What do you think?

Thanks again,

Sounds good @AbrahamYezioro . I have opened an issue for adding the methods that generate the ddy from the epw and, once you see that issue closed, you should know that the grasshopper components should be soon to follow.

Now that I think about it, once I have that one method, it will be easy to support all 3 of the solutions that I mentioned. So the OpenStudio component will generate the DDY and turn orange if no design days are found but will not be orange if the user has generated the DDY themselves with the appropriate component and plugged it in to their simulation parameters. The assumption being that the user has checked to be sure the auto-generated DDYs make sense if they have plugged them in.

I’ll try to address this as soon as I get the chance.

1 Like

Hey @AbrahamYezioro ,

I have managed to get all 3 of the solutions implemented in the most recent version. You should be able to get the updated Grasshopper components with the “LB Versioner” component.

You can run the simulation to completion with any of the Israel EPWs but it will give you an orange component if you haven’t generated the DDY yourself. Here is how you can get the orange component to go away and also get a DDY file that you can import in order to understand the result of the auto-generation of the design days:

FYI, I read through the relevant pages in the ASHRAE Handbook of Fundamentals in order to make sure that I generated the .ddy as accurately as I could and I found that they have a really nice graphic that explains the error associated with only using one or a few years to generate DDYs instead of the usual 30 years used to make DDYs distributed with the EPWs:
You can see that my initial estimate of 1-4 degrees C error was pretty close to what ASHRAE found across several climates.

Hi @chris,
Great!!! This works so nice …
Glad you decided to put your efforts on this.

Many thanks!! Sure i’ll not be the only one thanking you.

1 Like