ddahlen

Strictly from an energy conservation argument this doesnt make a whole lot of sense to me. Just some back of the envelope math if they take their current mirror size, make 50k of them and overlap all of the output on the same 3 mile spot (the spot size they claim they will get on a single mirror). With an ideal reflector it is still less than mid-day daylight. Thats 50k satellites to give you direct sun over one 3 mile spot.

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.

You can put in a public comment on these changes here:

https://www.federalregister.gov/documents/2026/05/29/2026-10...

I am a researcher studying orbital dynamics of asteroids/comets/dust. I made a very precise visualization tool for the solar system, it shows the motion of all of the known asteroids. When you click on a specific asteroid it will then show the hyper precise orbit for it which matches JPL's orbit calculations (full physics, n-body, relativity, non-spherical planets).

Not mobile friendly

https://dahlend.github.io/ketev/

Research grade orbital mechanics, specifically of asteroids/comets. I've been working on it for 4 years now, finally tried using some AI tooling the last few months and ended up vibe coding a fun little visualization.

(Desktop Strongly recommended) https://dahlend.github.io/ketev/

I suggest the appendix of the arxiv paper if you want to see some of the math required for solar system objects beyond simple Newtonian gravity (like Relativity corrections). I wrote that section specifically because I found it a pain in the ass to source those equations in literature.

Its an implementation of a pretty standard integrator used by astronomers informally called "RADAU", but it is not exactly the same RADAU you would find elsewhere. Basically it is about as good as you can typically get for multi-step integrators, tuned for speed not precision though.

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.

Working on orbital dynamics code for my PhD in astronomy, written in rust, it can accurately calculate the positions of all asteroids/comets to within a few meters. Today I am adding a new numerical integration method which should enable me to predict orbits from observations.

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.

Here you go, here is its orbit from 1900 to 2100 in the earth's rotating frame, sun is at -1 on the x axis.

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://github.com/dahlend/kete

I made a 3D visualization of this a few weeks ago:

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.

One good reason to keep the raw data and orientation separate is hardware calibrations. I see some discussion here along the lines of "why not just flip the data before saving it", and one counter-argument is that you should store the flip metadata anyways, as it important to trace which hardware pixel corresponds to which stored pixel. I realize this information is not vital for everyone, but it is super useful in fields where you need to characterize the hardware performance at the pixel level (for example astronomy).

There are quite a few open source projects in astronomy, but in my experience there is a tremendous amount of code that is squirrelled away as it is difficult to reproduce and entrenches peoples positions. I have mixed feelings about this in general, as I understand the incentive structures, but I do wish in general some of the sub fields were a bit more open. I do think things are getting better in general.

Also I fully agree with the "codes" rant.

Source: working professionally in the field for 4 years.

I am a professional astronomer, and I am running a survey for asteroids. This needs to be controlled from python, as it decides every night which objects to observe.

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.

https://www.cambridge.org/core/journals/international-astron...

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.

This is really impressive! I considered buying a big harmonic drive mount for my scope, but the cost is really prohibitive.

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

It is neat to see some of the old work done in the field, this looks like a pretty classic treatment of the topic. It looks like they were using a fourth-order Runge-Kutta integrator, which would likely limit long term integrations accuracy (though looks sufficient for their use case). Many algorithms I have seen typically use much higher order integration methods to beat down the accumulation of numerical error.

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

Final edits of a paper at the moment, aim to submit next week. Perturbers are easy to add, though a little poorly documented at the moment. Additional physics right now are J2 of jupiter/sun/earth, and GR corrections for the sun and jupiter.

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.

I wrote a custom implementation of the Radau integrator, its been heavily modified. I have a lot of additional physics, it supports the non-gravitational models that JPL Horizons defaults to, so diurnal yarkovsky at least. I've been using it to study dust and small object dynamics, as they get pushed around by the sun a lot.

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.

Different goals, kete is meant to be aimed more toward observers and telescope data processing, all asteroids and comets at once on a laptop. Short term analysis (<100 years) and speed are the priority.

Oort cloud comets are so distant that they are only weakly gravitationally bound to the solar system. When they come in and we see them, they have enough energy to go back out to the extreme distances. Minor nudges from the big planets are enough to cause them to become ejected from the solar system (ecc>1). This can lead to the whole "one and done" thing.

Eccentricity!

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).

I'm one of those astronomers! I'm working on my PhD in orbital dynamics.

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:

https://github.com/dahlend/kete

This orbit visualization uses a simple 2 body approximation, so only the sun. This is because unless an object has a VERY close approach to a planet the two body approximation is more then enough for this style of visualization.

I did a full proper n-body integration and it is not visually different than this.

The closest it will come is Mars, but when I say close these are quite literally astronomical distances, about 0.2 au from Mars. This is about 75x further than the moon is from the Earth.

If it is an inactive rock, then we will not see it as any more than a point of light during its visit.

I would recommend staying on Earth...

It is also a factor of where our surveys look on the sky. A lot of asteroid surveys have biases to look at the plane of our solar system (since this is where a lot of asteroids are).

It is probably random chance, however there may be some biases from where they come from on the sky (I know people who work on that, but I don't know much about it).

N=3 does not provide very robust statistics yet, give us another decade or two.

This is an announcement from the Minor Planet Center (MPC). They are the official international clearing house for observations of solar system objects.

The top indicates that the object has two names (this is common): 3I/ATLAS = C/2025 N1 (ATLAS)

ATLAS was the telescope that made the discovery.

The list of data are individual observations of the object by different telescopes. This observation format has been in use for a long time, but is being phased out. A row is meant to fit on a single punch card...

These observations are then used to calculate orbits, the MPC calculates the orbit as well, but this list of observations is also ingested by JPL and their Horizons service.

It is inside jupiter's orbit now, it will come inside Mars for a time. It is almost on the plane of the solar system, not very inclined.

I linked an orbit viewer above if you want to look.

This one is coming in fast, it has an eccentricity of over 6 with the current fits. For point of reference, 1I and 2I have eccentricities of 1.2 and 3.3.

Right now it is mostly just a point on the sky, it is difficult to tell if it is active (like a comet) yet. If it is not active, IE: asteroid like, then the current observations put it somewhere between 8-22km in diameter (this depends on the albedo of the surface). From what we know, we would expect it to likely be made up of darker material meaning given that range of diameters it is more likely to be on the larger end. However if it is active, then the dust coming off can make it appear much larger than it is. As it comes in closer to the sun and starts to warm up it may become active (or more active if its already doing stuff).

It will not pass particularly close to any planet. It will be closest to the sun just before Halloween this year at 1.35 au, moving at 68 km/s (earth orbits at 29-30 km/s). It is also retrograde (IE, it is moving in the opposite direction of planetary motion), for an interstellar object this is basically random chance that this is the case.

Link to an orbit viewer: https://ssd.jpl.nasa.gov/tools/sbdb_lookup.html#/?sstr=3I&vi...

The next couple of weeks will be interesting for a bunch of people I know.

Source: Working on my PhD in orbital dynamics and formerly wrote the asteroid simulation code used on several NASA missions: https://github.com/dahlend/kete

I posted a couple of months ago:

https://github.com/dahlend/kete

Research grade orbit calculations for asteroids and comets (rust/python).

I began working on this when I worked at caltech on the Near Earth Object Surveyor telescope project. It was originally designed to predict the location of asteroids in images. I have moved to germany for a PhD. I am actively extending this code for my phd research (comet dust dynamics).

Its made to compute the entire asteroid catalog at once on a laptop. There is always a tradeoff between accuracy and speed, this is tuned to be <10km over a decade for basically the entire catalog, but giving up that small amount of accuracy gained a lot of speed.

Example, here is the close approach of Apophis in 2029:

https://dahlend.github.io/kete/auto_examples/plot_close_appr...

As I said, just an order of magnitude estimate for many non-adaptive optics telescopes.