Possible bug in standalone MRCC ECP treatment for LMAX=1

Dear MRCC developers,

I believe I have found a problem in the standalone MRCC treatment of semilocal ECPs with LMAX=1 (local p channel).

I encountered this while converting the canonical ccECP pseudopotentials from pseudopotentiallibrary.org to the CFOUR format used by MRCC. The generated ECPs reproduce the published ccECP atomic PBE energies in PySCF, and ECPs with LMAX>=2 also agree between MRCC and PySCF.

However, for LMAX=1 ECPs, MRCC appears to omit the nonlocal s-p channel.

A minimal example is the C atom with ccECP and cc-pVQZ at UKS/PBE:

MRCC 25.1.1, full ccECP: -12.023750846 Ha
MRCC 26.1.1, full ccECP: -12.023750846 Ha

PySCF, full ccECP: -5.409591... Ha
Published ccECP PBE value: -5.40983 Ha

PySCF with the s-p channel explicitly removed: -12.023750... Ha

Thus, deleting exactly the s-p semilocal component of the ECP in PySCF reproduces the MRCC result.

I repeated the test for Li, Be, F, and Ne, and in each case the MRCC energy agrees with the PySCF Hamiltonian in which the s-p channel has been deleted to within approximately 10^-5 Ha.

As controls, ECPs with higher local angular momentum work correctly. For example, Si (LMAX=2, local d) and Cr (LMAX=2, local d) reproduce the full PySCF ECP results.

I also verified that:

* MRCC is reading the custom ECP from the run-directory GENBAS. Deliberately perturbing an ECP coefficient changes the MRCC energy substantially.
* The ccECP numerical parameters in GENBAS are identical to the original ccECP data.
* The same ECPs reproduce the published ccECP PBE energies when parsed independently by PySCF.
* Changing the formal LMAX and adding zero higher-l channels did not restore the missing contribution.
* The behavior is identical in MRCC 25.1.1 and 26.1.1.

I checked the MRCC manual before reporting this. It states that user-supplied ECPs in CFOUR format can be placed in GENBAS and that arbitrary non-default ECPs may be used. I could not find any documented restriction requiring LMAX>=2 or excluding ECPs for H-Ne.

I noticed that the ECPs distributed with MRCC start at Na, so perhaps the LMAX=1 case is simply not represented in the standard test set.

Could you please confirm whether LMAX=1 ECPs are intended to be supported by the standalone MRCC integral code? If so, this appears to be an indexing or loop issue in the treatment of the lowest nonlocal channel.



Best,
Roman Fanta

 

Dear Roman Fanta,

thank you for reporting this, we will put a better solution to the next patch.

Your specific problem can be fixed by perfectly following the ECP format up to the last whitespace when you add a new ECP to the current version. The next patch will include handling for a more flexible ECP format.

The current version has a rigid fix format read of ECP data:
read(gbasfile,"(11x,i3,11x,i1)") ncorecp(iatoms),lmax
If you reformat your ECP text, you should be able to use the current code too before the patch.

(Except for ccECP-O, i.e., when zero electrons are in the ECP, like for H. That fix will come in the next patch too)

I hope this helps you,
Peter

Dear Peter,
thank you again for identifying the fixed-format read of the NCORE/LMAX record.

I have now updated the converter accordingly, using
read(gbasfile,"(11x,i3,11x,i1)") ncorecp(iatoms),lmaxso
that NCORE is written in columns 12–14 and LMAX in column 26.

After this correction, I repeated the MRCC/PySCF tests. The tested canonical ccECPs with NCORE > 0 now use the intended full ECP operator. In particular, the light-element NCORE = 2 cases Li–Ne reproduce the corresponding full-ECP PySCF results to the expected numerical accuracy. Representative heavier-element tests are also consistent.

I have therefore converted the complete scalar-relativistic canonical ccECP library from PseudopotentialLibrary.org, together with the associated Gaussian orbital basis sets, for direct use with MRCC and CFOUR.
The current conversion contains 65 canonical ccECP pseudopotentials and 841 associated orbital basis-set entries, including the cc-pVXZ, aug-cc-pVXZ, cc-pCVXZ, and aug-cc-pCVXZ families where available.

For MRCC, the supplied GENBAS.mrcc file contains both the basis sets and the ECP entries and can simply be copied to the working directory as GENBAS.To avoid ambiguity with basis sets already present in the MRCC library, the orbital basis labels carry a -ccECP suffix, for example Fe:cc-pVTZ-ccECP and Fe:aug-cc-pVQZ-ccECP, while the ECP label remains Fe:ccECP.A typical MRCC input therefore uses, for example:basis=special
cc-pVTZ-ccECP
cc-pVTZ-ccECPecp=special
ccECP
ccECP

The numerical ccECP and basis-set data are not refitted or altered. The converter cross-checks the available analytic source representations, validates NCORE, LMAX, channel ordering, and radial powers, and performs numerical write/read round-trip checks. The accompanying README contains the validation details and usage examples.

One remaining compatibility point is NCORE = 0. The canonical H and He ccECPs keep all electrons explicit, and MRCC 25.1.1/26.1.1 do not handle these ECP entries correctly. I therefore leave the H and He ccECP data unchanged and document the limitation rather than applying a workaround.
I have attached the complete converted library together with the converter and documentation in case it is useful to other MRCC users.

Thank you again for your help with identifying the formatting requirement.Best regards,

Roman Fanta
 

Dear Roman,
Thank you very much for the ECPs and basis sets. We will add them to our library.
Now, you can download a patched program version, 26.1.2, which can handle this ECP format.