[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Ephemeris Writer Interface


Hi all,

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


Blocking factor is used in formats like OEM and STK E-files as a way of
specifying interpolation boundaries.  This is important if there is a
maneuver so that you don't try to fit a curve that straddles the state
change. So if you had a finite maneuver in your ephemeris span you may have
the first block be pre-maneuver, the second block during the maneuver, and
the third block after.


I noticed we do not provide any user-friendly way to go from a parsed OEM
to a usable ephemeris-based propagator. Use has to get the blocks, and then
to get the lines and set up the interpolation. We should probably add this.
Does anyone has some code already available for this part too or should I
write it? It is quite straightforward to do?

Luc



On Tue, Nov 1, 2016 at 4:41 PM, Evan Ward <evan.ward@nrl.navy.mil> wrote:




On 11/01/2016 02:38 PM, Hank Grabowski wrote:

One of the reasons I like generating files off off the pre-propagated
ephemeris versus insitu during the propagation is to get around some stuff
like that.  However it will create problems for formats that do blocking
factors et cetera.  It could also just be hold over from my old AGI days...


Thats a good point that using the result of ephemeris mode is less likely
to have the stopping early problem. Though it is still possible for the
ephemeris mode propagation to stop early if the user adds a new event
detector to it. I think using OrekitFixedStepHandler as the interface for
an ephemeris writer will work in both situations. Both for the original
propagator and for the BoundedPropagator produced from ephemeris mode.

What is the blocking factor you're referring to?

Best Regards,
Evan



On Tue, Nov 1, 2016 at 12:11 PM, Evan Ward <evan.ward@nrl.navy.mil> wrote:


On 10/25/2016 01:20 PM, Hank Grabowski wrote:


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. 



Hank, if you push up your OEM writer code I can help adapt it.


On 10/26/2016 09:32 AM, MAISONOBE Luc wrote:



Evan Ward <evan.ward@nrl.navy.mil> a écrit :

On 10/26/2016 08:30 AM, MAISONOBE Luc wrote:





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();



For the most part, yes. To provide a couple more details of what I'm
thinking:

Appendable out = ...;
Frame frame = ...;
TimeScale scale = ...;
OEMWriter writer = new OEMWriter(out, frame, scale, metadata);
Propagator propagator = ...;
propagator.setMasterMode(step, writer);
propagator.propagate();
// close out if necessary

The EphemerisWriter interface could provide methods such as getFrame(),
and getTimeScale(), but these methods don't seem especially necessary. I
think the writer can use the isLast parameter of handleStep(...) to figure 
out when to write the footer, if the file format has one.



Very good! I did not thought about this.

Do you see a case where we would need an explicit close() or flush()

method for the EphemerisWriter? If it turns out that we don't need any
additional methods beyond those in OrekitFixedStepHandler then we can just use that interface, with some documentation explaining the intended usage. 



No, I don't see why we should close the EphemerisWriter ourselves. If the
Appendable used also implements Closeable, the user should still close it
after the ephemeris is completed.





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.



I pushed up a commit that added the step size to the init(...) method.
I think this helps reduce the duplicated information that could become
mismatched.



This is fine with me. With this change and Pascal's change about
atmosphere, I guess next version will be 9.0.



It recently occurred to me that one aspect of using the target date from
the init() method of the OrekitFixedStepHandler to write the header for an
ephemeris file is that the header may be wrong if propagation stops early
due to an exception or due to a Action.STOP event. If propagation stops
early due to an exception I think it is acceptable to leave a half finished
ephemeris file as there is not much else that can be done. For stop events
my preference would be to leave the ephemeris file half finished as well
and just add some documentation recommending that the user not use stop
events when writing an ephemeris. The alternative is to buffer the entire
file in memory and then write the correct header for the data received,
regardless if the propagation made it to the target date or not. I dislike
this alternative because it can become very memory intensive and is
unnecessary in the common situation.

I'm also going to add an OrekitFixedStepMultiplexer similar to the
OrekitStepHandlerMultiplexer. This new class would be much easier to test
using Mockito (http://site.mockito.org/) for creating mocks in the unit
tests. Can I add a test dependency on Mockito, or is there a preference for
not adding any new test dependencies?

Best Regards,
Evan