need CP-VASP

[pangchq]

Dear Dr. Liu,

I hope this message finds you well. I recently read your articles on constant potential simulations and those by other researchers. I am currently planning to conduct a first-principles simulation with a constant potential and have submitted an application a few days ago at https://sites.utexas.edu/yuanyue-liu/codes/cp-vasp/. When convenient, could you please review my application? Thank you very much for your assistance!

Best regards, Gechuanqi Pan

[ZLevell]

Dear Gechuanqi Pan,

We recently released version 2 of CP-VASP and sent out access links. Were you included in this list? If not, I will email it to you.

[pangchq]

Dear Zachary Levell,

I have received version 2 of CP-VASP. But I encounter a problem about convergence. I'm running the AIMD at constant potential 0.6V vs SHE. The vasp 6.3.2 was compiled with vaspsol++ from Craig Plaisance and CP-VASP version-2 from you. I've test the examples supported by you and got the correct results. Now, I am currently suffering from the torture of slow convergence.I have already done my best to pinpoint which step is causing the slow convergence issue as follow,

1. ran a case without implict solvation and constane potential, the convergence is fast;
2. ran a case with vaspsol (ISOL = 1), the convergence is fast;
3. ran a case with vaspsol++ (ISOL = 2), the convergence is fast;
4. ran a case with vaspsol++ (ISOL = 2) and constane potential, the convergence is too slow to bear; For all of the four case, the only different is the setup in INCAR, the other files (KPOINTS, POTCAR, POSCAR) are the same. Based on the tests above, I believe the issue lies in the constant potential step. All the test files are attached (https://drive.google.com/drive/folders/1g3RoxGcPp44keClrjmieKUMtAbwq7RFh). I don't know if there is an issue with my INCAR file setup or there is another problem. Could you please give me some suggestions?

Best regards, Gechuanqi Pan

[ZLevell]

Dear Gechuanqi Pan,

Thank you for your testing, I'm glad the examples ran properly. The SCF steps in CP-VASP can be slower due to changes in the electron number, but in our experience the speed is not greatly reduced. I've requested access to your google drive folder.

[pangchq]

Dear Zachary Levell, I've opened up access to you, thanks.

[ZLevell]

Dear Gechuanqi Pan,

It looks like CP-VASP is slow because the SCF cycles take many steps to converge, whereas the other simulations have much shorter SCF cycles. There are a couple primary reasons that CP-VASP can have this issue:

1. When NEADJUST > 1, CP-VASP turns the implicit solvation model on to calculate the potential reference and then turns it back off to calculate the forces and ideally saves time. However, this change in the simulation conditions causes the initial guess for the charge density to be far from the final distribution and thus requires additional steps.

2. If the change in electron number is large, then the initial guess for the charge density (which is the previous charge density linearly scaled with the electron number change) may be far from the goal. For our exact potential schemes (1 <= NESCHEME <= 3) this can be a problem at first (as the initial potential may be far from the target) but will likely be minimal once the target potential is reached.

   Based on your results, I suspect the problem is mainly the first issue. There are a few options that may help:

• You can try increasing NEADJUST to a larger number. This will reduce the percentage of steps that turn the solvation model on/off and will be (theoretically) more efficient. So long as the potential doesn't go too far from the target, it's reasonable to use large values of NEDAJUST.

• You can set NEADJUST = 1 and LSOLOFF = .FALSE.. This will keep VASPsol turned on permanently so that each SCF cycle is consistent and will likely converge more quickly. However, you may run into the flying water problem since the forces are calculated with solvation on.

• Since you're using CP-VASP with VASPsol instead of VASPsol++, I'd recommend installing the VASPsol version of our code. The patches have a slight difference; for VASPsol, we keep record of the last charge density without solvation and use that for the next step without solvation. This was mainly done for other reasons, but it may also help with the speed.

  Finally, there are some other setting changes that can help:

• I'd recommend initializing your electron number to 845.87 from the calculation you already did.

• You can probably set POTIM = 1 instead of 0.5 so long as the structure doesn't explode.

• You could try setting NELM to 60 instead of 200. Although some SCF cycles won't converge, they may be correct enough where the structures won't explode and the energy/forces won't be significantly wrong.

  I hope this helps!