Geometry Optimization with RPA

[john_low1]

To whom it may concern,

I would like to optimize the geometry of my model with RPA in vasp.6.1.1. I am trying to use "LRPAFORCE = .TRUE." and "ALGO = ACFDTR". Unfortunately when VASP stops when it starts to calculate the forces for RPA with the following message.

Code: Select all

|     internal error in VASP: G0W0 method chosen but NELM larger than 1       |
|      for self-consistent GW, set ALGO=GW0R in INCAR                         |
|      will stop now                                                          |

In tutor.f the following statement can be found. It seems to me that my INCAR should have worked.

Code: Select all

            res = 'Currently RPA forces (LRPAFORCES = .TRUE.) can be calculated &
                &only with the formalism of euclidean quantum field theory &
                &(imaginary time Greens functions). That is, only ALGO = &
                &RPAR[K] | G0W0R[K] or similar options are supported.'

It appears that the value NELM from the DFT scf calculation has been passed to the routine calculating the RPA fources. When I calculated the RPA energy NELM was set equal to zero. It seems to me that NELM should have been set to zero when the forces are calculated. Does this mean I can't automatically optimize the geometry of my model with IBRION=1 or 2 with RPA forces in vasp.6.1.1?

Is there is a workaround to this issue? I have attached a zip file which contains input, output, log and script for an example.

Thanks for the help!

John J. Low
Argonne National Laboratory
Argonne, IL

[kresse_georg]

Dear user,

RPA relaxations are not yet well documented. To start with, in the present version of VASP, relaxation works only for insulators. Only vasp.6.2 will have RPA forces implemented for metals. The most important thing is to select the RPA mode, in which VASP takes over the entire workflow (i.e. DFT calculation, RPA calculation, linear response calculations, RPA forces, than step along gradient, and again DFT calculation, RPA calculation ... etc.).

This mode is selected by NOT setting NBANDS in the INCAR file. Below is an example file for relaxing SiO2.

# cutoff, and the usual things
ENMAX = 400
ISMEAR = 0 ; SIGMA = 0.05

# use Quasi-Newton algorithm
EDIFF = 1E-6
IBRION = 1 ; NFREE = 6
NSW = 6

# switch on RPA
ALGO = RPAR ; LRPAFORCE = .TRUE. ; NOMEGA = 10
LMAXFOCKAE = -1

Alternatively, you can set NSW = 0 (single step), and run no relaxation. In this case, the calculations are stopped after the RPA forces have been calculated and a step along
Hessian_matrix_from_DFT ^-1 Forces_from_RPA
is done and written to the CONTCAR file. If the RPA Hessian is similar to the DFT Hessian, this can be exceedingly fast. This mode is somewhat awkward in vasp.6.1, though. If I recall, the step is "damped" by a factor 0.7, with no way of changing the damping factor. Will be fixed in next release.


Georg Kresse

[john_low1]

To whom it may concern,

I have tried the settings suggested by Professor Kresse with VASP 6.1.1. I still get the same error message.

After changing the ALGO setting to GW0R, the calculation ran for 24 hours and stopped due to a time limit on the queue.

I would prefer to use RPAR setting which appears to more efficient. Does this setting work in a more recent version of VASP?

John J. Low
Argonne National Laboratory.

[henrique_miranda]

I am not sure I understand your post.

You said you tried the settings suggested by Professor Kresse: ALGO=RPAR.
But then you say you used GW0R, why so?
Did the calculation using ALGO=RPAR not work? If so then why? What is the error?

[john_low1]

Henrique,

I get the following error in the OUTCAR file, when I set "ALGO = RPAR", "LRPAFORCE = .TRUE.", and "LMAXFOCKAE = -1", as suggested by Professor Kresse.

Code: Select all

|     internal error in VASP: G0W0 method chosen but NELM larger than 1       |
|      for self-consistent GW, set ALGO=GW0R in INCAR                         |
|      will stop now                                                          |

I have attached a zip file entitled RPA_fail.zip which contains input (without POTCAR), output, script and logs for failed job.

Thank you for your help with this issue.

John

[merzuk.kaltak]

Dear John,

Just get rid of NELM in your INCAR, the error message should go away then.
The reason for this behavior is explained as follows. When you set RPAFORCE = .TRUE. and ALGO = RPAR|ACFDTR you do essentially an G0W0R calculation, because the density matrix is needed for the computation of the RPA forces.
However, if VASP finds a value of NELM in the INCAR, it assumes you want to perform an G[NELM]W0 calculation (which isn't implemented for RPA forces), so it drops the error.

I admit, the tutor message is shown very late and is also somewhat confusing. I am going to change that including the error message. It has to be shown earlier in the run and should be much clearer for the user. Thank you for pointing this out and submitting the error report.

Furthermore, there as some missing features in vasp-6.2 that you are requesting and I wouln't set due to the following reasons:

• ISIF=4 is not implemented, only ISIF=2 (so there is no need to set it at all for RPA forces in version 6.2 and older)
• MAGMOM for ISPIN=0 is ignored and ISPIN=0 is default, I wouldn't set either of these tags.
• KPAR is not supported for low-scaling GW computations.
  Also, for 2x2x2 k-points, the job finished with 16 mpi-ranks within 10 minutes without any performance flags set in the INCAR.
• get rid of LOPTICS and LPEAD. The WAVEDER is not really helping here to reach convergence.

As an example, I used following INCAR file to reach convergence with 2x2x2 k-points:

Code: Select all

!----- General
SYSTEM = RPA geometry optimization
ISMEAR = 0      ! Gaussian smearing
SIGMA  = 0.05   ! Width of the smearing in eV

!----- RPA from https://www.nersc.gov/assets/Uploads/VASP-Webinar-RPA.pdf
ALGO   = ACFDTR
NOMEGA = 16 ! converged to 2meV
PRECFOCK = NORMAL
LRPAFORCE = .TRUE.

!----- Ionic Relaxation
NSW    = 10    ! Number of ionic steps
IBRION = 2      ! (1) RMM-DIIS (2) CG
POTIM  = 0.1    ! Reduce trial step

!----- Precision
EDIFF  = 1E-08  ! Break electronic loop
EDIFFG = 1E-07  ! break ionic loop

The logfile is in the attachment:

[john_low1]

Merzuk Kaltak,

Thanks for the help. This case ran for me with 24 ranks and 6 threads per rank on four nodes with 96GB and 36 cores on each node.

Unfortunately, I needed more memory to run this case on the servers we are using.

Although, It appears that there should be enough memory on one node with 36 MPI processes my job dies when calculating the HF-Forces after the first SCF converges.

I have included an OUTCAR for a case that fails for reference.

Is this a user error, bug, or feature?

John Low
Argonne National Laboratory

[merzuk.kaltak]

Dear John Low,

Does the job die if you run it on a single node?
You can reduce the amount of memory required for the job by setting NTAUPAR = 1 (job is slower but uses less memory). Your job should fit on one node then.

Alternatively, you can also set MAXMEM (in MB) to the available free memory per MPI-rank.
For instance, if you run your job on one node with 36 cores that has 96GB, I would set MAXMEM = 2500 (using the complete memory might lead to issues, so a smaller number is safer).

What compiler-suite are you using? Is it one of the supported ones found at here?

[john_low1]

Merzuk Kaltak,

I can work around this issue by using more nodes and more threads per MPI process. I think it is an issue with intel-mpi because that is where the program is failing.

Unfortunately, I can not use the recommended Intel 2018 toolchain because it is not installed on the server I am using.

I have found that the 2018 toolchain has numerical issues with instruction sets newer than AVX2. I am using Intel 2020.1.217 for this build. I have found that VASP built with this toolset fails on tests involving the Andersen thermostat in the VASP test-suite. I have listed them below.

andersen_nve_constrain_fixed andersen_nve_constrain_fixed_MDALGO=11 andersen_nve_constrain_fixed_MDALGO=11_RPR andersen_nve_constrain_fixed_RPR andersen_nve_fixed andersen_nve_fixed_MDALGO=11 andersen_nve_fixed_MDALGO=11_RPR andersen_nve_fixed_RPR andersen_nvt_fixed andersen_nvt_fixed_MDALGO=11 andersen_nvt_fixed_MDALGO=11_RPR andersen_nvt_fixed_RPR

John Low
Argonne National Laboratory

[henrique_miranda]

I created a new thread to discuss this issue when running the test suite on VASP compiled with Intel 2020.1.217:
forum/viewtopic.php?f=2&t=18049
Can we continue this discussion there?

[john_low1]

Merzuk Kaltak,

It is OK to continue the Intel Compiler issue in another thread.

But I wanted to add a comment about RPA and memory issues. I found that increasing KMP_STACKSIZE from 256 Mbtyes to 512 Mbytes allowed me to use fewer nodes for RPA calculations.

The error message I was getting before increasing KMP_stacksize was "Fatal error in PMPI_Waitall: See the MPI_ERROR field in MPI_Status for the error code".

So the issue was not related to the total memory used by VASP but related to the stack size.

Thanks for your help on these issues.

John Low
Argonne National Laboratory.