sphw

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

Fair point. We will fix the language up

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.

Thanks for looking into it more. I was able to reproduce. We will get that fixed ASAP

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

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

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

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.

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

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

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

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

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

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.

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.

Yes! We are big fans