Parse intrinsic reaction coordinate calculations from Q-Chem #1042
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1042 +/- ##
==========================================
+ Coverage 87.79% 87.82% +0.03%
==========================================
Files 64 64
Lines 13435 13480 +45
==========================================
+ Hits 11795 11839 +44
- Misses 1640 1641 +1 ☔ View full report in Codecov by Sentry. |
| assert len(tokens) == 10 | ||
| assert self.rpath_direction is not None | ||
| coord_idx = len(self.atomcoords) - 1 | ||
| ircvalues_step = { |
There was a problem hiding this comment.
is there some guarantee of what fields will be populated in this dict for different IRC calculations? It seems like we are creating another metadata situation where the fields of this are not well defined. This might be necessary though
There was a problem hiding this comment.
Right now, I think the only thing that's important is some indication of which direction we're going (up or down the TS eigenmode). Other programs might only allow you to go in one direction, but I need a way of differentiating between the two since Q-Chem tries both.
|
Is this ready for v1.7.1? |
2944c88 to
659edde
Compare
|
I think all that remains is to make sure the tests are good and add some docs. |
|
I'm a bit stuck conceptually for how this implementation is supposed to work. For an IRC calculation, there are two levels of convergence:
I think we want to set it so that |
|
I think Gaussian was the initial implementation, so I've been refreshing my memory from there. Also looks like it's changed a bit since I last worked on it. It does look like I'm a bit surprised the first value is 5 ( |
659edde to
e7848c0
Compare
e7848c0 to
7095749
Compare
7095749 to
5a4365e
Compare
Closes #1040
Some things that need to be resolved:
ircstatusbeing separate fromoptstatusis more flexible in the event that a multi-step job is run, but the{converged,new,unknown,unconverged}_geometriesmethods only work withoptstatus, and their docstrings imply that they could be used for IRC calculations. The best solution is only useoptstatusand split multi-part jobs into multipleccDatainstances.optstatus.ircvaluesis a grabbag. Most of the stuff probably isn't important.The fix for printing an extra set ofI'm going to switch over to not removing the last printedatomcoords(the input ones appear again at the very end) fails for when a job appears after the IRC one.atomcoords, just so there are no surprises. Getting coordinates viaircstatus/optstatuswill make it so that these are easily avoided. My original thought process here was that IIRC the Gaussian BOMD parser doesn't keep rejected steps, so it's ok to leave stuff out ofatomcoords, but by that logic I'd skip everything that isn't going to be markedOPT_DONE, which doesn't make sense.