#486 Change "Time of day" options from sun angle to time.

[Anonymous]

Originally created by: gijsrooy
Originally owned by: gijsrooy

What steps will reproduce the problem?
1. Open the Environment > Time Settings dialog at KSFO.
2. Click all the pre-defined times (Noon, Afternoon etc.) and notice how the local/utc times change.
2. Now reposition yourself at EHAM and do the same trick. You'll notice that there is no difference in time between Noon and Afternoon (except for one minute).
3. At BIKF, there is no difference between Morning, Noon and Afternoon

What FlightGear version (or GIT date)?
Current FGdata and Jenkins build.

What operating system and graphics card?
Windows 7

The differences between various airports makes me wonder if it has something to do with Daylight Saving Time. In NL we switched to Winter-time two weeks ago (and I cannot remember seeing this bug before).

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

It is not related to daylight saving time. fgfs determines the time of day by calculating at what time a certain sun angle is reached - or at what time that angle is closest. For example, dawn means sun is at 90 degrees (at horizon), morning means 75 degrees (sun 15 degrees above horizon), noon means sun at 0 degrees (straight up), ...
However, depending on time of year and location, the sun never reaches the required positions. BIKF (Reykjavík) is beyond the arctic circle. At this time of year, the sun reaches a maximum of 10 degrees above their horizon - then starts to set again (poor guys!). Hence, by FlightGear definition, Reykjavík currently has no morning/noon/afternoon. And the closest approximation of the required sun angles is currently all the same...

The code calculating all this magic is in sunsolver.cxx (fgTimeSecondsUntilSunAngle). I'm not sure if this is a bug though - or just the way it is. I'm adding Durk here  - since he knows about calculating sun/moon/planet positions (so I've heard... somewhere... recently...). He may know things :).

Summary: "Time of day" depending on location, resulting in surprising results beyond the arctic circle
Cc: durkt...@gmail.com

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Summary: "Time of day" depending on location, resulting in surprising results in extremly Northern/Southern regions

[Anonymous]

Originally posted by: d...@flightgear.org

The sunsolver code was actually added after I wrote the basic astronomy and  time functions. Interestingly enought, in theory one could ask the code to perform impossible calculations. As and example, what happends when you select dawn, dusk, midnight, noon, while positioned at Scott-Amundsen base (yes we do have the runway in our database, and no we don't have decent scenery for it...). At this location, the sun only touches the horizon twice a year and for the remaining time, it remains either above or below the horizon. Right now, I don't have a clue how the sunsolver would handle calculating noon at this position in winter time when the sun is always below the horizon. Would it calculate it's highest point? Theoretically this should be possible, as long as your actual position is a little offset from -90 degree south. It's interesting to see how this would be done, but assuming that this is not a showstopping bug, I'm not immediately going to jump on to the bandwagon.

Nevertheless, it would be interesting to think about the extremes, if only to prepare for the day that we do have scenery for the Amundsen-Scott base. :-)

D.

[Anonymous]

Originally posted by: d...@flightgear.org

Okay, looking into it a little further, it appears that the problem is that for BIRK, the sunsolver wants to find the time when the sunangle equals -90 degrees (for morning), at a period of the year when even at noon the sun's angle doesn't even reach 90 degrees. But is that correct? Birk should still be below the arctic circle, meaning that even o December 21, it should still see some daylight. I'll have a look. 

[Anonymous]

Originally posted by: curtol... (code.google.com)@gmail.com

@ BIRK the sunsolver seems to work as designed.  It successfully finds the correct dawn and dusk times as well as the correct noon time.  Afternoon and Morning are defined by sun angle as mentioned in an earlier comment, so the closest the solver can get to these morning and afternoon constraints is noon when the sun is at it's highest position in the sky.

Also notice that the sun solver steps forward in 5 minute increments to reduce processing load, so it can be up to a couple minutes off the exact time.

I don't know how it behaves above the artic circle on Dec 21 -- Tromso Norway is the further north I've ever made it personally (ENTC) and they still get to see the sun a bit this time of year.

[Anonymous]

Originally posted by: gijsrooy

@Durk: I wouldn't call EHAM an "extreme" ;)
I can understand why it works like this for locations up north, but for EHAM...

[Anonymous]

Originally posted by: durkt... (code.google.com)@gmail.com

@Gijs, I think that the calculations are technically correct, and I think I can explain the weird results at BIRK: Morning and Afternoon are specified as a given sun angle, and it happens to be the case that around this time of year, that sun angle is even higher than the sun is able to reach, even at noon. So, that explains why morning and afternoon equate noon at BIRK.

I still don't have an idea where the 1 minute difference between noon and afternoon at EHAM comes from though. Currently, there's approx. a 2 hour period between dawn and morning, an additional 2 hour period between morning and noon, and approx 4 hours between noon and dusk (which boils down to an approx 8 hour daylight period, which is very consistent with real life). So, I would have expected another two hour difference between noon and afternoon, as well as an approximate 2 hour period between afternoon and dusk).

[Anonymous]

Originally posted by: gijsrooy

So, if it is correctly doing the current calculations, I'd vote for other calculations :)

When I, as an user, click "afternoon", I expect TIME to skip to afternoon-time. I don't expect the sun to move to a specific angle.

Changing this to feature request.

Summary: Change "Time of day" options from sun angle to time.
Labels: Type-FeatureRequest

[Anonymous]

Originally posted by: durkt... (code.google.com)@gmail.com

There is actually a slight anomaly in the code: Morning is defined as sun angle = 75 degrees (from zenith), while afternoon is defined as sun angle = 60 degrees from zenith. And this is probably what is causing trouble at EHAM. At mid winter solstice, the sun maximally extends approximatly 76 degrees from zenith (or in other words, rises only to about 14 degrees above the horizon at noon). The reason? We're at 52.5 degrees of latitude, and the earth's rotation axis is tilted by another 23.5 degrees.

Currently, in FlightGear, morning is defined as the sun angle being 75 degrees from zenith (or rising to approx 15 degrees above the horizon). Currently, we're still 1.5 months away from winter solstice, so the sun still climbs a few degrees more than the required 15 degrees above the horizon, so we can still compute a decent offset. Afternoon, however, is somewhat surprizingly, defined as 60 degrees from zenith, or 30 degrees above the horizon. At this time of year, there is no way the sun can climb this high, and therefore the functions just returns the max angle, which corresponds with noon.

Some additional comments: I think we should keep these functions relative to the sun's position. Typically, you would use this function to set specific ligthing conditions. If you want to define a specific time, I'd say use one of the specific time functions, like --start-date-gmt. With the possible exception of noon, which can be defined as 12 o clock local time, none of the other time parameters are defined in terms of a specific clock position, and are more closely related to the sun's position.

Secondly, in the short run, I think that we should equate the solar angle for morning and afternoon, unless Curt has an objection I would propose setting the afternoon sun angle to 75 degrees, just like the morning versions.

Thirdly, to avoid problems in the long run, I think that we should make the code relative, so that is first determines the local maximum and minimum positions and then defines the afternoon and morning positions as a proportion of the maximum sun angle.

  

[Anonymous]

Originally posted by: durkt... (code.google.com)@gmail.com

Just adding curt in the cc list.

Cc: curtol...@gmail.com

[Anonymous]

Originally posted by: curtol... (code.google.com)@gmail.com

Durk, no objection to equating morning sun angle with afternoon sun angle -- I don't recall the reason for setting it up like that originally.

Another idea would be to run through a 24 hour cycle and find sunrise, noon, and sunset and then define morning / afternoon as midpoints between these well defined angles.

That doesn't account for polar latitudes when the sun never crosses the horizon -- maybe that could be a step #2 for later.

[Anonymous]

Originally posted by: durkt... (code.google.com)@gmail.com

Curt, okay will do so. Re: The long term solution, I was indeed thinking about the same approach. With regard to computing the dawn/dusk values for the polar latitudes, there a few options: 1) If sun angle fails to reach 90 degrees, keep advancing the date until it does (in which case, dawn, dusk, and noon would coincide at the same time), or simply print a message stating that dawn is not possible at this location, for this time of the year.

Even though this would only affect a very limited number of airports, I do believe that it's good to come up with a better approach for the polar regions, because flying in (ant)arctic is really cool!

D.

[Anonymous]

Originally posted by: aeitsch...@yahoo.de

updated FG just right now and discovered that the local time is missing. :-(
On northern latitudes whenever I press noon, I get now evening instead.

Even when I'm in polar regions I expect to get 12:00AM when I press noon, independant of sun angle.