bug: symmetry constraints fail silently for mismatched choice of origin

[ycexiao]

Problem

In the example crystalpdfall.py, if the PDFGenerator("xG_si") is created by:

generator = PDFGenerator("xG_si")
stru = Structure()
stru.read(str(ciffile))
generator.setStructure(stru)
# ...
constrain_as_space_group("Fd-3m")

, which is the same as crystalpdf.py,
Instead of

xgenerator_si = PDFGenerator("xG_si")
stru = loadCrystal(ciffile_si)
xgenerator_si.setStructure(stru)

the generated ycalc will be completely off with only one broad peak.

Here is the analysis LLM provides:

For space groups with multiple valid origin choices (e.g. Fd-3m), diffpy.structure.spacegroups.get_space_group(name) returns a fixed table entry for one particular origin/setting. This silently produces wrong symmetry operators when combined with atom coordinates from a CIF that uses the other origin choice

When applied to a diffpy.structure.Structure parsed from a standard Origin-Choice-2 Fd-3m CIF (e.g. silicon), the resulting constraint equations don't match the atoms' actual site symmetry, and evaluating them collapses/moves atoms so that a subsequently calculated PDF shows a single huge unphysical peak instead of the correct pattern. Loading the same CIF through pyobjcryst.loadCrystal avoids the issue because ObjCryst always substitutes the crystal's own literal symmetry operators instead of trusting a by-name lookup.

Reproduction:

from diffpy.structure.spacegroups import GetSpaceGroup
from diffpy.structure.parsers import get_parser
from pathlib import Path

# Standard diamond-Si CIF (Fd-3m, Origin Choice 2, atom at 0,0,0)
sg_table = GetSpaceGroup("Fd-3m")
print(sg_table.symop_list[1].R, sg_table.symop_list[1].t)
# -> [[-1,0,0],[0,-1,0],[0,0,1]], [0, 0.5, 0.5]   (Origin Choice 1 convention)

p = get_parser("auto")
stru = p.parse(Path("si.cif").read_text())
print(p.spacegroup.symop_list[1].R, p.spacegroup.symop_list[1].t)
# -> [[1,0,0],[0,1,0],[0,0,1]], [0, 0.5, 0.5]     (Origin Choice 2 convention, matches the file)

Proposed solution