Show HN: Elodin – A better framework for physics simulation

[sphw]

Hey HN! We are the co-founders of Elodin (https://elodin.systems/), a code-first physics simulation framework. We just open-sourced our core libraries on Github: https://github.com/elodin-sys/elodin

Have you ever wondered what happens when a satellite is first placed into orbit? It turns out that often, they tumble out of control, end over end, in a miraculous fight against stability. Check out our demo here of a control system attempting to rectify this: https://app.elodin.systems/sandbox/hn/cube-sat

The spacecraft does not appreciate tumbling: deploying solar panels and antennas might not work, and doing anything worthwhile is out of the picture. So what are you to do about this? You'll equip your satellite with reaction wheels (or magnetorquers), but now you have a second problem. What commands do you send to the reaction wheels?

We created Elodin to help solve problems like this. These problems are firmly in the realm of GNC (guidance, navigation, and control) engineers; they are traditionally solved with MatLab / Simulink, a bunch of Python scripts, and/or a tool like Gazebo or Basilisk. While building the flight software for a deep-space mission, I tried all of these tools and didn’t like them. In particular, I found that running Monte Carlo simulations in the cloud was painful.

So we set out to build a better framework for physics simulation. You might call it "Tensorflow for Physics." The name fits for two reasons: we use XLA to accelerate your math, and we've built an extensible framework for creating new physics engines. Most physics engines are fixed-function. For example, something like MuJoCo (https://mujoco.readthedocs.io/en/stable/overview.html) is great for traditional robotics, but GMAT (https://gmat.atlassian.net/wiki/spaces/GW/overview) is far better for orbital analysis. No single physics engine can solve all problems, and it’s hard to integrate multiple engines. Our framework allows you to easily compose different physics algorithms.

Space is hard enough—let’s not have software make it harder than it needs to be! We are still early in building our stack, so we’d be grateful to hear any feedback that you have.

[noobermin]

You can always tell when developers and computer scientists try to "fix" computational physics, sigh. It looks "easy" when you have a helper method/call for common things like 1/r^2 or something like that but what about when you want something more tedious than that? I don't see how the example is better than a python script/fortran code with a bunch of arrays. Like the three body example, a script with arrays would be much simpler and take less boilerplate than a lot of what they had there, and adding the third body is a simple as making N=2 instead of N=3. The usual argument that codes in the computational style are messy and hard to read really only applies if you don't know physics which while daunting need not be, like anything it just needs to be learned.

Anyway, to each their own, it's fine for people who somehow think because there are wrapper methods everywhere a code is "cleaner". I just submit that this really is a aesthetic preference, and that instead of trying to "fix" other professions, understand there are often reasons why things are that way when everyone in a field works that way.

[sphw]

At the risk of exemplifying the coder turned physicist turned coder again, I think we are really talking about two slightly different fields here. There is the world of computational physics, which we haven't specifically built this tool for. Then there is the world of controls and robotics. In that world, it's very common to use highly abstracted tools like Simulink, that try and hide away all the implementation details. We are trying to bridge the gap between these two styles, by offering a more lightweight series of abstractions that still allow composability. I actually agree that for many things the more explicit, less abstract, array-first approach is good. But we also think that composability and shareability will allow teams to work faster. I think it's a hard balance to get right, but that's our goal.

[cl3misch]

Nicely put, thank you. What can sadly be even worse are physicists-turned-coders who think code is good if 1. everything is encapsulated as much as possible and 2. there are comments for every line.

Of course, I once was that physicist! Now I prefer working with arrays and functions that receive arrays and return arrays, even in the top-level, user-facing script.

But who knows, maybe there will be a next stage in the journey!

[igleria]

> adding the third body is a simple as making N=2 instead of N=3

As a computer scientist this sounds odd to me, but if you are the sole consumer of your own API, you do you!

[schreiaj]

Your ECS API looks very similar to that of Bevy's, were you inspired at all by that?

From the little I can see of it, it looks like you don't allow writes to data and instead prefer to return a new thing based on a query? Based entirely on the below.

``` @system def control( sensor: Query[WorldPos, WorldVel, Goal], rw: Query[RWAxis, RWForce] ) -> Query[RWForce]: ```

I assume this is due to the distributed nature of your simulation framework?

Either way, neat. Very interested in this though for more terrestrial applications.

[sphw]

Yeah we are huge fans of Bevy, and heavily inspired by their API. Mutability is tricky in XLA / JAX's computation model. Its optimizations rely on a purely functional style of programming, and so we've tried to map that onto an ECS. In addition, there are some counterintuitive things about programming with JAX that try and discourage through our API. Like accidentally unrolling a loop by using `for` instead of `vmap`.

EDIT: One thing I forgot to add is that we actually use Bevy for our 3D viewer. IMO, its the perfect framework for developing 3d applications that aren't quite games. Most games engines make you carry around a ton of features you will never use, but Bevy is really good at being flexible, lightweight, and easy to use

[leighleighleigh]

Hell yes, this looks awesome - do you see a future where Gazebo uses this as a physics engine?

Also just in case you were unaware, the name 'nox' refers to a popular Python testing framework... so if you were to release 'nox-py' on PyPi it would be a bit confusing. Maybe "nox-ecs"? Sorry to be a bummer!

[sphw]

Yeah I recently found out about `nox` in the Python world. That combined with someone squatting the crates.io name might make us change it completely. Our Python library right now installs as `elodin`, and we might just stick with that

[sphw]

Re: Gazebo - it's possible, but IMO Gazebo likes to approach things from a slightly different angle. Gazebo uses, mostly, config files to create your simulation whereas we prefer people to use code. Someone could certainly build a physics engine using our tools, and connect Gazebo to it. We are building our own Gazebo-esque frontend, that will have a better UX long-term for our framework

[leighleighleigh]

There is a huge talent pool of student engineers who compete in the University Rover Challenge each year, who would love to have access to this. Would you guys consider a non-commercial, student-only free tier? It would be a great way for you to break into the robotics industry from the inside! :)

[sphw]

Yeah we totally will have a free-tier for students / non-commercial. Our long-term plan is to replace Simulink & MatLab as the de-facto student tool

[leighleighleigh]

also while I'm asking annoying, non-profit-driving questions... how about a self-hosted option? ;)

[jcgrillo]

This looks really cool! I've often dreamt of having tools which would enable things like co-evolving a drone controller with physical aspects of the drone itself -- like rotor shape, dimensions, components selected (motors, battery, etc). The normal CAE workflow isn't set up for that kind of fast iteration. Code driven modelling tools combined with code driven simulation environments could make that real.

[sphw]

We completely agree. We want to develop a series of prebuilt modules for various components (motors, IMUs, star trackers, etc). The goal would be to let people easily test out new configurations quickly by just changing the code. Ideally, this will be a community effort, where people can contribute open-source models of various components that have been created.

[drojas]

This is great. Does anyone know any framework for simulating crystals or 3d lattices in general? I am trying to find something but I am not very familiar with this space.

[denhaus]

it depends on if you’re looking for an accurate calculation of atoms and the number of atoms. if you’re just interested in how a lattice of spheres interact, force field software might be your best bet. if you’re interested in electronic properties of real materials you will need higher levels of theory such as DFT or beyond

[archgoon]

What are you trying to simulate?

Elodin is not really the same sort of physics simulator at all.

[5kg]

Really interesting!

Curious, why reimplementing jax in rust (nox)?

[sphw]

For me, it boils down to 3 reasons. One is that the JAX tracing process can get a little slow for more complex programs. By bringing Jaxprs into Rust, we can optimize the compile path more. This doesn't matter for small simple programs, but for larger programs (especially with lots of unrolling) it could matter a lot. The 2nd reason is that I just prefer Rust for making production-ready software. The strong type-system especially allows you to catch many errors at compile time, Python is moving in that direction, but IMO isn't there yet. The 3rd reason is that we want this software to easily integrate with your existing flight software (the control software for your drone/satellite), and using a "systems" language like Rust makes that easier. Eventually, we would love to build out a suite of flight software in Rust that can easily integrate with the simulation but is still flight-ready.

A fun side-effect of this architecture is that when we run your simulation we aren't actually running your code, Python or Rust in the loop. We compile down the whole thing to HLO at runtime, then run that HLO. So we could theoretically support lots of other languages.

[amne]

I'm here to appreciate not sprinkling "Rust" in the title and all over the README to hype it up. Thank you!

[genshii]

Was this named after Elodin from The Kingkiller Chronicle? :)

[sphw]

Yes! We are big fans

[untech]

Heh, I thought it was L1, symbolising both aerospace (Lagrange point) and “close-to-hardware” (cache).

(odin means one in some languages)

[stealthcat]

Are there decent wind models and motor models if you want to model drones

[sphw]

Yeah we totally intend to build out good wind and motor models for drones. We are still building out are component library, and trying to decide exactly what to prioritize

[jcgrillo]

It seems like they're currently focusing on orbital dynamics problems, but I'm also curious if there are plans to simulate other physical phenomena (stresses, thermal effects, fluids, etc.)? I realize demanding a full multiphysics simulation environment is a tall order but one can hope.

EDIT: answered in a cousin comment.

[pests]

I will say the

  jax.lax.max()

call in the example is unintentionally funny to me. Almost felt like I was reading code written by Dr. Seuss.

[alephaleph]

Not sure why but everything below the hero section on your homepage is displaying as just grey background to me on Firefox, even with enhanced tracking protection and adblock off. In the console the only error is `Uncaught ReferenceError: tippy is not defined`.

[sphw]

We can't seem to reproduce that issue on Firefox. Is it possible you have animations disabled or some other setting?

[elashri]

It looks interesting. I will take this chance to say that I notice a lot of tools get dubbed “physics simulation frameworks” when they’re really more about mechanics,. As much as “physics” covers—from quarks to quasars—calling these tools something like "mechanics simulators” might be more on the nose. But, yeah, getting the naming conventions to shift might be a lost cause at this point. But hi, its better thab CERN naming the most used tool for their field "ROOT" and compete with every IT person in linux world on search engine space.

[sphw]

You are completely correct; right now it is just mechanics that we have built out. But, there isn't any theoretical reason you couldn't use this framework for other types of simulation. In particular, the Monte Carlo runner is super flexible. Since we are based on JAX you can utilize a ton of the tooling that others have built in the physics space like https://github.com/tumaer/JAXFLUIDS or https://github.com/DifferentiableUniverseInitiative/jax_cosm... . The goal right now though is pretty firmly focused on controls engineers and their needs, but we envision this becoming broadly used.