why is max. solar altitude not at midday

asked 2018-04-18 03:03:56 -0500

updated 2018-04-23 17:57:33 -0500

With reference to this earlier question https://unmethours.com/question/4885/... I have a simple EnergyPlus 8.9 model with

Building North Axis = 0
Output:Variable,*,Site Solar Hour Angle,hourly
Output:Variable,*,Site Solar Altitude Angle,hourly
Latitude -42 (south)

Why when the E+ CSV file is viewed with DView is the maximum solar altitude at 10:00 instead of midday 12:00? The Solar Hour Angle also passes through 0 degrees at 10:00. image description As a consequence the Direct Solar Radiation Rate is shifted to begin 05:00, finish 14:00 rather be centered over midday. I have tried a number of E+ US weather files in combination with a number of E+ examples & they all appear to have the same issue. This means sunshine is going to be biased towards morning facing surfaces & biased away from afternoon facing surfaces.

Thanks for any help.

24/4/2018 update After a day hacking away at DView C++ code I've finally gotten to the bottom of this hole I dug for myself. Some issues are my misunderstanding, but one is a bug in DView code. My main discoveries:

Although E+ creates a CSV file with its 1st column being a date/time every hour, DView completely ignores these values. DView ALWAYS starts its X axis at 1/1/0000 midnight with a 1 hour time increment. This is my misunderstanding. So if I have a CSV file for a single mid winter day, it won't have the correct date/ times on the X axis.
I believe there is a DView bug in which the 1st row from the E+ CSV is ignored. It reads (& discards) the date/time cell, but forgets the other cells on the 1st row. I have fixed this bug (it now reads the date but still ignores the time because E+ always works with a full 24 hour day) but it may cause problems for other use-cases. This explains a 1 hour timeshift on any DView graph.
E+ often has NULL (or empty) cells in its output CSV file. DView will display a messagebox for each & every NULL value. For an annual simulation that may mean 365+ message boxes. I've changed the code to only display the messagebox once, it now displays the line number, but then no further messageboxes.
the "debug" version of DView crashes if you close/ open other files, and at exit, but users of the "release" version will be blissfully unaware of dangling C++ pointers & other nasty stuff

Copy the text below into a CSV file using a plain ASCII editor like Notepad:

 Date/Time,col2,col3
 07/21  01:00:00,11,50
 07/21  02:00:00,12,51
 07/21  03:00:00,13,52
 07/21  04:00:00,14,53
 07/21  05:00:00,15,54
 07/21  06:00:00,16,55
 07/21  07:00:00,17,56
 07/21  08:00:00,18,57
 07/21  09:00:00,19 ...

(more)

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2018-04-18 11:21:52 -0500

Melissa B.
131 ●3

Andrew,

I'm not familiar with the inputs in E+. That said, what's your latitude? That may have something to do with it. So, if you're way far north (or east, or west), the "solar noon" may be different. Solar noon is (sunrise) - (sunset). So in winter, or peak summer, those numbers could be off rather than a straight-up 12 p.m.

Melissa

edit flag offensive delete link

add a comment

answered 2018-04-22 19:24:09 -0500

ANDREW HEARD
31 ●3

updated 2018-04-22 19:29:05 -0500

After many hours of debugging E+ code it turns out DView is the problem not E+. E+ generates the correct data but DView plots the maximum altitude at 10am instead of midday. A huge 2 hour offset. Extract of E+ CSV file below - the maximum is clearly at 12:00:

07/19 11:00:00,59.72341312759839

07/19 12:00:00,67.54636375727424

07/19 13:00:00,67.32938849937168

So why does DView plot it at 10AM? Annoying. Unfortunately to graph this data in Excel takes considerable extra manipulation because the timestamp in the first column is not valid (no year).

Is there any Windows program similar to DView that works better? Eg open CSV direct into the program & have a graph displayed without lots of extra setting up?

edit flag offensive delete link

Comments

Can you attach the E+ csv file here? If this is a bug with DView, it should definitely be fixed.

shorowit ( 2018-04-23 09:35:27 -0500 )edit

Probably not the right place to mention but first of all I must say only allowing one answer per user is a strange concept for a forum. It prevents any chronological context. I can't attach a CSV file in this comment, will next try to from my original post. There are very limited options when adding a comment, and a strict character limit means I can't even paste CSV rows as text below. But the DView issue, I'd dare say bug(s) is very easy to reproduce. Ooops - no characters left for this comment so will go back & update my original topic.

ANDREW HEARD ( 2018-04-23 17:35:14 -0500 )edit

add a comment

answered 2018-04-24 02:45:02 -0500

Joe Huang
2712 ●4 ●13

updated 2018-04-24 02:45:29 -0500

I don't want to get into the details of EnergyPlus or DView, but from a building physics and astronomical point of view, there are several reasons why solar noon is not simply 12 p.m.

The "Equation of Time" - because earth's orbit is not perfectly circular, its revolution around the sun varies depending on the time of year,which can cause up to 15 minutes difference between solar and clock time.
If the location is not at the Time Zone meridian, solar time will differ from clock time by 1 hour for every 15 degrees difference in longitude. Even if the Time Zone boundary is perfectly rational, i.e., +/- 7.5 degrees from the meridian, locations near the boundaries will be off by 30 minutes.

The other thing to take into consideration is that the sun position in EnergyPlus is calculated for the midpoint of the previous time step, since the solar irradiance is the total over the previous time step, NOT the average at the time stamp. For example, if Hour 1 is from 00:00 to 01:00, then the sun position is calculated for 00:30.

edit flag offensive delete link

Comments

Thanks Joe. Solar noon is 12:09 in our city. It was a simplification to say 12:00. But as discussed this is an E+ (or much more likely) DView issue, not an astronomical one. I can use a lat/lon of 0/0 in the E+ model to demonstrate the issue. I think it is best explained by the combination of DView ignoring the 1st data row (1 hour lost), and the E+ calculation midpoint (30 minute apparently lost) as your nicely describe in your last paragraph.

ANDREW HEARD ( 2018-04-24 04:49:46 -0500 )edit

add a comment