Repository navigation
MOs: "output has 22 basis functions, ECCE has 17" for an NWChem 6-31G* calculation (polarisation functions lost when reading the stored basis) #265
Description
9.0.0-beta.1, Linux. Opening Properties > MOs on an NWChem calculation (methane, SCF/RHF energy, created 2026-08-29 with an 8.x build, on the per-user data server) gives:
ECCE cannot draw this orbital: the output has 22 basis functions, but the basis set ECCE has for this calculation has 17. The calculation probably used a different basis set than ECCE expects.
The files agree with the output, not with ECCE:
- Input (
Inputs/nwch.nw):basis "ao basis" spherical,C library "6-31G*",H library "6-31G*". - Stored basis (
Parameters/BasisSet.ecce_basisset):Name="6-31G*", with a component tagged6-31G*:other_generally_contracted. - For CH₄, 6-31G* spherical gives 9 + 5 (C) + 4×2 (H) = 22 functions. 17 is 6-31G without the carbon d shell.
So the configuration ECCE builds from the stored basis (gbsConfig() → TGBSConfig, used by MoPanel/MoAoBasis) loses the polarisation functions. Possibly an older storage format (8.x era) that is read differently now, or the multi-part 6-31G* ("other_generally_contracted") losing a part. The message itself is correct to refuse; the basis is what is wrong.
To check:
- the same calculation's Organizer summary (Functions, Polarization);
- a fresh NWChem 6-31G* calculation from beta.1;
- the TGBSConfig built from this
BasisSet.ecce_basisset(shell list per element).
Related: docs/claude/codereg/ basis-writer entries, #118/#154.
Activity
Stored basis: rebuild an aggregate that lost a part when it was saved (…
ohlincha commentedon Oct 11, 2026
0feb170: the stored basis files themselves lack the second part of the aggregate (saved while the #164 library bug was active; fixed at save time in fa0847f, but old files and their copies were never repaired). Such a group, recognisable by a repeated key in its orbital mapping, is now rebuilt from the library when read; groups with edited contractions are left as stored. tests/basisload reproduces the codes' own counts (22, 16, 28 where ECCE had 17, 11, 23). Gaussian runs whose deck wrote the damaged basis out explicitly really ran without the d shell and are now refused by the MO viewer.
ohlincha commentedon Oct 11, 2026
3d9f518: when the output's basis width fits neither convention of the repaired basis, the MO viewer re-reads the basis as stored; if that matches the output, the orbital is drawn with it and the panel warns ("drawn with the 23-function basis the output used; the complete basis has 28 …"), once per calculation in a dialog and permanently in the panel. Otherwise the existing refusal stands. Still on the completed basis, so still refusing or disagreeing for such runs: the composition line, View Coefficients, the MO diagram and Mulliken from the viewer.
MO panel: draw a run that used the basis as stored, with a warning (#265
ohlincha commentedon Oct 12, 2026
Checked on screen (Linux): an NWChem 6-31G* calculation (Calculation-8-2-1-1) draws its MOs with no warning. Closing.