Bug in parsing CDM

Hello everyone,
I’m currently parsing a CDM using the Python Wrapper (I don’t know if this issue exists also in the Java version) and I encountered a pretty annoying bug.

My code is this (very very simple :laughing:):

parser = ParserBuilder().buildCdmParser();
cdm = Cdm.cast_(parser.parseMessage(DataSource("CDM.txt")));

The error returned is this

    Java stacktrace:
org.orekit.errors.OrekitException: unable to parse element CNDOT_TDOT at line 86, file CDM.txt
	at org.orekit.files.ccsds.utils.lexical.ParseToken.generateException(ParseToken.java:678)
	at org.orekit.files.ccsds.utils.lexical.ParseToken.getContentAsDouble(ParseToken.java:203)
	at org.orekit.files.ccsds.utils.lexical.ParseToken.processAsDouble(ParseToken.java:459)
	at org.orekit.files.ccsds.ndm.cdm.RTNCovarianceKey.lambda$static$20(RTNCovarianceKey.java:92)
	at org.orekit.files.ccsds.ndm.cdm.RTNCovarianceKey.process(RTNCovarianceKey.java:187)
	at org.orekit.files.ccsds.ndm.cdm.CdmParser.processCovMatrixToken(CdmParser.java:645)
	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.NumberFormatException: For input string: "-0.0000007002540315737258[m**2/s**2]"
	at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
	at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
	at java.lang.Double.parseDouble(Double.java:538)
	at org.orekit.files.ccsds.utils.lexical.ParseToken.getContentAsDouble(ParseToken.java:201)
7 more

The issue is caused by the fact that the value of the variable has so many digits that it reaches the bracket of the units. I tried to manually remove the last digit in the CDM file and the parser works fine. I think this is a bug, even though it’s probably a very rare one.

Hi Emiliano,

As per CCSDS definition of CDMs in the blue book of 2013, when units are displayed in KVN format, there must be at least one blank character between the value and them (page 6-4).
So this is not a bug, but an invalid file.


Hi Romain,

Oh I see, so it’s Space-track’s fault for not following the protocol :laughing:
Also, while parsing another CDM I encountered this error:

JavaError: <super: <class 'JavaError'>, <JavaError object>>
    Java stacktrace:
org.orekit.errors.OrekitException: value for key OBJECT has not been initialized
	at org.orekit.files.ccsds.section.CommentsContainer.checkNotNull(CommentsContainer.java:76)
	at org.orekit.files.ccsds.ndm.cdm.CdmMetadata.validate(CdmMetadata.java:143)
	at org.orekit.files.ccsds.ndm.cdm.CdmParser.finalizeMetadata(CdmParser.java:224)
	at org.orekit.files.ccsds.ndm.cdm.CdmParser.processGeneralCommentToken(CdmParser.java:547)
	at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.process(AbstractMessageParser.java:180)
	at org.orekit.files.ccsds.utils.lexical.KvnLexicalAnalyzer.accept(KvnLexicalAnalyzer.java:163)
	at org.orekit.files.ccsds.utils.parsing.AbstractMessageParser.parseMessage(AbstractMessageParser.java:139)

By looking at the file itself, the field OBJECT has the value OBJECT1 (and OBJECT2) just like other CDMs that are being parsed perfectly fine. I don’t understand what is causing the problem.


Hi Emiliano,

As you can see here for instance, spacetrack does not necessarily follow to the letter CCSDS standards. I encourage you to contact them though as the same link shows some reactivity on their part.

As for your second error, I would suspect a missing mandatory field or on the contrary one that should not be here. Is the order of keys different to other files correctly parsed?


Yes, you’re right. It’s again an issue with a field being reported wrong. In this case the COLLISION_PROBABILITY and COLLISION_PROBABILITY_METHOD (pretty important ones :rofl:) are missing their values. Damn you, Space-track!

Thanks for the help!
Best regards,