I have situations where I want to manually specify the number of frozen core orbitals using num_frozen_docc, do some work, then calculate some MBIS properties including the volume ratios. The latter causes psi4 to automatically calculate the free-atom volumes in the same method as the last-run calculation (in my case, wb97m-d3bj) and inherits all the settings... including num_frozen_docc. I can insert a set num_frozen_docc 0; set freeze_core true right before the oeprop(wfn, 'MULLIKEN_CHARGES') call and make things go away, but what worries me is just how things fail.

Well, sometimes things are in fact perfectly fine. Other times, psi4 segfaults. The behavior depends on just how large num_frozen_docc is -- I think if it ends up exceeding some other quality dependent on the calculation, things go belly-up. Here's the relevant line from a coredump.

#0  0x00002b4f362ef958 in psi::scf::HF::compute_fcpi (this=0x223c06c0) at [snip]/psi4/psi4/src/psi4/libscf_solver/hf.cc:830
830             for (int i = 0; i < nfzc; ++i) frzcpi_[pairs[i].second]++;

And here's a minimum working example of the issue that MBIS_VOLUME_RATIOS runs into, as a standalone calc:

set num_frozen_docc 20
set basis def2-tzvppd
set reference uks
molecule mol {
0 2
H 0 0 0
units angstrom
}
E, wf = energy('wb97m-d3bj',return_wfn=True,)

If you flip num_frozen_docc to 18, it works. (19 works for me on some machines, not on others -- eek!). In all cases I'm invoking psi4 the same way: psi4 -n1 -i run.in --memory 500MB.

I'm building off of 1.6.X, using icc/2020.2-108-02c7; I don't think I have anything "special" set in my compile environment besides buildtype=RelWithDebInfo. I didn't mess with any optimization flags, for sure.