Hi all,
I'm trying to use OSMPS to simulate Fermi-Hubbard model dynamics, but I got the following error:
lagrenge@lagrenge-Lenovo-ideapad-Y700-15ISK:~/software/OpenSourceMPS_v3.0$ python new-FermiHubbardDynamics.py --PostProcess=F
"('nsteps', 30)"
./Execute_MPSMain TMP/FermiHubbard_DynamicsL_30U_2.5tau_3.0deltat0.1Main.nml 0
** On entry to DLASCL parameter number 4 had an illegal value
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
Depending on the value of the parameter U, sometimes it happens earlier and sometimes later, e.g. at U=2.5 it happens at t=0.6, at U=1.0 it happens at t=2.7 (the data before t=2.7 are correct and readable, but the program stops at t=2.7 and no output after that). Do you have any idea about this error? Have you ever met it before? Thanks!
I briefly tried to reproduce your problem with your script and could not get the floating point exception / error in dlascl. Thus, one question and one suggestion, which will help us to narrow down the problem.
1) I run the simulation for a long time without getting the error. Can you check at which time step the error occurs? You can just list the dynamic results with 1) I run the simulation for a long time without getting the error. Can you check at which time step the error occurs? You can just list the dynamic results with "ls -la OUTPUTS/FermiHubbard_DynamicsL_30U_2.5tau_3.0deltat0.1ObsOutDynamics/" and see how far you got before the crash.
2) You should try to switch time evolution methods. Can you try e.g. TDVP with the line "myKrylovConv = mps.TDVPConvParam(max_bond_dimension=20)" and tell us if the error persists? The Krylov method is not the best for your problem; you do not perturb the parameters of the Hamiltonian in the first steps of the time evolution with regards to the ground state, but have a step function. This step-function causes problem for Krylov. You will see that TDVP (or TEBD) will be much faster due to this problem in Krylov, which might lead to the floating point exception, I suspect.
Thank you for asking the questions. It helps us a lot to further improve OSMPS.
Best regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Danial,
Here are my answers and further questions:
(1) As I mentioned before, when the error occurs depends on parameters. For U=1.5 the error occurs at t=2.5:
ls -la OUTPUTS/FermiHubbard_DynamicsL_30U_1.5tau_3.0deltat0.1ObsOutDynamics/
total 116
drwxrwxr-x 2 lagrenge lagrenge 4096 Jan 3 11:17 .
drwxrwxr-x 11 lagrenge lagrenge 12288 Jan 13 20:03 ..
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:11 Dynamics_1step_000001.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:12 Dynamics_1step_000002.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:15 Dynamics_1step_000003.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:18 Dynamics_1step_000004.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:20 Dynamics_1step_000005.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:25 Dynamics_1step_000006.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:31 Dynamics_1step_000007.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:38 Dynamics_1step_000008.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:46 Dynamics_1step_000009.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:57 Dynamics_1step_000010.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:08 Dynamics_1step_000011.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:21 Dynamics_1step_000012.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:34 Dynamics_1step_000013.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:49 Dynamics_1step_000014.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:05 Dynamics_1step_000015.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:23 Dynamics_1step_000016.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:40 Dynamics_1step_000017.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:58 Dynamics_1step_000018.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:17 Dynamics_1step_000019.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:36 Dynamics_1step_000020.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:56 Dynamics_1step_000021.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:16 Dynamics_1step_000022.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:37 Dynamics_1step_000023.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:57 Dynamics_1step_000024.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 11:17 Dynamics_1step_000025.dat
(2) I tried the TDVP method using myKrylovConv =mps.TDVPConvParam(max_bond_dimension=20) as you suggested. It now runs superfast(finishes in a few minutes), however, the result seems to be incorrect when t becomes large (see attached picture): according to Fig.11 of PRB 95, 165139 (2017), both lines should be damped oscillations and gradually approach equilibrium, but in my picture there are some weird behavior after t=1.5. What caused this numerical issue? Should I decrease deltat or increase bond dimension or both, or maybe change to another time evolution method?
thank you for your replies; from you answers I would suggest that you use the TDVP and we have some more time to look into the Krylov errors. TDVP would always be my choice over Krylov if I start a project today. So this option should not limit your research (unless you are doing it to study the methods themselves). But we want to get the Krylov right, of course.
You have to converge the TDVP simulations now. The bond dimension of 20 is very low, but allows you/us to figure out quickly if there are any errors appearing during the simulation. I've rerun the simulations with max_bond_dimension=100 and TDVP and got oscillations more similar to the PRB result. Sorry not having pointed out this approach in the previous post. I would increase the bond dimension gradually and plot the difference between the results on a log-scale to get a better grasp and ensure convergence.
The feedback on the Krylov helps a bit. Errors which are conditional on simulation parameters and are appearing after five hours of simulation won't be an easy fix.
Best regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually cannot reproduce your error; to try again, I would need OSMPS version, operating system, compiler version, compiler flags etc. But that would be a huge effort depending on your setting. That being said, I get some output that the first SVD method failed, which was solved through using the more stable of the two LAPACK implementations as a fallback solution. But I have seen cases where the second one fails two and one gets errors similars to yours.
Maybe Matthew had more luck reproducing the problem?
Best regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
For my research the TDVP method you suggested works good for me and I'll move on with that method, thanks! For your information, the operating system I use is Ubuntu 16.04.1 LTS, python version 2.7.12, the OSMPS was downloaded from sourceforge on Dec 18 2018.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I'm trying to use OSMPS to simulate Fermi-Hubbard model dynamics, but I got the following error:
lagrenge@lagrenge-Lenovo-ideapad-Y700-15ISK:~/software/OpenSourceMPS_v3.0$ python new-FermiHubbardDynamics.py --PostProcess=F
"('nsteps', 30)"
./Execute_MPSMain TMP/FermiHubbard_DynamicsL_30U_2.5tau_3.0deltat0.1Main.nml 0
** On entry to DLASCL parameter number 4 had an illegal value
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
Depending on the value of the parameter U, sometimes it happens earlier and sometimes later, e.g. at U=2.5 it happens at t=0.6, at U=1.0 it happens at t=2.7 (the data before t=2.7 are correct and readable, but the program stops at t=2.7 and no output after that). Do you have any idea about this error? Have you ever met it before? Thanks!
I have not seen this error. I will look at this in more detail as soon as possible.
Thanks for your patience.
Hello Allen,
I briefly tried to reproduce your problem with your script and could not get the floating point exception / error in dlascl. Thus, one question and one suggestion, which will help us to narrow down the problem.
1) I run the simulation for a long time without getting the error. Can you check at which time step the error occurs? You can just list the dynamic results with 1) I run the simulation for a long time without getting the error. Can you check at which time step the error occurs? You can just list the dynamic results with "ls -la OUTPUTS/FermiHubbard_DynamicsL_30U_2.5tau_3.0deltat0.1ObsOutDynamics/" and see how far you got before the crash.
2) You should try to switch time evolution methods. Can you try e.g. TDVP with the line "myKrylovConv = mps.TDVPConvParam(max_bond_dimension=20)" and tell us if the error persists? The Krylov method is not the best for your problem; you do not perturb the parameters of the Hamiltonian in the first steps of the time evolution with regards to the ground state, but have a step function. This step-function causes problem for Krylov. You will see that TDVP (or TEBD) will be much faster due to this problem in Krylov, which might lead to the floating point exception, I suspect.
Thank you for asking the questions. It helps us a lot to further improve OSMPS.
Best regards,
Daniel
Hi Danial,
Here are my answers and further questions:
(1) As I mentioned before, when the error occurs depends on parameters. For U=1.5 the error occurs at t=2.5:
ls -la OUTPUTS/FermiHubbard_DynamicsL_30U_1.5tau_3.0deltat0.1ObsOutDynamics/
total 116
drwxrwxr-x 2 lagrenge lagrenge 4096 Jan 3 11:17 .
drwxrwxr-x 11 lagrenge lagrenge 12288 Jan 13 20:03 ..
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:11 Dynamics_1step_000001.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:12 Dynamics_1step_000002.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:15 Dynamics_1step_000003.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:18 Dynamics_1step_000004.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:20 Dynamics_1step_000005.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:25 Dynamics_1step_000006.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:31 Dynamics_1step_000007.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:38 Dynamics_1step_000008.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:46 Dynamics_1step_000009.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 06:57 Dynamics_1step_000010.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:08 Dynamics_1step_000011.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:21 Dynamics_1step_000012.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:34 Dynamics_1step_000013.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 07:49 Dynamics_1step_000014.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:05 Dynamics_1step_000015.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:23 Dynamics_1step_000016.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:40 Dynamics_1step_000017.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 08:58 Dynamics_1step_000018.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:17 Dynamics_1step_000019.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:36 Dynamics_1step_000020.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 09:56 Dynamics_1step_000021.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:16 Dynamics_1step_000022.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:37 Dynamics_1step_000023.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 10:57 Dynamics_1step_000024.dat
-rw-rw-r-- 1 lagrenge lagrenge 3817 Jan 3 11:17 Dynamics_1step_000025.dat
(2) I tried the TDVP method using myKrylovConv =mps.TDVPConvParam(max_bond_dimension=20) as you suggested. It now runs superfast(finishes in a few minutes), however, the result seems to be incorrect when t becomes large (see attached picture): according to Fig.11 of PRB 95, 165139 (2017), both lines should be damped oscillations and gradually approach equilibrium, but in my picture there are some weird behavior after t=1.5. What caused this numerical issue? Should I decrease deltat or increase bond dimension or both, or maybe change to another time evolution method?
Hello Allen,
thank you for your replies; from you answers I would suggest that you use the TDVP and we have some more time to look into the Krylov errors. TDVP would always be my choice over Krylov if I start a project today. So this option should not limit your research (unless you are doing it to study the methods themselves). But we want to get the Krylov right, of course.
You have to converge the TDVP simulations now. The bond dimension of 20 is very low, but allows you/us to figure out quickly if there are any errors appearing during the simulation. I've rerun the simulations with max_bond_dimension=100 and TDVP and got oscillations more similar to the PRB result. Sorry not having pointed out this approach in the previous post. I would increase the bond dimension gradually and plot the difference between the results on a log-scale to get a better grasp and ensure convergence.
The feedback on the Krylov helps a bit. Errors which are conditional on simulation parameters and are appearing after five hours of simulation won't be an easy fix.
Best regards,
Daniel
Hello Allen,
I actually cannot reproduce your error; to try again, I would need OSMPS version, operating system, compiler version, compiler flags etc. But that would be a huge effort depending on your setting. That being said, I get some output that the first SVD method failed, which was solved through using the more stable of the two LAPACK implementations as a fallback solution. But I have seen cases where the second one fails two and one gets errors similars to yours.
Maybe Matthew had more luck reproducing the problem?
Best regards,
Daniel
Hi Daniel,
For my research the TDVP method you suggested works good for me and I'll move on with that method, thanks! For your information, the operating system I use is Ubuntu 16.04.1 LTS, python version 2.7.12, the OSMPS was downloaded from sourceforge on Dec 18 2018.