Show HN: Elodin – A better framework for physics simulation(github.com)
github.com
Show HN: Elodin – A better framework for physics simulation
https://github.com/elodin-sys/elodin
51 comments
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.
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.
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.
Exactly, the difference boils down to:
(a) is the calculation itself the end goal--e.g. am I trying to draw a plot which shows the motions of the three bodies?
or
(b) am I trying to use the code which describes the motion of the 3 bodies as a modular part of a system to answer other questions, perhaps interactively.
If everything is a one-off, and you're working on a very small team, of course excessive abstractions make little sense. But that's not how engineering is done. Abstractions are really important, because they allow us to collaborate.
(a) is the calculation itself the end goal--e.g. am I trying to draw a plot which shows the motions of the three bodies?
or
(b) am I trying to use the code which describes the motion of the 3 bodies as a modular part of a system to answer other questions, perhaps interactively.
If everything is a one-off, and you're working on a very small team, of course excessive abstractions make little sense. But that's not how engineering is done. Abstractions are really important, because they allow us to collaborate.
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!
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!
> there are comments for every line.
I used to work at a company that wrote an atomic scale simulation package. Every dev was a physics/chemistry PhD turned coder. We didn't quite hit one comment for _every_ line of code, but we were close! At first I really hated this style; one comment every few lines. However, I eventually learned to kind of like it, even though it was a bit redundant.
I don't really have a point here, but I just wanted to echo your statement that the physicists-turned-coder style is real!
I used to work at a company that wrote an atomic scale simulation package. Every dev was a physics/chemistry PhD turned coder. We didn't quite hit one comment for _every_ line of code, but we were close! At first I really hated this style; one comment every few lines. However, I eventually learned to kind of like it, even though it was a bit redundant.
I don't really have a point here, but I just wanted to echo your statement that the physicists-turned-coder style is real!
Jesus living through that now. Physics PhDs and postdocs turned coders all around. They dislike anything "not made here" and can build tools for years before a prototype solution to the actual problem exists. System design decisions are made frivolously and end user feedback is actively discouraged, "have to be careful who we show this to" one said in a meeting after something got criticized by an end user representative.
I'm venting a bit but it is a culture clash for sure.
Jesus is back?!? And she’s a Physics PhD?!?
> 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!
As a computer scientist this sounds odd to me, but if you are the sole consumer of your own API, you do you!
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.
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.
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
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
No, I actually like that approach better than the traditional ECS approach. Though I assume it both adds and removes some complexity. In a traditional ECS approach you can depend on certain systems running in certain orders because you depend on them having run. Then you refactor, forget this dependency, and suddenly you have changed behaviors and you have no idea why until you remember this. If, as I assume, you have per step immutability that removes a whole class of bugs at the cost of a slight increase in complexity.
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!
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!
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
Stick with `elodin` everywhere. Make sure to register the vendor name at all the package managers for languages you might make a library for.
ahh what a bummer... 'naming things' continues to be an ongoing challenge in programming lol
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
keen to see it! I'll definitely give it a whirl using ReRun as a front-end, it looks like it would pair really nicely.
You can try out the frontend online at https://app.elodin.systems/sandbox/hn/cube-sat or you can install the desktop version using pip: `pip install elodin` and then run `elodin editor cube_sat.py` against this file https://github.com/elodin-sys/elodin/blob/main/libs/nox-py/e...
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! :)
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
That is awesome to hear! Good riddance to Matlab!
also while I'm asking annoying, non-profit-driving questions... how about a self-hosted option? ;)
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.
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.
> let people easily test out new configurations quickly by just changing the code
If it's all just code, and we can compute some (multi-)objective function from each simulation run, then we can turn a metaheuristic loose on it ;)
If it's all just code, and we can compute some (multi-)objective function from each simulation run, then we can turn a metaheuristic loose on it ;)
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.
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
The subject I am studying is not atoms but perhaps it is similar so I think I can start with force field software and see if it works for my use case. Thanks!
What are you trying to simulate?
Elodin is not really the same sort of physics simulator at all.
Elodin is not really the same sort of physics simulator at all.
Really interesting!
Curious, why reimplementing jax in rust (nox)?
Curious, why reimplementing jax in rust (nox)?
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.
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.
Exciting! I have been wanting a Rust port of JAX for a long time! (I mostly care about the ability to write numerical GPU code via XLA, not differentiation)
Is there a crate in the works? I would start using it (and contributing if needed) instantly.
Is there a crate in the works? I would start using it (and contributing if needed) instantly.
Yes you can use Nox separately today. https://github.com/elodin-sys/elodin/tree/main/libs/nox . It just hasn't been released on crates.io yet, and no promises about stability. I mentioned this in a sibling comment, but we likely will have to rename Nox to something else since someone is squatting the name on crates.io
I'm here to appreciate not sprinkling "Rust" in the title and all over the README to hype it up. Thank you!
Was this named after Elodin from The Kingkiller Chronicle? :)
Yes! We are big fans
How do y’all avoid lawsuits and stuff? I always wonder that about Palantir and Anduril and all those other companies.
Did you have to ask permission? Or is this just a run it til there’s a lawsuit because you’re in a different industry thing?
We were curious as well, but after some research when we named the company we discovered that names (even distinctive ones) can't be copyrighted just trademarked. Of course IANAL, so do your own digging :)
Heh, I thought it was L1, symbolising both aerospace (Lagrange point) and “close-to-hardware” (cache).
(odin means one in some languages)
(odin means one in some languages)
Are there decent wind models and motor models if you want to model drones
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
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.
EDIT: answered in a cousin comment.
I will say the
jax.lax.max()
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`.
We can't seem to reproduce that issue on Firefox. Is it possible you have animations disabled or some other setting?
Checked on a private window; it happens only when I say no to inessential cookies. Being in California might also have something to do with it, because according to the logs that sets something to opt in mode.
Thanks for looking into it more. I was able to reproduce. We will get that fixed ASAP
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.
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.
I came to say the same as GP. In my world, if you don't solve time-dependent coupled PDEs in 3D you're not doing real physics. In someone else's world, if you don't have particle-in-cell functionality or symplectic integrators or P3M methods or whatever, you're not doing real physics.
To my mind any software that calls itself a generic physics engine is not doing "real" physics, more like "Blender physics".
Of course this can still be super useful! But the field of numerical physics is super broad and deep, and different sub-fields require dramatically different data structures and algorithms.
To my mind any software that calls itself a generic physics engine is not doing "real" physics, more like "Blender physics".
Of course this can still be super useful! But the field of numerical physics is super broad and deep, and different sub-fields require dramatically different data structures and algorithms.
[deleted]
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.