Future of nmo, nbasis and similar attributes #99
Comments
nmo, 'nbasis' and similar attributes|
Related: #116 ( |
Closed
|
Also related: comment in #129 (in short: ONIOM jobs also change stuff, so they could be considered a specific case of fragments). |
This was referenced Sep 15, 2014
|
There are a number of breaking changes I have in mind, along with the ones already presented here. Most of them are related to the way data is handled during geometry optimizations. Where should we have this discussion? |
|
Perhaps a more general discussion is better suited for the mailing list. My rough idea of the way forward is to merge in the pending branches (writers, DALTON) and do as many things as possible with backwards compatability for 1.4. After that, it might be clearer what we should change for 2.x. What do you think? |
|
Yes, let's do this. |
langner
added a commit
to langner/cclib
that referenced
this issue
Nov 18, 2020
langner
pushed a commit
to langner/cclib
that referenced
this issue
Nov 18, 2020
Add Gaussian98 G3 job from NIST CCCBDB suite
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following #94 and similar bugs in the past, there was an idea to change
nmointo an array, since it can change between SCF cycles as orbtials are dropped for various reasons. This issue is meant to collect our discussion on what to do with this.Two aspects to consider:
nmoin this way suggests other attributes should also change that can behave similarly, includingnbasis.The text was updated successfully, but these errors were encountered: