buildPropagator overwrites spanned parameter values

Orekit usage
1

Good afternoon,

I noticed some unexpected behaviour with propagators based on spanned parameter drivers, and I think this might be caused by a small bug in AbstractPropagatorBuilder. The default implementation of buildPropagator() extracts the normalised parameters from selected parameter drivers:

@Override
public T buildPropagator() {
    return buildPropagator(getSelectedNormalizedParameters());
}

The current implementation of getSelectedNormalizedParameters() does not handle spanned parameters correctly and will use the value at AbsoluteDate.ARBITRARY_EPOCH for each of the parameter spans.

/** {@inheritDoc} */
public double[] getSelectedNormalizedParameters() {

    // allocate array
    final double[] selected = new double[getNbValuesForSelected()];

    // fill data
    int index = 0;
    for (final ParameterDriver driver : orbitalDrivers.getDrivers()) {
        if (driver.isSelected()) {
            for (int spanNumber = 0; spanNumber < driver.getNbOfValues(); ++spanNumber ) {
                selected[index++] = driver.getNormalizedValue(AbsoluteDate.ARBITRARY_EPOCH);
            }
        }
    }
    for (final ParameterDriver driver : propagationDrivers.getDrivers()) {
        if (driver.isSelected()) {
            for (int spanNumber = 0; spanNumber < driver.getNbOfValues(); ++spanNumber ) {
                selected[index++] = driver.getNormalizedValue(AbsoluteDate.ARBITRARY_EPOCH);
            }
        }
    }

    return selected;

}

All implementations of buildPropagator(double[] normalisedParameters) immediately use these parameters to overwrite the underlying ParameterDriver, so the spanned values are lost as a side-effect of calling buildPropagator().

This seems undesirable to me, but I just wanted to check if there is some reason that this would be intended behaviour.

Best,

Simon

2

Hello Simon,

I observed this same problem a while ago (see Bug in OD with multiple CD estimation?). There is already a gitlab issue open about this, so it’s definitely not the intended behavior.

For now, the workaround I use to avoid this problem is to reconstruct the normalized parameters myself using the value during each interval, the reference value, and the scale, and then passing this new set of normalized parameters to PropagatorBuilder.buildPropagator(normParams)

1 Like