To do this, I need to compute the time derivative of the gravitational potential. I wonder if any of you have already easily calculated this derivative using Orekit methods?
The only method that comes to mind would be to field the “value” and “nonCentralPart” methods from HolmesFeatherstoneAttractionModel (these methods do not support field at the moment) and use UnivariateDerivative1. What do you think?
I wonder if for time derivative it would not be easier to provide an ad hoc method. But for sure a Field method would be more general and could be helpful for further evolutions.
I’m surprised that nonCentralPart doesn’t have a Field equivalent already. However if contributed it should not be in the HolmesFeatherStone class which is already quite busy.
For now you might be able to use Field as is via the acceleration method and the derivate/integrate methods of DerivativeStructure.
A long time ago, there was such an implementation, and it was used for computation as force models are really based on gravity field gradient and not gravity field value. This was removed because it had awful performances in terms of computation time.
I don’t know, I’ve not thought about it. I just think that for readability and maintenance we should avoid classes that are 1000+ lines long. Evaluating the potential itself is not the main role of the gravity force, so it could definitely go elsewhere.
I understand your point about classes > 1000+ lines long but in this case i would say it should be its responsability to be able to give its derivative w.r.t time. Unfortunatly with Java, with get x2 lines because of Field equivalent code and after taking a look, there are not that many methods but each of them are quite long.
Another solution would be to move everything related to derivatives including current gradient method into another class but i have not thought of such an architecture yet.
Hum I disagree: HolmesFeatherStone is a ForceModel. As such, its main responsibility is to implement acceleration. The potential itself is a scalar function and its evaluation brings absolutely nothing to numerical propagation. So we could definitely have a dedicated class for the potential function, with possible class composition (or something else to avoid duplication) with the force model.
Indeed, i forgot we were in HolmesFeatherStone and not inside a potential. Then it would indeed make more sense to add such function to the GravityFields interface. Perhaps inside SphericalHarmonicsProvider instead ?
I’m not sure. There is no Field yet in SphericalHarmonicsProvider, so maybe it’s better to keep it that way. I’m afraid we need a new class, SphericalHarmonicsPotentialEvaluation or something
@rcuvilllon
About your original question, I’ve not checked it numerically against finite differences, but this might work:
private double compute(final HolmesFeatherstoneAttractionModel hfModel,
final FieldAbsoluteDate<DerivativeStructure> fieldDate,
final FieldVector3D<DerivativeStructure> fieldPosition) {
final Field<DerivativeStructure> field = fieldDate.getField();
final TimeStampedFieldPVCoordinates<DerivativeStructure> fieldPV = new TimeStampedFieldPVCoordinates<>(fieldDate,
fieldPosition, FieldVector3D.getZero(field), FieldVector3D.getZero(field));
final FieldAbsolutePVCoordinates<DerivativeStructure> absPV = new FieldAbsolutePVCoordinates<>(FramesFactory.getEME2000(),
fieldPV);
final FieldSpacecraftState<DerivativeStructure> fieldState = new FieldSpacecraftState<>(absPV);
final FieldVector3D<DerivativeStructure> acceleration = hfModel.acceleration(fieldState, hfModel.getParameters(field));
final DerivativeStructure potential = acceleration.getX().integrate(0, 1); // integral over X
final DerivativeStructure rate = potential.differentiate(3, 1); // differentiation over T
return rate.getValue();
}
assuming you’ve built the DerivativeStructure date and position with independent variables X, Y, Z and T (time) at order 2
Thanks a lot for the code snippet. In my project I chose to duplicate the HolmesFeatherstone class and to field the methods I’ve mentionned then use UnivariateDerivative1. I’ll try your code to see if there is a significant difference between the two in terms of computation time, as Luc mentionned.
Cheers,
Romain