Re: [Orekit Users] Please help me understanding normalizedParameters

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

Le 22/02/2018 à 17:07, Maria Sousa a écrit :
> Dear Orekit group,

Hi Maria,

>  
> I'm been using Orekit mainly for Orbit Determination with considerable
> success (only with simulated data). Thank you for your effort and
> generosity.

Thanks for the kind words, it is really appreciated.

>  
> However, I'm still confused about the normalized parameters and the
> impact on the propagation.
>  
> I am using the NumericalPropagatorBuilder class to build a numerical
> propagator. It is used for propagation and for orbit determination. When
> used for propagation, I build a NumericalPropagator from it providing
> using buildPropgator, with a normalizedParameters argument.
>  
> However, I don't quite understand the effect of these
> normalizedParameters for propagation. I usually provide an array of
> zeros, but I've noticed that if I provide other numbers, the propagation
> results are different.

Generally speaking, the users should use setValue/getValue on parameters
rather than seNormalizedValue/getNormalizedValue. The first methods
use physical parameters which have a physical meaning for users. The
other methods are more intended for internal use by the optimizer,
which don't care about physics but works better when all parameters
are of the same order of magnitude.

As an example, if you have one parameter for eccentricity in a circular
orbit and one parameter for central body attraction coefficient, the
physical values will be of the order of magnitude 1.0e-6 for one and
1.0e+14 for the other, or 20 order of magnitude. As a user, you know
what an eccentrcity is and what an attraction coefficient is, so you
deal with it correctly. The mathematical optimizer on the other
hand gets confused when putting everything in a big double arrays, as
it finds one coefficient is negligible with respect to the other one.

>  
> In addition, I've noticed that after performing an orbital
> determination, if I use the orbit returned by the estimator to build a
> new PropagatorBuilder and use zeroes to get a NumericalPropagator, the
> propagation is slightly different than the propagator returned by the
> estimation. In fact, I can get the same propagation if I extract the
> NormalizedParameters from the estimated propagator and use them as
> normalizedParameters for the new propagator.

If I understand what you do, this is expected.
If you reuse already built parameters drivers, they were created
before orbit determination and their initial value was selected
as the reference value. As you point out later in the mail, the
normalized value is (reference value - current value) / scale.

So for these parameter drivers, setting the normalized value to 0.0,
will always give you back reference value, which was the initial
orbit. If you want the current value, you have to extract it.

> I'm a bit confused by this, as it seems that the orbit returned by the
> estimator is not all the information I need to create a different
> propagator and propagate the same orbit. It seems that I also need the
> normalized parameters, which makes no sense for me as I not understand
> the underlying process.

The orbit should be the only thing needed *if you only estimated orbit*.
If you also estimated some force models parameters (typically drag
coefficient) you need to configure them in the new propagator too.

This is in fact the reason why orbit determination does not return
only an orbit, but instead returns a propagator ready to use, already
fully configured.

>  
> When reading the documentation, I understand that those normalized
> parameters are defined as (reference value - current value) / scale. So
> my first idea is that it should not affect the propagation, as the
> current value is the same in the estimator and in the newly created
> propagator. However, it differs.
>  
> I would need a way to extract an orbit from the estimator that I could
> store and retrieve later to replicate the propagation, without
> additional normalized parameters. In fact I may use that orbit with a
> completely different propagator (not Orekit) where those parameters have
> no use.

There are two ways to extract estimation data as orbit determination.

The first one is to call getOptimum().getPoint(). However, this will
give you the mathematical view of the optimization problem, i.e. with
normalized parameters only and with orbit and model parameters packed
in a single array that you need to dispatch by yourself. I would not
recommend this.

The second and better solution is to call the methods
getOrbitalParametersDrivers to get the drivers used for the orbit, and
getPropagatorParametersDrivers to get the parameters drivers used for
the force models (and you could also call
getMeasurementsParametersDrivers to get for example measurements
biases). From the parameters drivers that suit your needs, you can just
use getValue (not getNormalizedValue()) to have the physical parameters.

If you really want only the orbit itself and don't care about the
force model (if you did not estimate drag or anything else), there is
a third solution, even simpler but limited to orbit. This solution is
to use the returned propagator and call getInitialState().getOrbit()
on it. This is the estimated orbit as by definition the propagator has
been completely set up to start from the estimated orbit.

>  
> Could you help me to understand this behaviour?

Hope this helps.

Best regards,
Luc

>  
> Thank you for your help.
> 
> 
>