Convergence with LATTICE_CONSTRAINTS

[aohara]

First, I'm happy to see that VASP has implemented LATTICE_CONSTRAINTS into >6.4.3, so that we no longer need to recompile separate versions of the code for doing strain response or 2D materials.
However, I am noticing a few cases where convergence isn't met when I use LATTICE_CONSTRAINTS. I am not sure if I am missing an additional flag or if there is some bug in how the threshold is called. I have included the examples discussed below in the attachment. I am running the GPU standard version of 6.4.3.

For GaAs, I have done a regular relaxation first without this flag for comparison. Then I did one where it was set to LATTICE_CONSTRAINTS = .TRUE. .TRUE. .TRUE. and gotten the same result. When I set LATTICE_CONSTRAINTS = .FALSE. .FALSE. .FALSE., the code keeps iterating over the ionic steps until NSW is reached. If I do some combination for strain, it does stop after a finite number of steps.

In a more complicated system (more similar to what I am working on for research), I have noticed that sometimes when straining the system, the code keeps iterating as well. In this case, I was trying to reproduce some results from a recent paper on orbital ordering in Sr2CrO4 when clamped to the substrate lattice constant (LATTICE_CONSTRAINTS = .FALSE. .FALSE. .TRUE.). It keeps going despite the forces being significantly below EDIFFG. For this test, I did an initial run to generate WAVECAR/CHGCAR (not included), a subsequent NSW = 3 run to get timings, and then one with NSW = 20. In this case, the external pressure is still larger in magnitude than 1 kB, but I'm not sure if that is the issue. Here, I started from an initially fully relaxed structure before adding the strain and constraint.

Thank you for any insight that you can provide.

[merzuk.kaltak]

Dear aohara,

thank you for the bug report. VASP's behaviour, even for your GaAs_lattconst_all_false job, is indeed unwanted.
There are two main issues why this is so.

• First, and this affects your GaAs_lattconst_all_false job: LATTICE_CONSTRAINTS=F F F and ISIF=3 contradict each other. On the one hand you tell vasp not to change any lattice parameter, while on the other hand you allow explicitly to change it. Only ISIF=2 makes sense in this case. Because we usually do not alter user input implicitly, the code will drop in this case an error message as of version 6.5.0 with following content:

  Code: Select all

   -----------------------------------------------------------------------------
  |                                                                             |
  |     EEEEEEE  RRRRRR   RRRRRR   OOOOOOO  RRRRRR      ###     ###     ###     |
  |     E        R     R  R     R  O     O  R     R     ###     ###     ###     |
  |     E        R     R  R     R  O     O  R     R     ###     ###     ###     |
  |     EEEEE    RRRRRR   RRRRRR   O     O  RRRRRR       #       #       #      |
  |     E        R   R    R   R    O     O  R   R                               |
  |     E        R    R   R    R   O     O  R    R      ###     ###     ###     |
  |     EEEEEEE  R     R  R     R  OOOOOOO  R     R     ###     ###     ###     |
  |                                                                             |
  |     ISIF=3 and LATTICE_CONSTRAINTS= F F F contradict each other. I          |
  |     suggest to remove LATTICE_CONSTRAINTS from INCAR.                       |
  |                                                                             |
  |       ---->  I REFUSE TO CONTINUE WITH THIS SICK JOB ... BYE!!! <----       |
  |                                                                             |
   -----------------------------------------------------------------------------
  

  This error message can be forced manually in main.F after line 999 with following code

  Code: Select all

  !> if all three directions are restricted but cell is allowed to change
  IF( DYN%ISIF == 3 .AND. .NOT. (LATTICE_CONSTRAINTS_GL(1) .OR. LATTICE_CONSTRAINTS_GL(2) .OR. LATTICE_CONSTRAINTS_GL(3) )  ) THEN
     CALL VTUTOR%ERROR( "ISIF=3 and LATTICE_CONSTRAINTS= F F F &
                &contradict each other. I suggest to remove LATTICE_CONSTRAINTS from INCAR.")
  ENDIF
  

• Second, the reason why the Sr2CrO4 job doesn't stop even though the force criterion is reached, is due to the fact that the break criterion is determined before the constraints are applied.
  This bug is fixed as of version 6.5.0 with following lines of code in main.F (in line 4339):

  Code: Select all

  ...
          CALL CONSTR_CELL_RELAX(D2SIF)
  #ifdef tbdyn
          IF (DYN%IBRION==1.OR. DYN%IBRION==2) &
             CALL APPLY_STRESS_CONSTRAINT( D2SIF, TSIF, LATTICE_CONSTRAINTS_GL )
  #endif
  ...
  

  If you add these lines of code, it makes sense to remove the redundant two calls to APPLY_STRESS_CONSTRAINT further below in lines 4364 and 4399 for IBRION=2 and 3 in main.F, respectively.
  [/item]

[aohara]

Thank you for your help.

I just wanted to clarify the insertion lines for patching the as released 6.4.3 as I think these line numbers refer to edits to the still internal, not yet released 6.5.

I first did the update for calling APPLY_STRESS_CONSTRAINT:

When I do:
grep -n APPLY_STRESS_CONSTRAINT main.F
The line number in 6.4.3 are 4223 and 4259 (not 4364 and 4399).

So if the shift is the same, then this lines up at 4199 where the original "CALL CONSTR_CELL_RELAX(D2SIF)" occurs and after the ISIF if block.

I updated this to include the insertion of the new block for calling APPLY_STRESS_CONSTRAINT and removed the two mentioned above.

Then, I went back to put the error message part in for parsing the INCAR at line 999. It wasn't clear to me if it could actually come earlier in 6.4.3 or not, so I kept it at that point.

After recompiling and rerunning the examples, I now get the expected error message for the GaAs all false job and the Sr2CrO4 calculation finishes with convergence in a reasonable number of steps.

Thank you again for helping me solve this.

[merzuk.kaltak]

Here is a proper patch for 6.4.3:

patch.zip

[aohara]

Thank you for making it up as a patch file - much appreciated!