I have created a variable thrust maneuver which implementsAdditionalEquations. This is because thrust and Isp depends on tank pressure (defined as a SpacecraftState.additionalState) which is a parameter that evolves along the propagation.

As I am obliged to define my maneuver as an AdditionalEquations and not as a ForceModel I don’t know how I could perform a Thrust Calibration in Orbit Determination as my maneuver is not a ForceModel (where the derivative of the acceleration with respect to the parameter to calibrate is computed from ForceModel.acceleration(FieldSpacecraftState<T> s, T[] parameters)). So that is my question, how could I carry out a Thrust Calibration from a maneuver which has to be defined as an AdditionalEquations. Is there any other alternative ?

I guess you design is related to this thread Question about additional parameters for acceleration computation. I think we are reaching here the limits of what can be done with additional equations. As I said in one of my posts on the previous thread, the equations really belong to the primary state but it was possible to use a workaround by using a rarely used feature of additional equations (the fact they can tinker with primary state derivatives). Basically, we changed the derivatives surreptitiously without the integrator noticing it. In order to do a calibration, we need the integration to know about these derivatives, and to know that these derivatives depend on a parameter, and to extract the Jacobian of the time derivatives with respect to the parameter so the orbit determination can wrap everything up and adjust said parameter so the after maneuver orbit fits measurements.

I think we need to add a feature for that, we cannot rely anymore on workarounds. Such a feature would rather be a way to allow ForceModel implementations to see the additional states so it can depend on it. This means we should probably answer more properly to the initial thread and then get all the features already available on force models (including calibration or estimation of force models parameters in OD).
This feature would also imply changes in both Orekit and Hipparchus, but this is something we can do.

Thank you so much for your answer.
As you say, my design is exactly what you proposed in that thread.

So basically, it is not possible to do a calibration of a maneuver which is defined as an AdditionalEquations, isn’t it? It has to be necessarily a ForceModel so that integration knows about those derivatives… I understand. It would be any other different and possible way to attack this problem?

The feature in which ForceModel implementations could see additional states seems very interesting and useful, but I guess it’s not a simple thing and it would take time.

Well, here is an ugly hack that you may try. It’s just off the top of my head, so you will have to check by yourself. The idea would be that you set up:

your specific force model implementation with a method setLastKnownStepInterpolator

a step handler that has a link to your force model and can call the setLastKnownStepInterpolator whenever its handleStep method is called, to pass the step interpolator to the force model at the end of each step

Then, when your force model needs to retrieve the additional state, it would use the last known interpolator and call lastInterpolator.getInterpolatedState(state.getDate()).getAdditionalState("tankPressure"). Then it could used it to compute its acceleration.

The drawbacks are:

it is ugly and breaks modularity

you get the additional state extrapolated from the previous step (the last known). I think tank pressure evolution is smooth enough that extrapolation from one step to the next one is not critical, but you will have to check

I’m not sure you can add your own step handler directly in the orbit determination, but it is probably simple to modify Orekit to add this feature and use chaining between the OD own step handler and the one you need.