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

Re: [Orekit Developers] OrekitStepNormalizer sign switching bug



The stages of the steps in the test I wrote had a time sequence of the following by calling a series of propagate commands

t = 0
t = 86400
t= 0
t = 120
t = 240
...

The step from 86400 to 0 took the positive step size of 3600 and made it -3600.  When stepping from 0 to 120 the h value is still -3600 however because it is moving forward it won't try to negate it thus it is always -3600.  

Putting it in init may work, I have to take a look at it more though...



On Thu, Mar 19, 2015 at 10:55 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

Hank Grabowski <hank@applieddefense.com> a écrit :

I've been playing around with the step handlers and have discovered a bug
in OrekitStepNormalizer.  In my case I am bouncing around in the direction
of propagation on the Keplerian propagator.  The OrekitStepNormalizer has a
good check on the first pass to see if it needs to be initialized.  In that
process if it determines that it is stepping backwards it changes the sign
of the step.  The problem comes when it switches back again.  The sign is

What do you mean by "switches back again"?

never changed positive and therefore it just walks backwards ad infinitum.
I was going to fix it by changing these lines (starting at 108 in the
class):

                forward = interpolator.getCurrentDate().compareTo(lastDate)
= 0;
                if (!forward) {
                    h = -h;
                }


to be:

               h = FastMath.abs(h);
                forward = interpolator.getCurrentDate().compareTo(lastDate)
= 0;
                if (!forward) {
                    h = -h;


Thoughts?

Your fix seems good in any case. I guess h = FastMath.abs(h) could
also be added at the init() method level.

best regards,
Luc


Hank