Hi all.
I’m trying to use the DSST propagator. I want to put in it the earth gravitational field up to 10,10 (order and degree).
So I add DSSTTesseral up to 10,10. Is it sufficient, or I have to add also DSSTZonal?
In summary, are the zonal forces included in tesseral forces if I add them up to 10,10?
Thanks in advance.
I think that DSSTZonal is needed, otherwise the results are bad, while including it they are good.
Hi Bryan,
Yes they are very much needed! As you found out yourself 
Hi @MaximeJ, I’ve a question related to this topic. I’m trying to use DSST propagator to propagate mean elements adding the geopotential up to a certain order and degree:
provider = GravityFieldFactory.getUnnormalizedProvider(3, 3)
dsstProp.addForceModel(DSSTZonal(provider))
dsstProp.addForceModel(DSSTTesseral(ITRF, Constants.WGS84_EARTH_ANGULAR_VELOCITY, provider))
But I notice that the propagation result does not change if I include the line for DSSTTesseral, or also if I change the degree (for example using in the provide 4,1 4,2 4,3 4,4).
Am I wrong in adding tesseral forces? Or they are not relevant in the propagation?
Hi @Bryan
That’s a strange behaviour. Could you provide a runnable script in order to investigate your issue?
Thank you!
Bryan
Thank you for providing the code. I tested the impact of DSSTTesseral by displaying the position and velocity of end_state parameter.
Pos: {2 005 373,7334269823; -6 736 187,734305549; 767 642,7271911697}
Vel: {-1 259,8884086102; 474,9381960373; 7 387,2564526759}
Pos: {2 005 373,7334269823; -6 736 187,734305549; 767 642,7271911697}
Vel: {-1 259,8884086102; 474,9381960373; 7 387,2564526759}
It is indeed strange!
I quickly investigated your problem. I saw that the tesseral contribution is equal to 0.0 because they are no resonant terms for your orbit. For DSST mean orbit propagation no resonant terms means no tesseral contribution.
I first saw that these terms are only initialized in case of OSCULATING propagation mode. It is an ugly bug of Orekit DSST.
I quickly fix it by adding an initialization. However, no resonant terms were found for your orbit.
Honestly, I don’t know why they are no resonant terms for your orbit… I need to investigate it more to understand.
The only thing I can recommend you is to keep the DSSTTesseral because I think that the issue is very specific to some orbits.
Bryan
Hi @bcazabonne, and thanks a lot for your answer. So I’ve a general question: what the DSSTTesseral add as force model? I thought that It simply adds the harmonics up to the chosen order/degree. How does resonance has to be intended?
Another doubt: If I add zonal and tesseral, don’t I miss the sectorial? Are they included in the tesseral?
Many thanks in advance for your help
Bryan
Yes, secorial terms are included in DSSTTesseral.
Let “n” be the degree and “m” the order of the Earth’s geopotential terms.
For mean elements propagation, only the resonant terms are considered by the DSSTTesseral. The condition to consider if a term is resonnant or not depends on the orbital period and the central body period.
Ok clear but,
Why only resonant terms are taken into account? If some terms are not resonant they’re not necessary for MEAN propagation?
Otherwise, why it’s not possible to simply take harmonics up to a certain order/degree?
Another thing to better understand, the resonance (in my case) is a condition about the satellite period and the earth rotation (about its rotation axis)?
That’s the question I would like to answer in order to understand why they are no resonant terms for your orbit.
The non resonant terms are only used for DSST OSCULATING propagation mode.
That’s already the case when you call
GravityFieldFactory.getUnnormalizedProvider(3, 3). You limit the harmonics to degree and order 3. Therefore, you will have J(2, 0), J(3, 0) added by DSSTZonal and J(2, 1), J(2, 2), J(3, 1), J(3, 2), and J(3, 3) added by DSSTTesseral.
The only thing in this specific case is that DSSTTesseral contribution is equal to 0.0 because any of the order is consider as resonant.
Yes. For more details you can look at the implementation of getResonantAndNonResonantTerms
Hi @Bryan
Could you please open an issue on the Gitlab repository for the following issue:
Thank you
Bryan
Thank you very much!
Hi guys,
Jumping in the conversation.
I think there are no resonant terms because of the orbital period of your orbit @Bryan.
With a = 7070966.981581845, the orbital period is T_{orb} = 5917.376s, so there are 14.56 orbits per sidereal day (T_{E} = 86164.1006s).
Resonances happen when m * T_E/T_{orb} is an integer where m is the order of the gravity field coefficient (from 1 to the max order selected).
So if you choose for example T_E/T_{orb}=14 (a=7258689.658m), you will get a resonant term for each m multiple of 14 (m=14, 28, 42, etc.)
Or if you choose T_E/T_{orb}=14.5 (a=7090849.227m), which is closer to your initial orbit, you will have resonant terms for m=29, 58, etc.
I think it’s alright because the method DSSTTesseral.initializeShortPeriodTerms is called in DSSTPropagator.beforeIntegration, no matter the PropagationType.
(In fact, I did test it in tutorial DSSTPropagation and I could see the resonant terms being initialized when choosing proper values for the semi-major axis and (degree, order) of the gravity field).
However I admit it’s weird to initialize data for computing mean elements in a method called “initializeShortPeriodTerms”, we should probably split the method getResonantAndNonResonantTerms into two.
I think the method shall move to the init method of the force model
Agreed yes