Halo computation not finishing in newer version of AstrodynamicalSolvers

[tahoe-vegas]

Hi, I began using GeneralAstrodynamics today to investigate various halo orbits around Sun-Earth L1 and associated manifolds, with the eventual objective of determining the trade space of dV vs transfer time for a mission concept.

Using the latest version of GeneralAstrodynamics from the Julia package repository, I was successfully able to calculate a few example halo orbits and manifolds but had some confusion with exported function names. I snooped around this repo and figured that out I was using older versions of the library packages, since newer AstrodynamicalCalculations/Models/Solvers versions have been released but not GeneralAstrodynamics.

I tried removing GeneralAstrodynamics and re-adding the libraries so they are the most recent:

  [c0cf9fb7] AstrodynamicalCalculations v1.0.0
  [4282b555] AstrodynamicalModels v3.8.0
  [636ee813] AstrodynamicalSolvers v1.0.0

I also found this documentation and tried the "Manifolds Computation" code blocks, first with the CR3BP parameter for Sun-Earth and then with no changes. Both times the halo computation runs on and on before Julia crashes.

Is there something I'm doing wrong, or is this just a bad time to be trying out these solvers? It seems like this package might be in the middle of a significant refactor, so no worries if that's the case. This is a very impressive project and I'm excited to see where it goes and possibly contribute as it is very relevant to my work.

[cadojo]

Thank you for the issue! This project is in the middle of a big refactor, though the "refactor" part is mostly done, and I'm now ironing out bugs, working on documentation, and linking different pieces of functionality across the sub-packages.

The issue you found is one I found today too! For some reason, the MVector type in the function body for halo is causing a massive re-compilation that practically does not finish on my computer. Just today I replaced those with Vector and the calculations do finish, but I need to verify it more during this week.

I'm happy to hear the project is useful! All issues and PRs are welcome. This is the culmination of my grad school work, and now I'm working full time as an RSE in robotics, so my time tidying up these packages has been mostly limited to weekends.

So all that is to say: you could try using the dev versions of the packages because I think this specific issue might be fixed with my latest commits. But unfortunately the solvers specifically are most brittle parts right now. I hope to have the examples working again in the next week or so.

[tahoe-vegas]

Good to know, I will try out the dev versions with managed expectations. Thanks for the quick response!

[cadojo]

Hey @tahoe-vegas, I've tracked this issue to OrdinaryDiffEq#2535. The issue is due to CartesianState being a sub-type of StaticArrays.FieldVector. I've changed all ODEProblem calls in the code to use Vector instead of CartesianState or MVector.

I'm currently updating the documentation. I'll close this issue when that is done. You should be able to work around the issue by using Vector for your state vector type. Let me know if that does not work, and feel free to re-open this issue if you think I'm closing it prematurely.

[tahoe-vegas]

Sounds good. I have been able to use the halo and manifold solvers with no issues after pulling the dev versions of the packages, and using regular Vectors.