Ramblings about states, orbits, arrays, and a roadmap - poliastro/poliastro GitHub Wiki

Simplifying and arrayfying states

• Now BaseState objects carry the plane around, but they don't use it for anything
• They also carry the attractor, but they only use attractor.k
• Seems obvious that we could have one lower layer, but for what purpose?
• It would be cool to have arrays of states, for example

>>> ss = StateArray(...)
>>> len(ss)
100
>>> ss.a
<Quantity [1000., 2000., 3000.] km>

• These are essentially astropy.table.QTable (which have a .to_pandas() method)!
• Arrays of states could be the output of https://github.com/poliastro/poliastro/issues/380
  • Still undecided what API would compute them from an Orbit or an Ephem
• Arrays of states would basically be like an OrbitArray that doesn't have a propagate method
• At the lowest level, what if a state could be just a record dtype of NumPy? (Crazy idea)

Above and beyond states

• I don't really need much for propagating an Orbit and that we should reconsider frameless orbits https://github.com/poliastro/poliastro/issues/659
  • Some original ideas in https://github.com/poliastro/poliastro/wiki/%5BOLD%5D-Orbits-and-reference-frames
  • I actually made a proposal! https://github.com/poliastro/poliastro/wiki/New-ideas-for-the-object-hierarchy
    • See that "element sets" without k cannot be converted from one to the other. But they still carry enough information to provide a snapshot!
  • Should there be simple Orbits with custom bodies, but no frame attached (a default one is assumed)? Or should the creation of custom bodies (and custom "solar systems") also require the user to create a custom plane to be used everywhere?
• After re-reading https://github.com/poliastro/poliastro/wiki/Different-element-sets, what if the original problem of having to pick between p and a was solved by having a ClassicalState that can be created using one or another? Or by having a SMAClassicalState and SemiLatusClassicalState?
  • Having several classes is not scalable: notice that we also can pick from the anomaly (true, eccentric/parabolic/hyperbolic, "mean")
  • In summary, states (specifically classical states) could be a bit smarter. But how does that play with the "element sets"?
• Going back to frameless orbits, what we need is to make the "planes" system unobstrusive, approachable and easy, and let the users introduce their own "planes", or just ignore them
  • And possibly make .sample return an Ephem, that carries that plane information!
  • What about a GenericPlane or GenericFrame that people can use in their own bodies? Can't be converted to anything
    • Or maybe it could be the default, unless folks have opinions
  • Maybe "plane" is a bad name and we should call it "frames" - good opportunity to break backwards compatibility but not repurpose and existing name
  • Essentially my idea to "wrap" astropy.coordinates frames in a more user-friendly manner, lost in a notebook somewhere...
  • A first step will probably be repurposing the current Enum + mapping into something more convenient

Meta ideas

• Introducing too many objects is tempting, but makes the code more complex and introduces indirection as well!
  • Therefore, try not to introduce element sets and frameless orbits unless you see the need for it
• Changes should be driven by user requirements!

Ideas for future PRs

• No more plane in BaseState objects
• Orbit.sample returning an Ephem
• Ephem.from_orbit to generate trajectories from orbits (luckily, there is no Orbit.to_ephem!)
• GenericPlane that is not connected to anything, and possibly refactoring the Plane objects from Enum + mapping to classes for convenience
• Refactor propagators to avoid extra element conversions
• Sample properties easily (maybe returning astropy.table?)
  • But, aren't ephemerides essentially astropy.table too? Boom! Didn't think about it because I'm storing (r, v) in a CartesianRepresentation for convenience, maybe it makes sense this way

...And I think with this + the dammed OrbitArray + OMMs + "EarthSatellite" (that might have to go away), I have "solved" the major API problems in poliastro! 1.0 is approaching?