Skip to content

ORCA fixes and additions#1142

Open
jvalegre wants to merge 1 commit into
cclib:masterfrom
jvalegre:1.-orca_fixes
Open

ORCA fixes and additions#1142
jvalegre wants to merge 1 commit into
cclib:masterfrom
jvalegre:1.-orca_fixes

Conversation

@jvalegre

@jvalegre jvalegre commented Jul 4, 2022

Copy link
Copy Markdown

@berquist this is a summary of fixes/additions for the ORCA parser.

  1. Fixed issues:
    Compatible with print mini
    Avoids errors related to "**** THE GBW FILE WAS UPDATED" parts

  2. Additions:
    Final single point energy as properties:energy

@jvalegre

jvalegre commented Jul 4, 2022

Copy link
Copy Markdown
Author

BTW I'm having trouble adding the parsed Final single point energy to properties:energy in the resulting json file, do you know where the problem might be?

@berquist berquist left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that you're working through the attributes/metadata on the other PRs with others, so I won't focus on those, other than "final single point energy". Can you remove all of the newly-added attributes in this PR that don't have to do with the ORCA-specific updates?

assert maxDP_target == self.scftargets[-1][1]
else:
rmsDP_value = 0.0
rmsDP_target = 0.0

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies if this has come up before in a conversation, but do you have an example ORCA output where not having this causes problems? If this fixes an issue, we will need a test to make sure it's covered.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've hit this for geometry optimization with unrestricted methods, described in #1177
However, the fix in this PR is not correct, because it influences the parser output where it shouldn't.

A better fix for this is at ezpzbz/aiida-orca#67

@jvalegre jvalegre Feb 17, 2023

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@berquist - sorry, I just realized you had replied. I added this fix as a "quick patch" to avoid an error I was having when using the miniprint keyword (so I'm not sure if this patch also fixes Daniel's issue with unrestricted methods)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an example file where I find the issue when parsing with cclib
Bi2PyrH_SMD_DLPNO.zip

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Can you add this as a PR to https://github.com/cclib/cclib-data? We'll merge that after confirming any fix to the code gets it parsing.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I just added it

break
lines.append(line[line.find('> ')+2:])
if 'printlevel mini' in line or 'miniprint' in line:
self.logger.warning("WARNING: print level is set to mini, which might cause the loss of relevant information")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

# ------------------------- --------------------
# FINAL SINGLE POINT ENERGY -40.463946017697
# ------------------------- --------------------
if line[:25] == 'FINAL SINGLE POINT ENERGY':

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the value in adding this and agree it's important, but would like input from the others. It's definitely not metadata, but is not directly parsable from most programs and for ORCA doesn't mean anything in the context of an excited-state calculation (IIRC it's the energy of the first excited state).

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you talk to the other devs about this property?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We did talk about it, but I can't remember the entire conclusion. Do you expect it to be present for NWChem, Gaussian, ... and not just ORCA? Based upon your other proposals, you assume this isn't the G4 (or some other thermochemical) energy, right?

The risk to me is that

is not directly parsable from most programs

means we would have to construct it manually. That might be ok depending on what components you expect to be present.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to retrieve this property for all the programs. The goal is to have a unified parameter that could be used as a single-point energy correction (SPC). In ORCA, "FINAL SINGLE POINT ENERGY" contains the final SPC that you want to use. In Gaussian, the final SPC value that you want to use can be specified in different ways, but we could adapt the code that GoodVibes uses to detect these energies.

The problem I had when trying to adapt the energy values from cclib with GoodVibes/AQME is that QM programs sometime give different types of energy values that get parsed, so I couldn't use a single parameter to choose the final energy that I wanted to use as SPC.

An example in Gaussian for G4 calcs, you get multiple energy values during the same calculation, but the final energy you want to use for a SPC is that of the G4 protocol. However, in other calculations, the energy values you want to use are those coming from DFT or TDDFT calcs, which are contained in different properties of the cclib object or JSON.

Same for ORCA, for example when using CASSCF-NEVPT2 calculations, you get different types of energy, but for SPC you only want the final NEVPT2 energy. When you change the calc type (for example, to DLPNO energy calcs), the value of the SPC isn't NEVPT2 anymore (i.e. the DLPNO energy in this case).

Let me know if you need further information on this issue or the explanation wasn't clear enough!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi folks, excuse me for jumping in. @jvalegre, am I following you correctly in that what you are looking for is a single property that represents the 'final' energy of the calculation? ie, at the highest level of theory available?
So for for standard HF/DFT, this would be SCF, for MP2 (where HF and MP2 are available) this would be MP2, for MP3 (where HF, MP2 and MP3 is available) this would be MP3 and so on?

If so, I can see this being a useful property, particularly in more complicated calculations where the 'correct' choice may not be intuitive to the user. Whether this should be a numerical property or a pointer to one of the other properties though I'm less sure. Ideally whatever this final energy is, it should already have been parsed into another property, and at the very least it would be useful to indicate which energy is stored there.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @oliver-s-lee - that's correct, I want to retrieve the energy from the highest level of theory available. In my case, it's useful for DLPNO single-point energy corrections. I'm attaching an example file, in which the final energy should be:

-------------------------   --------------------
FINAL SINGLE POINT ENERGY     -1365.394243212048
-------------------------   --------------------

IntI-CF2-CF2H,OH,ax-a_DLPNO.txt

@berquist berquist self-assigned this Mar 4, 2023
@berquist berquist added the ORCA label Mar 4, 2023
@berquist

berquist commented Mar 8, 2023

Copy link
Copy Markdown
Member

Let's wait for #1143 to be merged before really tackling this, then #1141, unless you have a different preference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants