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

Re: [Orekit Developers] Next Orekit Version



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.

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

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