BRMIX: very serious problems the old and the new charge density differ

[dominic_varghese]

Hi everyone,

I am using VASP 6.5.0 for structural relaxation along z. To do this, I modified the file constr_cell_relax.F in the src folder (attached). However, when I run the calculation, I get the following error:

BRMIX: very serious problems, the old and the new charge density differ

Based on previous discussions in the forum, I already tried:
setting ADDGRID = .TRUE.
changing the number of cores used (varied 32 to 16 to 8)
running with LSCALAPACK = .FALSE.

Unfortunately, I still encounter the same error. I am attaching my input files here for reference. Could you please advise if the modification to constr_cell_relax.F might be causing this, or if there are additional settings I should try?

Thanks in advance for your help!

[michael_wolloch]

Hi Dominic Varghese,

Thanks for your question. I am not entirely sure why you would need to introduce an additional subroutine to constrain a structural relaxation to the z direction.

You should be able to achieve a relaxation in only a single lattice direction by setting Selective Dynamics in the POSCAR file. E.g. if you want to relax only the z-coordinates in your cell, set up your POSCAR like this to constrain the x and y coordinates of all atoms and the z coordinate of the atom at the origin:

Code: Select all

Ba8 O8                                  

   1.00000000000000     

    -5.3665983243299999   -5.3665983243299999    0.0000000000000000
    -5.3665983243299999    0.0000000000000000   -5.3665983243299999
     0.0000000000000000   -5.3665983243299999   -5.3665983243299999
  Ba              O             

     8     8
Selective Dynamics
Direct
     0.0000000000000000    0.0000000000000000    0.0000000000000000  F  F  F
     0.0000000000000000    0.0000000000000000    0.5000000000000000  F  F  T
     0.0000000000000000    0.5000000000000000    0.0000000000000000  F  F  T
     0.0000000000000000    0.5000000000000000    0.5000000000000000  F  F  T
     0.5000000000000000    0.0000000000000000    0.0000000000000000  F  F  T
     0.5000000000000000    0.0000000000000000    0.5000000000000000  F  F  T
     0.5000000000000000    0.5000000000000000    0.0000000000000000  F  F  T
     0.5000000000000000    0.5000000000000000    0.5000000000000000  F  F  T
     0.2500000000000000    0.2500000000000000    0.2500000000000000  F  F  T
     0.2500000000000000    0.2500000000000000    0.7500000000000000  F  F  T
     0.2500000000000000    0.7500000000000000    0.2500000000000000  F  F  T
     0.2500000000000000    0.7500000000000000    0.7500000000000000  F  F  T
     0.7500000000000000    0.2500000000000000    0.2500000000000000  F  F  T
     0.7500000000000000    0.2500000000000000    0.7500000000000000  F  F  T
     0.7500000000000000    0.7500000000000000    0.2500000000000000  F  F  T
     0.7500000000000000    0.7500000000000000    0.7500000000000000  F  F  T

If this is not quite what you want, or you want more general constraints which can be achieved in a molecular dynamics run, it will also be worth checking out the ICONST file.

It might also be useful to know that external forces can be put on any atom since version 6.5.0, using the INCAR tag EFOR.

Also, I could not reproduce the BRMIX problems when running a single ionic step using your setup, without any modifications to the 6.5.0 source code. The calculation converges fine in 29 steps, but after step 19, I do get some warnings:

Code: Select all

WARNING in EDDRMM: call to ZHEGV failed, returncode =   6  3     23

However, these warnings can be easily avoided when using ALGO=Normal, which converges with no errors or warnings in 18 steps.

As a general comment: Your EDIFFG setting is very tight for relaxations. Forces below 0.001 eV/A will be effected by noise a lot.

If you need more assistance, please also provide OUTCAR and the standard output alongside your input files in your next post, so I can help you more efficiently.

All the best,
Michael

[dominic_varghese]

Hi Michael,

Thanks for your reply. From my understanding both Selective Dynamics and EFOR tags are for relaxing the atoms along specific directions, what I wanted was to do a biaxial relaxation where 2 axes(say x and y) are fixed and relaxation happens only along the z direction (atoms are also allowed to relax). Is it possible to do that without making the edit in constr_cell_relax.F file and compiling it?

Thanks
Dominic

[michael_wolloch]

Dear Dominic Varghese,

If you want to keep x and y fixed and relax only the z-direction, the POSCAR I provided with selective dynamics will work. Since the atoms are fixed in the xy plane, the cell cannot relax in those directions. But movement along z is allowed. Is this not exactly what you want to do?

[dominic_varghese]

Hi Michael,

I tried relaxing the system along z as per the Selective dynamics part as well as with my compilation with the additional subroutine. The results are different in both case. I am attaching the outputs here

vasp_forum.zip

. What I wanted was to relax the system along z direction (fixing x and y lattice parameters and relax along z). With the selective dynamics the whole lattice is relaxing (x and y aren't fixed anymore).

Thanks
Dominic

[michael_wolloch]

Dear Dominic Varghese,

Thanks for the CONTCAR files. You are absolutely right that the selective dynamics option does not work in this case. I was under the impression that the Cartesian coordinates of the atoms would be fixed, but this is not the case. It just fixes the relative positions of the atoms with respect to the lattice parameters, but still allows the lattice to relax if ISIF=3.

Nevertheless, there is an option in VASP that is able to replicate the modification of the CONSTR_CELL_RELAX routine without the need to recompile:

The LATTICE_CONSTRAINTS INCAR tag.

When setting

Code: Select all

LATTICE_CONSTRAINTS = .FALSE. .FALSE. .TRUE.

You allow only the zz component of the stress tensor to be non-zero.
The advantage is that you do not need to recompile the code if you want to set a different constraint.

I redid your relaxation with the 6.5.1 release version, and the LATTICE_CONSTRAINTS results match the hard-coded version up to 9 decimal places in the lattice vectors.

I apologize again for my initial mistake and hope that you have not lost too much time.
Michael

[dominic_varghese]

Thanks Michael, this was helpful.

[michael_wolloch]

Dear Dominic Varghese,

Do you have any more questions on the topic, or can I lock the thread?

Cheers, Michael

[dominic_varghese]

Yeah sure, thanks for the help!