Skip to content

** VERSION 0.9.9.406R CHANGELOG **

(1) – Terminal 5 (Lunar Eclipses) has been simplified. As some contacts adopt the same equation (P1,P4 – U1,U4 – U2,U3) I removed their duplicates. In addition, now a closest to 0 value of the functions is to be found, that’s the easiest way to locate the time of a contact. It’s possible to choose if Center of Mass or Figure of the Moon is applied to geometry of the eclipse so the results can be compared with Espenak’s predictions (the best available around, in my opinion), using COM.


(2) – The Flag showing the geocentric radius of the Moon has been removed. I noticed that the slight distortion of the angular distances introduced by the stereographic projection is greater than this correction, so after looking for the approximate instant of a contact on the graphic map, the use of equations will still give the exact instant.


(3) – MAIN WINDOW : The controls that change manually Longitude and Latitude are now linked one another. Inrementing 23′ 59″ now cause an automatic passage to 24′ 00″ and so on. This has to be intensively tested because in particular situations some bug can appear.


(4) – Moon librations. Now Terminal 3 shows lunar geocentric and topocentric data about librations (optical + physical).


(5) – Sun Physical Data. Terminal 1 shows conventional physical data of the Sun, L0, B0, P.


(6) – UDC (User Defined Clock) LED doesn’t blink anymore. Now is simply ON or OFF.


(7) – Sun and Moon now show their respective rotation axis.


(8) – Code for Comets’ management is under test.

I would have liked to have been able to use the file generated by the JPL but strangely missing the information to estimate the magnitude of the comet (Absolute Magnitude and Slope parameter). So I chose the Minor Planet Center file (CometEls.txt). I noticed that it happens that for the same comet the two sources may report two slightly different orbits, which rarely leads the final result obtained by me to coincide perfectly with the ephemeris calculated by the Horizons system. Generally the difference is pretty small, about 3-5s in AR and a few arcseconds in declination, but it is there.

As an example we have :

Comet C2020 R4 (ATLAS) - 2021 06 15  12:00 TT (Elliptical orbit e = 0.9894)
 
 Uruk1 (Astrometric J2000 MPC data)
 AR = 10h 55m 15.061s
 DC = +18° 51’ 36.52”
 Mv = 17.79

 Horizons Platform (Astrometric J2000 JPL Data)
 AR = 10h 55m 20.97s
 DC = +18° 51’ 29.7”
 Mv = 17.679
 
 Injecting JPL Orbital Elements into URUK1 I obtain:
 
 Uruk1 (Astrometric J2000 JPL data)
 AR = 10h 55m 20.157s
 DC = 18° 51’ 31.95”
 Mv = 17.85

The residual is almost certainly due to the non-gravitational corrections applied by Horizons, which are ignored by me, but in this case the result would be much closer.

What can I say? I would certainly have preferred to use the JPL file but I don’t understand why they don’t publish values for the magnitude estimation.


(9) Input Date Window. Since I am quite lazy and often have to deal with comparison dates of different ephemerides, tired of always resetting minutes and seconds I have included the possibility to quickly enter the values 0h, 6h, 12h, 18h in the Input Date window. 🙂


(10) New files containing data about Asteroids and Comets (MPCORB.DAT and CometEls.txt) will be placed into the new folder USER_PATH/ExternalData, that will be automatically created at first run of the Application. The old files downloaded into USER_PATH can be deleted as they are no more used.


(11) Comets Window – Identifying comets can be a little bit tricky because of their names, so I added a Search function.

14 thoughts on “** VERSION 0.9.9.406R CHANGELOG **”

  1. Hi
    At 4:12:42 TDT, geocentric apparent RA and DE of the Moon are :
    INPOP19a (CALCEPH) 15 31 27.796 -19 19 40.466 (IMCCE MULTI-SAT)
    DE441 15 31 27.796 -19 19 40.467 (IMCCE MULTI-SAT)
    DE406 15 31 27.795 -19 19 40.465 (IMCCE MULTI-SAT)
    VSOP87 15 31 27.809 -19 19 40.507 (IMCCE MULTI-SAT)
    Regards

  2. Yep, that’s exactly what they are expected to do in dates closed to J2000. The differences will grow progressively with the passing of the centuries up to the limits declared for each ephemeris. Even a Russian ephemeris exists, EPM-ERA 2013, actually I don’t know if it’s available to public. The Authors (Yagudina, Vasiliev) state that is slightly worse than DE430 so it needs further improvements. What about a Chinese ephemeris?
    Regards

  3. Well, it looks like Chinese ephemerides exist too.
    Here’s the link: https://www.researchgate.net/publication/248627854_PMOE_planetarylunar_ephemeris_framework

    The PMOE planetary/lunar ephemeris framework was established in 2003, and has been improved in recent years. In the framework of the post-Newtonian effects, the figure perturbation effects arising from the a finite size of the Sun, Moon and the Earth, and the effect of the Earth tide were taken into account. The accuracy of using the PMOE ephemeris to predict the positions of the planets in the solar system are the same as that of JPL DE 405. Based on this framework, the orbit optimization for the LISA, ASTROD and ASTROD I missions, and the computation of celestial phenomena and lunar phases in the Xia Shang and Zhou period of ancient China have been completed.
    Regards

  4. Buongiorno.
    Nell’attesa di esaminare il gradito registro delle comete sulla prossima versione, mi viene un dubbio circa il grado di incertezza, prodotto in Uruk con Heywatsthat, per stimare correttamente l’altezza di un astro che sorge/tramonta sull’orizzonte fisico. Come sappiamo quando il punto di intersezione sul profilo dell’orizzonte fisico tra il sito di partenza e quello di arrivo supera una certa distanza (mediamente sopra i 10 Km.), l’errore di misura dell’altezza diventa sensibile a causa della forma del geoide terrestre. Mi chiedevo se per ridurre questo errore viene applicata una qualche correzione che tenga conto del suddetto problema.
    Grazie.

  5. Buongiorno a lei,
    mah, il problema in effetti è piuttosto articolato viste le variabili che sono in campo. La determinazione dell’altezza di un astro in prossimità dell’orizzonte depresso risente, oltre che dell’elevazione dell’osservatore, di fattori non facilmente determinabili a priori con precisione, quali pressione atmosferica, temperatura, umidità, quindi tutto questo già genera una inevitabile approssimazione della realtà. In aggiunta poi, sulla ricostruzione del profilo naturale rappresentato in genere da montagne, non posso esprimermi in quanto si tratta di dati esterni generati principalmente diversi anni fa da una mappatura radar effettuata dallo Space Shuttle e poi sottoposta a varie revisioni. Dalle prove fatte dal mio sito e di cui ho postato qualche risultato tempo fa la corrispondenza al reale si è rilevata piuttosto buona per l’uso a cui sono destinati questi dati. Sono pronto a scommettere però che non sempre possa venir generato un profilo orizzonte totalmente affidabile, e solo un riscontro sperimentale più ampio potrà accertarlo. Queste sono incognite che, a parer mio, si pongono su un ordine di grandezza ben superiore rispetto al modello di geoide considerato. La cosa importante da tenere in considerazione penso sia l’uso finale a cui sono destinati questi cosiddetti profili, che non è ovviamente di predire il sorgere di un astro al decimo di secondo, cosa di nessuna utilità pratica, ma di verificare la presenza di ostacoli che spostino l’apparire del Sole anche di 20-30 minuti o che spostino ad esempio il sorgere eliaco di un astro di diversi giorni. Se si ha la possibilità di fare verifiche sul posto tanto meglio. Un esempio per tutti: scarichiamo il profilo di Stonehenge e calcoliamo l’istante del sorgere del Sole al solstizio d’estate. Se fossimo sul posto ci accorgeremmo che proprio in corrispondenza dell’azimuth previsto c’è in lontananza una bella e fitta fila di alberi che ritarderà l’apparire del Sole di almeno una decina di minuti, ostacolo che sul profilo non c’era.

    cordialmente

  6. Buongiorno. Concordo con quanto sostiene circa la complessità del problema e le molte variabili che entrano in gioco. Io quando devo verificare il punto del sorgere e tramontare di un astro con il possibile allineamento di un sito, cerco di fotografare l’oggetto sincronizzando lo scatto
    con l’orologio radiocontrollato e confrontando poi Azimut e Altezza dell’astro con un software adeguato (Uruk ad es.). In un prossimo futuro, se lo riterrà opportuno, non sarebbe male se potesse presentarlo al convegno annuale dell’AlSSA (Associazione Ligure Sviluppo Studi Archoastronomici) di Genova. Cordiali saluti.

    1. Buongiorno,
      certo, controllare come fa Lei mi sembra giusto e doveroso. Poi, se le necessità lo giustificano, il profilo generato da Heywhatsthat altro non è che un file di testo zeppo di coppie Azimuth/Altezza che può essere modificato dove serve, facendosi carico di fare di persona dei rilievi. Per il resto penso che nel prossimo futuro si navigherà ancora a vista, questa pandemia continua a condizionare molti eventi trasformandoli in videoconferenze multiple (per fortuna). Staremo a vedere.

      La saluto.

  7. Hmmm…… Vanbuitenen’s copy of the MPC file reports a MPEC 2021-L04 revision for C/2020 R4 orbit and the epoch of elements is 20210611. Last MPC file published today refers to a MPEC 2021-BE3 revision, with epoch at 20210614, that is today. I have a strong suspicion about what’s happening, so next week I’ll do the same queries on all the platforms. 🙂

    1. Yep, considering that I don’t apply A1,A2,A3 corrections for non-gravitational perturbations that’s the result with the current MPC file. Is this orbit newer than the others? Let’s see what happens next days with other platforms.

      regards

Leave a Reply

Your email address will not be published. Required fields are marked *