Orca Irc

ORCA IRC Calculation Skill

This skill handles the full IRC workflow: generating an ORCA input file from a confirmed transition state geometry, and post-processing the output to extract the reaction-path energy profile and endpoint geometries.

Scope: Input generation, local post-processing, and (optionally) HPC submission via the CatGo workflow engine. The "Submitting to HPC" section below covers the proven Expanse flow. If the user is running on their own non-CatGo infrastructure, just generate the input file from the template in Stage 1 and skip the submission section.

Target version: ORCA 6.x. The parser and defaults below are written against the ORCA 6 output layout used by CatGo's own parser (server/catgo/utils/orca_output.py::OrcaIrcOutput).

Prerequisites

IRC requires a transition state geometry that has been confirmed by a frequency calculation showing exactly one imaginary frequency corresponding to the reaction coordinate.

If the user has not run a frequency calculation on the candidate TS, suggest the orca-freq skill before generating an IRC input. Running IRC on a geometry that isn't a true first-order saddle point produces meaningless paths. This is a suggestion, not a hard stop — if the user confirms they know what they're doing and still wants the input, generate it.

Stage 1: Input Generation

Before generating the input, gather from the user:

• TS geometry — file path or pasted XYZ coordinates
• Method and basis set — must match whatever was used for the TS optimization and frequency calculation. Method/basis consistency across Opt → Freq → IRC is critical; mixing levels means the TS may not be a stationary point on the new surface.
• Charge and multiplicity
• Number of cores (%pal nprocs)
• Memory per core (%maxcore, in MB)

Optional (apply only if user specifies):

• Solvent model (CPCM). Gas-phase IRC is standard practice for confirming connectivity; solvation mainly affects barrier heights, not topology.
• Dispersion correction — again, match whatever was used for the TS search.

Hessian Handling (important — read all of this)

IRC moves downhill from the TS along the imaginary-frequency mode. To identify that mode, ORCA needs a Hessian at the TS geometry. Getting this step right is the single biggest factor in whether the IRC gives a sensible path.

What the Hessian is used for, concretely:

1. Diagonalize to find the mode with a negative eigenvalue (the imaginary frequency). That eigenvector is the initial descent direction.
2. Build a mass-weighted quadratic model around the TS. The very first displacement along the mode is scaled by Scale_Displ_SD, chosen (via Init_Displ_DE) to correspond to a target drop in energy.
3. Subsequent steps use an adaptive integrator in mass-weighted coordinates; the Hessian is not re-diagonalized every step (that's what SD vs. LQA flavors are about), but the first-step quality dominates the final path.

Consequences:

• A Hessian with more than one negative eigenvalue means your geometry is not a clean TS. IRC will pick one of the negative modes and the result is arbitrary. Fix the TS first.
• A numerically noisy Hessian (bad SCF convergence, too-loose grid) can flip the sign of a small imaginary mode or rotate the eigenvector into a nearby low-frequency mode. The IRC then follows the wrong coordinate — often tumbling, rotation, or a methyl rock instead of the bond-making/breaking mode. calc_numfreq or InitHess read from a converged AnFreq job is the fix.
• Reusing a .hess file from a calculation at a different method/basis/grid/solvation is a silent footgun. The eigenmode numbering can differ, so "the imaginary mode" may not be the same mode on the IRC surface. Only use InitHess read if the .hess was produced at the same level as this IRC job.

The three options:

Option A — InitHess read (preferred when applicable): Read a pre-computed .hess file from the frequency calculation at the same level of theory. Fastest and most accurate, because the Hessian is already well-converged and you skip recomputing it. Ask the user for the filename.

%irc
  InitHess read
  Hess_Filename "previous_freq.hess"
end

Option B — InitHess calc_anfreq: Compute analytical frequencies at the start of the IRC. Use when no .hess file is available and the method supports analytical Hessians (common DFT functionals, HF). Cleanest and still fairly fast for small-to-medium systems.

%irc
  InitHess calc_anfreq
end

Option C — InitHess calc_numfreq: Compute numerical frequencies. Use when analytical Hessians aren't available or aren't reliable for the chosen method (some double hybrids, multireference, custom-parameter methods). Much slower (scales with 6N SCFs) but works everywhere.

%irc
  InitHess calc_numfreq
end

Decision flow for the skill: ask "Do you have a .hess file from your frequency calculation at this level of theory?" If yes → Option A with filename. If no and the method supports analytical Hessians → Option B. If no and it doesn't → Option C.

IRC Parameters and ORCA Defaults

ORCA 6's documented defaults:

• MaxIter = 20 iterations per arm
• Step = adaptive, governed by Scale_Displ_SD (initial value derived from Init_Displ_DE) and dynamically rescaled — bounded to 1/16× – 4× of the initial value. There is no single fixed step-size default to quote.

The default 20 iterations is often too few to reach a clear minimum, so the recommended override is:

%irc
  MaxIter 70
  PrintLevel 1
  Direction both
end

Do not set Step unless the user specifically asks for a fixed step — the adaptive algorithm is usually better than any constant. If the path behaves badly, the right lever is usually MaxIter, InitHess, or the TS quality, not a fixed step size.

Rationale for the overrides:

• MaxIter 70 — ORCA's default of 20 is almost always too few for a path that reaches a clear minimum. Bump to 100–150 for flat PES regions.
• PrintLevel 1 — prints energy and gradient at each step so the run can be monitored and the path summary is written in full.
• Direction both — follows the path in both directions from the TS. Almost always what you want when confirming connectivity.

Composite Methods

For composite methods like PBEh-3c or r²SCAN-3c, do NOT specify a separate basis set — the basis is built into the method keyword.

! PBEh-3c IRC

This automatically satisfies method/basis consistency since the composite method has a fixed internal basis.

Template

# ORCA IRC Calculation
# Method: {method} {basis}
# TS confirmed by frequency calculation: {num_imaginary} imaginary mode(s)

%pal nprocs {nprocs} end
%maxcore {maxcore}

! {method} {basis} {dispersion} IRC

%irc
  InitHess {inithess_option}
  {hess_filename_line}
  MaxIter 70
  PrintLevel 1
  Direction both
end

%output jsongbwfile True jsonpropfile True end

* xyzfile {charge} {multiplicity} {ts_geometry_file}

When generating the input:

• If the user provides inline coordinates, use * xyz {charge} {mult} followed by the coordinates and closing *.
• Omit {dispersion} if already included in a composite method.
• Omit {basis} for composite methods.
• Omit the Hess_Filename line unless using InitHess read.
• Keep the %output jsongbwfile True jsonpropfile True end line — it makes ORCA emit the JSON files OPI's Output.parse() consumes during post-processing (Stage 2).

About OPI input builders

OPI (pip install orca-pi) ships typed BlockIrc builders that validate keys at construction. However, the catgo backend's irc node already emits its own %irc block from node params (irc_max_iter, irc_direction, init_hess, etc.). Pasting an OPI-built %irc block via extra_blocks would produce two %irc blocks in the same .inp, which is undefined behavior.

For this skill, stick with node params for %irc content and use extra_blocks only for %output. The OPI parsing wins (Stage 2) still apply. If you need a knob BlockIrc exposes that the node params don't (scale_init_displ, tolmaxg, monitor_internals, etc.), open that as a node-def gap rather than dual-emitting blocks.

Submitting to HPC (Expanse) — proven flow

Use this when the user wants the CatGo workflow engine to run the IRC on Expanse. Skip if they only want the input file.

Use catgo_workflow (graph-based), NOT catgo_workflow_engine (task-based). The graph-based tool auto-captures the viewer structure on create and lets you wire opt → freq → IRC explicitly. Param keys differ from the task-based API: graph-based uses method/basis, task-based uses orca_method/orca_basis.

1. Confirm TS structure is loaded and find session_id

catgo_view(action: "get_state")

curl -s http://localhost:8000/api/hpc/connections

Copy the session_id for host: login.expanse.sdsc.edu.

2. Create the workflow (auto-captures the TS structure)

catgo_workflow(action: "create", name: "IRC from TS")

3. Add the IRC node

catgo_workflow(action: "batch", workflow_id: "<wf_id>", operations: [
  {"op": "add_node", "node_type": "irc", "label": "irc1",
   "params": {
     "software": "orca",
     "method": "B3LYP",
     "basis": "def2-SVP",
     "charge": 0,
     "multiplicity": 1,
     "dispersion": "D3BJ",
     "max_iterations": 70
   }},
  {"op": "connect", "from_id": "<structure_input_id>", "to_id": "irc1",
   "from_handle": "structure", "to_handle": "structure"}
])