RE: [Orekit Developers] Writing an OEM file after anephemerispropagation

[<contact@nicolasrol.fr>]

This possibility would seem a bit strange since the OEM files have a standard recommended by the CCSDS so not following the standard would mean not writing a proper OEM file.

 

However it may be interesting to have a generic class that would allow the users to generate files following the format string they specify. That class could also allow the user to add some meta-data in a different format.

I don’t know if it’s already what is done in Orekit but such class could then be extended to generate the files following the different standards ?

 

 

De : Hank Grabowski
Envoyé le :mercredi 8 mars 2017 18:27
À : orekit-developers@orekit.org
Objet :Re: [Orekit Developers] Writing an OEM file after anephemerispropagation

 

An interesting idea, but maybe a bad one, would be to allow people to specify the format string with a default and a couple of options?

 

On Wed, Mar 8, 2017 at 10:21 AM, <contact@nicolasrol.fr> wrote:

Thanks for your answers.

Writing the OEM file works well indeed !

 

However I would have modified the format of the exported data in OEMWriter.writeEphemeris() in order to respect the CCSDS recommended standard for OEM files. Today, the format is set to « %16.16e » which means 16 digits after the decimal point (for example : -2.9007962960875825e+03) while the CCSDS recommends a mantissa of 16 digits (https://public.ccsds.org/Pubs/502x0b2c1.pdf, §6.5.5).

A better format may then be « %21.14e ». 14 will allow to have a mantissa of 16 digits (1 before the point, the point and 14 after the point) while 21 allows to have a place for the sign (« - »  or a blank space), the 16-digit mantissa and the 4 digit exponent (a character, the sign and a 2-digits integer).

With this format, the previous example would look that way : -2.90079629608758e+03

 

What do you think about it ?

 

Regarding the covariance : thanks, I’ll take a look at those pages !

 

Best Regards,

Nicolas