Hank Grabowski <hank@applieddefense.com> a écrit :
Should we create a branch where we can start building out interfaces and class stubs or is there another mechanism for us to hash out the API for this?
A branch would be fine. We don't use enough branches and should force ourselves to these best practices. Luc
On Thu, Nov 3, 2016 at 4:57 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:Hi all, Hank Grabowski <hank@applieddefense.com> a écrit : Blocking factor is used in formats like OEM and STK E-files as a way ofspecifying 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? LucOn 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 itgeneric 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 beused as the interface for an EphemerisWriter.Do you imply that EphemerisWriter would extendOrekitFixedStepHandler? 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'mthinking: 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 ismissing is the step size, but that could easily be added to theinit(...) method call.Yes, but if we use constructor for other meta-data, we could alsoprovide 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