Re: [Orekit Developers] Ephemeris Writer Interface

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Hank Grabowski <hank@applieddefense.com> a écrit :

> Yes, we can contribute the OEM stuff we wrote.  I didn't write it generic
> enough to just drop in but with some refinement it should be there.  I've
> been doing it in a two-step process: propagation to an Ephemeris propagator
> and then sampling the ephemeris propagator.  I've done it the way you
> specified before too.  The advantage is there is no interpolation error.
> The downside is that you are artificially changing the step sizes used for
> numerical integration.

I don't get this. Regardless of using a one step or two steps process to
get the sample, the result should be the same. For analytical propagators,
the ephemeris created is in fact a wrapper and the propagator itself is
still used from the ephemeris interface. For numerical propagator, the
ephemeris is a wrapper on top of the DenseOutputModel from the integrator,
which really simply contains all the StepInterpolator instances created
during integration. This means that at the end, when you ask for a point
at some fixed step dates, you will either end up using the propagator
itself if it is an analytical one, or using a StepInterpolator if you
used a numerical propagator.

Did you observe some differences using one or two steps?

> Things get more interesting with propagations that have maneuvers for a few
> reasons too, but let's try to get the simple case thought out first :).
>
> On Tue, Oct 25, 2016 at 12:03 PM, Evan Ward <evan.ward@nrl.navy.mil> wrote:
>
> > Hi,
> >
> > I'm thinking about creating an interface for writing an ephemeris file
> > from a Propagator and I would appreciate your thoughts on it.
> >
> > At this point I'm trying to figure out what types of ephemeris files
> > should be supported, e.g. OEM, STK .e. These formats as well as several
> > internal formats in use at NRL all have one satellite per file, so my
> > current plan is to create the interface assuming only one satellite. One
> > notable exception to this assumption is the SP3 file format where the
> > states of many spacecraft are listed at each epoch. The SP3 format is
> > specific to GNSS satellites and the Orekit Propagator does not support
> > propagating multiple satellites at the same time, so there is no way to
> > efficiently implement a SP3 writer in Orekit. (All of the states for all of
> > the satellites would need to be buffered in memory.) Given those drawbacks
> > of the SP3 format, my current plan is to not support the SP3 format with
> > the EphemerisWriter interface.

I agree with your rationale.

> > For the most part it seems that the OrekitFixedStepHandler could be used
> > as the interface for an EphemerisWriter.

Do you imply that EphemerisWriter would extend OrekitFixedStepHandler? What
would be the additional methods in this case? So do you intend something like:

  OEMWriter writer = new OEMWriter(file, metaData1, metaData2, ...);
  writer.method1();
  writer.method2();
  propagator.setMasterMode(step, writer);
  propagator.propagate();
  writer.close();


> > One piece of information that is
> > missing is the step size, but that could easily be added to the init(...)
> > method call.

Yes, but if we use constructor for other meta-data, we could also provide the
step size this way.

> > Additional meta data could be passed in through the
> > constructor of the EphemerisWriter, such as frame, time scale, and center
> > name. Given the wide variety of metadata accepted by different formats I'm
> > not planning on standardizing an interface for setting the metadata. I
> > think covariance output could also be supported by providing an initial
> > covariance and a suitable mapper to extract the STM from the
> > SpacecraftState.
> >
> > Hank, are you still interested in contributing your OEM writer and would
> > it fit with the described interface?
> >
> > Are there any other formats that would need to be supported by the
> > EphemerisWriter interface?

I guess the interface should be designed so we provide a few implementations
for well-known formats, but also to let people implement it really easily
for their own mission-specific formats. That is it should be something
closer to OrekitFixedStepHandler, OrekitStepHandler (user-oriented interfaces)
rather than IAUPole or PropagatorConverter (interfaces mainly intended  
for internal use)


Anyway, I think this feature would be really interesting for Orekit.

best regards,
Luc

> > Best Regards,
> > Evan