schaubh
commented
7 months ago scenarioBasicOrbit.py is using a point mass gravity model and doesn't have any planet states. That is why the planet is not seen rotating. See the example that uses the SPICE data to pull full planet ephemeris.
Regarding super-imposing multiple gravity models, that has not been a use case for us. I'm not saying it is not possible, but I'd recommend reading through the gravity effector code to see if it is possible to have more than one gravity model active.
Describe your use case Hello all, I've a propagation scenario where I'd like to only consider main body inhomogeneous gravity. That gravity is based on the superpositions of >1 gravity models subscribing to the same ephemeris message. I think that does not suit well for the alternate "isCentral" flag and I got a weird result going that way (maybe because it's adding other models as 3rd body perturbations?).
My proposition is to have something similar as the computeAttitudeFlag for orbit computation in planetEphemeris (I could try to implement it). So one can place the planet static at origin with not translation but only rotation. Would that make sense?.
Right now, the first paragraph setup only works if Sun is added as a grav body (that way, spacecraft dynamics moves accordingly with asteroid ephemeris) but that induces a perturbation on the satellite that I'd like to remove for my analysis.
Describe alternatives solutions you've considered
Additional context I've been also checking scenarioBasicOrbit.py with the spherHarm option activated to get ideas (as there is no planetEphemeris module there) and I think that simulation is lacking Earth's rotation. Is that an intended behaviour?.
If I print dcm from N to planet rotating frame in gravityEffector
I got identity matrix every time (not the most professional debugging Iol)
PS: I could also PR mascon gravity model + a modification I did to polyhedron (they are done with the new gravity refactor) if that's also of interest