Description

@carolinesargent identified a bug where running FSAPT with an external potential w/o having frozen the orientation with no_com + no_reorient would run but give the wrong answer. :-(

External potentials has long been one of those cases where we required the user to freeze the orientation at molecule creation time so that the potential could be set in the same frame. This couldn't be fixed driver-side because as soon as the core.Mol builds w/o freeze directives, it loses the original Cartesian coordinates. (The clone, set_nocom, set_noreorient calls in the driver allow regular sapt to forego user setting by preventing the dimer, monoA, monoB from having different frames.)

Happily, in the intervening period, @maxscheurer ran into exactly this problem for polarizable embedding potentials and solved it by tacking a copy of the original Cartesians onto the molecule. So we're applying this to FSAPT also.

I've been getting some segfaults that I think are a quirk of my directory, hence the cc31 testing.

User API & Changelog headlines

• Fixes bug where FSAPT with an external potential and without no_com/no_reorient set would return wrong answer.

Dev notes & details

• Let's use this route to accommodate aux info in the frame of the Cartesianmol

Checklist

• Tests added for any new features
• All or relevant fraction of full tests run

Status

• Ready for review
• Ready for merge