[Orekit Developers] Problem with angle event detectors in OREKIT

[Tanguy Yannick <Yannick.Tanguy@cnes.fr>]

Hello,

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).

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

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
- the detector will fit better to user needs (no need to "filter" the useful detections).

This solution needs to modify a few classes :
OREKIT : 
- EventDetector : add a new int getSlopeSelection to know if we are interested in descending, ascending g function, or both
- EventState : depending on the slope selection, detect or not the event (mapping with Commons Math solvers)
- All classes implementing EventDetector

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

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.

Best regards,

Yannick