Menu
▾
▴
cppqed-support
|
From: Raimar S. <rai...@ui...> - 2012-03-21 18:00:13
|
Dear András, I tried to continue a MCWF simulation by increasing --T and leaving the output file and .sv file in place. The simulation aborted with an InfiniteDetectedException. Indeed: I looked into the average function of the mode, the first displayed step is fine, but in the second display step this is the LazyDensityOperator which is passed to the average method (std::cout of the corresponding DensityOperatorLow): (0,4) x (0,4) [ (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) ] It is the same for the other frees of the system. Unfortunately I couldn't find the reason. This only happens for longer trajectories, i.e. everything is fine if I continue a short trajectory with T=15, but I get the exception with T=120. For the case that you don't know what is going on right away, I have attached the output file and .sv file as a test case. You would need to checkout the raimar/private bazaar branch for the script and the interactions I use therein. The command line is 2ParticlesRingCavityFull --etaSin 9 --minitSin 0.1 --modeCavSin Sin \ --kappaCos 5 --pinit1 "(0.5 0 0.09 0)" --pinit2 "(-0.5 0 0.09 0)" \ --UnotSin -5 --Dt 1 --cutoffCos 3 --deltaCSin -20 --deltaCCos -20 \ --evol single --fin1 5 --fin2 5 --precision 6 --dc 0 --minitCos 0.1 \ --cutoffSin 5 --modeCavCos Cos --UnotCos -5 --kappaSin 5 --seed 1001 \ --o 2ParticlesRingCavityFull.out.1001 --T 121 Best regards, Raimar |
|
From: Andras V. <and...@ui...> - 2012-03-29 19:17:23
|
Dear Raimar, I've started to experiment, and try to reproduce your error. Just a quick question: did you try in debug mode? András On Wed, Mar 21, 2012 at 6:59 PM, Raimar Sandner <rai...@ui...>wrote: > Dear András, > > I tried to continue a MCWF simulation by increasing --T and leaving the > output > file and .sv file in place. The simulation aborted with an > InfiniteDetectedException. > > Indeed: I looked into the average function of the mode, the first displayed > step is fine, but in the second display step this is the > LazyDensityOperator > which is passed to the average method (std::cout of the corresponding > DensityOperatorLow): > > (0,4) x (0,4) > [ (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) > (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) > (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) > (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) > (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) ] > > It is the same for the other frees of the system. Unfortunately I couldn't > find > the reason. > > This only happens for longer trajectories, i.e. everything is fine if I > continue a short trajectory with T=15, but I get the exception with T=120. > > For the case that you don't know what is going on right away, I have > attached > the output file and .sv file as a test case. You would need to checkout the > raimar/private bazaar branch for the script and the interactions I use > therein. The command line is > > 2ParticlesRingCavityFull --etaSin 9 --minitSin 0.1 --modeCavSin Sin \ > --kappaCos 5 --pinit1 "(0.5 0 0.09 0)" --pinit2 "(-0.5 0 0.09 0)" \ > --UnotSin -5 --Dt 1 --cutoffCos 3 --deltaCSin -20 --deltaCCos -20 \ > --evol single --fin1 5 --fin2 5 --precision 6 --dc 0 --minitCos 0.1 \ > --cutoffSin 5 --modeCavCos Cos --UnotCos -5 --kappaSin 5 --seed 1001 \ > --o 2ParticlesRingCavityFull.out.1001 --T 121 > > Best regards, > Raimar > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > > |
|
From: Andras V. <and...@ui...> - 2012-03-29 22:04:07
|
I could already detect the error at T=30 (after several continuations). There is also a hint of some bug, cf. http://sourceforge.net/tracker/?func=detail&aid=3512988&group_id=187775&atid=922653 On Thu, Mar 29, 2012 at 9:16 PM, Andras Vukics <and...@ui...>wrote: > Dear Raimar, > I've started to experiment, and try to reproduce your error. > Just a quick question: did you try in debug mode? > András > > > > On Wed, Mar 21, 2012 at 6:59 PM, Raimar Sandner <rai...@ui... > > wrote: > >> Dear András, >> >> I tried to continue a MCWF simulation by increasing --T and leaving the >> output >> file and .sv file in place. The simulation aborted with an >> InfiniteDetectedException. >> >> Indeed: I looked into the average function of the mode, the first >> displayed >> step is fine, but in the second display step this is the >> LazyDensityOperator >> which is passed to the average method (std::cout of the corresponding >> DensityOperatorLow): >> >> (0,4) x (0,4) >> [ (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) >> (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) >> (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) >> (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) >> (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) (-nan,-nan) ] >> >> It is the same for the other frees of the system. Unfortunately I >> couldn't find >> the reason. >> >> This only happens for longer trajectories, i.e. everything is fine if I >> continue a short trajectory with T=15, but I get the exception with T=120. >> >> For the case that you don't know what is going on right away, I have >> attached >> the output file and .sv file as a test case. You would need to checkout >> the >> raimar/private bazaar branch for the script and the interactions I use >> therein. The command line is >> >> 2ParticlesRingCavityFull --etaSin 9 --minitSin 0.1 --modeCavSin Sin \ >> --kappaCos 5 --pinit1 "(0.5 0 0.09 0)" --pinit2 "(-0.5 0 0.09 0)" \ >> --UnotSin -5 --Dt 1 --cutoffCos 3 --deltaCSin -20 --deltaCCos -20 \ >> --evol single --fin1 5 --fin2 5 --precision 6 --dc 0 --minitCos 0.1 \ >> --cutoffSin 5 --modeCavCos Cos --UnotCos -5 --kappaSin 5 --seed 1001 \ >> --o 2ParticlesRingCavityFull.out.1001 --T 121 >> >> Best regards, >> Raimar >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Cppqed-support mailing list >> Cpp...@li... >> https://lists.sourceforge.net/lists/listinfo/cppqed-support >> >> > |
|
From: Raimar S. <rai...@ui...> - 2012-04-19 08:31:48
|
Dear András, I want to look into this problem a little bit more. You closed the bug about the erroneous parsing of the timestep as invalid, but it seems to be a valid bug. The timestep is read in as 1 which is clearly wrong or am I mistaken? Best regards Raimar On Friday 30 March 2012 00:03:46 Andras Vukics wrote: > I could already detect the error at T=30 (after several continuations). > There is also a hint of some bug, cf. > http://sourceforge.net/tracker/?func=detail&aid=3512988&group_id=187775&atid > =922653 > On Thu, Mar 29, 2012 at 9:16 PM, Andras Vukics <and...@ui...>wrote: > > Dear Raimar, > > I've started to experiment, and try to reproduce your error. > > Just a quick question: did you try in debug mode? > > András > > > > > > |
|
From: Andras V. <and...@ui...> - 2012-04-19 08:49:02
|
Dear Raimar, Actually, no, because the timestep displayed in the 2nd column is dtDid and not dtTry, while the timestep read in from the .sv file is dtTry. This was my confusion, too. I have pushed a new revision recently, with a bit clearer output in the case of trajectory continuation to remove this confusion. So, I still (or, again) have no idea why you get these infinites. Keep in touch, András On Thu, Apr 19, 2012 at 10:30 AM, Raimar Sandner <rai...@ui...>wrote: > Dear András, > > I want to look into this problem a little bit more. You closed the bug > about > the erroneous parsing of the timestep as invalid, but it seems to be a > valid > bug. The timestep is read in as 1 which is clearly wrong or am I mistaken? > > Best regards > Raimar > > On Friday 30 March 2012 00:03:46 Andras Vukics wrote: > > I could already detect the error at T=30 (after several continuations). > > There is also a hint of some bug, cf. > > > http://sourceforge.net/tracker/?func=detail&aid=3512988&group_id=187775&atid > > =922653 > > On Thu, Mar 29, 2012 at 9:16 PM, Andras Vukics > <and...@ui...>wrote: > > > Dear Raimar, > > > I've started to experiment, and try to reproduce your error. > > > Just a quick question: did you try in debug mode? > > > András > > > > > > > > > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > |
|
From: Raimar S. <rai...@ui...> - 2012-04-20 13:54:31
|
Dear András, I think I found a fix to this problem, pleas have a look at the raimar/continue_fix branch. To reproduce the problem and test the fix it is sufficient to do 1particle1mode --o try2.d --T 30 --dc 0 --Dt 1 1particle1mode --o try2.d --T 32 --dc 0 --Dt 1 Best regards, Raimar On Thursday 19 April 2012 10:48:31 Andras Vukics wrote: > Dear Raimar, > > Actually, no, because the timestep displayed in the 2nd column is dtDid and > not dtTry, while the timestep read in from the .sv file is dtTry. This was > my confusion, too. > I have pushed a new revision recently, with a bit clearer output in the > case of trajectory continuation to remove this confusion. > > So, I still (or, again) have no idea why you get these infinites. > > Keep in touch, > András > > > > > On Thu, Apr 19, 2012 at 10:30 AM, Raimar Sandner > > <rai...@ui...>wrote: > > Dear András, > > > > I want to look into this problem a little bit more. You closed the bug > > about > > the erroneous parsing of the timestep as invalid, but it seems to be a > > valid > > bug. The timestep is read in as 1 which is clearly wrong or am I mistaken? > > > > Best regards > > Raimar > > > > On Friday 30 March 2012 00:03:46 Andras Vukics wrote: > > > I could already detect the error at T=30 (after several continuations). > > > There is also a hint of some bug, cf. > > > > http://sourceforge.net/tracker/?func=detail&aid=3512988&group_id=187775&at > > id> > > > =922653 > > > On Thu, Mar 29, 2012 at 9:16 PM, Andras Vukics > > > > <and...@ui...>wrote: > > > > Dear Raimar, > > > > I've started to experiment, and try to reproduce your error. > > > > Just a quick question: did you try in debug mode? > > > > András > > > > -------------------------------------------------------------------------- > > ---- For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > > Cppqed-support mailing list > > Cpp...@li... > > https://lists.sourceforge.net/lists/listinfo/cppqed-support |
|
From: Andras V. <and...@ui...> - 2012-04-21 08:29:25
|
Dear Raimar, Great! Thanks a lot for tracking this down. But this means that the first timestep after a continuation was always erroneous so far (that is, if the system time development had *Exact* part)? And this eventually produced an overflow when the trajectory was continued after long enough a time? A little correction is yet necessary, however: if you look at * MCWF_Trajectory<RANK>::coherentTimeDevelopment*, you can see that *tIntPic0_ * is expected to equal the beginning of the present timestep only if *ex_*is true. Otherwise, it is expected to remain zero. (You can find a tentative explanation for this here<http://cppqed.sourceforge.net/structure.html#hamiltonian> .) This condition has to be included here as well. I have merged, corrected and pushed revision #212. Could you please have a look at * MCWF_Trajectory.tcc:128–130* once more and see whether you agree? (You can also remove the raimar/continue_fix branch). Thank again, and best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck |
|
From: Raimar S. <rai...@ui...> - 2012-04-23 11:49:50
|
Dear András, thank you for adjusting and merging the fix. On Saturday 21 April 2012 10:28:58 you wrote: > Great! Thanks a lot for tracking this down. But this means that the first > timestep after a continuation was always erroneous so far (that is, if the > system time development had *Exact* part)? And this eventually produced an > overflow when the trajectory was continued after long enough a time? The stack when psi first gets corrupted is something like (left out some indirections): quantumtrajectory::evolve -> MCWF_Trajectory<RANK>::step -> MCWF_Trajectory<RANK>::coherentTimeDevelopment -> Evolved<A>::step -> evolved::details::apply -> gsl_odeiv_evolve_apply -> MCWF_Trajectory<RANK>::derivs -> Hamiltonian::addContribution -> BinarySystem::addContribution -> Hamiltonian<2,ONE_TIME>::addContribution Here, after the call to addContribution of the binary Hamiltonian (the frees are ok in the first step, why?), the maximum absolute value in dpsidt is 3.5e+130. I would think this is because the transformed non-hermitian Hamiltonian has some huge elements as we evaluate U(t) for large t. These large values carry on to psi as the odeiv stepper takes the huge derivatives and updates the state (max is 4e+126). The next time derivs is called, the maximum absolute value of dpsidt is already on the order of 3e+257 and psi gets updated to something on the order of 3e+257. Then first dpsidt and afterwards psi overflows. What I don't understand is why derivs gets called three times with different values of t (t=30, t=30.00014 and t=30.00021) before dpsidt overflows, but each time tIntPic0_=0. Shouldn't tIntPic0_ get updated? And the question remains if continuation always was erroneous. I would argue that as long as the stepper makes it to the first update of tIntPic0_ without overflow, everything should be fine except if rounding errors skew the results. Physically large values of t should be legal, the problems arise if we cannot represent the transformation numerically accurate. Best regards Raimar |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X