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

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

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

> Hello,

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 :
> OREKIT :
> - 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,
Luc

> Best regards,
>
> Yannick



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