Hi! I’ve been using Orekit’s CR3BP functionality a lot recently and I’ve wanted to contribute for some time, so I thought this might be a good place to start:
I’m pretty familiar with the paradigms used throughout the baseline w.r.t. PVCoordinates and AbsoluteDate, and I’ve developed frameworks plenty of times, but I was wondering if there was any additional guidance of which I should be aware before I begin. I also don’t want to “step on any toes” if work has already started.
Thank you very much for your wish to contribute to Orekit.
Just note that a lot of work has been done recently by Alberto Fossà in CR3BP features. This work has been merged in develop branch. Therefore, if you start working on it, don’t forget to use the last version of the develop branch .
I’ve finally got some time to get this done, and I was wondering if you had any particular paradigm in mind.
I envisioned these new classes as simple extensions of AbsolutePVCoordinates and AbsoluteDate.
E.g., something like this:
public class NormalizedPVCoordinates extends AbsolutePVCoordinates {
...
/** Get the position {@link Vector3D}, in the units used on instantiation/in normalized units/TBD */
@Override
public Vector3D getPosition() {
return super.getPosition();
}
}
Classes that override methods which have JavaDoc that mention units, writing the new JavaDoc to describe only “normalized” position/velocity/acceleration/time, with a Factory class that takes an epoch and four scalars; e.g.:
public NormalizedPVCoordinatesFactory {
/** javadoc */
private final AbsoluteDate epoch;
/** javadoc */
private final double positionScale;
...
/** javadoc */
private final double timeScale;
...
public NormalizedPVCoordinates createNormalized(final AbsolutePVCoordinates absPV) {
// scale and return absPV
}
}
I planned on doing it this ^ way so that the new class would be compatible with the existing SpacecraftState infrastructure.
That said, would you/the rest of Orekit prefer something that was totally distinct from the AbsolutePVCoordinates infrastructure?
Thinking about this since yesterday, I’m wondering if, in fact, it makes more sense to use unique objects that are outside of the purview of AbsolutePVCoordinates and SpacecraftState
Perhaps something like
public class NormalizedPVCoordinates {
private final Vector3D pos;
private final Vector3D vel;
private final Vector3D acc;
private final AbsoluteDate epoch;
private final double normalizedDTSinceEpoch;
private final Frame frame;
// etc.
public AbsolutePVCoordinates asAbsPV(final Frame targetFrame,
final double timeScale,
final double posScale,
final double velScale,
final double accScale) {
// scale, convert, and return
}
}