Inconsistency of Model runs between downloaded and local file location for EPW files

ladybug-tools
1

I am pretty sure I am not doing something that is very simple. But I cannot fathom what.

I have attached two new weather files - a standard TMY3 from NIWA in New Zealand from 2024, and a DSY file for overheating analyses.

I have attached them because I cannot get analyses to run if I point to these files on disk. The standard download a zip file from the Internet works for both a London Gatwick and a New Zealand location, but not for load a file from the local disk TRULY STRANGE.

I am keen to figure out how to use these new format files because as of last year we have available TMY3 plus morphed, 2030, 2050 and 2080 year “typical” to combine with DSY typical as well as the morphed versions…

I cannot fathom why these are not working, and apparently no error is thrown even when I load the E+ in.idf from the LBT folders!

tmy3_nz_wn.zip (623.7 KB)
TM59-NiwaFiles.zip (1.3 MB)
TMY3_NZ_WN.epw (1.4 MB)
DSY1_NZ_WN.epw (1.5 MB)

A curious turn of events - always learning…

I have tried loading a simple, sample, shoebox file and it runs without a hitch from the downloaded epw, but not from the local file location.
FAIL:

image
image1977×1320 220 KB

SUCCESS
image
image2284×1551 320 KB

DIFFERENCE:

image
image1389×403 38.7 KB

I have set things up so the lower section of the load EPW is from local file (including generate a ddy from the ddy data in the epw file) OR from the internet download option in the upper section. All that needs to happen is that the relay on the right (highlight blue) is connected internally to the download or to the local file source.

This appears to be working:
Local file at relay:
image

Download at relay
image

I have tested this by uploading files into the shoebox energy sample file
EnergySample.gh (87.2 KB)

2

Hey @MichaelDonn ,

The DDY files that you have next to your local EPWs don’t have the expected data in them. So the simulation fails because it has no design days:

image
image2347×1036 189 KB

If you delete the DDYs that you have next to the EPWs, then the component will generate the design days from the EPW data instead.

Or you could just explicitly do this in your Grasshopper script:

image
image2074×1147 269 KB

1 Like
3

Thank you.

I had been writing those ddy files to the directory where the epw was sourced, but that did not appear to solve the problem, so i was looking for other explanations. Oddly, the component was not warning me about the lack of a ddy for sizing, so was looking for something else.

M

4

Hey @MichaelDonn ,

I realized that I could make a change to the “Model To OSM” component to get it to still run for this case that it does not pull any of the design days from the DDY file adjacent to the EPW file. I made the change here:

And, now, you will just get a warning when this happens:

image
image1579×637 56.6 KB

I also owe you an explanation for why the design days from your manually-written DDYs are not being read by the Model To OSM component, which is that we are looking for very specific types of design days when we process DDYs that are next to the EPW files, which your manually-written DDY did not have. So I recommend following the format used by the DDY files on OneBuilding or the DOE website if you are looking to place DDY files next to your EPW files.

1 Like