Re: [Cppqed-support] Problem with fuzzy time bugfix

[Raimar S. <rai...@ui...>]

Dear András,

here is what I think is happening, let's take rev 203 and this example:

PumpedLossyMode_C++QED --kappa 0 --eta 0 --minitFock 2 --dc 0 --Dt 0.1

Dt is 0.1 and DtTry is 0.01 initially. This means 
*MCWF_Trajectory<RANK>::coherentTimeDevelopment* is called 10 times, each time 
*stepToDo* evaluates to 0.01. Due to rounding errors this does not sum up to 
0.1 exactly but to something that is slightly less then 0.1 (0.1 - 1e-17 in my 
case). Just before the next display *coherentTimeDevelopment* is called once 
more with *stepToDo* evaluating to 1e-17. In the next call to 
*getEvolved()->update*, DtTry is updated to this very small value. As there is 
no mechanism to increase DtTry again, the stepper will continue with this 
DtTry also after the next display, and the trajectory seems to be stuck (where 
really it is just extremely slow).

Even if initially Dt is not an even multiple of DtTry the problem might occur 
eventually. DtTry can only become smaller whenever the trajectory approaches 
the next display timestep, so sooner or later after some displays the 
trajectory probably won't make any significant progress anymore.

This also explains why this only happens if the system has no Hamiltonian 
part. With a Hamiltonian the gsl integrator takes care of DtTry.

Please have a look at raimar/bug3482771, where I reverted the changes 
introduced in rev 204 (except the check for li_ when calculating *stepToDo* 
which is independent from the rest). To fix the bug, I would suggest to leave 
DtTry unchanged for the case ha_=0, there is no reason to decrease DtTry only 
because we reach a display time. In my branch this is achieved by calling 
*getEvolved()->update* with the argument *getDtTry()* instead of *stepToDo*.

Best regards
Raimar