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.