Hi Bogdan, did you do any work on these issues? The code related with deltaT is quite messy and I was about to do some cleanup when I remembered your email. Fabien
On Sun, Aug 11, 2013 at 8:25 PM, Georg Zotti <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
