Asteroids scripted extraction from MPCORB.DAT

[BobHegwood]

Downloads work fine now my friend.

Thanks for allowing us to get these things. Will let you know how it
goes as soon as I can get to viewing the asteroids later today (I
hope.)

Getting rather busy in my old age.

[abramson]

This looks very impressive. I'm looking forward
to one day being able to observe the relationship between these
triangular structures and the locations of lagrange points in my lagrange
addon.

It's beautifull, isn't it. The Hildas triangle has its vertices at Lagrangian
points L4 and L5 (the Trojans points) and L3 (the anti-Jupiter point). Each
Hilda asteroids visits all the Lagrangian points in succession. Their orbits
are elliptical, of course. The way in which the whole swarm appears
triangular still escapes me.

I was reading yesterday that the peuliarities of the Hilds distribution of
eccentricities seems to indicate that Jupiter migrated half an AU sunward
not very long ago.

I have to find that Lagrange add-on you mention. I don't remember it.

G.

[BobHegwood]

Again, just FYI...

Ran the Windows executable, and followed the command prompts
as instructed. I simply tried to extract only the asteroids with a radius
from between 300 and 500 km, and got about 7 different objects
listed in the output SSC file.

Looks like this will work out great, so thanks again for all of your
work here. The command prompt menus are very nice too.

I do think, however, that this setup will not be for everyone. This is
a somewhat complicated task for your average Joe.

Again, though very much appreciated. I simply cannot imagine how
much work went into this project. Way beyond my feeble brains at
any rate.

[abramson]

Thanks, Bob. I will be glad that anybody finds this tool useful. I wrote it
for myself after that thread about the full asteroids database in the
MotherLode, and then inflated it with instructions and readmes because
the Trojans and Hildas looked so cool!

I understand it requires some attention to use, but it's OK. I could have
written a full-fledged windows application with menues, checkboxes and
dropboxes, but I wanted to improve on my Perl, which is still rather
rudimentary. Also, it would have left the potential Linux users outside.

Guillermo

(The ACTUAL reason I wrote it was that, just after that thread, an asteroid
was named after the founder of my Institute, the physicist
[url=http://en.wikipedia.org/wiki/Jos?©_Antonio_Balseiro]Jos?© Balseiro[/url], and I wanted to convert its
MPC elements to Celestia format, to show it to my mates here. I
will try to photograph it later this year.)

[selden]

Guillermo,

Have you considered rewriting it in Lua?

[abramson]

Have you considered rewriting it in Lua?

That would be fantastic, should I know any Lua. In that manner, it could
be run from Celestia itself. Eventually, I or somebody else will surely do
it.

By the way, something I have just observed:

ASTEROID CLASS: MPCORB.DAT provides a class identifier for some
asteroid orbital families (Trojans, Atens, etc). I believe this identification
is incomplete. For example, the asteroids identified as "Other resonant
TNO" do not include a single Neptune trojan, which are not identified
otherwise. I really do not know what it identifies. Neptune trojans are in
the list, though, and can be extracted by their names.

I also do not find in that family any of the 1:2 or 2:5 resonant asteroids
listed on Wikipedia. I have browsed the list of extracted "Other resonant
TNO" and found one 3:4 resonant, one scatter disk (which have and
identifier of their own) and a bunch of other guys I do not know what
they are.

It is possible that there is no consensus about the orbital families of TNO
(besides few observations for some of these objects) and the MPC is
waiting.

Another example: 1996 TR66 is classified as a Centaur, and has a 2:1
resonant period with Neptune.

G

[Chuft-Captain]

This looks very impressive. I'm looking forward
to one day being able to observe the relationship between these
triangular structures and the locations of lagrange points in my lagrange
addon.

It's beautifull, isn't it. The Hildas triangle has its vertices at Lagrangian
points L4 and L5 (the Trojans points) and L3 (the anti-Jupiter point). Each
Hilda asteroids visits all the Lagrangian points in succession. Their orbits
are elliptical, of course. The way in which the whole swarm appears
triangular still escapes me.

I was reading yesterday that the peuliarities of the Hilds distribution of
eccentricities seems to indicate that Jupiter migrated half an AU sunward
not very long ago.

I have to find that Lagrange add-on you mention. I don't remember it.

G.

Very cool addon (and very easy to use Guillermo).
The only negative is that I experienced this...

I am getting an error message when running these rather big celx's:

Code: Select all

Timeout: script hasn't returned control to celestia (forgot to call wait()?)

Do you know how to overcome this? I tried with a wait() at the beginning of the scriot but it does not do the job. Vincent, perhaps you know...

I assume it doesn't affect the output and is just an annoyance, although it does appear that less objects are marked in my image, than in yours...strange, maybe it DID crash the script..


Here are the Hildas with Jupiter's L3,L4 and L5 points marked.

Click on the image to go to the Lagrange addon thread. The current download version has colored spheres as markers. The final version will have Invisible lagrange pints, but I haven't uploaded that version yet.

[abramson]

I assume it doesn't affect the output and is just
an annoyance, although it does appear that less objects are marked in
my image, than in yours...strange, maybe it DID crash the script..

Thanks, Chuft-Captain. It's possible that Celestia aborted the execution
of the script and didn't mark all the asteroids. You can edit the
markasteroids.celx file and add a few extra wait() commands every
hundreds markers to prevent the timeout. I will change it to every 500 in
the next update.

G

[Chuft-Captain]

I assume it doesn't affect the output and is just
an annoyance, although it does appear that less objects are marked in
my image, than in yours...strange, maybe it DID crash the script..

Thanks, Chuft-Captain. It's possible that Celestia aborted the execution
of the script and didn't mark all the asteroids. You can edit the
markasteroids.celx file and add a few extra wait() commands every
hundreds markers to prevent the timeout. I will change it to every 500 in
the next update.

G

Yep, I was going to do that anyway. The other thing I was going to do was make a copy, edit it, and call it unmarkasteroids.celx. (You might like to consider generating that at the same time as the markasteroids.celx, so we don't have to do this every time we change criteria.

Cheers
CC

PS. I ran it for a couple of hundred years and this happens:


I wonder what's going on here?... some inaccuacy of the orbits in Celestia over time perhaps???

[abramson]

The other thing I was going to do was make a
copy, edit it, and call it unmarkasteroids.celx. (You might like to
consider generating that at the same time as the markasteroids.celx, so
we don't have to do this every time we change criteria.

Excellent idea. I have added it.

G

[chris]

PS. I ran it for a couple of hundred years and this happens:


I wonder what's going on here?... some inaccuacy of the orbits in Celestia over time perhaps???

It's not Celestia. The Keplerian elements from mpcorb aren't accurate that far into the future because of perturbations by other bodies in the solar system (mostly Jupiter.) You need more sophisticated orbit model than a simple ellipse.

Wikipedia has a few interesting paragraphs about the dynamics of the Hilda family:
http://en.wikipedia.org/wiki/Hilda_asteroid

You can use JPL's HORIZONS system to integrate the orbit of an asteroid over a long time span and produce an xyz file for Celestia. This is probably impractical to do for every asteroid in the Hilda family, but you could do it for one of them.

--Chris

[selden]

I commented on this previously, but in case it was overlooked...

I am getting an error message when running these rather big celx's:

Code: Select all

Timeout: script hasn't returned control to celestia (forgot to call wait()?)

Do you know how to overcome this? I tried with a wait() at the beginning of the scriot but it does not do the job.

Celestia will forcibly terminate any script which runs for more than 5 seconds without letting Celestia update the screen. Celestia updates the screen during wait() calls. Long scripts must call wait() frequently -- or more often than every 5 seconds, anyhow. A script which has been terminated by Celestia will not have finished its calculations and its output will be incomplete.

[abramson]

Excuse my little knowledge of celx commands, but does anybody know if
it would be possible to show the orbits of specific asteroids using a .celx?
I could add that to the script, also. Too many asteroidal orbits are
useless, but a few could be interesting to see.

G

[Chuft-Captain]

Thanks Guillermo

The celx scripts are still crashing on me...(perhaps a wait() every 100 would fix it?) ... or perhaps my machine is just slow.

Trojans, Hildas and Atens:

[Nastytang]

Hey got it to work




Now I need to learn how to use it



HEE HEE there a lot of them

Nasty

[abramson]

The celx scripts are still crashing on
me...(perhaps a wait() every 100 would fix it?) ... or perhaps my
machine is just slow.

Something does not work as we expect. I also got the timeout when
trying to paint the zone I asteroids (they are too many, like 100
thousands, I admit). Neither waiting every 500, nor every 100, avoided
the timeout. And my machine is fast. Every 10 asteroids did the work,
but that is so slow, after all smaller lists worked with 1000 here. I
suspect that if the painting script is too long, Celestia itself may clog, and
incommunication ensues.

I don't know how to get out of this. Perhaps painting "one every so
many" when there are more than 10 thousand asteroids filtered. But that
will need either keeping the names in an array (probably a huge one for
smallish machines), or two passes of reading (slower but smaller). Either
way, I don't have the time now. This will be after my holidays .

Aren't the spehrical shells of Trojans, hovering over the shperical shells
making the verties of Hildas, so so nice?! I encourage everybody to
experiment with this, it's so cool.

Guillermo

[Chuft-Captain]

The celx scripts are still crashing on
me...(perhaps a wait() every 100 would fix it?) ... or perhaps my
machine is just slow.

Something does not work as we expect. I also got the timeout when
trying to paint the zone I asteroids (they are too many, like 100
thousands, I admit). Neither waiting every 500, nor every 100, avoided
the timeout. And my machine is fast. Every 10 asteroids did the work,
but that is so slow, after all smaller lists worked with 1000 here. I
suspect that if the painting script is too long, Celestia itself may clog, and
incommunication ensues.

I don't know how to get out of this. Perhaps painting "one every so
many" when there are more than 10 thousand asteroids filtered. But that
will need either keeping the names in an array (probably a huge one for
smallish machines), or two passes of reading (slower but smaller). Either
way, I don't have the time now. This will be after my holidays .

I managed to get it to work by putting a wait() after about every 130-140 objects. What version of Celestia are you using Guillermo? I'm using either PRE5 or PRE6 on WIN-XP, and this seems to work (as long as I remember not to pause time ).
I doubt that my machine's as powerful as yours.

Aren't the spehrical shells of Trojans, hovering over the shperical shells
making the verties of Hildas, so so nice?! I encourage everybody to
experiment with this, it's so cool.

Yes, I couldn't help wondering why the trojans tend to have such large inclinations compared with the Hildas.

It's also interesting to watch the way that some Hildas appear to "migrate" from one vertex of the triangle to another.

Can anyone explain the reasons behind these effects ?
[EDIT: Chris, I just noticed that you've already posted a link to a WIKI page about this, so I'm sure I'll find some answers there.]

Enjoy your holiday Guillermo.

[abramson]

What version of Celestia are you using
Guillermo?

I use the latest CVS and build myself on Win XP Pro with the free MS
C++ 2003, as taught by Cartrite (I believe) years ago. My machine is a
rather powerful Core 2 Duo, 2 GB RAM dual channelled on an Intel board
with a 1.3GHz bus.

It's also interesting to watch the way that some Hildas appear to
"migrate" from one vertex of the triangle to another.

Indeed, all of them do. Hildas are on a 3:2 resonsnce with Jupiter. They
visit the three vertices in succession. The Wikipedia article that Chris
mentined has interesting information, and point to scholarly articles
about the Hildas.

Enjoy your holiday Guillermo.

I sure will. Summer here has been nasty, we had snow 2 weeks ago,
and freezing temperatures. I'm running towards the tropic to store some
heat for the winter...

G

[abramson]

Hi, folks.

I have put up a new version of the script mpcorb2ssc. I was concerned
by the fact that some searches end up with still too many asteroids for
Celestia to work properly. For example, a search of the Flora family finds
nearly 50 thousand asteroids. With new tiny bodies being discovered all
the time, the situation will just worsen.

So, I wrote two "prunning" algorithms to be run whenever the search
finds more than 10000 asteroids. They offer to keep a user-chosen
fraction of the whole set:

1. Decimate at random.

2. Keep the firstmost asteroids of the list.

Random prunning samples uniformly the set, but since tiny bodies are
over-represented, you may end up with a Flora family catalog without,
ahem, Flora!

Firstmost asteroids is a proxy for keeping the biggest ones (since the
database is written chronologically). It is a sensible approximation, since
writting a true prunning by size routine would require much more effort.

After they run, both routines write corresponding ssc and celx files, with
self-explanatory names. It is advisable to keep just one set of the three,
of course, and delete or move out of Celestia's reach the others.

Other small changes have been made. Also, there are some changes in
the readme section (or file), concerning the possible use of ASTORB.DAT
instead of MPCORB.DAT, and of proper elements for better identification
of families. (Find families definitions here.)

The new version distributions (perl and executable) can be found at the
same place:

Mpcorb2ssc script

Mpcorb2ssc Windows executable

Regards,

Guillermo

[abramson]

UPDATE:

Now that Chris has implemented alternative names for Solar System objects in Celestia 1.6, I decided to update my MPCORB2SSC tool. In addition, I implemented a "true" prunning by size if the selected asteroids are too many (as opposed to the proxy that kept the first asteroids in the catalog). I think there are other small corrections as well (see the readme for a changelog).

Find it at my webpage. Direct links: perl sript, win executable.

Regards,

Guillermo