https://dahlend.github.io/ketev/#t=2026-10-28.9204&sel=2026%...
1,359 karma · joined September 4, 2024
https://github.com/dahlend/kete
Previously worked in quantum computing in both hardware (transmons) and writing compilers.
https://dahlend.github.io/ketev/#t=2026-10-28.9204&sel=2026%...
My old day job was to compute asteroid positions for NASA telescopes, if you are interested in orbit prop you may be interested in: https://github.com/dahlend/kete
I made an asteroid only version of yours earlier this year, where it does full orbit propagation in workers: https://dahlend.github.io/ketev/
dahlend.github.io/ketev/
I refit the orbit and yeah this is not a dangerous object. Given its (currently poorly constrained) orbit it is likely a comet, it came the closest it will ever come to Earth last month at about half an AU from us. (IE: half the distance from the earth to the sun).
It is at about a 110 degree inclination, meaning it is basically perpendicular to the solar system plane and already passed perihelion.
MOID, or Minimum Orbital Intersection Distance, is a basic geometric measurement that says how close the geometric ellipses of two orbits get together. It doesnt mean that the objects will actually be that close ever. For example the MOID of the jupiter trojan asteroids is basically 0 since the orbits are the same, but they dont get close to jupiter. It's really handy to use it to rule out dangerous stuff though, non-zero MOID usually means there is no way it could ever be dangerous.
Here is some of the orbit code I used: https://github.com/dahlend/kete
I have slowly built out a set of tools for asteroid orbits and photometry (measuring how bright stars/asteroids are).
It is very rough still (Desktop only), and it only supports the FITs file standard.
Basically it is a full professional grade telescope processing pipeline in your browser. It does 2 queries to some custom databases to identify known asteroids and stars, but all image processing and calculations are done in the browser. This means the backend is pretty tiny. That said it is running on an old box in my closet, so queries may take a while if it gets hammered.
I built it since I have worked with quite a few astronomers over the past 4 years and I keep watching them do the same steps, purely built to make my friends lives easier. I wrote it all in rust and managed to compile it into wasm. With some help from fable as I am not a frontend guy at all, I built it into a small website.
Some of the code is public, the orbital mechanics code I wrote while I worked at Caltech. Which is being used on SphereX, NEO Surveyor, and the Roman telescopes to identify known asteroids. https://github.com/dahlend/kete
I suppose to make this feasible they would have to up the size of the mirrors. Unless this is somehow dirt cheap I can't imagine farmers or solar operators buying this.
https://www.federalregister.gov/documents/2026/05/29/2026-10...
Not mobile friendly
(Desktop Strongly recommended) https://dahlend.github.io/ketev/
Note that how the code is laid out you cant really simulate non-solar system masses. Its really aimed at massless objects in the solar system, your 3-body simulations are actually quite difficult to do given the design.
https://github.com/dahlend/kete
I'm working on modeling the motion of observed dust particles coming off of comet 67P, here is are some example 3d plots:
Example of rocks ejected from one position and their possible motions: https://dahlend.github.io/67p_beta_dust.html
Trying to determine possible orbits from a set of observations (the straight lines): https://dahlend.github.io/67p_dust_orbit.html
Shout out to pyvista for making these great 3d plots possible, a little less ergonomic than matplotlib, but it can export directly to html.
https://dahlend.github.io/2025_PN7_Orbit_1900-2100.png
Its hanging out for a while near us.
Shameless plug for my software I used compute it:
https://dahlend.github.io/the_belt.html
This includes about 1.3 million known asteroids (most of the known ones), so the page is like 45mb. Consider yourself warned.
This is a plot of semi major axis, orbital eccentricity, and inclination of the orbit. The blobs are collisional groups, where a bigger rock(s) got smashed into 'families' of asteroids. Color is by the absolute magnitude H, which is a normalized, log scaled, brightness measurement. Typically smaller H means larger object.
You can see the Kirkwood gaps clearly along one axis, but as you move around you can see more complex orbital resonances. These resonances pump energy into or out of the orbit of the asteroid, causing them to leave the resonance after some time, depleting the region of phase space.
Source: I do solar system simulations for my PhD work.
Also I fully agree with the "codes" rant.
Source: working professionally in the field for 4 years.
I also heavily use Jupyter for analysis, and with this code I can take over the telescope and command it in a jupyter session, allowing me to do live data analysis.
Here is a heavily used method in astronomy, this involves a higher order polynomial expansion than RK4.
This method has been extended a few times, my code uses a variation of it, and I know of several other projects which are also descended from it.
I have experienced the pain of getting ekos/kstars/indi tools to work well on my personal scope. If you want to try driving indi devices via python I have some python code (it's not super polished, but it does enough for my needs): https://github.com/dahlend/contindi
Source: Working on my PhD in orbital mechanics of asteroids/comets, here are my open source (python/rust) orbital integration tools: https://github.com/dahlend/kete
Biggest speed gain is that I have a custom SPICE reader that is multi-core friendly (I re-implemented a lot of the SPICE standard in rust), and it is used as the source for planet positions. Being able to skip planet integration leads to massive speedups.
It does an OK job for impactors, but the integrator is tuned heavily for performance, and the tolerance defaults are not great for impactors.
I match jpl horizons for apophis to a few km, they have a lot more intense earth gravitational model then I care to implement, and by default I only include the 5 heaviest main belt asteroids, they have many more. That was the sweet spot for accuracy vs speed for me, overall accuracy goal is less than a few km over a decade.
The goal is to be able to handle the huge influx of new asteroids that the catalog will have due to LSST and eventually NEO Surveyor (which I worked on for 3 years). Most systems I know have been throwing hardware at the problem, I tried to make fast and efficient enough software that we can use it on a laptop for 5-10 million asteroids.
You can approximate the orbits of basically everything in the solar system using 2-body mechanics (IE, ignore the planets). If you do this you get orbits which are elliptical (eccentricity <1), parabolic (eccentricity = 1), or hyperbolic (eccentricity>1).
If the object has an eccentricity above 1, its not bound to the solar system.
Many long period comets have eccentricity hovering near 1, often these long period comets will be on their first pass (sometimes only pass) through the solar system. These comets though usually dont get much above eccentricity of 1. The 3 interstellars we have spotted have had like 1.2 or bigger. This one is above eccentricity 6! Its moving fast.
Edit: I have heard that when the first interstellar was found it actually broke a lot of peoples code, as it was common to hard code limits to allowed eccentricities (or simply not support ecc>1 at all).
A lot of people are requesting discretionary time on telescopes trying to get observations in. The orbit will put us on the other side of the sun when 3I is nearest the sun in october, we can see it now and after it comes back out from behind the sun.
Unfortunately, right now the it is in a very crowded star field (IE, its close to the galactic plane, lots of stars in the background).
If you are interested in orbital dynamics, I have an open source rust/python package for accurate orbital calculations of asteroids/comets:
I did a full proper n-body integration and it is not visually different than this.
If it is an inactive rock, then we will not see it as any more than a point of light during its visit.