I've never seen anyone use Barnes-Hut for an earth gravity model. I'd be curious to see how an implementation like that would work. I think Barnes-Hut is typically used for large N-body simulations where each particle moves independently, like for galactic simulations.
One of the biggest barriers to alternate geopotential models is the availability of trusted data-sets. In another comment someone linked to a PINN based method that looks super promising
It's a pretty minor point, but the pedant in me appreciates it nonetheless!
It's also true that since most people are not subjected to the horrors of learning about PDEs, the place where they may be exposed to spherical harmonics is in atomic orbitals from high school chemistry, so I could see where you were coming from.
Yup, your understanding is correct. When set to full fidelity, it computes and sums 2,331,720 terms. What we optimized is the way the spherical harmonics are generated, which allows for the generation and summation to happen in less than 250 ms. Once that force information is generated, it is passed to a semi-implicit integrator – we also support RK4, but this test was using semi-implicit. That allows you to run orbital dynamics simulations; our primary use case is for testing satellite control systems.
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.
(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.
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
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.
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.
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.
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.
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
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
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
One of the biggest barriers to alternate geopotential models is the availability of trusted data-sets. In another comment someone linked to a PINN based method that looks super promising