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

Re: [Orekit Developers] Ephemeris Writer Interface

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,

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, ...);
 propagator.setMasterMode(step, writer);

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);
// 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,