Tried very hard to get the first order methods to work with the new EnsembleEndpointThreaded, but alas, there is some state being shared in the problem parameters within a thread that ruins subsequent solves and i have no idea what is causing it. The only way to fix it is to reinstantiate the integrator after each solve, which just defeats the point of it.
So I've added instead a warning that the endpoint threading method does not work, and then let it automatically change to EnsembleThreaded. Made all tests pass.
Also closes #87 -- the progress bar was causing all of the problems, so that can now be optionally passed to tracegeodesics, and incremented thread-safe and contextually. This does mean it's now much easier to add new progress meters to other methods too that don't rely on rendergeodesics.
Fixed some issues related to half-changes in the process_solution API, so that the metric type, if unspecified, is infered from the ODE solution.
Tried very hard to get the first order methods to work with the new
EnsembleEndpointThreaded, but alas, there is some state being shared in the problem parameters within a thread that ruins subsequent solves and i have no idea what is causing it. The only way to fix it is to reinstantiate the integrator after each solve, which just defeats the point of it.So I've added instead a warning that the endpoint threading method does not work, and then let it automatically change to
EnsembleThreaded. Made all tests pass.Also closes #87 -- the progress bar was causing all of the problems, so that can now be optionally passed to
tracegeodesics, and incremented thread-safe and contextually. This does mean it's now much easier to add new progress meters to other methods too that don't rely onrendergeodesics.Fixed some issues related to half-changes in the
process_solutionAPI, so that the metric type, if unspecified, is infered from the ODE solution.