Dear Bogdan, while I was the one pointing out how important DeltaT would be, I never had the time to think and work through all of the code myself. Alex Wolf did most of the implementation. I will however try to answer your questions. Alex, please correct me if/where I am wrong.
A first note: this whole topic is pretty involved and DeltaT models are derived from an interplay of planetary and lunar ephemeris models and observations (mostly lunar occultations or historical solar eclipses), and try to describe Earth's slightly erratic rotation. As I understand, using one set of planetary models, like VSOP+ELP, requires a certain model of DeltaT, while applying the results from another model to a system using VSOP+ELP will require a slightly different model for DeltaT, i.e., using a "correction term". Such a term is given for adjusting the best available DeltaT estimates (Stephenson/Morrison) for use with VSOP/ELP in Espenak/Meeus, 5000 year Canon of Solar Eclipses, but the correction term is given without derivation, and without any hint on how to adjust other models. This means, most likely the other models currently implemented should be seen as experimental features and are most likely not in agreement with the orbital models they were originally derived from. But we have currently no proper information how to adjust them. (may even be an astronomical thesis work, or do you know the answer already, Alex?) More answers below... On Sa, 10.08.2013, 15:06, Bogdan Marinov wrote: > Hello to all, and especially to Georg Zotti. :) > > For my work on the time zone feature I'll have to do some work on the > delta-T feature. I need to understand it first, so I have several > questions about its current implementation. This e-mail is better read > with Stellarium's code open in Qt Creator, because Qt Creator allows > for fast lookup and jumping between methods. > > **None of this should be interpreted as an urgent need to change the > code - I'm asking for changes I'm going to make in my branch.** > >>From what I've read so far: Delta-T is handled in StelCore. The same > class keeps the current observer time as a Julian Date. In the old > version, that JD was in UTC. In the new version, StelCore::JDay is in > Terrestrial Time. Is this correct? This should be the case, and ... mmmh, it should be documented as such :-P As prime suggestion, if you go over the code to make it more readable etc, may I suggest that we use consistent variable names in order to avoid confusion. In my own programs, when I have to discern, I use "JDE" for "Julian Day, Ephemeris Time" [the old name for TT], or "JD" or sometimes "JD_UT" and even "JD_ZT" to make clear I mean UT or "Zone Time". But naming conventions in Stellarium are different, suggestions? Basically, all astronomical ephemeris calculation (positions of moving bodies in the solar system) I am aware of uses the continuously running TT scale, while UT may insert leap seconds. "Regular" time (UT or zone derivates) is only required for all things where sidereal time is used, e.g. to translate equatorial coordinates to horizontal coordinates. From what I have seen, however, satellite ephemerides are given in UT, apparently justified by the fact that orbital elements are changing so rapidly anyhow. > In the current implementation, the delta-T correction needs to be > applied to a JD before calling StelCore::setJDay(). There are cases in > which it is not applied, for example: > - In StelCore::init(), StelCore::setJDay() is used in the "preset sky > time" initialization case with no delta-T correction. > - In StelCore::setTodayTime(), which in turn is called by > StelCore::init() to provide the "time of day" initialization case. > I assume those cases have been overlooked or ignored. Uh oh, I never use the preset time feature, but it seems this is a bug. If I want to start with today's sky at 22:00 hours, this must mean zone time, not JDE. So the time should be corrected. > (There are also > a few cases that have been deliberately and correctly ignored - for > example, in StelCore::addSolarDays().) Not inadvertently ignored, this is a deliberate simplification which will hardly be noticed. A hypercorrect implementation would be: If (location is on earth) JDE->JD_UT, add X days, JD_UT->JDE else add X days end as long as day lengths given for the planets are to be understood on the JDE time frame. If X is not decades, we can likely ignore the difference. > Do I understand correctly that the delta-T correction is usually > applied only once, on setting the JD, and then the correction is no > longer updated? (Even though StelCore::JDay is updated in > StelCore::update() and it can be modified rather drastically without > using setJDay(), for example by StelCore::addSiderealYear().) Hmm, maybe the longer conversion would be better after all? DeltaT can currently grow around 1s/year or so (that famous leap second). > Do I understand correctly that while the internal time is in > Terrestrial Time, the date/times displayed to and set by the users are > not? (For example, ConfigurationDialog::setFixedDateTimeToCurrent() > removes delta-T before displaying the date/time; this happens again in > DateTimeDialog::setDateTime(), and a straight correction is applied in > DateTimeDialog:: ) Yes. Most users want to see on screen, and use, their watch times, i.e. zone times (with or without daylight saving time), but nobody should be bothered by the fact that this time is plagued with leap seconds which the planets don't care about. > Some of the delta-T corrections/reverse corrections are dependent on > whether the observer is on the Earth. Is this really necessary? (I > think it's not - time in Stellarium is always Earth time.) It's also > inconsistent, so it's possible to set a non-corrected JD value on one > planet, jump to another and then various functions will apply an > anti-correction. Is that so? Setting a time by the user should IMO always set UT or zone time, and of course JDE corrections should be applied "behind the curtain". Anything else would appear strange to me. > StelObject::getSideralPosGeometric() and getSideralPosApparent() use > getDeltaT() for something that looks like reverse correction - the > following expression is passed as a parameter: > -core->getLocalSideralTime()+dt , which is equivalent to > -(core->getLocalSiderealTime() - dt). Does this mean that this reverse > correction can be removed, if the underlying function > (StelCore::getLocalSiderealTime()) uses JD(UTC) instead of terrestrial > time? Yes. Sider*E*al positions (please, can you also correct the function names while fixing inconsistencies?) must be derived from UT. Actually, from hour angle, which is linked to UT and longitude. Hmm, speaking about observing from other planets, what would that really mean? Not my specific interest, but maybe we need another grid that shows hour angle/declination in the respective planet's coordinate system? > I'm a bit confused by StelCore::getIsTimeNow(). It uses getJDay(), > getting the system time and applying a delta-T correction. I think > there might be a mistake there, and I'm not sure about the logic of > the whole thing. Any pointers? seems correct to me. It tries to see whether current JDE is equal (within 1/4s) to a JD freshly computed from system time and adjusted by DeltaT. values are cached in static vars, recomputed only if necessary (max. every 1/4s?) > Do I understand correctly that, because of the typical small values of > deltaT, converting from terrestrial time back to UTC means computing > the deltaT for the JD(TT) as if it was a JD(UTC), and then > substracting it? Because this is how it's done for every reverse > correction at the moment. Yes, indeed. DeltaT is minutes, or hours at best, in historical times, so between the original and corrected times, DeltaT will not change significantly. Still, esp. for eclipses, this is a crucial correction. Of course, there may be situations where we will be catapulted out of a DeltaT model's valid range, and the backward-application will no longer work when found to be zero. But whoever leaves the default DeltaT model should be aware of that. (Or maybe we *should* add a note in the user doc?) > WHAT I'M GOING TO DO in my branch: > > The solution I'm thinking of is keeping two separate JD values in > StelCore - one for JD(UTC) and one for JD(TT), derived from the other > one. That may be a good idea as long as they are kept in-sync. Please use consistent names, see above. (suggestion: classical name JDE for the corrected term, JD or JDu (?) for UT-based, or even JD_ET, JD_UT to make that a very clear distinction?) > Delta-T correction will be applied in StelCore::setJDay(). (The other > alternative is to apply it at getJDay(), but it will be > computationally expensive and may cause problems.) > > There will be a way to set a JD(TT) directly, and a way to specify > whether one wants to get a JD(TT) or JD(UTC). This will remove the > need of reverse corrections. At the moment, I'm trying to decide how > exactly this should be implemented best (separate functions or a flag > or bool parameter, etc.). I think, setting should set both to stay consistent, and in a boolean flag you specify which flavour you are providing. That is, in a new setJD(double newJD, bool isJde=false), compute DeltaT and set JD_UT and JD_ET, and add a getJD(bool wantJde=false). Or even, leave out the default so the programmer really has to specify what he needs! > > Any questions, ideas or criticism? Thanks for caring about legibility and consistency! The dozens of ways time can be changed and adjusted, with differences if you are outside Earth, are not easy to comprehend. Kind regards, Georg ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
