8000 Parses ORCA dispersion correction by jevandezande · Pull Request #418 · cclib/cclib · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Parses ORCA dispersion correction #418

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Parses ORCA dispersion correction #418

wants to merge 1 commit into from

Conversation

jevandezande
Copy link
Contributor

This PR parses the the dispersion correction in ORCA. Since a dispersion correction is done for every scf calculation, the dispersion energies are placed in an array that mirror the scf energies. Is this how we would like to organize it?

@langner
Copy link
Member
langner commented Aug 20, 2017

First of all thanks! Parsing the dispersion part would be great.

But I don't think dispersionenergies is a good name, because:

  1. The dispersion correction is a purely empirical value, it's not really an energy computed ab initio, so I don't think it should be treated analogically to SCF energies.
  2. It is specific to DFT, not relevant to Hartree-Fock.

I'm also thinking we could consider parsing all six DFT energy components and generalize in that direction. @berquist @ATenderholt what do you guys think?

As far as the logfile, could you fold that into the existing dft example we have? Is it possible to print and parse the other components as easily?

@berquist
Copy link
Member

The dispersion correction is a purely empirical value, it's not really an energy computed ab initio, so I don't think it should be treated analogically to SCF energies.

Most of the time it's empirical, that's correct. But there are nonlocal, nonempirical dispersion functionals (VV10 to name the most popular) that are density-dependent. However, this is a moot point as they are self-consistent and can't be separated from the SCF energy.

It is specific to DFT, not relevant to Hartree-Fock.

You can add empirical corrections to Hartree-Fock; one of Grimme's predefined set of parameters is for Hartree-Fock. There is also his HF-3c method, which is based on Hartree-Fock and incorporates an empirical correction.

The - part of the diff is the PR logfile, which actually uses HF, and the + part is a PBE0 calculation I ran.

@@ -2899,7 +2777,7 @@ SOSCF solution              ....       0.002 sec  (  0.0%)
                               DFTD3 V3.1  Rev 1                                
                           USING Becke-Johnson damping                          
 -------------------------------------------------------------------------------
-Hartree-Fock is recognized
+The PBE0 functional is recognized
 Active option DFTDOPT                   ...         4   
 
 molecular C6(AA) [au] = 4612.935949 
@@ -2908,23 +2786,23 @@ molecular C6(AA) [au] = 4612.935949
             DFT-D V3
  parameters
  s6 scaling factor         :     1.0000 
- a1 scaling factor         :     0.3385 
- s8 scaling factor         :     0.9171 
- a2 scaling factor         :     2.8830 
+ a1 scaling factor         :     0.4145 
+ s8 scaling factor         :     1.2177 
+ a2 scaling factor         :     4.8593 
  ad hoc parameters k1-k3   :    16.0000     1.3333    -4.0000 
 
- Edisp/kcal,au: -98.004057881696  -0.156179390875 
- E6   /kcal   : -48.511398547 
- E8   /kcal   : -49.492659334 
- % E8         :  50.500622530 
+ Edisp/kcal,au: -11.651506426106  -0.018567855411 
+ E6   /kcal   :  -7.273450074 
+ E8   /kcal   :  -4.378056352 
+ % E8         :  37.575024140 
 
 -------------------------   ----------------
-Dispersion correction           -0.156179391
+Dispersion correction           -0.018567855
 -------------------------   ----------------

I'm also thinking we could consider parsing all six DFT energy components and generalize in that direction.

I think they could be added to scfenergies once the attributes are made more flexible.

As far as the logfile, could you fold that into the existing dft example we have? Is it possible to print and parse the other components as easily?

One thing we need to be careful of: I just tested and confirmed that for ORCA, the dispersion correction isn't added to scfenergies, probably because the parser doesn't use FINAL SINGLE POINT ENERGY. However, any corrections in Q-Chem are added to scfenergies. I'm not sure what other programs do regarding the combination, and what fields the other parsers look for.

When parsing scfenergies, what should we expect that number to include? It makes sense that some effects are non-separable (VV10), and the user would know that. Ideally, everything is separable, and scfenergies always gives the ab initio energy, and dispersionenergies can be added to get the corrected energy. But this could be inconsistent depending on the program and the above argument, and users might always expect the SCF energy to be the corrected energy.

One possible answer is that scfenergies gives the dispersion-corrected energy, and dispersionenergies (or whatever we decide to call it) gives just the separable dispersion part (as done here), and scfenergies - dispersionenergies would give the nonempirical energy.

Thoughts?

@langner
Copy link
Member
langner commented Aug 21, 2017

The dispersion correction is a purely empirical value, it's not really an energy computed ab initio, so I don't think it should be treated analogically to SCF energies.

Most of the time it's empirical, that's correct. But there are nonlocal, nonempirical dispersion functionals (VV10 to name the most popular) that are density-dependent. However, this is a moot point as they are self-consistent and can't be separated from the SCF energy.

Well, I did not know about this case, I think I'll need to read up. The point is well taken, though, and you could in principle compute dispersion in some perturbative way akin to SAPT which would be interesting to parse.

Nonetheless, I am somewhat wary here since we are talking about an empirical correction, one of many possible. OTOH, I suppose you could use the same argument against any ab initio method, in the sense that it is an approximation. It's not a valid argument to not parse the data if it's there. We can deal with the nuances once we make attributes more flexible in 2.x (yay!).

I'm OK now with this. However, maybe we should call the attribute dispenergies or simply dispersion?

I don't think scfenergies should include any such corrections, though, if they are not part of the self-consistent computation. This is the approach we've taken with mpenergies and ccenergies as separate number that should be added to scfenergies, and I think we should be consistent in that way. However, if we wanted to parse and provide some component of scfenergies, I think ideally it would be part of that attribute in the future. The particular case here is not that category IIUC.

@langner langner modified the milestones: v1.5.3, v1.5.2 Aug 30, 2017
@langner
Copy link
Member
langner commented Sep 2, 2017

So, @berquist are you OK with merging this as-is? Do you prefer dispersion as a name or dispenergies?

@berquist
Copy link
Member
berquist commented Sep 3, 2017

Let me try and run some -D3 calculations with as many programs as I can, and I'll think about it.

@jevandezande
Copy link
Contributor Author

@berquist any thoughts on how to deal with dispersion?

@langner
Copy link
Member
langner commented Apr 4, 2018

Pushing back to v1.5.4, but let's try to resolve this before the summer.

@langner langner modified the milestones: v1.5.3, v1.5.4 Apr 4, 2018
@berquist
Copy link
Member
berquist commented Apr 4, 2018

I did end up running a bunch of calculations and will revisit this in the summer. There are complaints on the Q-Chem issue tracker about how the dispersion energy is displayed, which may help decide this.

@langner
Copy link
Member
langner commented Apr 17, 2018

Unfortunately this needs to be modified due to a recent refactorting.

-------------------------------------------------------------------------------
DFT DISPERSION CORRECTION

DFTD3 V3.1 Rev 1
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the dispersion version parsed somewhere else? Shouldn't this be done?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, but I'm hesitant to just stick it in metadata, because I think there is a better solution: If the standalone DFTD3 program produces output that is formatted the same as the above, we could use this as a test case for instantiating a parser inside a parser. It is probably worth having a DFTD3 parser.

Copy link
Contributor
@schneiderfelipe schneiderfelipe left a comment

Choose a reason for hiding this comment

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

This looks good. Can this be merged?

@berquist
Copy link
Member
berquist commented Apr 7, 2020

I think we ended up agreeing that this PR is what we want. #745 actually contains all the above changes, so I'm going to close this in favor of finishing that PR.

@berquist berquist closed this Apr 7, 2020
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.

4 participants
0