unexpected result of get_conventional_standard_structure() to mp-644693

[lwk8891]

Describe the bug The get_conventional_standard_structure() method of pymatgen.symmetry.analyzer.SpacegroupAnalyzer class changes the atomic connection of mp-644693.

To Reproduce

1. get the structure of mp-644693 by calling s=get_structure_by_materials_id('mp-644693') of pymatgen.ext.matproj.MPRestrer class
2. Create the SpacegroupAnalyzer class for structure s by anal=SpacegroupAnalyzer(s)
3. Get the conventional standard structure by conv_struct=anal.get_conventional_standard_structure()
4. Visualize the structures s and conv_struct by making POSCAR format of VASP, then the atomic connections are different

Expected behavior The atomic connection is maintained after getting conventional standard structure.

Screenshots

Additional context

[mkhorton]

Thanks @lwk8891, this is almost certainly a serious bug. I will investigate.

For now, I suggest you use .get_refined_structure() which might work for your purposes.

[ehofgard]

Has this issue been resolved? I need to transform to the conventional setting and want to ensure I'm getting the correct results. Currently, I'm getting the same unit cell parameters using both .get_conventional_standard_structure() and .get_refined_structure().

Example:

entry = "mp-28243"
with MPRester(api key) as mpr:
    structure = mpr.get_structure_by_material_id(entry)
    sga = `SpacegroupAnalyzer(structure)` 
    print('Prim',structure.lattice.abc, structure.lattice.angles)
    conventional_structure = sga.get_conventional_standard_structure()
    print('Conventional', conventional_structure.lattice.abc, conventional_structure.lattice.angles)
    refined_structure = sga.get_refined_structure()
    print('Refined', refined_structure.lattice.abc, refined_structure.lattice.angles)

Output: Prim (4.121743287390061, 7.1843702, 7.499651169364684) (90.0, 105.94984245397592, 90.0) Conventional (4.121743287390061, 14.421868563834614, 7.1843702) (90.0, 90.0, 90.0) Refined (4.121743287390061, 14.421868563834614, 7.1843702) (90.0, 90.0, 90.0)

These parameters do not match the associated entry in the ICSD (https://www.ccdc.cam.ac.uk/structures/Search?Ccdcid=36216&DatabaseToSearch=ICSD) even though .get_refined_structure() is said to have the same parameters as the ICSD.

[fraricci]

Hi!

I quickly checked the original issue and could not reproduce it. I get the same structure for mp-644693 after using the get_conventional_standard_structure(). There is just a swap of the a and b axes, but the structure is the same. This swap is due to the "convention" used in the definition of the cell as reported in the doc of the function:

Gives a structure with a conventional cell according to certain
standards. The standards are defined in Setyawan, W., & Curtarolo,
S. (2010). High-throughput electronic band structure calculations:
Challenges and tools. Computational Materials Science,
49(2), 299-312. doi:10.1016/j.commatsci.2010.05.010
They basically enforce as much as possible
norm(a1)<norm(a2)<norm(a3). NB This is not necessarily the same as the
standard settings within the International Tables of Crystallography,
for which get_refined_structure should be used instead.

In your case, there is a similar swap of the a and b axes, but I'm guessing the structure is the same. The small difference in the decimal digits could come from the fact that the ICSD is the exp. structure while the stucture from MP is relaxed.

Hope this helps.

[ehofgard]

Hi! Thanks for the help! What is the difference between get_conventional_standard_structure() and get_refined_structure() then? In the documentation, it says that get_refined_structure() should be used to get the standard settings used within the International Tables of Crystallography, but it seems to return the same results as get_conventional_standard_structure() in the example above.

[fraricci]

well, get_conventional_standard_structure() follows the convention in Setyawan, W., & Curtarolo, S. (2010); whereas the get_refined_structure() follows the International Tables of Crystallography ;-) I'm not sure about which convention is used in ICSD, it might be neither of the above.

[Andrew-S-Rosen]

@janosh: Looks like this can be closed based on @fraricci's analysis.