MRCC 26.1.3: segfault in `mrcc` (`transp3`) for a perturbative-triples request

# MRCC 26.1.3: segfault in `mrcc` (`transp3`) for a perturbative-triples request (ex.lev=3, CC/CI method=3) with two correlated electrons and spatial symmetry

*Drafted by Claude Code (AI coding agent) on behalf of the Molpro developer who ran the tests.*

## Summary

The general-order `mrcc` executable crashes with SIGSEGV at the start of the CC
iterations when `fort.56` requests `ex.lev=3` together with `CC/CI method=3`
(the request Molpro sends for CCSD(T)) for a system with only two correlated
electrons and spatial symmetry switched on. The crash is in `transp3`
(`mrcc.f`, line 6942 in the 26.1.3 source). It reproduces with MRCC alone, with
integrals generated by MRCC itself, by changing only two fields of `fort.56`.
It does not occur with `ex.lev=2`, with `method=1`, or without symmetry.

## Environment

- MRCC 26.1.3, built from source with `build.mrcc -pOMP` (GNU, OpenMP)
- GNU Fortran (Homebrew GCC 16.2.0), Apple Accelerate BLAS/LAPACK
- macOS 27.0.1, arm64
- An older MRCC build (`/opt/mrcc`) crashes in the same way when driven by Molpro
  (its version string was not recorded)

## MRCC-only reproducer

`dmrcc` is first run with `ccprog=mrcc`, which makes it use the general-order
engine (`goldstone`, `xmrcc`, `mrcc`) and write `fort.55`/`fort.56` itself.
Only the first two numbers that matter, ex.lev and CC/CI method, are then
replaced in `fort.56`, and `xmrcc` and `mrcc` are run again.

```bash
#!/bin/bash
# usage: PATH=/path/to/mrcc:$PATH ./mrcc-repro.sh [ex.lev] [method]   (default 3 3)
mrop=${1:-3}; method=${2:-3}
d=$(mktemp -d); cd "$d" || exit 1
cat > MINP <<EOF
calc=CCSD(T)
ccprog=mrcc
basis=cc-pVDZ
mult=1
geom=xyz
2

H 0.0 0.0 0.0
H 0.0 0.0 0.74
EOF
dmrcc > dmrcc.out 2>&1 || { echo "dmrcc failed"; exit 2; }
# dmrcc writes: "2 1 0 0 1 0 0 1 0 1 1 1 0 0 0 6 0 0 0.00000 0 256 0 0.000E+00"
awk -v m="$mrop" -v c="$method" 'NR==1{$1=m;$5=c} {print}' fort.56 > fort.56.new \
  && mv fort.56.new fort.56
xmrcc > xmrcc.out 2>&1
mrcc > mrcc.out 2> mrcc.err; echo "mrcc exit status: $?  (dir: $d)"
grep -m1 "calculation" mrcc.out; grep -E "Total (CC|MP)" mrcc.out; head -3 mrcc.err
```

Results (H2, cc-pVDZ, D2h; 2 correlated electrons):

| ex.lev | method | `mrcc` header | Result |
|---|---|---|---|
| 3 | 3 | `CCSD(2) calculation` (`xmrcc`: `CC(1)(2)`) | **SIGSEGV** (exit 139), reproducible |
| 2 | 3 | `CCS(2) calculation` | works |
| 3 | 1 | `CCSDT calculation` | works, same energy as CCSD |
| 2 | 1 | `CCSD calculation` | works, E = -1.163374491952 |

`ex.lev=3, method=3` is the case that corresponds to CCSD(T): the first column
is the excitation level, the second the CC/CI selector, as in the header line of
`fort.56`. (My reading of the labels is from the program output only; I did not
check them against the MRCC manual.)

`mrcc.err`:

```
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
```

lldb, running `mrcc` in the same directory:

```
* thread #1, stop reason = EXC_BAD_ACCESS (code=1, address=0x625d079849001d8)
    frame #0: mrcc`transp3_ + 2608
->  str    d23, [x20, x4, lsl #3]
```

The faulting address looks like garbage, which suggests an out-of-bounds index
or an uninitialised array.

## How it was found (Molpro)

Molpro (2026.2) calls MRCC through the interface: it writes `fort.55`
(integrals), `fort.56` and an `iface` marker file, with no `MINP`, and runs
`dmrcc`. For `{MRCC,METHOD=CCSD(T)}` it writes

```
     3     1     0     0     3     0     0     1     0     1     1     1     0     0     0     7     0     0   0.000     0     256    35
```

(the last header name there is `ccmaxit`; `mrcc.f` and `xmrcc.f` read only up to
`mem`, so that extra field is not used and not the cause). The Molpro inputs

```
geometry={H;H,H,0.74}
{hf}
{MRCC,METHOD=CCSD(T)}
```

crash as described; with `nosym` they run. The stand-alone `dmrcc` with
`calc=CCSD(T)` (no `ccprog=mrcc`) does not crash, because it uses the separate
`ccsd` module rather than the general-order engine.

## Where it fails and where it does not (via Molpro, `rhf; mrcc,method=ccsd(T)`)

In Molpro the core orbitals are not correlated by default, so the MRCC input
describes only the valence electrons. All the failing cases below therefore have
exactly two correlated electrons (LiH has one frozen core orbital).

| System / basis | Symmetry | Result |
|---|---|---|
| H2: cc-pVDZ, cc-pVTZ, 6-31G | D2h | **SIGSEGV** |
| H2, cc-pVDZ | C2v | **SIGSEGV** |
| H2, STO-3G | D2h | works |
| H2, cc-pVDZ | `nosym` | works |
| He: cc-pVTZ, aug-cc-pVQZ | D2h | **SIGSEGV** |
| He, cc-pVDZ | D2h | works |
| LiH, cc-pVDZ (1 frozen core orbital) | C2v | **SIGSEGV** |
| LiH, cc-pVDZ | `nosym` | works |
| He2, H2O, Ne, cc-pVDZ | D2h/C2v | work (more than two correlated electrons) |

`METHOD=CCSD` works for H2 in all bases tried.

Unexplained: He/cc-pVDZ and H2/STO-3G work although they also have two
correlated electrons and symmetry; the failing cases all have more than one
virtual orbital in the totally symmetric irrep (an observation, not verified).
## Cause (found with a -g -O0 build and temporary diagnostics)

The crash is at `mrcc.f:7185`:

```
v(jj,i2,i1)=isign(1,ii)*wold(istro+i+iabs(ii))
```

in the symmetric branch of `transp3`, where the loop count and indices come
from the coupling-coefficient table `coup2`. Printing them just before the
store (H2, ex.lev=3, method=3) shows that the table does not contain integers:

```
jj,ii,i1,i2,i3 = 0 0 1 1 1
kk,n1,n2,n3,nn,nstr = 2 1 2 2 4 2
istro,i,coup2(n2+i2) = 0 0 4684959637965897728   (= 0x410451F800000000)
nir,mr,nsumnew = 8 F 2
```

`coup2(n2+i2)` is used as a loop count and contains the bit pattern of the
double-precision number 166463.0, i.e. stale workspace, so `jj` becomes garbage
and `v(jj,i2,i1)` writes far outside `v`. The table is passed at the call in
`mrcc.f` (about line 11604):

```
call transp3(..., icore(icmem(ism2,ism1,isa2,isa1,1,1,mod(is1,4)+4)),
                  icore(icmem(ism3,ism2,isa3,isa2,1,1,mod(is2,4)+4)), ...)
```

so the `icmem` entry for this symmetry/activity combination appears to point to
memory in which no coupling coefficients were stored. With two correlated
electrons, a three-fold-excitation (n3) intermediate has no strings, so
presumably no coefficients are generated for it, but `transp3` is still called
with n1=1, n2=2, n3=2 and nstr=2. I did not trace why `icmem` has no valid entry
here, or why other cases (e.g. He/cc-pVDZ) happen to work (perhaps the stale
memory is zero there). `nosym` takes the separate `nir.eq.1` branch of
`transp3`, which does not use `coup2`.

Note: `-fcheck=bounds` cannot be used on MRCC as a whole, because the workspace
arrays (`icore`) are declared with size 1 and trip the check immediately in
`integ.f`.

## Not tested

- Other compilers, optimisation levels, an MPI (non-OMP) build, Linux, x86-64.
- A system with two correlated electrons and `ex.lev=3` in other symmetry groups
  beyond D2h/C2v, or an open-shell two-electron case.