Frequency Parsing in ORCA

Hello everyone,

I would like to report and discuss an issue I’ve encountered when loading vibrational frequency data in Avogadro2 (2.0.0) from ORCA output files that include the block:

%geom
  Calc_Hess true
end

Description of the Issue

When this keyword is used, ORCA performs an additional Hessian calculation at the end of the geometry optimization. As a result, the output file contains multiple sets of frequencies:

  1. Frequencies from earlier steps (e.g., intermediate or previous Hessians)

  2. The final, correct frequencies from the last Hessian calculation

However, Avogadro2 appears to:

  • Load the initial/previous frequencies first

  • Then append the final frequencies at the end of the list

  • But only the earlier frequencies are properly associated with animation modes

  • The final frequencies (which are the physically meaningful ones) often do not display animations

Expected Behavior

The parser should:

  • Detect multiple frequency blocks

  • Preferentially select the last (final) frequency set, since it corresponds to the converged structure

  • Ensure that vibrational modes associated with these final frequencies are correctly animated

Suggested Improvement

A robust solution would be:

  • Always prioritize the last frequency block in the output file

  • Optionally, provide a mechanism for users to select which frequency set to load (advanced use case)

Yes, @Juanes was reporting this as well, e.g. Conformer analysis: error in structures? - #3 by ghutchis

I opened an issue for this: Handling vibrations along trajectories · Issue #2764 · OpenChemistry/avogadrolibs · GitHub

The central issue is that vibrations are handled by generating multiple 3D coordinates, and there’s not currently support for handling vibrations for multiple steps.

While there are some good ways to handle this particularly in the context of multiple properties per coordinate / conformer block (Add new properties for conformers · Issue #2577 · OpenChemistry/avogadrolibs · GitHub) it’s not something I wanted to jam in right before the 2.0 release. (It’ll require some work in the underlying data structures as well as the UI.)

So the robust solution I’m proposing is:

  • Avogadro can store multiple vibrational sets connected with different coordinate sets (i.e., there’s a list of vibrations / frequencies connecting with different geometries)
  • When you select a particular coordinate set, you’ll get the vibrations connected with that

This is particularly important for things like an IRC or NEB-TS calculation in which you might want to verify that the start / end geometries are minima, and the TS has only one imaginary frequency.