Asteroids, comets, minor planets, and externally-defined bodies

[cosinekitty]

Just putting this out there to get feedback. What solar system bodies would you like to have added to Astronomy Engine? Prime candidates are:

• Major asteroids: Ceres, Pallas, Vesta, Juno.
• Famous comets.
• Dwarf planets in the outer solar system: Quaoar, Sedna, Haumea, Eris, etc.

Also, how important is it for you as a developer to be able to register arbitrary objects to be calculated by Astronomy Engine? There are two major interfaces I would consider adding:

1. Keplerian elements: You would provide 6 numeric parameters that define an elliptical orbit. Pro: keplerian elements are usually easy to find. Con: they pretend like orbits are ellipses, but they are inaccurate, especially over longer periods of time.
2. Initial state vector: You would provide the object's barycentric position vector and velocity vector at a specific moment in time. Astronomy Engine would simulate gravitational forces of the Sun and planets to extrapolate the trajectory of that object before or after that moment in time. Pro: much more accurate, and would even allow simulating interplanetary spacecraft. Con: would require lots of calculation in small time increments to make predictions.

[offsky]

I like the idea of being able to simulate spacecraft. Someone could make a supporting library of historical and current spacecraft data so you could quickly simulate whatever you want. What about satellites? It would be cool to be able to get the location of the ISS, Hubble, JWST, etc.

Since you are asking for feature requests? How about simulating Saturns largest moons, like you did with Jupiter? And Phobos 😄

[cosinekitty]

I agree, the spacecraft idea would be neat. As for Earth-orbiting satellites, take a look at Chris Peat's Heavens Above; if you have never used it, it is amazing. His database of satellites is huge. If I happen to be outside after sunset and see a satellite passing overhead, I will make note of its rough position and direction, and what time it is. Then I run inside, get on Heavens Above and I find out exactly what it was. Really cool.

Yes, it would be cool to add more moons. I will probably prioritize objects that can be seen with a small amateur telescope. Right now, Pluto is the only body I support that most amateurs are not equipped to see. I have seen Vesta, Uranus, and Neptune through my own telescope, but never Pluto (probably impossible with my 8-inch reflector).

I have never managed to spot Titan myself, but I'm sure other amateurs see that all the time.

I will also prioritize any body that a developer is actively trying to implement, if I can figure out how to do it well.

[offsky]

You should definitely be able to see Titan with an 8-inch scope. I have seen it with my 6inch. Maybe you just happen to look when its behind Saturn. I wonder if there is some library that could determine its position so we could know when and where to look...... 😜

[xeno-sama]

Just putting this out there to get feedback. What solar system bodies would you like to have added to Astronomy Engine? Prime candidates are:

• Major asteroids: Ceres, Pallas, Vesta, Juno.
• Famous comets.
• Dwarf planets in the outer solar system: Quaoar, Sedna, Haumea, Eris, etc.

Also, how important is it for you as a developer to be able to register arbitrary objects to be calculated by Astronomy Engine? There are two major interfaces I would consider adding:

1. Keplerian elements: You would provide 6 numeric parameters that define an elliptical orbit. Pro: keplerian elements are usually easy to find. Con: they pretend like orbits are ellipses, but they are inaccurate, especially over longer periods of time.
2. Initial state vector: You would provide the object's barycentric position vector and velocity vector at a specific moment in time. Astronomy Engine would simulate gravitational forces of the Sun and planets to extrapolate the trajectory of that object before or after that moment in time. Pro: much more accurate, and would even allow simulating interplanetary spacecraft. Con: would require lots of calculation in small time increments to make predictions.

I guess we need these options

if to think .. it should be not too long till times, when we would be able to rent - telescope on some Masks satellite )))
and we could see comets/asteroids/dwarf_planets - by using [cosinekitty]astronomy

[moab360]

Just putting this out there to get feedback. What solar system bodies would you like to have added to Astronomy Engine? Prime candidates are:

• Major asteroids: Ceres, Pallas, Vesta, Juno.
• Famous comets.
• Dwarf planets in the outer solar system: Quaoar, Sedna, Haumea, Eris, etc.

Also, how important is it for you as a developer to be able to register arbitrary objects to be calculated by Astronomy Engine? There are two major interfaces I would consider adding:

1. Keplerian elements: You would provide 6 numeric parameters that define an elliptical orbit. Pro: keplerian elements are usually easy to find. Con: they pretend like orbits are ellipses, but they are inaccurate, especially over longer periods of time.
2. Initial state vector: You would provide the object's barycentric position vector and velocity vector at a specific moment in time. Astronomy Engine would simulate gravitational forces of the Sun and planets to extrapolate the trajectory of that object before or after that moment in time. Pro: much more accurate, and would even allow simulating interplanetary spacecraft. Con: would require lots of calculation in small time increments to make predictions.

I was searching for a way to calculate rise and set times for a comet and came on this discussion thread. I think well known comets would be a great addition. I also think being able to add a comet or body with orbital data (similar to definestar but with necessary orbit data) would be cool, then we could calculate rise set times of arbitrary/newly discovered comets like C/2022 E3 (ZTF). Perhaps this is possible with the gravity simulator portion of the library?

[cosinekitty]

Yes, that is exactly what I had in mind for the gravity simulator. To make it work for a small body like a comet or asteroid, all you need are a position vector, a velocity vector, and the time at which they are both valid. Thus you need 7 numbers: (rx, ry, rz), (vx, vy, vz), and t. Collectively these 7 numbers make up a so-called state vector. You put the state vector into the gravity simulator and run it in time increments to make predictions.

Interestingly, the time increments can be positive or negative. That means you can run the simulation forward or backward in time.

Here are some things to be aware of regarding the time increment:

• If your time increment is too small, the simulation can use up a lot of CPU time.
• If your time increment is too large, accuracy will suffer.
• There is no simple answer to how small a time increment is small enough. It all depends on how close the body gets to the Sun or a planet.

Astronomy Engine internally uses gravity simulation to calculate Pluto, and this works very well because it is so far out in the solar system that I can use a time increment of 146 days. However, the time increment might need to be a few days, or even a fraction of a day, to get good accuracy in other cases. A really sophisticated generalized simulation would adjust the time increment dynamically based on varying proximity to larger bodies.

Other considerations:

• The movement of planets can be predicted accurately over thousands of years because gravitational forces are the only significant thing acting on their movement. But very low-mass bodies like asteroids and comets have additional significant forces acting on them.
• Asteroids and comets both experience sunlight pressure, a tiny but accumulating force of photons from the Sun reflecting off of them.
• Asteroids in the main belt between Mars and Jupiter are essentially in a swarm with very complex interactions among them.
• Comets passing into the inner solar system also have outgassing which can make their long term trajectories impossible to predict accurately. They essentially act like weak but random rockets!

The summary is, predicting comets and asteroids is best done using the most recent and accurate state vector you can find. Maintaining and updating state vectors for small bodies is outside the scope of Astronomy Engine. That is why Astronomy Engine does not include built-in support for comets and asteroids.

However, it is possible that JPL Horizons, NASA, ESA, or some other government agency can provide these data (I haven't tried to look yet). If you can find a good source of data for the comet, I will take a look and help you figure out how to adapt it to Astronomy Engine's gravity simulator.

[moab360]

Thanks! I've got the data from horizons. I think I'll do what you do for Pluto and store some estimated velocity vectors at checkpoints in the future and snap to the closest one.

What's the fastest/most efficient way to go from a gravity simulated state vector to an altitude above or below horizon for an observer? My goal at the end of the day is to show a comets altitude and rise and set times for the observer.

[cosinekitty]

That's great! Just make sure your vectors are all relative to the SSB (Solar System Barycenter); this is required because the gravity simulator needs an inertial, i.e. non-accelerating, frame of reference. Also make sure they are oriented with respect to the Earth's equator in the year 2000.

When you create the GravitySimulator, use the Earth as originBody. Then you will get geocentric vectors as output.

Once you have a geocentric position vector, you call ObserverVector with ofdate = false to find a vector from the center of the Earth to the desired observer at the given time. Subtract the observer vector from the geocentric vector to obtain a vector from the observer to the body. This is a topocentric vector.

Convert the topocentric vector to equatorial angular coordinates using EquatorFromVector. This will give you right ascension (RA) and declination (DEC).

Then call Horizon to find horizontal coordinates, which tells you the compass direction (azimuth) and angle above/below the horizon (altitude).

I strongly recommend you test to make sure your code is correct, and that your simulation step size is small enough, by simulating from one checkpoint forward to another checkpoint, and make sure the simulated result matches the subsequent known correct state from JPL Horizons.

I hope this helps!

[tylergannon]

Hi! I'm just arriving here, and feeling a bit late to the party, since the nodejs application I'm developing has already got a separate service I've written in Python using Skyfield. I'd like to migrate to Astronomy Engine when I get a chance, but I'll need to be able to calculate the positions of a few asteroids as well.

What would it take to add either one of the options you've mentioned? I wouldn't mind packaging my application with a small ephemeris for each additional body I add, to reduce the time difference between the query date and the initial state. I'd be happy with the Keplerian orbits method; superlative accuracy isn't an issue for me.

[cosinekitty]

Hi Tyler, and welcome to the project!

Do you already know which specific asteroids you are interested in? If so, you could use Astronomy Engine's gravity simulator to handle this. It's a matter of looking up each asteroid's position vector and velocity vector at a specific start time of your choosing. (This is straightforward using JPL Horizons; I can show you how.) Then you can simulate forwards or backwards in time to any other time.

The downside of the simulator is that it works only in fixed time increments from a given start time. There is no way to instantly calculate where an object is at a random time. You have to work your way toward that time in small time steps. It also requires experimentation to find a time step that is large enough to make it efficient, but small enough that you don't lose accuracy.

In fact, Astronomy Engine uses gravity simulation to calculate the orbit of Pluto. I have snapshots of Pluto's position and velocity vectors at many times for centuries in the past and future, so that decreases the overhead of random time jumps.

Currently I don't have support for Keplerian elliptical orbits because they don't meet my accuracy targets for Astronomy Engine. However, I'm not opposed to supporting them as a special case, but they do cause other problems. Every few years you will have to update your 6-element model as actual orbits drift away from the ideal ellipse shape. This is just a pain for multiple reasons. One problem is that you end up with an abrupt change in your calculations when you update the elements. It might not matter for your application though.

So if you are willing to talk a little more about your project and what its needs are, I'm sure we can work toward finding a good solution.

Also, I'm curious why you want to phase out Skyfield. Is it so you can have smaller code? (The reason I started Astronomy Engine was to have reasonably accurate calculations without hundreds of megabytes of ephemeris data coming along for the ride.)

[tylergannon]

Hi! Glad to be in touch!

I'm building an astrology app, not particularly scientific. I'm not particularly an astrologer, but my wife is studying and I seemed to notice that the available applications are somewhat poor and don't do much to promote awareness of what you're looking at when viewing a chart of planetary positions. So I thought I'd visualize an actual Earth-centric model of the Solar system, that will allow someone to actually see, e.g., what "opposition" means. Or what the nodes of the moon are, really.

I can't answer how or why I didn't notice your repo until now. I could swear I typed "ephemeris" into npmjs.com more than once, and looked at least halfway down the page.

At any rate, I'll want to transition off of Skyfield because this is a browser app that currently has to ask a remote server for each astronomical fact it needs.

Given what I'm doing, I imagine that using elliptical orbits would be easiest, though I think I understand that the method you're suggesting just requires basically optimizing the time parameter that scales the number of operations needed to accurately predict positions, as well as providing "known" position and velocity data for specific dates, to calibrate the calculation? I can probably manage that! Maybe I should just look at your code for Pluto, to see what you've done there.

Probably won't be able to really dive into this for at least a few days, so there's no complete urgency. I'll just drop the package into my app and start using it for the objects that it already provides.

Hope you have a good one!

[xeno-sama]

Hi! Glad to be in touch!

I'm building an astrology app, not particularly scientific. I'm not particularly an astrologer, but my wife is studying and I seemed to notice that the available applications are somewhat poor and don't do much to promote awareness of what you're looking at when viewing a chart of planetary positions. So I thought I'd visualize an actual Earth-centric model of the Solar system, that will allow someone to actually see, e.g., what "opposition" means. Or what the nodes of the moon are, really.

I can't answer how or why I didn't notice your repo until now. I could swear I typed "ephemeris" into npmjs.com more than once, and looked at least halfway down the page.

At any rate, I'll want to transition off of Skyfield because this is a browser app that currently has to ask a remote server for each astronomical fact it needs.

Given what I'm doing, I imagine that using elliptical orbits would be easiest, though I think I understand that the method you're suggesting just requires basically optimizing the time parameter that scales the number of operations needed to accurately predict positions, as well as providing "known" position and velocity data for specific dates, to calibrate the calculation? I can probably manage that! Maybe I should just look at your code for Pluto, to see what you've done there.

Probably won't be able to really dive into this for at least a few days, so there's no complete urgency. I'll just drop the package into my app and start using it for the objects that it already provides.

Hope you have a good one!

Skyfield very slow )

btw for astrology much easier choose swiss ephemeris as it already has hundreds objects needed for astrology

[tylergannon]

Yeah Swiss Ephemeris is written in C and has a substantial license fee, both of which aren't ideal for the way I'm building this. I've really enjoyed learning what I've needed to know in order to build the same objects using open source astronomy software.

[tylergannon]

@xeno-sama if you find Skyfield to be slow, I think it's likely due to a lack of a vector library (MKL, Apple Accelerate, BLAS/OpenBLAS) that's accessible to Skyfield. When all the math is happening in C/C++, performance is not a problem at all ; meanwhile I did find that it was unimpressive on a vanilla installation.

One thing Skyfield does which is pretty useful for a beginner, is to give all of its measurements in a Position object, which is more or less agnostic of a particular reference frame (well, it translates to ICRF but does so transparently). This allows the programmer to compare positions or transform to a given reference frame, without needing to track the frame that a given measurement came from.

[tylergannon]

@cosinekitty checking in on this before I get too deep into trying to implement my own asteroid position calculator: have you had any reflections on which direction you'd like to go, towards exposing an API that one could use for estimating body positions that aren't directly supported?

[tylergannon]

Hey that's pretty cool! Mine's a hobby project, too, or perhaps just a fun way for me to practice and learn some new technology. My wife is pretty into her weekend/evening occupation as an astrologer, so we can work together a bit via this project. Are you by chance tracking any asteroids? I'd install and play with it but I haven't got any android devices at the moment.

[cosinekitty]

One thing I'm curious of is why Pluto doesn't directly use the same Gravity Simulator class that's exposed by the API.

Oh, I'm happy to explain... First of all, the Pluto calculation was done first as a special case. The VSOP model I use for all the other planets does not include Pluto. I found that I could accurately simulate Pluto by calculating the gravitational forces acting on it from the Sun, Jupiter, Saturn, Uranus, and Neptune. The inner 4 planets are insignificant in their effects on Pluto, which saves time.

When I decided to add the generic gravity simulator, I left the original Pluto calculation as-is for efficiency, but made the generic simulator calculate forces from all 8 planets, since I wanted it to work reasonably well for objects that might pass into the inner solar system.

[tylergannon]

@cosinekitty that totally makes sense. While I didn't get a chance to fully interpret your Pluto calculation, I did make sense of the general fact that you went to some trouble to cache certain figures to avoid repetitive computation. Also, that's good thinking on your part to leave the inner planets out of the Pluto calculation, but allow them to have an effect on comets, etc.

That gives me a clue, as well, to the need for experimentation with each object, to determine the frequency needed for Update operations on the Gravity simulator. For the more eccentric orbits, one would want to update more frequently whenever there's a chance for a closer interaction with one of the larger planets.

[xeno-sama]

Hey that's pretty cool! Mine's a hobby project, too, or perhaps just a fun way for me to practice and learn some new technology. My wife is pretty into her weekend/evening occupation as an astrologer, so we can work together a bit via this project. Are you by chance tracking any asteroids? I'd install and play with it but I haven't got any android devices at the moment.

I see)
https://apps.apple.com/kg/app/astrodiary-dar/id1661471263

as for asteroids - i didn't try yet

[cosinekitty]

For the more eccentric orbits, one would want to update more frequently whenever there's a chance for a closer interaction with one of the larger planets.

Yes, that's right. I didn't attempt to figure out what the Δt value should be. I leave it up to the application to decide that. One thought I had would be to simulate for a given Δt, then rewind using the Swap method and try Δt/2 twice, and compare the results. If the results are significantly different (whatever that means), start over at the original time and try again with four iterations of Δt/4, and so on. Unfortunately, Swap won't work for more than one time step, so I will have to think about how best to save a "checkpoint" at a given simulation state.