[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 :
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.