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

Re: [Orekit Developers] Ephemeris Mode & AbstractPropagator



Thomas Neidhart <thomas.neidhart@gmail.com> a écrit :

On 04/01/2012 07:08 PM, MAISONOBE Luc wrote:

The thing I was referring to was the EventDetector interface, which in
my understanding, uses fixed step sizes.

No, EventDetector does not uses fixed step sizes. The maxCheckInterval
is only an often very large setting to avoid missing some events. It is
not related to the accuracy of the event detection.

That's strange, I have experimented a lot with the maxCheck setting and
visibility detectors, and it was missing events if the setting was too
big (e.g. 10 min). Thus I always assumed (without actually looking at
the code), that events that are shorter than the maxCheck setting would
not get detected.

For visibility, it is normal.

Event detection is based on finding roots of arbitrary functions which are expected to be continuous near their roots and to not change sign when they have discontinuities far from their roots. The sign of the function is then checked at t1, t2, t3 ... if sign changes between tk and tk+1, a root has been bracketed (not found yet), and a root solver is called to precisely locate it in the bracketed interval.

This works regardless of t1, t2, t3 ... being on a regular grid or not. However, it works only as long as there is not an even number of roots between tk and tk+1. This is what maxCheckInterval tries to prevent. The various tk are chosen at step ends (which may be variable step size), but if this would imply a time different tk+1 - tk > maxCheckInterval, then intermediate dates are used to ensure we check the function sign at least once every maxCheckInterval seconds.

For events that occur at almost regular intervals (say once or twice per orbit, like equator crossing), setting maxCheckInterval to one half or one third Keplerian period is enough to make sure no event is missed. For events that may be close to each other, maxCheckInterval should be set to the duration of the shortest events pair we accept to miss. This includes visibility and eclipses. If we consider visibilities shorter than one minute cannot be used, then maxCheckInterval should be set to one minute.

Lets give an example. Suppose a visibility is really between 16:10:23 and 16:11:33. It is a 70 seconds visibility. Regardless of the step size, we are sure at least one check point will be between the start and end date, so we are sure we will see the sign change at visibility start, and the dual sign change at visibility end. If however we use a maxCheckInterval set to 10 minutes, we may detect this visibility if we are lucky (i.e. one sign check occurs between the start and end), but we may miss it if one check is at 16:05:00 for example and the next check is at 16:15:00, i.e. at both checks the satellite will be below minimum elevation. Typical values for visibilities are one minute for the maxCheckInterval and 1 second (or far smaller than that if you want) for convergence threshold.

The same thing occurs with eclipses, as you have events pairs with the two dual events may be close to each other.



Maybe changing the behavior of EventDetector#getMaxCheckInterval could
help in such a case. Or do the other classes (EventState,
BasicStepInterpolator) assume this value to be fixed and not changing
throughout the propagation?

I think I begin to understand. Do you want to have maxCheckInterval
being modified by a stepHandler to enlarge and reduce as you know there
will not be any event for some time ? This would imply adding a
resetMaxCheckInterval in the detector interface which for sure is possible.

Yes, that's exactly what I had in mind, sorry for my first post, which
was quite misleading.

OK, this is an interesting feature. Could you open a new ticket for this feature on the forge ?

I think it is easy to implement this, so it would be a good starter for someone wanting to contribute and get familiar with the code, the tests and the development process.

best regards,
Luc


Thomas





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