(DSST) Effect of lunar shadow in SRP

Hi there,

I am aware that, by default Earth shadow effect (the case where Earth is central body) is considered while computing solar radiation pressure perturbing acceleration. Is there a way to include Lunar shadow also as an occulting body?. If it is already available in OREKIT, can you provide a code snippet on how to use it. In reality, its effect is insignificant, but for the correctness sake, I feel it must be included.

Hi,

Yes it is possible since Orekit 11.0, it is documented here: https://www.orekit.org/static/apidocs/org/orekit/forces/radiation/SolarRadiationPressure.html

1 Like

Hello @Rajesh,

As you pointed out, such change will be interesting if you are looking for really small precision (i would say sub-cm but that’s only a guess). Beware that this will come at an additional computation cost.

It also means that you are also adding all other forces of higher & equivalent magnitude (gravity potential, drag, third bodies, tides, IR emission, relativistic effects) , otherwise it would not make much sense.

Code

You can do so by doing the following (moon flattening is taken from this NASA spreadsheet) :

      // Define Earth body shape
      final IERSConventions  iersConventions = IERSConventions.IERS_2010;
      final boolean          withSimpleEOP   = false;
      final Frame            itrf            = FramesFactory.getITRF(iersConventions, withSimpleEOP);
      final OneAxisEllipsoid earthBody       = ReferenceEllipsoid.getIers2010(itrf);

      // Define moon body shape
      final double           MOON_FLATTENING = 0.0012;
      final Frame            moonBodyFrame   = CelestialBodyFactory.getMoon().getBodyOrientedFrame();
      final OneAxisEllipsoid moonBody        = new OneAxisEllipsoid(Constants.MOON_EQUATORIAL_RADIUS, 
                                                                    MOON_FLATTENING, 
                                                                    moonBodyFrame);

      // Get sun
      final CelestialBody sun = CelestialBodyFactory.getSun();
      
      // Define spacecraft configuration for solar radiation pressure
      final RadiationSensitive radiationSensitive = ...;

      // Define solar radiation pressure force without moon
      final SolarRadiationPressure srp = new SolarRadiationPressure(sun, earthBody, radiationSensitive);

      // Add moon occulting body
      srp.addOccultingBody(moonBody);

Cheers,
Vincent

1 Like

Hi @Vincent and @yzokras,

Good that it is available in numerical propagation. But I could not find a similar thing in DSSTSolarRadiationPressure !

Indeed such option is not directly available for the DSST version. You can open an issue here.

Workaround

After looking through the code, the following constructor is used to create the DSST version of the solar radiation pressure :

protected AbstractGaussianContribution(final String coefficientsKeyPrefix, final double threshold,
            final ForceModel contribution, final double mu) {

        gmParameterDriver = new ParameterDriver(DSSTNewtonianAttraction.CENTRAL_ATTRACTION_COEFFICIENT, mu, MU_SCALE,
                0.0, Double.POSITIVE_INFINITY);

        this.coefficientsKeyPrefix = coefficientsKeyPrefix;
        this.contribution = contribution;
        this.threshold = threshold;
        this.integrator = new GaussQuadrature(GAUSS_ORDER[MAX_ORDER_RANK]);
        this.isDirty = true;

        gaussianFieldSPCoefs = new HashMap<>();
    }

It is called from this DSSTSolarRadiationPressure constructor:

public DSSTSolarRadiationPressure(final double dRef, final double pRef,
                                      final ExtendedPVCoordinatesProvider sun,
                                      final OneAxisEllipsoid centralBody,
                                      final RadiationSensitive spacecraft,
                                      final double mu) {

        //Call to the constructor from superclass using the numerical SRP model as ForceModel
        super(PREFIX, GAUSS_THRESHOLD,
              new SolarRadiationPressure(dRef, pRef, sun, centralBody, spacecraft), mu);

        this.sun  = sun;
        this.ae   = centralBody.getEquatorialRadius();
        this.spacecraft = spacecraft;
    }

You could extend the DSSTSolarRadiationPressure and create a custom constructor that would add the Moon as an occulting body to the input SolarRadiationPressure of AbstractGaussianContribution.

Cheers,
Vincent

Hi Rajesh,

There is an open issue on gitlab (#199) saying that eclipses are ignored with the DSST. Anyway, even if they were not, I would really not bother with adding the Moons shadow in the dynamical model. The semi analytical propagator is already an approximation and adding such small detail is rather useless as other sources of errors are much bigger. See issue #1491 for example.

Cheers,
Romain.

1 Like

Thank you for the additional information :heart:, i was not aware of this issue.

Hi @Serrof,

I fully agree with you, the effect of lunar shadow in SRP (also for Earth shadow) is very benign and it is negligible, for practical purposes.

Moreover, in DSSTSolarRadiationPressure, Earth shadow effect is included as default.

I suggest OREKIT development team to include option in DSST as well as numerical, for considering shadow effects for central body (Earth) and other bodies (e.g. Moon), so that the user can choose to use or not.

As you pointed out rightly, not including the eclipse effect is computationally effective. But for the completeness sake, it can be included optionally.

May be for higher area-to-mass objects it could have a reasonable effect, (I don’t know, just speculating) or for central bodies close to Sun (e.g. Mercury as central body !.. I need to analyze, this could be a good outcome, if a systematic analysis is done)

I’m confused. You can add the shadow of as many bodies as you want with SolarRadiationPressure in Orekit, as Vincent explained. So you can go really high in fidelity with the numerical propagation. As I said, I don’t see the point in having that within the DSST, which suffers other missmodelling problems of higher magnitude. Besides, the point of a semi analytical propagator is to sacrifice a bit of accuracy in exchange for increased computational performance. And actually I think that Orekit implementation could do better on the second point, especially when osculating elements are included in the mix. So that’s where I would put the focus on future developments from my point of view.

Cheers,
Romain.

1 Like