Measuring daysIn many cases, it would be interesting to learn how the movement of the sun across the sky looks like in a particular location. The software offers two different ways of accessing that information - a quick and easy solution that works mostly to get an impression, and a more detailed simulation.The quick and easy way works as follows: The orbital simulation moves the planet to a particular location, and the simulation rotates it there for a standard day (aka one rotation). This works as long as the length of the day is significantly shorter than the length of the year - if that is not the case, the standard day simply does not exist (the extreme case is a tidally locked world where the length of orbital and rotation period coincide - here the length of the day is infinite despite the finite time it takes for a sidereal rotation). The notion of a standard day is generally based on the sidereal rotation - for instance, the method will find the highest sun angle (aka noon) shifted by half a rotation period when half a year as elapsed - because the star is then opposite to a particular location on the surface. The general issue here is that is is not quite clear what measure of time should be used to plot the day - local (planetary) time will probably have timezones based on local noon, and so by definition the highest sun angle will always occur at local noon and never be shifted by half a rotation period. On the other hand, absolute simulation time is not in any sense a useful time measure for the planet, but the reference used for all configuration files. Thus the method described here provides information about the length of the day and the height of the sun angle but does not provide an absolute time reference for sunrise.
Helliconia daysInsert the following configuration file into the Helliconia definition:
The variable norm_daytime corresponds to fractions of a full rotation - a value of 1 means te rotation is completed. The variable sun_angle requests the elevation of the sun above the horizon. The keywords lat and lon allow to select a specific geographic location, and body companion selects the angle of Freyr (body star would select Batalix). The time of 260 days is chosen such that Freyr and Batalix are in opposition, and this is what the plot shows - when one star sets, the other rises:
Changing the orbital evolution time to 100 days and the latitude to 65.6 degrees (above the arctic circle) results in a sitution in which Freyr never sets and Freyr noon is about a quarter of a day different from Batalix noon.
Saving and resuming orbital statesRunning a lengthy orbital simulation to get day estimates for different location can be tedious in a case like Helliconia. Here, the keywords save_to and resume_from (both expecting a filename as argument) can be used. When save_to is used, the position and momentum of all bodies in the orbital simulation are written to file after the evolution has been carried out. If resume_from is used, an attept is been made to read the state from the specified file before the orbital evolution is run (so if an evolution time is specified, this is executed after whatever time has elapsed to create the saved state).The following example will evolve the system for 10.000 days and then write the result to file:
Note that saving and resuming does not work with fully thermal evolved states as these are significantly more complex.
Continue with Time series. Back to main index Back to science Back to worldbuilder Created by Thorsten Renk 2021 - see the disclaimer, privacy statement and contact information. |
