Programma per l'integrazione numerica delle orbite degli asteroidi
Ultimo aggiornamento: 3 Maggio 2004
Traduzione in lingua italiana di Giuliano Pinto
Scopo di questo programma: I dati che vengono usati correntemente per gli elementi orbitali degli asteroidi sono quelli contenuti nei file MPCORB del Minor Planet Center e ASTORB del Lowell Observatory . Questi dati forniscono gli elementi orbitali per una particolare epoca standard. Tale epoca può differire anche di 100 giorni dalla data attuale.
Non è una differenza molto grande, tuttavia significa che, se si calcola la posizione di un asteroide "in questo momento", usando il semplice metodo dei due corpi, si verranno a trascurare fino a 100 giorni di perturbazioni. Per oggetti della fascia principale, tale approssimazione comporta in genere errori dell'ordine di un secondo d'arco. Invece, per oggetti vicini alla Terra, che sono passati vicino a noi recentemente, l'approssimazione può comportare errori di alcuni minuti d'arco o anche di qualche grado. Inoltre, se si vuole conoscere dove l'asteroide si trovava, diciamo, cinquanta anni fa (nella speranza di localizzarlo su qualche vecchia lastra), ci si trova completamente fuori strada. Infatti gli elementi orbitali forniti sono del tutto inutilizzabili.
Una soluzione può essere allora quella di usare un programma che effettui, a richiesta, l'integrazione numerica dell'orbita. Ho considerato l'idea di scrivere io stesso un programma di questo genere, e forse lo farò in seguito... ma il risultato non sarebbe privo di inconvenienti in termini di velocità e facilità d'uso. Sarebbe comunque utile poter integrare un gran numero di elementi per una certa epoca, e tenere i risultati a disposizione.
Nel mio programma commerciale ("Guide"), ho adottato la soluzione di prendere i dati del "Lowell Observatory" e inserirli nel mio programma di integrazione, generando così elementi orbitali a intervalli di 200 giorni e coprendo un periodo di alcuni decenni. Quando si chiedono gli elementi orbitali di un asteroide per una certa data e ora, il programma valuterà quale gruppo di elementi è più "vicino" a quella certa data e ora. E' questa una soluzione comoda, tranne che per il fatto che in tal modo vengono generati file di enormi dimensioni (anche se vengono memorizzati in forma binaria). Con il numero attuale di asteroidi conosciuti, mi sono ritrovato a memorizzare circa 200 MByte di dati orbitali compressi su un CD. Poiché il numero di asteroidi conosciuti tende a crescere, dovrei ridurre l'arco di tempo considerato, oppure togliere qualcosa dal CD. E comunque gli utenti potranno utilizzare soltanto i dati disponibili al momento in cui sono stati realizzati i CD.
Pertanto, ho pensato di fornire il programma di utilità gratuito INTEGRAT, di cui rendo anche disponibile il codice sorgente. Tale programma è in grado di leggere un file nel formato MPCORB.DAT, e restituisce poi un file relativo ad un'epoca specificata dall'utente.
Uso di questo programma: Per prima cosa, occorre fare clic qui per scaricare il programma (circa 152 KByte). Va costruita poi una cartella per il programma nella quale decomprimere il file compresso (.ZIP), e infine si può avviare INTEGRAT.EXE da una finestra DOS. Facendo così, senza argomenti sulla riga di comando, si ottiene questa schermata (in inglese):
INTEGRAT takes as command-line arguments the name of an input file of the MPCORB.DAT type; the name of the output file that is to be created; and the epoch of that output file, as either a JD or in YYYYMMDD form. For example, either: integrat mpcorb.dat 2452600.mpc 2452600.5 integrat mpcorb.dat 2452600.mpc 20021122 would read in the 'mpcorb.dat' file, and create a new file updated to the epoch JD 2452600.5 = 22 Nov 2002. One can also specify the date as "today", or "today+7" (i.e., this day next week) or "today-30" (a month ago).
La traduzione italiana di questa schermata è la seguente:
INTEGRAT prende come argomenti sulla riga di comando: il nome di un file in ingresso del tipo MPCORB.DAT; poi il nome del file in uscita, che è quello che verrà generato; e infine l'epoca del file in uscita, o nella forma di Giorno Giuliano oppure nella forma AAAAMMGG. Per esempio, una di queste due righe di comando: integrat mpcorb.dat 2452600.mpc 2452600.5 integrat mpcorb.dat 2452600.mpc 20021122 leggerà il file 'mpcorb.dat' come file in ingresso, e genererà in uscita un nuovo file aggiornato all'epoca GG 2452600.5 = 22 Nov 2002. Si può anche specificare come data "today" (cioè "oggi"), oppure "today+7" (cioè tra una settimana esatta), o anche "today-30" (un mese fa).
A questo punto, è possibile sostituire questo nuovo file 2452600.mpc al posto di quello originario MPCORB.DAT in molti programmi di simulazione planetaria (incluso il mio Guide) e fare così in modo che il programma utilizzi gli elementi orbitali aggiornati all'epoca prescelta.
Una avvertenza: effettuare questa integrazione numerica può richiedere parecchio tempo. Durante lo svolgimento del programma, viene visualizzato il tempo trascorso (in secondi) e il tempo stimato ancora richiesto per completare il calcolo. Se si vuole soltanto usare il file attuale MPCORB e aggiornarlo alla data corrente (cioè effettuare una integrazione su circa cento giorni o anche meno), basteranno circa 15 minuti su un sistema a 500-MHz. Il tempo di calcolo richiesto è proporzionale all'arco di tempo considerato: se si intende effettuare una integrazione numerica all'indietro nel tempo di alcuni decenni, occorrerà una intera nottata di calcolo.
Se si procede ad integrare uno degli altri file del tipo mpcorb, come, per esempio, nea.dat, questo problema praticamente non sussiste, poiché gli altri file contengono solo una piccola parte delle orbite contenute in mpcorb.dat.
Il tempo di calcolo è anche proporzionale al numero di asteroidi presenti nel file in ingresso. Lasciando solo qualche dozzina di asteroidi (come, per esempio, nel caso di nea.dat), i tempi di calcolo saranno del tutto ragionevoli, anche nel caso di un arco temporale molto lungo. (In tali casi, la maggior parte del tempo di calcolo è impiegato per valutare inizialmente le posizioni planetarie; usando le Effemeridi JPL si velocizza notevolmente il processo).
Codice sorgente in C/C++: Nel file compresso INTEGRAT.ZIP sono già presenti integrat.cpp e integrat.mak. Occorre però avere anche la libreria delle funzioni astronomiche fondamentali e il codice sorgente delle effemeridi JPL per poter poi compilare il codice completo e farlo funzionare.
Uso delle effemeridi JPL per le posizioni planetarie: Come impostazione predefinita, INTEGRAT calcola le posizioni della Luna e dei pianeti, usando una versione semplificata del metodo VSOP87. Questa approssimazione comporta errori molto piccoli, normalmente trascurabili. Il maggiore inconveniente, però, consiste nel fatto che, se si vogliono integrare orbite relative a date molto remote nel passato o nel futuro, vi è una lunga pausa, quando il programma inizia, mentre vengono calcolate tutte le posizioni richieste per coprire l'arco temporale scelto.
Per entrambe queste ragioni, può essere utile passare dal VSOP alle effemeridi JPL. Per far questo, occorre procurarsi i file JPL DE; tali file possono essere scaricati da Internet, o copiati dal secondo CD-ROM di Guide 8.0, oppure anche comprati su CD-ROM dalla Willmann-Bell. Tutte queste opzioni sono discusse sulle pagine Web collegate.
Una volta che si sia ottenuto un file DE, occorre "dire" al programma INTEGRAT di usarlo, mediante l'opzione '-f'. Per esempio, il comando:
integrat mpcorb.dat 2452600.mpc 2452600.5 -fd:\unix.405
dirà a INTEGRAT di usare il file DE d:\unix.405 come sorgente per le effemeridi.
Metodi usati in questo programma: Nella maggior parte dei casi, INTEGRAT usa il metodo Runge-Kutta-Fehlberg a passo fisso. L'uso del passo fisso ha il vantaggio di consentire al programma di preparare una tabella delle posizioni planetarie una volta per tutte, piuttosto che consumare tempo di calcolo per ricalcolare le posizioni per ogni passo. E' anche usato il metodo di Encke: invece di integrare l'orbita "direttamente", viene calcolata soltanto la differenza tra il moto reale e quello ellittico basato su un sistema a due corpi. Questo fatto comporta un notevole aumento di complessità del programma, ma significa che sarà possibile usare una ampiezza del passo molto maggiore.
Con l'uso del metodo RKF si ottiene una grossolana stima dell'errore ad ogni passo. Se l'errore stimato è grande (in genere, questo significa che l'asteroide si è avvicinato molto a un pianeta), il programma potrà calcolare un passo più piccolo e riprovare con tale valore. (Talvolta, può capitare che anche un passo di ampiezza minore porta ad un errore eccessivo, nel qual caso il programma dovrà ripetere il calcolo con un passo di ampiezza ancora più piccola). Alla fine, si sarà risolto il "problema del passo". Se tutto va bene, la fase successiva non darà problemi e il programma può ritornare ad usare la sua tabella pre-calcolata delle posizioni planetarie. In ogni caso, le tolleranze sull'errore e l'ampiezza del passo sono state impostate in modo tale che il "problema del passo" non dovrebbe verificarsi molto spesso. (Quando si verificano dei problemi, il programma è in grado di gestirli autonomamente... soltanto il procedimento sarà più lento rispetto al caso di passi "normali").
In aggiunta al metodo RKF, menzionato sopra, potrebbe essere utile al programma l'uso di un metodo multipasso (come il metodo Gauss-Jackson). Supponiamo di dover gestire un caso che richieda i dati ottenuti da quattro precedenti passi; in tal caso, potremo usare il metodo RKF per generare i quattro passi, poi passeremo invece ad usare il metodo Gauss-Jackson. Di tanto in tanto, il metodo Gauss-Jackson può portare ad errori eccessivi; in tali casi, il passo sarà preso con il metodo RKF. Tutto questo ci porta a concludere che verrà usato il metodo Gauss-Jackson la maggior parte delle volte (e l'elaborazione sarà molto più veloce), ma è importante ricordare che, se l'asteroide si avvicina molto a un pianeta e si nota una crescita degli errori, si potrà passare a un metodo che garantisca una certa accuratezza.
Aggiornamenti: (3 Maggio 2004) Recentemente si sono avuti problemi con le orbite di oggetti NEA (Near Earth Asteroids, Asteroidi che si avvicinano alla Terra) fornite nel formato mpcorb sul sito dell'MPC e su siti speculari FTP. In particolare, nel file neatod.dat, che dovrebbe contenere orbite di oggetti NEA, riferite all'epoca odierna, sono risultati mancanti alcuni oggetti recenti.
Per aggirare il problema, alcuni hanno scaricato il file nea.dat, con la sua epoca che può essere un centinaio di giorni lontana dall'oggi, e hanno effettuato l'integrazione numerica portando le orbite all'epoca odierna, generando così un proprio file neatod.dat. Per esempio:
integrat nea.dat neatod.dat 20040503
Ho voluto allora semplificare questo procedimento, facendo in modo che il programma integrat fosse in grado di interpretare l'unico argomento "today" (cioè "oggi") sulla riga di comando, come se si dicesse al programma "integra il file nea.dat fino all'epoca corrispondente ad oggi e salva il risultato nel file neato.dat". In questo modo, basta semplicemente digitare
integrat today
per ottenere il risultato desiderato. Inoltre, è anche possibile usare l'argomento "today" invece di digitare l'epoca espressa in Giorni Giuliani o nel formato AAAAMMGG, oppure è anche possibile usare espressioni come "today-7" (giorni) o "today-30" per avere un file con gli elementi riferiti a una settimana o a un mese fa.
Infine, integrat aggiunge ora alcune righe all'intestazione del file in uscita, menzionando il fatto che il file è stato ottenuto mediante integrazione numerica, a partire da una certa data fino a un'altra data specificata, e inoltre riporta la data della versione di integrat. Non è molto, ma questo significa che se si è dimenticato da dove proviene un certo file in formato mpcorb, oppure con quali operazioni è stato ottenuto, basterà leggere l'intestazione del file stesso. (Forse sono soltanto io la persona che potrebbe averne bisogno!)
(6 Febbraio 2004) Ho aggiornato il programma in risposta a una domanda da parte di Cristovao Jacques. Questa nuova versione si comporta meglio per quanto riguarda le perturbazioni causate dagli asteroidi. Precedentemente, integrat assumeva che il primo, il secondo e il quarto asteroide, contenuti nel file mpcorb.dat, fossero (1) Cerere, (2) Pallade e (4) Vesta, gli agenti perturbatori considerati durante l'integrazione numerica delle orbite. In effetti, se si usa il "normale" file mpcorb.dat, questo è vero; però, i file contenenti gli oggetti NEO o altri oggetti, forniti dall'MPC, come pure i file in formato mpcorb.dat, generati dalla opzione Monte Carlo del programma Find_Orb, non contengono questi tre asteroidi. In questa nuova versione aggiornata, integrat controlla gli effettivi nomi degli oggetti, anziché fare erronee assunzioni basate solo sulla posizione degli oggetti all'interno di un file.
Futuro/miglioramenti previsti: Il principale inconveniente di questo programma è costituito dal fatto che esso non ha una interfaccia utente molto amichevole. Penso che mi dedicherò a questo aspetto, prima di fare ogni altra modifica.
Dopo aver reso più "amichevole" il programma, con una piacevole interfaccia Windows, penso di lavorare per aggiungere un metodo di integrazione multipasso. Questo non causerà alcuna differenza per quanto riguarda l'operatività del programma o la sua accuratezza, ma renderà la velocità di calcolo molto più spedita (almeno lo spero).