You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ORCA labels orbitals in an abelian subgroup, so its MO diagrams never correlate #147
An ORCA calculation on methane, run with symmetry enabled, produces an MO diagram with no correlation at all. The diagram's own note says why:
The fragment orbitals and the calculation's labels do not span the same representation (2A + 2B1 + 2B2 + 2B3 reported, 2A1 + 6T2 from symmetry)
The orbitals are labelled 2A, 1B₁, 1B₂, 1B₃ — which are D2 irreps — while the heading reads Td.
Why
ORCA says so itself:
Point group .... Td
Symmetry-adapted orbitals .... D2
Irrep A has 7 symmetry adapted basis functions (ofs= 0)
Irrep B1 has 5 symmetry adapted basis functions (ofs= 7)
ORCA only symmetry-adapts orbitals in abelian point groups. It detects the full group correctly and then works in the largest abelian subgroup — D2 for Td, and in general D2h or one of its subgroups.
So ORBSYM for any ORCA calculation carries labels from an abelian subgroup, not from the group ECCE detects on the structure. MoDiagramPanel builds its fragment columns in the structure's group, the two label sets cannot match, and correlation falls back to composition — which is not wired up (#132), so nothing is drawn.
This affects every ORCA calculation of a molecule whose point group is not already abelian. Water (C2v) is abelian and works; methane (Td), ammonia (C3v), benzene (D6h) and every coordination complex do not.
Not a regression, but newly visible
Until now ORCA jobs were generated with symmetry off by default, so they had no orbital labels at all and failed the same way for a simpler reason. Defaulting symmetry on means they now have labels — from a different group.
What a fix looks like
The diagram should be built in the group the calculation actually used, not the one the structure has, whenever the calculation's labels are irreps of an abelian subgroup of it. The machinery is largely present: MoFragments already has subgroupOf() and nameSubgroup(), added for splitting ethene across a subgroup, and MoDiagram::reconcile() already handles axis-convention disagreements within one group.
What is needed is the step before those: recognising that {A, B1, B2, B3} is D2, that D2 is a subgroup of Td, and rebuilding the fragment columns in D2 so the two sides speak the same language. A methane diagram in D2 is less informative than one in Td — the t₂ set splits into b₁+b₂+b₃ — but it is correct, and it is what the calculation computed.
Worth stating in the diagram when that happens, so nobody reads a D2 diagram as a Td one.
Reproducing
Any ORCA calculation of a non-abelian molecule with "Use symmetry" ticked. The point group and the adapted group are both printed near the top of the ORCA output, a few lines apart.
Confirmed live by Andy (2026-09-27): ORCA CH4 with def2-SVP (methane_orca-2-1) now draws in Td. The labels are computed from the orbitals and cross-checked against ORCA's own D2 labels. 2a1/1t2 are bonding, 3a1*/2t2* antibonding, and correlation lines run to C 2s/2p and to the 4H TASOs (a1 + t2). Implemented in 65e743f..862b771 plus 8a5e23a/2a23298/6715c6a. Still open: with 6-31G*, ECCE's stored basis is missing carbon's d shell (a basis-library bug with multi-file sets, under investigation), so the coefficient width doesn't match and the diagram falls back to D2. Keeping this open until that case works.
Confirmed live by Andy (2026-09-27): ORCA CH4 with 6-31G* (methane_orca, basis re-picked on a build with fa0847f) now draws in Td, as def2-SVP already did. The last blocker was the basis-library bug: stale DAV properties on the data server made both halves of 6-31G* identical, so the d shell was dropped. fa0847f makes the index outrank those properties, and tests/basisload covers it.
Activity
Basis sets: stop handing out a pointer into a frozen stream buffer
Move ComputeMoCmd's basis flattening into shared tdat/BasisFlatten (#151
ShellRotation: derive a symmetry operation's matrix for any shell (#151…
SymmetryAnalysis: full-point-group ORBSYM oracle (#147/#132 phase 3)
ohlincha commentedon Sep 27, 2026
Confirmed live by Andy (2026-09-27): ORCA CH4 with def2-SVP (methane_orca-2-1) now draws in Td. The labels are computed from the orbitals and cross-checked against ORCA's own D2 labels. 2a1/1t2 are bonding, 3a1*/2t2* antibonding, and correlation lines run to C 2s/2p and to the 4H TASOs (a1 + t2). Implemented in 65e743f..862b771 plus 8a5e23a/2a23298/6715c6a. Still open: with 6-31G*, ECCE's stored basis is missing carbon's d shell (a basis-library bug with multi-file sets, under investigation), so the coefficient width doesn't match and the diagram falls back to D2. Keeping this open until that case works.
ohlincha commentedon Sep 27, 2026
Confirmed live by Andy (2026-09-27): ORCA CH4 with 6-31G* (methane_orca, basis re-picked on a build with fa0847f) now draws in Td, as def2-SVP already did. The last blocker was the basis-library bug: stale DAV properties on the data server made both halves of 6-31G* identical, so the d shell was dropped. fa0847f makes the index outrank those properties, and tests/basisload covers it.
tests/symmetry: add SF6/Oh to the full-orbital-irrep oracle (#147/#132)
SymmetryAnalysis: independent no-gensym-frame subgroup cross-check (#147
MoDiagramPanel: draw the FULL point group when the cross-check passes (…