Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
Good times! When you say your models "give the expected output" with EnergyPlus alone, what exactly does that mean, regarding the daylighting? i.e., are you looking at the illuminance map data from the eplusout.sql file for those runs? Do they show daylight?
If you can post your model someplace (e.g. Dropbox) I'll take a look at it...
| | 2 | No.2 Revision |
Good times! When you say your models "give the expected output" with EnergyPlus alone, what exactly does that mean, regarding the daylighting? i.e., are you looking at the illuminance map data from the eplusout.sql file for those runs? Do they show daylight?
If you can post UPDATE (2017.10.16) Sorry for the delay, I just returned to the office from medical leave. I tried your simple model someplace (e.g. Dropbox) I'll take a look (linked in your first comment) with OS 2.3 and it worked fine. Since Results Viewer is no longer included with OpenStudio, I loaded the merged_space.ill file in Excel and looked at it...the Radiance daylight data there. It clearly shows reasonable daylight during daylit hours.
The data is presented as a matrix of data points (columns) and annual hours (rows). So the first four (summer) to eight (winter) columns will always read zero, right down the column. Does this make sense?
| | 3 | No.3 Revision |
Good times! When you say your models "give the expected output" with EnergyPlus alone, what exactly does that mean, regarding the daylighting? i.e., are you looking at the illuminance map data from the eplusout.sql file for those runs? Do they show daylight?
UPDATE (2017.10.16) Sorry for the delay, I just returned to the office from medical leave. I tried your simple model (linked in your first comment) with OS 2.3 and it worked fine. Since Results Viewer is no longer included with OpenStudio, I loaded the merged_space.ill file in Excel and looked at the Radiance daylight data there. It clearly shows reasonable daylight during daylit hours.
The data is presented as a matrix of data points (columns) and annual hours (rows). So the first four (summer) to eight (winter) columns will always read zero, right down the column. Does this make sense?
UPDATE (2017.10.24) Thanks for posting links to the stdout and stderr. It appears the measure is unhappy with the weather file:
gendaymtx: input weather tape format error
No Instance(s) Available.
...which leads to bad data output that is, unfortunately, poorly reported to you:
fatal - unexpected EOF in header
<stdin>: cannot load matrix
rmtxop: operation failed on '-'
No Instance(s) Available.
output\ts\WG0.ill: cannot load matrix
rmtxop: operation failed on 'output\ts\WG0.ill'
Please try this model with a standard weather file (i.e. one included with EnergyPlus) and if you could post a link to your Brussels wx file I'll take a look at that and try to see what the specific issue is. It appears the Radiance weather translator is pretty particular about format, and we can do a better job of letting the user know about it...
| | 4 | No.4 Revision |
Good times! When you say your models "give the expected output" with EnergyPlus alone, what exactly does that mean, regarding the daylighting? i.e., are you looking at the illuminance map data from the eplusout.sql file for those runs? Do they show daylight?
UPDATE (2017.10.16) Sorry for the delay, I just returned to the office from medical leave. I tried your simple model (linked in your first comment) with OS 2.3 and it worked fine. Since Results Viewer is no longer included with OpenStudio, I loaded the merged_space.ill file in Excel and looked at the Radiance daylight data there. It clearly shows reasonable daylight during daylit hours.
The data is presented as a matrix of data points (columns) and annual hours (rows). So the first four (summer) to eight (winter) columns will always read zero, right down the column. Does this make sense?
UPDATE (2017.10.24) Thanks for posting links to the stdout and stderr. It appears the measure is unhappy with the weather file:
gendaymtx: input weather tape format error
No Instance(s) Available.
...which leads to bad data output that is, unfortunately, poorly reported to you:
fatal - unexpected EOF in header
<stdin>: cannot load matrix
rmtxop: operation failed on '-'
No Instance(s) Available.
output\ts\WG0.ill: cannot load matrix
rmtxop: operation failed on 'output\ts\WG0.ill'
Please try this model with a standard weather file (i.e. one included with EnergyPlus) and if you could post a link to your Brussels wx file I'll take a look at that and try to see what the specific issue is. It appears the Radiance weather translator is pretty particular about format, and we can do a better job of letting the user know about it...
SOLVED (2017.10.25) Thanks again @Ward I, I think we got it. Your advisor's modified file had a few lines with a bunch of trailing commas in them -- most notably, the first line of the header which I'm betting is the only one the Radiance epw data translator really cares about. Specifically, Lines 1, 4, 5, and 7 all had a number of trailing commas, e.g.:
## BEL_Brussels.064510_IWEC_epw_correctedsnowfall.epw
LOCATION,BRUSSELS,-,BEL,IWEC Data,064510,50.9,4.53,1,58,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
## BEL_Brussels.064510_IWEC.epw
LOCATION,BRUSSELS,-,BEL,IWEC Data,064510,50.9,4.53,1.0,58.0
I removed the trailing commas from L1, L4-5 but left them in L7 (it's a comment line I suspect the Radiance translator skips anyway), applied the new weather file to your test model, and it ran fine. Please let me know if this works on your main model as well; I expect it will. I will enter an issue about this in the OpenStudio issues tracker. I doubt we will get the Radiance weather translator fixed anytime soon, but at least we can notify the user there was an issue with weather translation a little better than we are.
