bug: structure not loading properly in new version of PDFgui

[sbillinge]

Problem

this from Ben Frandsen

Hi all,

I noticed some unexpected behavior in PDFgui2 and wonder if it might be a bug. I was modeling some PDF data of cubic pyrochlore compounds and was getting horrible results in PDFgui2, even though I had previously generated nice fits using the old PDFgui. Looking closer, I found that PDFgui2 was expanding the unit cell incorrectly. As a simple example, consider cubic Ho2Ti2O7 (CIF attached; space group Fd-3m ). The asymmetric unit is:
loop_
_atom_site_label
_atom_site_type_symbol
_atom_site_symmetry_multiplicity
_atom_site_Wyckoff_symbol
_atom_site_fract_x
_atom_site_fract_y
_atom_site_fract_z
_atom_site_B_iso_or_equiv
_atom_site_occupancy
Ho1 Ho 16 d 0.5 0.5 0.5 0.5 1.
Ti1 Ti 16 c 0 0 0 0.5 1
O1 O 48 f 0.324(2) 0.125 0.125 0.5 1.
O2 O 8 b 0.375 0.375 0.375 0.5 1.

My installation of PDFgui2 (v. 2.0.4) generates a unit cell with 8 Ho atoms, 8 Ti atoms, 96 O1 atoms, and 32 8b atoms, which is obviously completely wrong. On the other hand, my old PDFgui (v. 1.1.2) gives me the 16 + 16 + 48 + 8 = 88 atoms expected.

I haven't used PDFgui2 enough to know if this is a widespread problem or some weird fluke with the Fd-3m space group. Has anyone encountered something like this?

Sorry to bring up this issue right now! I know there's a lot going on with the new diffpy release, so maybe this goes to the back burner for now, but I just wanted to mention it in case it had not yet been noticed.

Proposed solution

@Tieqiong this looks like something a bit bad. If you get a chance, could you take a look? Is it some change we have made in diffpy.structure? or utils? loaddata?

[Tieqiong]

@sbillinge Yes I'll take a look! I think it might be diffpy.structure, but probably a much older bug introduced before 2023. This seems also relates to diffpy/diffpy.structure#86

[sbillinge]

yah, maybe. The cif was attached to the message so I will try and grab it and send it to you so you can reproduce the bug.

[sbillinge]

That is the cif. I had to change its name with a .txt on the end to get GH to accept it.

[Tieqiong]

Do we want to keep this file here? I already downloaded it

[sbillinge]

ok to remove it after you download it. Probably a good idea.

[Tieqiong]

@sbillinge I think the error is caused by cif file parsing. Here (diffpy.structure/parser/p_cif::541)

    def _parse_space_group_symop_operation_xyz(self, block):
        """Process symmetry operations from a CifBlock.

        The method updates `spacegroup` and `eau` data according to symmetry
        operations defined in `_space_group_symop_operation_xyz` or
        `_symmetry_equiv_pos_as_xyz` items in `CifBlock`.         
         [...]
        """
        [...]
        # determine space group number
        sg_nameHall = ...
        sg_nameHM = ...
        self.cif_sgname = sg_nameHall or sg_nameHM or None
        sgid = block.get("_space_group_IT_number", "") or block.get("_symmetry_Int_Tables_number", "") or sg_nameHM
        self.spacegroup = None

        # try to reuse existing space group from symmetry operations
        if symop_list:
            try:
                self.spacegroup = FindSpaceGroup(symop_list)
            except ValueError:
                pass

        # otherwise lookup the space group from its identifier
        if self.spacegroup is None and sgid and IsSpaceGroupIdentifier(sgid):
            self.spacegroup = GetSpaceGroup(sgid)

        # define new spacegroup when symmetry operations were listed, but
        # there is no match to an existing definition
        if symop_list and self.spacegroup is None:
            new_short_name = "CIF " + (sg_nameHall or "data")
         [...]
        return

If the cif file provide the sgid (space group id, in this case "_space_group_IT_number 227"), the space group object will be created by searching the spacegroup table. However 227 is Fd-3m, and the cif actually is "_space_group_name_H-M_alt 'F d -3 m Z'" so instead of our default origin, the cif is origin choice 2. This caused wrong symmetry operations.

I'm not very familiar with detailed crystallography, so I might be wrong. But if we skip this id match and directly build the spacegroup from the given symops, the result is correct. So a easy fix (on user end), is to delete the line

_space_group_IT_number 227

A fix on our end is to re-ordering which piece of information we trust the most from the cif. e.g changing to:

sgid = sg_nameHM or block.get("_space_group_IT_number", "") or block.get("_symmetry_Int_Tables_number", "")

[Tieqiong]

Seems like only you can delete messages (the cif file) you sent...