Due to recent changes in the SciML ecosystem, return codes are now enums instead of symbols, which means we can't piggy-back custom return codes anymore. Consequently, have to keep track of them using an (allocated :cry:) parameter structure, which is updated during calls to terminate!.
The performance hit of this is fairly small, about 1 allocation per geodesic, but given we already have GC issues, this might prove a little annoying.
A few things we can maybe do to cope with that
custom solution structs before OrdinaryDiffEq.jl packages the structures together, and reduce allocations in parsing
clever and targetted use of GC.gc(false), as this was quite successful in the transfer functions
In theory there is no need for the integrator to allocate anything, given we are only interested in the initial and final 8-vectors (pos + vel), so perhaps we can go digging as see if there's anything we can do on that front as well.
Due to recent changes in the SciML ecosystem, return codes are now enums instead of symbols, which means we can't piggy-back custom return codes anymore. Consequently, have to keep track of them using an (allocated :cry:) parameter structure, which is updated during calls to
terminate!.The performance hit of this is fairly small, about 1 allocation per geodesic, but given we already have GC issues, this might prove a little annoying.
A few things we can maybe do to cope with that
GC.gc(false), as this was quite successful in the transfer functionsIn theory there is no need for the integrator to allocate anything, given we are only interested in the initial and final 8-vectors (pos + vel), so perhaps we can go digging as see if there's anything we can do on that front as well.