OpmParser and MAN_DELTA_MASS

Orekit development
1

Hi all,
I noticed that in the Orekit OpmParser as of Orekit 11, maneuvers which contain no MAN_DELTA_MASS keyword are skipped altogether without raising a parse error, since they never satisfy the currentManeuver.completed() condition in processManeuverToken.

I think that this behavior should be revisited and Orekit should allow the parser to return Maneuvers with deltaMass = Double.NaN. First, IMO it is not clear in the CCSDS standard (502.0-B-3) that the MAN_DELTA_MASS keyword (or in fact any MAN_ field) is actually required. In the OPM DATA table, each MAN_ field is labeled “Optional”. The only numbered standard I see which could perhaps be interpreted to mean that all MAN_ fields are required for any maneuvers that are present is this:

3.2.4.8 Multiple sets of maneuver parameters may appear. For each maneuver, all the
maneuver parameters shall be repeated in the order shown in table 3-3.

However, I think there are two issues with this. First, if the intent of this standard was that the MAN_ fields are conditionally required if any one of them is present, then the standard would have used the “C” (Conditional) requirement instead of the “O” (Optional) requirement. Second, in the old Orekit 10 version of the OPM parser, these maneuvers were not ignored, even though this part of the standard is as far as I can tell unchanged in CCSDSv3 comapred to CCSDSv2.

Finally, I think that even if my above argument is rejected and the team decides that maneuvers must contain all MAN_ fields to be parsed and returned to the user, this should either be a configurable behavior (similar to the ParsedUnitsBehavior mechanism used to resolve unit parsing ambiguities in the CCSDDS standards) or raise a parse error that can be handled by the user instead of silently skipping the maneuver altogether. In my experience, many large satellite operators operationally publish OPM files which do not contain MAN_DELTA_MASS fields, and I think that Orekit’s silent omission of “incomplete” maneuvers is likely to cause users to misinterpret OPM files which are communicated across organizations.

I couldn’t find any discussion on this topic on the Orekit forum, so I’d like to hear the team’s opinion on the matter. Thank you!

2

Hi @dstrobel welcome!
You are right. Delta mass and I think also duration should be optional.
I see that frame, epoch ignition and velocity increments are also optional as per CCSDS standard, but I am not sure what we could do if they are missing. If someone declares a maneuver without any data, it is pointless.
So I guess we should just change the completed method to remove the check for duration and delta mass.
Could you open an issue for this on our issue tracker?

3

Luc,
Thanks for the quick reply! Yes, I’ve just submitted a request for approval to create an account on the Orekit Gitlab and will post an issue there once I’m admitted.

Regarding the other fields, I agree that CCSDS doesn’t provide a satisfying provision on how to treat them… I do agree that practically speaking, specifying a maneuver with e.g. a velocity increment and no reference frame is impossible to interpret physically since there is no default maneuver frame in the standard, but I wonder whether it should be the responsibility of the parser to administer this requirement.

Epoch ignition seems to me to be the special case, since it’s this token which signals the beginning of a new maneuver, so it must be required, but I still don’t think that ignoring maneuvers without a dV altogether is the right solution - it seems like they should either be parsed with NaN values (my personal preference since it seems to me closer to the standard as written) or throw a parse error - otherwise, the user will have no way to know that the file contains data that was not processed.

In terms of implementation, perhaps this could be achieved in processManeuverToken by adding currentManeuver to maneuverBlocks upon receipt of a new MAN_EPOCH_IGNITION token if currentManeuver is not null.

4