so today I got my hands on the brand new CDM parser (through the Python wrapper, but that should be of no consequence) and I’m getting an error at first try:
org.orekit.errors.OrekitException: valeur non initialisée pour la clef TIME_SYSTEM
at org.orekit.files.ccsds.section.CommentsContainer.checkNotNull(CommentsContainer.java:76)
at org.orekit.files.ccsds.section.Metadata.validate(Metadata.java:50)
at org.orekit.files.ccsds.ndm.cdm.CdmMetadata.validate(CdmMetadata.java:122)
at org.orekit.files.ccsds.ndm.cdm.CdmParser.finalizeMetadata(CdmParser.java:206)
However, ‘TIME_SYSTEM’ is not a CDM field (not a mandatory one nor an optional one), as times are always UTC there. So I’m guessing this is a bug inherited from reused code for ODMs? Or maybe I’m misusing Orekit?
Sidenote: avoid errors in French maybe?
EDIT : here is the code
from org.orekit.data import DataSource
from org.orekit.files.ccsds.ndm import ParserBuilder
from org.orekit.files.ccsds.ndm.cdm import Cdm
if __name__ == "__main__":
file_name_and_path = "kvn3"
data_source = DataSource(file_name_and_path)
parser = ParserBuilder().buildCdmParser()
Cdm.cast_(parser.parseMessage(data_source))
You are right, there is a bug here.
You can fix it by removing the call
super.validate(version);
at line 122 of CdmMetadata.java. Indeed, this keyword is mandatory in all NDM based messages (APM, AEM, OMM, OPM, OEM, OCM, TDM) but not in CDM. Therefore, line 164 in the same file, which sets the time system to UTC is also suspicious, but may in fact still be required so dates are properly parsed, this is something we have to check.
Could you open a bug report for this?
Concerning the message in French, this occurs because your computer is configured in French. Orekit supports error messages in English, French, German, Danish, Spanish, Italian, Romanian, Greek, Galician and Norwegian (but some languages are incomplete). If a language is not supported, then Orekit will fall back to English. If you know someone who could contribute another language, we would also be happy to include it!
Ok, I’ll create an issue. However I’m surprised this didn’t raise errors in Orekit’s tests, where some CDMs are read (I tried to read them from Python and it’s fine). The code should still encounter that line there no?
I didn’t know about all the supported languages through the computer config. That’s pretty awesome!
I guess he OBJECT keyword (which is also mandatory) is missing in your file and the time system is forced to UTC when this keyword is parsed (and the CdmMetadata.setObject() is called).
As super.validate() is called before checkNotNull(object, CdmMetadataKey.OBJECT); is called, we get the wrong error message.
Turns out I do have the OBJECT keyword. But I think I understand what’s happening. The CDM I’m trying to read follows the 1.0.1 guidelines (from the CCSDS 508.0-P-1.0.1 Pink Book from Decembre 2020). However this document seems to have vanished from the internet, replaced by CCSDS 508.0-P-1.0.2 Pink Book from March 2022.
The latter is accessible here:
Anyway both in 1.0.1 & 1.0.2 there is for example a keyword “CONJUNCTION_ID”, not accepted by Orekit but not explicitly rejected either.
Are Pink books draft versions or released versions of the format?
I ask the question because, in my opinion, fixing an official version can be done in a patch release while be compatible with a draft (or new) version is an a new feature (or an improvement) that can be done only for minor or major release.
if I’m not mistaken, pink books are draft releases!
What could be targeted for a patch maybe is that Orekit does not crash when encountering the new fields, but does not interpret them either?
I believe I have found another bug, more problematic:
Orekit (at least the Python wrapper) cannot read CDMs where the field ‘MANEUVERABLE’ (for any object) is set to ‘N/A’:
org.orekit.errors.OrekitException: impossible d’analyser l’élément MANEUVERABLE de la ligne 68 du fichier kvn7
at org.orekit.files.ccsds.utils.lexical.ParseToken.generateException(ParseToken.java:611)
at org.orekit.files.ccsds.utils.lexical.ParseToken.toEnum(ParseToken.java:659)
at org.orekit.files.ccsds.utils.lexical.ParseToken.getContentAsEnum(ParseToken.java:175)
at org.orekit.files.ccsds.utils.lexical.ParseToken.processAsEnum(ParseToken.java:354)
at org.orekit.files.ccsds.ndm.cdm.CdmMetadataKey.lambda$static$12(CdmMetadataKey.java:70)
at org.orekit.files.ccsds.ndm.cdm.CdmMetadataKey.process(CdmMetadataKey.java:115)
at org.orekit.files.ccsds.ndm.cdm.CdmParser.processMetadataToken(CdmParser.java:375)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:180)
at org.orekit.files.ccsds.utils.lexical.KvnLexicalAnalyzer.accept(KvnLexicalAnalyzer.java:137)
at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.parseMessage(AbstractMessageParser.java:139)
Caused by: java.lang.IllegalArgumentException: No enum constant org.orekit.files.ccsds.ndm.cdm.Maneuvrable.N/A
at java.lang.Enum.valueOf(Enum.java:238)
at org.orekit.files.ccsds.utils.lexical.ParseToken.toEnum(ParseToken.java:652)
… 8 more
But ‘N/A’ is a valid value for this field, including in the 1.0 version of CDMs.
Should I open another issue?
I saw that there are already two merge requests fixing the two separate issues, that’s awesome.
I also saw that the field ‘CONJUNCTION_ID’ from 1.0.2 was added as an accepted field, that’s great but there are many other fields from version 1.0.2 than just this one (e.g. ‘MAHALANOBIS_DISTANCE’), so maybe this would require a dedicated branch/issue?
You’re right. Could you maybe add this request in the issue description?
I think the best solution is to continue the development on the current opened branch.
