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

[Andras V. <and...@ui...>]

Dear Raimar,

Sorry for the delay.

I think your explanation is correct, and this was more or less my
explanation, too, although I didn't want to believe that adding up
x/10. ten times will not result in x. (Do you think there is some
floating point type in some library which doesn't have this problem?)

I experimented a bit with your bugfix, which seems perfect to me,
although at the moment I don't quite understand where dtTry comes into
play in the case when ha_=li_=0.

However, a deeper problem in this case is that it is a waste to do 10
steps between two outputs, but we could rather make one step always to
the next output. I think it is rather in this way that this bug should
be resolved. (Perhaps somehow already in the constructor of
MCWF_Trajectory.)

What do you think?

Keep in touch,
András


On Thu, Apr 26, 2012 at 11:55 PM, Raimar Sandner
<rai...@ui...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support