Wrong structures with new API/db

Materials Project Materials Project Data/API
1

Hello, when I query the new materialsproject database for a crystal structure via new API I obtain wrong results for some materials. In the case of bulk iron for example

from mp_api.client import MPRester
with MPRester(MP_API_KEY) as mpr:
    x = mpr.materials.summary.search(material_ids=['mp-13'], fields=["structure"])

would not result in a standard bcc conventional or primitive cell, but yields instead

    abc : 2.477813028804854 2.477809133849768 4.054295207189474
 angles : 90.00003845025343 90.00031950636807 109.469836683298

I also got a dubious result for bcc Cr (mp-90), with a strangely large unit cell volume of 26.169 A^3. Generally speaking, the structures seems somehow degraded with respect to those present in the legacy database, eg in the case of fcc Al (mp-134) one has

    abc : 2.8559542459167657 2.855954291634759 2.855955
 angles : 60.00000337792521 60.00000284838631 60.000002428463056

which looks like a single-precision trucation of the values, contrary to the legacy database where symmetries seemed to hold up to double precision.

Is there anything wrong in the way I query the database, or the new materialsproject has indeed different entries with respect to the legacy one, even for simple metals as these?

2

Hi,

any news on this issue? Am I querying the database in a wrong way?

3

Hey @gornit, keep in mind that the representation of a crystal is nonunique. The particular cells for both bcc Fe and Co that you identified are neither a primitive cell nor the conventional cell (the primitive cell is also nonunique, e.g., you could choose the Wigner-Seitz cell over one that’s easiest to write down by hand).

Also important: the cell presented by MP can contain any number of repeat units in a “non-standard” representation of the cell. We do not show a unit cell nor the conventional cell by default.

To see this, try the following:

from mp_api.client import MPRester

with MPRester("your_api_key") as mpr:
    summary_docs = mpr.materials.summary.search(material_ids=["mp-13","mp-90"])

mp_structures = {
    str(doc.material_id): doc.structure
    for doc in sorted(summary_docs, key = lambda sdoc: sdoc.material_id)
} # get structures indexed by MPID and sort in ascending order

conventional_cells = {
    mpid : structure.to_conventional()
    for mpid, structure in mp_structures.items()
}

primitive_cells = {
    mpid : structure.get_primitive_structure()
    for mpid, structure in conventional_cells.items()
}

When you print conventional_cells, you see clear bcc structures:

{'mp-13': Structure Summary
 Lattice
     abc : 2.863035498949916 2.863035498949916 2.863035498949916
  angles : 90.0 90.0 90.0
  volume : 23.468222587900303
       A : 2.863035498949916 0.0 1.75310362981713e-16
       B : -1.75310362981713e-16 2.863035498949916 1.75310362981713e-16
       C : 0.0 0.0 2.863035498949916
     pbc : True True True
 PeriodicSite: Fe (0.0, 0.0, 0.0) [0.0, 0.0, 0.0]
 PeriodicSite: Fe (1.432, 1.432, 1.432) [0.5, 0.5, 0.5],
 'mp-90': Structure Summary
 Lattice
     abc : 2.968899355116029 2.968899355116029 2.968899355116029
  angles : 90.0 90.0 90.0
  volume : 26.16895775704032
       A : 2.968899355116029 0.0 1.817926546116743e-16
       B : -1.817926546116743e-16 2.968899355116029 1.817926546116743e-16
       C : 0.0 0.0 2.968899355116029
     pbc : True True True
 PeriodicSite: Cr (0.0, 0.0, 0.0) [0.0, 0.0, 0.0]
 PeriodicSite: Cr (1.484, 1.484, 1.484) [0.5, 0.5, 0.5]}

(The various 1e-16 values are rounding errors, you can safely treat these as zero.)

The same goes for primitive_cells. You can confirm this by getting the space group of any of the structures:

mp_structures["mp-13"].get_space_group_info()
>>> ('Im-3m', 229)
conventional_cells["mp-13"].get_space_group_info()
>>> ('Im-3m', 229)
primitive_cells["mp-13"].get_space_group_info()
>>> ('Im-3m', 229)
1 Like
4

Dear @Aaron_Kaplan thanks indeed for your reply, this point

was not clear to me at all. Is this reported in some kind of documentation I am missing?

I now see that the symmetry of the structures is indeed correct, still I have some perplexity about some properties: in the new database the magnetic moment per site for Fe-bcc is quite high (2.7 Bohr magnetons) and far both from the experimental and DFT(PBE) values, whereas the old database reported something close to the expected value of 2.2 Bohr magnetons. The same goes for antiferromagnetic Cr-bcc, where both the volume and the magnetic moments seems overestimated in the new database with respect to the old one. Have these calculations been generated with a non-standard DFT functional? If so, which one?

5

Is this reported in some kind of documentation I am missing?

I don’t see it in a clear place in our documentation, that’s something we should add for clarity.

Our structures typically come from an experimental source, such as ICSD, or site substitution on known prototypes. These are often are not the primitive cell and we usually run these without symmetry reduction. Numeric symmetry determination can sometimes lead to incorrectly determined symmetries, and then a wrong primitive cell.

Have these calculations been generated with a non-standard DFT functional? If so, which one?

These are computed with the r2SCAN meta-GGA, which is represents a generally more-accurate, higher level of theory than the PBE GGA which was used to generate legacy MP data.

The tendency of meta-GGAs like r2SCAN (and hybrids like HSE) to predict too-large on-site ferromagnetic moments is well known, see ex. Table V of this paper. However, they tend to improve on GGAs in pretty much every other category (magnetic moments in oxides + better AFM ordering, more accurate thermodynamic stabilities, etc.)