CHChrisRackauckas·Oct 9, 2025
We use it for binary deployments via building simulations into the FMI standard (i.e. building FMUs) https://fmi-standard.org/. We still need to get libraries updated for getting the smallest possible trim when using the more computationally difficult implicit methods, but at least the stack is matured for simple methods like explicit RK and Rosenbrock-type solvers already. For folks interested in --trim on SciML, the PR to watch is https://github.com/SciML/NonlinearSolve.jl/pull/665 which is currently held up by https://github.com/SciML/SciMLBase.jl/pull/1074 which is the last remaining nugget to get the vast majority of the SciML solver set trimming well. So hopefully very soon for anyone interested in this part of the world. Note that does not include inverse problems in the binary as part of small trim.
But all of this is more about m
Read the rest
aturing the ecosystem to be more amenable to static compilation and analysis. The whole SciML stack had an initiative starting at the beginning of this summer to add JET.jl testing for type inference everywhere and enforcing this to pass as part of standard unit tests, and using AllocCheck.jl for static allocation-free testing of inner solver loops. With this we have been growing the surface of tools that have static and real-time guarantees. Not done yet, some had to be marked as `@test_broken` for having some branch that can allocate if condition number hits a numerical fallback and such, but generally it's getting locked down. Think of it as "prototype in Julia, deploy in Rust", except instead of re-writing into Rust we're just locking down the behavior with incrementally enforcing the package internals to satisfy more and more static guarantees.