Dear VASP Team and Users,
First, I'd like to mention that I don't have any experience with Fortran or scientific programming, so my question might be a bit unwise. However, I'm curious about something.
Is it possible to change certain INCAR parameters during a calculation? For instance,Eg. EDIFF, EDIFFG, NELM, NSW, POTIM, and especially the TIME flag for the Damped algorithm, which greatly affects convergence speed.
This idea came to me after experiencing the need to restart calculations due to suboptimal parameter choices, sometimes after couple of days spending in the queue. It would be very convenient to adjust these parameters on-the-fly, similar to how the LSTOP and LABORT flags work.
Is it feasible to implement such a feature, and how difficult would it be? One approach could be to create a CHANGECAR file with the same flags as in the INCAR file (excluding crucial ones), and then modify the main.F file to read this CHANGECAR file and update the parameters.
Best regards,
On-the-fly change of INCAR flags
Moderators: Global Moderator, Moderator
-
- Newbie
- Posts: 3
- Joined: Fri Mar 15, 2024 10:35 am
-
- Global Moderator
- Posts: 492
- Joined: Mon Nov 04, 2019 12:41 pm
- Contact:
Re: On-the-fly change of INCAR flags
It is certainly possible to implement such a feature, but not very easily or the best solution to the use case you describe.
One problem with this idea is that it would become very difficult (if not impossible) to reproduce previous calculations.
Basically, we would need to keep track of the INCAR tags that can change during each electronic and ionic convergence step.
In general, our advice for complicated or difficult to converge calculations is to start from a minimalistic INCAR file and low convergence parameters (PREC=Normal, ENCUT=ENMAX and few k-points to sample the Brillouin zone) such that these calculations can be run quickly on few computational resources (so that in principle one would not need to wait too long in a queue).
This is important so that you can shorten the feedback loop, and try what combinations of INCAR tags improve/worsen the convergence.
Then, once these low basis set calculations run, it is less likely to encounter the problem you described in production calculations.
We are collecting a few tips and tricks in this page:
https://www.vasp.at/wiki/index.php/Trou ... onvergence
I know that in practice this is not always possible, but I don't think that the possibility to change the INCAR files on-the-fly is the best solution to this problem.
Most users would probably prefer if the code would fix this convergence issues algorithmically without their intervention.
And we would rather work on that than a feature that requires a user to manually monitor the calculation.
One problem with this idea is that it would become very difficult (if not impossible) to reproduce previous calculations.
Basically, we would need to keep track of the INCAR tags that can change during each electronic and ionic convergence step.
In general, our advice for complicated or difficult to converge calculations is to start from a minimalistic INCAR file and low convergence parameters (PREC=Normal, ENCUT=ENMAX and few k-points to sample the Brillouin zone) such that these calculations can be run quickly on few computational resources (so that in principle one would not need to wait too long in a queue).
This is important so that you can shorten the feedback loop, and try what combinations of INCAR tags improve/worsen the convergence.
Then, once these low basis set calculations run, it is less likely to encounter the problem you described in production calculations.
We are collecting a few tips and tricks in this page:
https://www.vasp.at/wiki/index.php/Trou ... onvergence
I know that in practice this is not always possible, but I don't think that the possibility to change the INCAR files on-the-fly is the best solution to this problem.
Most users would probably prefer if the code would fix this convergence issues algorithmically without their intervention.
And we would rather work on that than a feature that requires a user to manually monitor the calculation.