IIRC I ripped this from pyscf many years ago, but it indicates that for CIS/TDA you're correct, but if there are deexcitation vectors you need to normalize them together:

    def norm_xy(z: np.ndarray, nocc: int, nvirt: int) -> Tuple[np.ndarray, np.ndarray]:
        x, y = z.reshape(2, nvirt, nocc)
        norm = 2 * (np.linalg.norm(x) ** 2 - np.linalg.norm(y) ** 2)
        norm = 1 / np.sqrt(norm)
        return (x * norm).flatten(), (y * norm).flatten()

Ah thanks, TD was originally missed because the DVB calculation wouldn't converge for whatever reason, I've now added a new test for TD with water to test the normalisation with both x and y. The implementation is now:

def norm_xy(x, y):
    norm_factor = 1.0 / np.sqrt(
        np.linalg.norm(x) ** 2 - np.linalg.norm(y) ** 2
    )
    return (x * norm_factor, y * norm_factor)

This logic is beyond me really, but the 2 * multiplication factor in your function was giving the wrong results?

This is fine for now but I'm going to try and understand this.

Can we put this in alphabetical order for the second column?

(Also, quick poll...should I convert this to JSON/TOML/YAML/... like I did for regressionfiles.yaml?)

Yep no problem.

Personally I'm a YAML fanboy so my default position is yes, but in this case the table format is actually pretty useful and it would be a shame to lose that. Maybe an argument for the condensed list form?
Eg

- [Basis, Psi4,  GenericBasisTest, basicPsi4-1.7, dvb_sp_rks.out]
- [Basis, QChem, GenericBasisTest, basicQChem5.1, dvb_sp.out]
...

Or maybe could nest? Something like:

Basis:
  Psi4:
    - [GenericBasisTest, basicPsi4-1.7, dvb_sp_rks.out]
  QChem:
    - [GenericBasisTest, basicQChem5.1, dvb_sp.out]

Wow, in the 11 years I've been working on this code, I've never noticed that this Gaussian calculation is wrong.

I can't tell from the control or ricc2.out, but it looks like the Turbomole calculation is unrestricted but a paired singlet, so an almost identical problem to the Gaussian calculation.

I could have sworn that I added an unrestricted TDDFT Q-Chem calculation in unit or regression tests, but apparently not.

#1533

Yeah I'll be honest this did confuse me for a sec, funny how things can slip through. I wonder if the intention was originally to do a delta-SCF type calculation (the original file name in G03 was apparently deltasym.log) and maybe this was the ground state? Just speculation.

That Turbomole one was probably me I'd guess so woops there too. Will address in another PR.

Horrifying. This is another part IMO of the pain from having "parsing" being a separate path from IO and now bridges.

Yeah a bit of a mess right now. This 'bridge' does feel quite a lot like a parser, but then again we might want an actual PySCF parser (from the PySCF log files) in the future in which case this guy would need another name or something

I think, but am not sure, that these don't need to be here if stuff is reworked. We keep them in bridges, so they're only specified once, and then you'd do pip install cclib[dev]. The (naming) problem is that test isn't all things needed for testing, but only things needed for testing, and needing dev instead is confusing.

If we rename test to test-infrastructure (better name welcome), then add

test = ["cclib[bridges,docs,test-infrastructure]"]

it will be more consistent.

Yeah that makes sense, and have now updated.

As an unfortunate side effect the docs build then broke because of #1523, which is not something we've considered before I don't think. Considering obabel really isn't a dependency in Pip terms atm, and the wheel build doesn't seem to be functioning, I've removed it from the pyproject for now. Doesn't feel great so would be happy to explore alternative/better alternatives...

This is driving me crazy. I would like to push njzjz/openbabel-wheel#6 and openbabel/openbabel#2408 as a solution but not sure I have the energy.