Page 1 of 1

Minimum number of ionic steps?

Posted: Tue Apr 16, 2024 11:00 pm
by matthewkuner
Hello all,

I am interested in running standard PBE / r2SCAN VASP calculations with a minimum number of ionic steps. Without going into details as to why, I am not able to simply set EDIFFG = 0. Moreover, setting EDIFFG = 10 eV (for example) does not work in high-throughput situations, as some of the structures I am running have total energies less than 10 eV (and hence simply converge after the first ionic step converges).

Is there no parameter like NELMIN but for a minimum number of ionic steps?

Best,
Matthew

Re: Minimum number of ionic steps?

Posted: Wed Apr 17, 2024 1:01 pm
by michael_wolloch
Hi Matthew,

we do not have a parameter like this. However, it would be quite simple to hardcode a minimum number of steps. If you can give me a bit more details and maybe a small example system (e.g. converges in 3 steps, but you want to run 5), that I can use as a test case, I am happy to provide a patch for you.

1) Can the minimum number of steps be fixed (e.g. 5), or do you absolutely need to have it accessible by an INCAR tag?

2) Do you want to run with positive, or negative EDIFFG, or do both have to work?

3) Do you need it to work for all optimization algorithms, or just one, e.g. IBRION = 2.

4) What about MD and MLFF?

4) Would it be fine if this change breaks something else (like finite differences for phonons)? I would prefer to not have to put safeguards in, but provide you with a minimal patch that you can use to compile a single version for exactly your use case.

Cheers, Michael

Re: Minimum number of ionic steps?

Posted: Wed Apr 17, 2024 5:08 pm
by matthewkuner
Hi Michael,

Thanks for the speedy response! While I could provide an example test-case, I plan to use this in a high-throughput fashion for hundreds of thousands of calculations. To be more explicit, I am generating data to train MLFF's and just want a few ionic steps per structure to diversify my training set (especially for the far-from-equilibrium structures I typically start with). So my hope would be that this would function for any structure during a standard PBE / R2SCAN relaxation.

To your questions:

1) INCAR is preferable
2) I am indifferent to whether this works through positive or negative EDIFFG, or both.
3) Just for IBRION = 2.
4) I will not be running MD / MLFFs, so I do not need those to be supported.
5) Breaking phonons or the like is perfectly acceptable to me.

Let me know if this information is sufficient :)

Re: Minimum number of ionic steps?

Posted: Thu Apr 18, 2024 10:14 am
by michael_wolloch
Dear Matthew,

thanks for elaborating a bit on the use case. If you are starting from unreasonable positions, and want to do a few steps, why not simply set your force criterion very tight (e.g. EDIFFG = -0.001) and NSW=10 or similar? You will not be able to converge the forces that quickly and simply run for the 10 steps. If you are already starting in a minimum (as an extreme case) and the algorithm converges immediately, you would not have diversified anything anyhow by producing essentially the same structure NSW_MIN=10 times.

On the other hand, if you set e.g. EDIFFG = -0.05, and start at a nearly relaxed structure, with the proposed NSW_MIN = 10, there would be problems I assume. Especially for IBRION = 2, where the line minimization tends to fail and the code is terminated in error if you are already converged, the gradient is very small, and the potential energy surface is not extremely smooth.

So you see that this feature request has some problems, which we would have to guard against. In contrast to electronic minimization, which is a self-consistent field loop stabilized by density mixing, the ionic relaxation algorithms can get unstable if convergence is already achieved.

Maybe I am not fully grasping what you want to do, but after thinking more about the issue I am not convinced that it would be a good idea to patch this in. Please note that such a patch would then de-facto be a part of VASP as it can be found on the forum, and other users might not necessarily think about the context for which it was initially designed.

If you can make a good case for the feature, however, and we can figure out a way to make it "safe" and useful together, I will discuss with colleagues about providing a patch now, which then would be released as a feature in the next version of VASP.

Cheer, Michael