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

*To*: orekit-developers@orekit.org*Subject*: Re: [Orekit Developers] Problem with angle event detectors in OREKIT*From*: MAISONOBE Luc <luc.maisonobe@c-s.fr>*Date*: Mon, 02 Jul 2012 14:24:48 +0200*In-reply-to*: <6D12B38919D1A54DA27AE99C5EAAEAD40C7853@TW-MBX-P04.cnesnet.ad.cnes.fr>*References*: <6D12B38919D1A54DA27AE99C5EAAEAD40C7853@TW-MBX-P04.cnesnet.ad.cnes.fr>*User-agent*: Internet Messaging Program (IMP) H3 (4.3.9)

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

Hello,

Hi Yannick,

We have implemented some additional Event detectors, usingCommons-math and Orekit functionnalities.Some of these detectors aim at detecting specific angular valuescrossing. Example:Anomaly Detector Argument Of Latitude Detector LocalTime Detector SolarTime Detector or extremal values: Extrema Elevation Detector Extrema DistanceDetector Extrema LatitudeDetectorIn all these cases, the user is frequently interrested in only oneof the zero types of the commutation g function (only the ascendingzeros, 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 longperiod (as done frequently in operationnal FDS) it is non optimal tocompute events which are not used (half of them are unuseful). Thesame problem is for Nodes or Apsides Detectors.To solve this problem for angular detectors we tried a specialformulation of the g function (like sin(alpha/2)) with the aim tocross zero only for the requested events (both ascending anddescending are useful).This led to difficulties linked to the fact that all propagators donot give angular parameters in the same range (some propagatorsdon't use a modulo 2*Pi).

- 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,

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 bedetected (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 Pidiscontinuity management- for some specific events logs computations the computation timewill 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 areinterested in descending, ascending g function, or both

- EventState : depending on the slope selection, detect or not theevent (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

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

**Follow-Ups**:**RE: [Orekit Developers] Problem with angle event detectors in OREKIT***From:*Tanguy Yannick <Yannick.Tanguy@cnes.fr>

**References**:**[Orekit Developers] Problem with angle event detectors in OREKIT***From:*Tanguy Yannick <Yannick.Tanguy@cnes.fr>

- Prev by Date:
**Re: [Orekit Developers] Attitude class : conventions, problems, solutions and improvements** - Next by Date:
**Re: [Orekit Developers] Detecting two events at the same date** - Previous by thread:
**[Orekit Developers] Problem with angle event detectors in OREKIT** - Next by thread:
**RE: [Orekit Developers] Problem with angle event detectors in OREKIT** - Index(es):