Repository navigation
bug: structure not loading properly in new version of PDFgui #291
Description
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?
Activity
Tieqiong commented on Aug 22, 2025
@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 commented on Aug 23, 2025
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 commented on Aug 23, 2025
That is the cif. I had to change its name with a .txt on the end to get GH to accept it.
Tieqiong commented on Aug 23, 2025
Do we want to keep this file here? I already downloaded it
sbillinge commented on Aug 23, 2025
ok to remove it after you download it. Probably a good idea.
Tieqiong commented on Aug 23, 2025
@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") [...] returnIf 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
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 commented on Aug 23, 2025
Seems like only you can delete messages (the cif file) you sent...
stevenhua0320 commented on Mar 8, 2026
@sbillinge should we also take care about this before the new release for diffpy.structure? I remembered this is the cif lookup bug dating back when I joined the group for the first time. We could take a try for the solution provided by @Tieqiong. If so I would make a PR for this.
sbillinge commented on Mar 8, 2026
yes, let's fix it if we can.