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

Re: [Orekit Developers] Ephemeris Writer Interface

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