Hi, nice to see people in ESA experimenting with newer tools. I’ve been developing similar software entirely in Julia for the past few years, and I’ve got some experience working with the mainstream simulators often used in ESA-related missions. I think section 3.7 in the paper pretty much sums it up. Almost everything you do is non-linear and sensitive to inevitable perturbations in the initial state. Running a simulation for hours to produce timeseries plots where you could be running multiple MC analyses is essential IMO. Plus, you can take it a step further and do sensitivity analysis, etc. I recall Dario Izzo and the ACT doing stuff like a differentiable SGP4 propagator proof of concepts back in the day. These things are trivial to do in Julia. Having one extra software engineer to join your team and help you squeeze out performance or simplify the codebase is absolutely free compared to having to deal with Simulink, or worse yet, things like SIMULUS. Even installing the toolchain can be complicated, let alone working with it to do anything useful. AFAIK there’s a lot of people in aerospace companies and NASA working with Julia (see (For what) is NASA using Julia? as an example).
As an aside, I think your simulation code is fast enough. Yes, you might be able to make it slightly faster by using generated functions here and there or using static arrays for pretty much everything (don’t forget the quaternions), if you aren’t already, but it will roughly be on the same order of magnitude. In my experience, what can help significantly more is building different “tiers” of the simulation: replacing computationally intensive models with simpler ones, without sacrificing much on the fidelity side. Then, you can build workflows where you use the cheap simulation for exploring the parameter/state space, iterating on the design, etc., and you use the high-fidelity version as a sanity check. If possible for your use-case, that’s probably a good way to unlock more performance.