Re: [Orekit Developers] Next Orekit Version

[Evan Ward <evan.ward@nrl.navy.mil>]

Hi Hank,

On 02/12/2016 01:29 PM, Hank Grabowski wrote:

I'm not sure I'm following the propagator changes you are talking about.  Are you looking for an object that manages multiple propagators and the I/O to and from Orekit or for something else?  For some projects we've written readers and writers to proprietary formats and it has worked pretty well except for some performance problems with the lookup ephemeris propagator.

My goal in this change is to make it easier to load a file and get a Propagator. For example, adding a method to OrbitFile with the form

public BoundedPropagator getPropagator(String satId) {...}

Currently I think there is a lot of repeated code in converting a List<SatelliteTimeCoordinate> to a List<SpacecraftState> and then creating a new Ephemeris

I'd be interested in exploring the derivative structure and STM stuff.  We are trying to use that for covariance propagation and uncertainty analysis.

Excellent. I see that the AdditionalEquations interface can also compute an effect on the main state equations. So I'm thinking that when a NumericalPropagator has a PartialDifferentialEquations added to it then the propagator would skip computing the main state accelerations and leave it up to the PartialDifferentialEquations. Would someone more familiar with the code (such as Luc or Véronique) be able to comment if this is a sane approach?

I've also noticed that PartialDifferentialEquations assumes that d(mass dot) / d(force model parameter) is zero, but I think this assumption is violated for the mass flow rate parameter in ConstantThrustManeuver.

Regards,
Evan

On Thu, Feb 11, 2016 at 11:53 AM, Evan Ward <evan.ward@nrl.navy.mil> wrote:

Hi,

Now that 7.1 has been released I've started thinking about the next
version. Are we targeting a 7.2 release or an 8.0 release?

One thing I would like to include in the next version is better
integration between the ephemeris load/save classes and the propagator
classes. I've come across some instances where I need to perform event
detection on an ephemeris file the same way I would a propagated
trajectory. I would like to add a method for getting a BoundedPropagator
for each satellite in a OrbitFile. I think this would involve setting
some default values, perhaps in the constructor for the orbit file
reader. I would also like to combine all of the getX(satId) into one
method that returns an object with all of those properties. Or perhaps
just return a map. On the writer side I think it would be good to have
an OrbitFileWriter that takes a propagator and creates an ephemeris
file. I don't think we need to support all the options of every file
format, just some basics such as UTC and ECI or ECEF. Any thoughts on
improving the integration between the propagator interface and ephemeris
files?

Another issue that I've noticed is that using a numerical propagator to
compute the state transition matrix involves evaluating the force model
twice at every evaluation: once for its effect on the main state and
once for its derivatives. Since the DerivativeStructure that holds the
derivatives also holds the acceleration values the first evaluation is
unnecessary. I haven't yet quantified the speed up, but I think it could
be significant if we halve the number of force model evaluations. Using
a single force model evaluation for both the main state and derivatives
might need some API changes as well. Any thoughts on this?

Best Regards,
Evan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature