In re-reading the previous post by la.epfl@xxxxxxxxx, I noticed that he/she spoke of a TimeHourOffset of -0.50, which may be what I was referring as a "SOLAR-OFFSET". If so, I stand corrected and apologize for any confusion. That's what I get from not paying close enough attention to EnergyPlus development.
However, back to la.epfl@xxxxxxxxx's question, if the TimeHourSet allows for adjusting the clock only for the solar calculations, that then opens up two ways to synchronize the solar radiation with the solar position calculation:
(1) input the solar from -1:00 - 0:00 and have a offset of -0.5
or (2) input the solar from -0:30 - +0:30 and have an offset of 0.0
Joe
Joe Huang White Box Technologies, Inc. 346 Rheem Blvd., Suite 205A Moraga CA 94556 yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx http://weather.whiteboxtechnologies.com for simulation-ready weather data (o) (925)388-0265 (c) (510)928-2683 "building energy simulations at your fingertips"
I don't think the time has been shifted by an hour, but it's just a difference in how hours are reported.
0:00 - 1:00 is the first hour == Hour 1
1:00 - 2:00 is the second hour == Hour 2
etc.
However, your question about the effect of the time offset on the solar calculations is very pertinent, and something that has been largely overlooked or ignored. As used in EnergyPlus, time offset means the difference in time from UTC (formerly called GMT or Greenwich Mean Time). This is only relevant when the raw weather data is reported in UTC. If you're using data recorded in local standard time, which is almost always true, you don't need to worry. However, you should worry about a different time offset which has to do with how the solar radiation is reported and the solar position calculated in simulation programs like EnergyPlus.
In North America, the convention is to do both over the preceding hour, i.e., the solar radiation on a TMY and IWEC weather file would be from -1:00 to 0:00, and the solar position calculated by EnergyPlus at -0:30 from the time stamp.
Outside of North America, i.e., Europe, Australia, Japan, etc., the convention is to do both from -0:30 to +0:30 of the hour, i.e., the solar radiation on a European weather file would be from -0:30 to +0:30 and the solar position calculated at 0:00.
Therefore, when one is using such a weather file with EnergyPlus, there will be a 30 minute mismatch between the solar radiation on the file and the sun position calculated by EnergyPlus. Now, some may think this is insignificant, but it will produce wierd results, especially at sunrise hours where there could be no solar when the sun is above the horizon and vice-versa, at sunset hours where there could be solar when the sun is entirely below the horizon. There can also be a noticeable dissymmetry in the solar on the east versus the west facade.
Therefore, I suggest that you determine the convention used in the raw data file that you have, and if it originated in Europe there's a very high probability that it's from -0:30 to +0:30 and not from -1:00 to 0:00. And if so, what can you do about it in your simulations? I've suggested to the EnergyPlus Development Team several years back that they add a new input variable for SOLAR-OFFSET, but I'm doubtful this was ever done. Until that happens, the easiest way to correct for this "Solar Offset" is simply to shift the building longitude west by 7.5 degrees.
As a final note on this matter to all users, I have only spot checks, but I'm quite certain that most if not all of the weather files on the EnergyPlus Weather web site of non-North American origin follow the second, i.e., non-North American, convention in reporting their solar radiation. Note that the main determinant is not the location, but the authorship of the weather file. IWEC and SWERA files were produced in the US and thus use the North American convention.
Joe
Joe Huang White Box Technologies, Inc. 346 Rheem Blvd., Suite 205A Moraga CA 94556 yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx http://weather.whiteboxtechnologies.com for simulation-ready weather data (o) (925)388-0265 (c) (510)928-2683 "building energy simulations at your fingertips"Hello,
I am having an issue with the weather file conversion. I am using collected data to create an .epw file for simulation. I put here a sample of the data I am using
CSV:
20/11/2015,00:00,13.300000000000001,84.0,5.0,8.0
20/11/2015,01:00,13.300000000000001,85.72274143302181,5.0,9.0
20/11/2015,02:00,13.800000000000001,82.0,5.0,8.0
20/11/2015,03:00,13.800000000000001,80.56357388316151,5.0,8.0
20/11/2015,04:00,13.699999999999999,86.0,5.0,8.0
20/11/2015,05:00,13.323364485981308,88.255451713395644,5.0,9.0
and the def file is:
&location
City=Lausanne
InLat=46.519
InLong=6.633
InTime=1
InElev=495
/
&wthdata
NumInHour=1
InputFileType='CUSTOM'
InFormat='DELIMITED'
DataElements=Date,HH:MM,Dry Bulb Temperature,Relative Humidity,Global Horizontal Radiation, total sky cover
DataUnits='dd/mm/yyyy','hh:mm','C','%','Wh/m2','tenths'
DataConversionFactors=1,1,1,1,1,1
DelimiterChar=','
DecimalSymbolChar='.'
/
&miscdata
Comments1='Standard EPW Custom def format for reading EnergyPlusCSV files in EnergyPlus Weather Converter'
SourceData='EnergyPlusCSV'
/
&datacontrol
NumRecordsToSkip=0
MissingWindDirAction=DEFAULT
MissingDataAction=DEFAULT
MissingOpaqueSkyCoverAction=DEFAULT
/
In the .epw file produced I have:
2015,11,20,1,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.3,10.7,84,95518,9999,9999,342,5,0,5,999900,999900,999900,99990,180,2.5,8,8,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,2,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.3,11.0,86,95518,9999,9999,350,5,0,5,999900,999900,999900,99990,180,2.5,9,9,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,3,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.8,10.8,82,95518,9999,9999,345,5,0,5,999900,999900,999900,99990,180,2.5,8,8,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,4,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.8,10.5,81,95518,9999,9999,345,5,0,5,999900,999900,999900,99990,180,2.5,8,8,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,5,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.7,11.4,86,95518,9999,9999,345,5,0,5,999900,999900,999900,99990,180,2.5,8,8,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,6,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,13.3,11.4,88,95518,9999,9999,351,5,0,5,999900,999900,999900,99990,180,2.5,9,9,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
2015,11,20,7,0,?9?9?9?9E0?9?9?9?9*9?9*9?9?9*9*9?9?9*9*_*9*9*9*9*9,12.7,11.3,91,95518,9999,9999,347,5,0,5,999900,999900,999900,99990,180,2.5,9,9,999.0,999,9,999999999,0,0.0000,0,88,999.000,999.0,99.0
So I notice that the time as been shifted by one hour.
Now, I can;t figure why this happens. I guess it could be timezone related, that is the program thinks I am inputing UTC time but I do not think so and I don't know if the sun calculations will be fine if I change the time offset. A related topic to this is actually if I should use the field TimeHourOffset set to -0.5 for the sun calculations or not. My data in the CSV is the average horizontal global radiation in the hour preceding the timestamp as required in the doc.
Best and thanks in advance,
__._,_.___
Posted by: Joe Huang <yjhuang@xxxxxxxxxxxxxxxxxxxxxxxx>
Primary EnergyPlus support is found at:
http://energyplus.helpserve.com or send a message to energyplus-support@xxxxxxxx
The primary EnergyPlus web site is found at:
http://www.energyplus.gov
The group web site is:
http://groups.yahoo.com/group/EnergyPlus_Support/
Attachments are currently allowed but be mindful that not everyone has a high speed connection. Limit attachments to small files.
EnergyPlus Documentation is searchable. Open EPlusMainMenu.pdf under the Documentation link and press the "search" button.
![]()
![Yahoo! Groups]()
__,_._,___