Discrepancy between uploaded and calculated charge density

Materials Project
1

Dear team,

I calculated the charge density (CHGCAR) for structures uploaded in MP, and I observe a discrepancy compared to the charge density shared through the mp-api. I believe the error I am seeing is about 1%. I would like to ask if there are any differences in the DFT methods I used for the calculation.

I used MPGGAStaticMaker() from atomate2 for the DFT calculation, as shown below. Just in case, I am also attaching a sample INCAR file.

relax_job = MPGGAStaticMaker().make(structure)
relax_job = update_user_incar_settings(relax_job, incar_updates={'NCORE':4})

INCAR

ALGO = Fast
EDIFF = 0.0002
ENCUT = 520.0
ISMEAR = -5
ISPIN = 2
LASPH = True
LCHARG = True
LMAXMIN = 6
LORBIT = 11
LREAL = False
LWAVE = False
MAGMOM = 1*5.0 3*0.6
NCORE = 4
NELM = 100
NSW = 0
PREC = Accurate
SIGMA = 0.05

I appreciate your time and your response will be very helpful to me.
Sincerely,

Junkil Park

2

It’s possible that the input sets differ, especially if the charge density was generated at the end of a relaxation. Also a discrepancy of 1% is reasonable (wouldn’t call this an error, both the charge densities are approximate)

If you have the specific MP ID of the charge density you can check your input settings against those used in the calculation - happy to show you how as well!

3

I am always grateful for your kindness.

I would greatly appreciate it if you could share the input settings used to obtain the charge density for the structure mp-1114103 (Rb₃TlBr₆). Additionally, I would like to ask whether the charge density provided via the MP API is extracted directly from the optimization process, or if it is obtained through a separate static calculation after the optimization. I am curious whether there could be any differences in the resulting charge density between these two approaches.

4

For material mp-1114103, it looks like the charge density is coming from task mp-1816132:

from mp_api.client import MPRester

with MPRester() as mpr:
    charge_dens, task = mpr.get_charge_density_from_material_id('mp-1114103',inc_task_doc=True)

print(task.calcs_reversed[0].input.task_id)
>>> mp-1816132
print(task.calcs_reversed[0].input.incar)
print(task.calcs_reversed[0].input.kpoints)

Additionally, I would like to ask whether the charge density provided via the MP API is extracted directly from the optimization process, or if it is obtained through a separate static calculation after the optimization

The client only returns charge densities computed from a static calculation.

There could be differences in the charge density computed during a geometry optimization and a static if the k-point mesh no longer reflects the symmetry of the crystal, or if the volume of the crystal changes significantly

5

Thank you for your response. I’m sorry to bother you again, but I’d like to ask just one more question.

Through the code you provided, I confirmed that there is a difference between the INCAR used in my calculation and the one used for the data uploaded to the MP-API. (The KPOINTS were used identical) As mentioned earlier, I’m using MPGGAStaticMaker() from Atomate2 to prepare VASP inputs. So, if I want to perform calculations identical to those in the MP-API for a large number of structures, how can I prepare the inputs? Or is this not possible?

The following is the difference I observed in INCAR files. Most notably, the ediff values are different.
Once again, thank you for your kindness!

INCAR from mp-api (mp-1114103)

PREC = Accurate
ALGO = Normal
ISPIN = 2
NELM = 100
IBRION = -1
EDIFF = 1e-05
NSW = 0
ISIF = 3
ENCUT = 520.0
MAGMOM = 10*0.6
LREAL = Auto
ISMEAR = -5
SIGMA = 0.05
LWAVE = False
LCHARG = True
LVHAR = True
LASPH = True
LAECHG = True

INCAR from Atomate2

ALGO = Fast
EDIFF = 0.0005
ENCUT = 520.0
ISMEAR = -5
ISPIN = 2
LASPH = True
LCHARG = True
LMAXMIN = 6
LORBIT = 11
LREAL = False
LWAVE = False
MAGMOM = 10*0.6
NCORE = 4
NELM = 100
NSW = 0
PREC = Accurate
SIGMA = 0.05
6

If you’re using atomate2, then it’s safe to use the MPGGADoubleRelaxStaticMaker for our legacy PBE GGA / +U data, and MPMetaGGADoubleRelaxStaticMaker for the newer r2SCAN data

That doesn’t always guarantee that an older calculation used the same input sets, as in this example. But a discrepancy of 1% is completely reasonable. Numeric discrepancies of that order can even arise from compiler / architecture / parallelization differences