I’ve run into a problem that must have a solution, but I can’t seem to find it. I’m trying to determine visibility windows for hundreds of sensors at a time, and I found that using a full numerical propagator ended up taking a massive amount of time to do this, since it has to re-propagate for every sensor-satellite pair (to ensure the event detectors are all triggered appropriately). I decided to try propagating in ephemeris mode into a BoundedPropagator and using that for my ‘propagator’ to determine sensor visibility, and then attach all my detectors to the BoundedPropagator before determining visbility windows. What I found is that only the larger windows were detected using the ephemeris generated by the numerical propagator, but when I used the propagator itself, it was able to find all the windows I would expect for a given time. I’m guessing there is some timestep issue on the ephemeris, but I’ve tried using fixed step handlers to create the ephemeris, as well as setting my max prop step on the numerical propagator, but I get the same incorrect results. Here’s what I have (below), do you have any ideas how I can get the same accuracy from an ephemeris that I do from the numerical propagator?
// This factory produces a NumericalPropagator with drag, srp, lunar/solar grav, etc
Propagator prop = PropagatorFactory.getPropagator(sat.getInitState(),sat.getFrame(), sat.getPropConfig());
EphemerisGenerator ephemGen = prop.getEphemerisGenerator();
prop.propagate(start, start.shiftedBy(2 * 86400));
BoundedPropagator ephem = ephemGen.getGeneratedEphemeris();
// This method attaches the appropriate detectors, and then propagates (2 days) to compute triggered
// event windows. Feeding in the ephemeris results in only two windows (incorrect), but the propagator
// results in six windows (correct)
List<AccessWindow> windows = SensorCoverage.computeAccessForOneSat(sat, ephem, sensors, start, 2880.0);
This is strange because the ephemeris generated by a propagator should always have the same accuracy as the propagator, even if using variable step size. This is because in fact an ephemeris is just built by storing the step interpolators provided by the underlying integrator, so theoretically, there should be no differences at all.
What is the approximate size (in seconds) of the smaller windows that are undetected?
What is your step in the step handler? Your max prop step? And the maxCheck in your ElevationDetectors ?
Have you tried lowering this last one?
If it makes any difference, my test case was using the calibration satellite Stella which was passing over a LEO capable radar with a unique field of regard (defined using a GroundPolygonFieldOfViewDetector, which was verified against STK, and seemed to be working correctly with the numerical propagator). The propagation duration was 2 days.
The window sizes are shown below in the STK section, and my max prop step is 60s, which is consistent with the size windows it produced with the propagator. The maxCheck is whatever the default value is, so I’ll look at that to see if it fixes the issue.
The windows for the ephemeris were generated in 5 seconds and produced the following for 78 total sensors in the run:
The interpolator scheme is the same but the step history would be different , hence the interpolator “settings” too right? If the event detector is included in the integration, it will affect the propagation noise, in particular because it might have been forced to perform smaller steps. Anyway the error would be tiny. But if the max check with the ephemeris is big, it might miss some windows.
It looks like the detector MaxCheck was the issue! That said, once I set the smaller step (from 600 down to 60 seconds) it slowed the process down quite a bit (took 46 seconds as opposed to 5). I’m going to try and parallelize the process a bit more to see if I can bring down the run times a bit further.
You can try using the custom AdaptableInterval that Luc implemented for ElevationDetector. I don’t have the code in front of me, should be called ElevationDetectionAdaptableIntervalFactory or something.