Request for ORCA formatting of ECP

[mphoff-ac22]

Hello,

I would like to request that the ECPs be added in ORCA format (the basis sets are fine, they are just in GAMESS US format).

Thank you!

[prckent]

Thanks for the request. We would indeed like to support more code formats, including ORCA's. Are you currently using a conversion tool that you have found to work or would we have to write and test the conversion?

[welchbr]

First time post, but ORCA can use the GAMESS format for basis and ecp input. You don't need to convert it.

[romanfanta4]

A small correction regarding the statement that the existing GAMESS-US files can be used directly in ORCA: the numerical data are in GAMESS-US conventions, but the files distributed in recipes are generally file fragments rather than complete external files in the format expected by ORCA.

For example, the Fe orbital-basis file begins directly with:

S 13
...

The documented external format used by GTOName also requires an element identifier. The $DATA and $END delimiters are optional, but the element identifier is not:

$DATA
Fe

S 13
...
$END

The same issue is more apparent for the ECP. Testing the original Fe.ccECP.gamess with

ReadFragECP 1 "Fe.ccECP.gamess"

produces:

Reading of a custom ECP requested
ECP file: Fe.ccECP.gamess
ECP read successfully!

Error: No ECP found in FragECP/ReadFragECP

Thus, “read successfully” only confirms that ORCA opened and parsed the file; it does not mean that an ECP was found and assigned. The bare recipe file cannot be used directly through ReadFragECP.

I prepared convert_gamess_ecp_to_orca.py to convert both kinds of files. Run it from the repository’s recipes directory:

cd pseudopotentiallibrary/recipes

# Inspect what would be generated
python3 convert_gamess_ecp_to_orca.py --dry-run

# Perform the conversion
python3 convert_gamess_ecp_to_orca.py

It recursively converts:

Fe/ccECP/Fe.aug-cc-pVDZ.gamess
    -> Fe/ccECP/Fe.aug-cc-pVDZ.orca

Fe/ccECP/Fe.ccECP.gamess
    -> Fe/ccECP/Fe.ccECP.orca

The basis output is a complete external basis file:

$DATA
Fe

S 13
...
$END

The ECP output is a native ORCA block:

NewECP Fe
  N_core 10
  lmax d

  s 2
    1 22.21062697 277.50032547 2
    2 9.51515800 46.20495585 2

  p 2
    1 24.57000871 194.99875056 2
    2 8.86648776 31.67945132 2

  d 4
    1 23.22091713 16.00000000 1
    ...
end

A minimal ORCA input is therefore:

! NoIter PrintBasis

%basis
  GTOName = "Fe.aug-cc-pVDZ.orca"

  # Contents of Fe.ccECP.orca:
  NewECP Fe
    N_core 10
    lmax d

    s 2
      1 22.21062697 277.50032547 2
      2 9.51515800 46.20495585 2

    p 2
      1 24.57000871 194.99875056 2
      2 8.86648776 31.67945132 2

    d 4
      1 23.22091713 16.00000000 1
      2 23.54714679 371.53467417 3
      3 23.47256344 -181.22603445 2
      4 9.85238815 -2.37305236 2
  end
end

* xyz 0 5
  Fe 0.0 0.0 0.0
*

ORCA provides GTOName for loading orbital bases from external files, but there is no corresponding global ECPName keyword for loading a native NewECP block. The converted ECP block must therefore be inserted into %basis.

The converter preserves all numerical fields exactly, changes only the required channel and column ordering, validates the ccECP Coulomb tail, writes outputs atomically, and skips identical completed conversions when rerun. On the current repository tree, it recognizes all 1,161 .gamess files: 88 ECP files and 1,073 orbital-basis files, with no failures or warnings.

Converted ccECP files checked against the reference energies shipped with the Pseudopotential Library. Each ORCA run uses only converted files:
<El>.cc-pV5Z.orca for the orbital basis (via %basis GTOName)
and
<El>.ccECP.orca for the potential (pasted in as a NewECP block).

ORCA 6.1.0, ! UKS PBE NORI DEFGRID3 VeryTightSCF PAL8. The reference is the Pyscf/PBE value in each element's energies.txt, which is UKS/PBE/cc-pV5Z (their NOTE 2), so the method and basis match and the numbers are directly comparable.

El	NCORE	e⁻	nbf	ORCA (Ha)	Pyscf/PBE (Ha)	Δ (Ha)
C	2	4	90	-5.409824790076	-5.40983	+5.2e-06
O	2	6	90	-15.884558732587	-15.88454	-1.9e-05
Si	10	4	90	-3.761089696967	-3.76109	+3.0e-07
Fe	10	16	148	-123.407469712266	-123.40717	-3.0e-04
Cu	10	19	148	-196.469994590186	-196.46999	-4.6e-06
Br	28	7	90	-13.341598624774	-13.34161	+1.1e-05
I	46	7	90	-11.442872846724	-11.44288	+7.2e-06
Au	60	19	148	-135.962173339615	-135.96224	+6.7e-05

0 of 8 cases outside tolerance. Six agree to better than 1e-4 Ha; Fe is at
3.0e-4 Ha.

Notes:

• NCORE and e⁻ are the values ORCA reports after reading the ECP, and match Z − NCORE for every element, i.e. the core count survives the conversion.
• Agreement at the 1e-4 Ha level is the expected outcome: the reference is quoted to five decimals and the two programs use different DFT integration grids. A misread N_core or a channel written to the wrong angular momentum moves the energy by whole Hartrees, and a misread contraction by several mHa, so this is a sharp test despite the loose tolerance.
• Fe's larger residual is a property of the reference, not of the conversion:
  an independent PySCF run on the same ccECP data also lands 2.0e-4 Ha below the published Fe value.
• Coverage: light main-group (C, O), third row (Si), 3d transition metals (Fe, Cu), heavy main-group (Br, I) and a 5d transition metal (Au, lmax = g, 60 core electrons).

See the ORCA documentation for external basis files and manual ECP parameters.

convert_gamess_ecp_to_orca.py