[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Problem with angle event detectors in OREKIT

Tanguy Yannick <Yannick.Tanguy@cnes.fr> a écrit :


Hi Yannick,

We have implemented some additional Event detectors, using Commons-math and Orekit functionnalities. Some of these detectors aim at detecting specific angular values crossing. Example:
 Anomaly Detector
 Argument Of Latitude Detector
 LocalTime Detector
 SolarTime Detector
or extremal values:
 Extrema Elevation Detector

 Extrema DistanceDetector
 Extrema LatitudeDetector

In all these cases, the user is frequently interrested in only one of the zero types of the commutation g function (only the ascending zeros, or only the descending ones). For example:
Argument Of Latitude detector (with g function like sin(AoL-AoLref))
SolarTime Detector : noon only
Extrema Elevation: only the maximal elevation from the stations
Apsides Detection: only apogees.
Extrema Distance: only minimal distance...

Especially when the user wants to compute the Events Log on a long period (as done frequently in operationnal FDS) it is non optimal to compute events which are not used (half of them are unuseful). The same problem is for Nodes or Apsides Detectors.

To solve this problem for angular detectors we tried a special formulation of the g function (like sin(alpha/2)) with the aim to cross zero only for the requested events (both ascending and descending are useful). This led to difficulties linked to the fact that all propagators do not give angular parameters in the same range (some propagators don't use a modulo 2*Pi).

This is on purpose. Performing arbitrary normalization between 0 and 2PI (or -PI and +PI) in the middle of a computation has a lots of drawbacks:

 - it is inaccurate
   the normalization process always loose some bits, this is exactly the
   reason why the trigonometric functions (sin, cos, tan ...) use specific
   algorithms for argument range reduction like Payne/Hanec or Cody/Waite
 - it is often not useful
   normalization is mainly useful for final display (nobody likes to see
   a 10 millions degree true anomaly in an ephemeris), but not for
   intermediate computation as the trigonometric functions are able to
   cope with these huge angles and in fact are more accurate if user does
   *not* attempt to fix them as they have better method to cope with them,
of course, your case is an exception for this rule and you need normalization
   in your case
 - it creates huge problems as soon as you need interpolation, fitting,
   root finding as it introduces artificial large discontinuities in a
   process that is otherwise smooth

We propose to solve the problem by extending the Events Detection function:
allow to specify the type of the zeros of the g function to be detected (at low level: org.apache.commons.math3.ode.events.EventState.evaluateStep):
- all zeros
- ascending zeros only
- descending zeros only

This sounds really interesting.

The advantages are:
- all angular detectors work well with a simple g function (sin(alpha - alphaRef)) without problems of modulo 2 Pi discontinuity management - for some specific events logs computations the computation time will be significantly reduced

Note that as the computation needs to compare previous step and current step to correctly bracket the roots, we still need to switch some internal variables around the ignored zeros. Of course, as we know user is not interested in this zero, we simply updates these state preserving data and do not attempt to refine a zero that will be ignored later. So there will be some savings, but we have to make sure we do not forget some important parts of the algorithm.

- the detector will fit better to user needs (no need to "filter" the useful detections).

This solution needs to modify a few classes :
- EventDetector : add a new int getSlopeSelection to know if we are interested in descending, ascending g function, or both

I'm not sure I understand the purpose of this method. Do you intend it to be overridden by users on all detectors or do you intend it to be implemented directly at AbstractDetector level based on a fixed boolean field provided at construction ? I would prefern the second case, since the type of events user is interested in seems to me to be of the same level as the maxCheck and threshold parameters.

- EventState : depending on the slope selection, detect or not the event (mapping with Commons Math solvers)
- All classes implementing EventDetector

If the type of events desired by users is set as a constructor parameter and if we preserve both the current constructors without this setting (which would default to select all events) and add a new constructor, then modifying the current EventDetectors would be more backawrd compatible: we would mainly add a new setting but would not force people to use it. Existing code would still work without a change.

Commons Math :
- EventHandler : new slopeSelection parameter (see EventDetector)
- EventState : uses the new parameter to decide to call the solver or not

Please ask on the Apache Commons Math lists for this change.

Do yo think this is a useful feature for OREKIT ? If it make sense, we can create features in both Commons Math and OREKIT and contribute our source code.

Concerning Orekit, I think it is useful.

best regards,

Best regards,


This message was sent using IMP, the Internet Messaging Program.