Skip to content
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

Gaussian FCHK Errors and Inefficiencies #1272

Open
JonathonMisiewicz opened this Issue Oct 1, 2018 · 11 comments

Comments

Projects
None yet
5 participants
@JonathonMisiewicz
Copy link
Contributor

JonathonMisiewicz commented Oct 1, 2018

Reposted from the forum. I can't investigate this myself, due to being banned by Gaussian.

  1. The MO and Density blocks are being mislabeled, for all levels of theory as far as I can tell. This prevents 3rd party apps from parsing the files correctly. The labels for the MO orbital energy and coefficients blocks should always be as follows:

Alpha Orbital Energies
Alpha MO Coefficients
Beta Orbital Energies
Beta MO Coefficients

Title case is important.

The Density blocks should be labeled according to the level of theory as follows:

Total SCF Density (this should be the label for both HF and DFT)
Total MP2 Density (don’t prepend ‘DF’ to any methods when using density-fitting)
Total MP3 Density
Total MP4 Density
Total CC Density
Total CI Density

Spin Density should be labeled similarly:

Spin SCF Density (this should be the label for HF, DFT, and CASSCF)
Spin MP2 Density
Spin MP3 Density
Spin MP4 Density
Spin CC Density
Spin CI Density

  1. Don’t write the Beta blocks for RHF jobs, as their presence makes 3rd party apps think that the level of theory is UHF, and that in turn leads to unnecessarily expensive calcs

  2. If canonical orbitals have been removed from the basis due to S_TOLERANCE, then the “number of independent functions” in the .fchk file should be the resulting number of canonical orbitals. Currently the “number of independent functions” always seems to be equal to the “number of basis functions”, which screws up parsing because the matrices aren’t nbasis x nbasis in this case.

  3. This wasn’t happening in v1.1, but in v1.2, writing the .fchk file triggers printing of the MOs to the output file, which bloats the file tremendously. I can’t figure out how to turn this off, but it is undesirable as a default behavior.

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Oct 2, 2018

Um, I think the standard is that MOs are always printed to the checkpoint file, since the point is that they're needed to run calculations and analyses anyhow. I don't see any reason why they wouldn't be dumped to the checkpoint.

I fully agree with points 1-3 though.

@andysim

This comment has been minimized.

Copy link
Member

andysim commented Oct 2, 2018

I think the problem is the MOs appearing in the output file in addition to the FCHK file. Should be an easy one to track down, I hope.

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Oct 2, 2018

I think the problem is the MOs appearing in the output file in addition to the FCHK file. Should be an easy one to track down, I hope.

Whoops, that's right..

@loriab loriab added this to the Psi4 1.3 milestone Oct 10, 2018

@dgasmith dgasmith modified the milestones: Psi4 1.3, Psi4 1.4 Dec 22, 2018

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Jan 14, 2019

#1475 now includes fixes to everything else but the spin-restriction; this would be easy to fix as well, I just need a way to check if the calculation is RHF or not.

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Jan 14, 2019

Done, so this is fully fixed by #1475.

@JonathonMisiewicz

This comment has been minimized.

Copy link
Contributor Author

JonathonMisiewicz commented Feb 4, 2019

I'm closing this tentatively, per #1475. If users still see problems, I'll reopen. #1478 may be relevant for problems related to inability to separate reference from correlated densities for passing into FCHK.

I'll post on the original forum topics the next time we get conda packages out, since users can check if further work is needed.

@JonathonMisiewicz

This comment has been minimized.

Copy link
Contributor Author

JonathonMisiewicz commented Feb 21, 2019

And, reopening. Let me quote the user:

Still not working in this latest version.

MP2 and CI jobs both write sections labeled “CC Density”. Instead, MP2 jobs should write “MP2 Density” and CI jobs should write “CI Density”. “CC Density” is for coupled-cluster jobs only.

Also, all post-HF methods are writing the same density to the “SCF Density” section as to their post-HF section. In the case of MP2 and CC jobs, it looks like it’s just the SCF Density. In the case of CI jobs, I think it’s the CI density, but in that case the CI density shouldn’t be written to the “SCF Density” section.

The point about the incorrect density being written seems distinct from #1478, as that bug is about the reference wavefunction returning a correlated density, not the correlated wavefunction returning a reference wavefunction.

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Feb 21, 2019

@JonathonMisiewicz

This comment has been minimized.

Copy link
Contributor Author

JonathonMisiewicz commented Feb 23, 2019

It's not clear to me that the label is aesthetic, but I'll assume it is for sake of argument. The mislabeling is still confusing, and it would be good to have the correct label printed. Is there a reason this wasn't done in #1475? The wavefunction's name attribute, as I recall, should have the information to specify whether the wavefunction is MP2, CI, CC, etc.

There is discussion elsewhere about the CI density being written to SCF Density (#1478), but I can't find any discussion about the SCF density masquerading as MP2 or CC densities.

@susilehtola

This comment has been minimized.

Copy link
Member

susilehtola commented Feb 24, 2019

Did they build the post-HF density? If not, then of course it'll dump out the SCF density.

@JonathonMisiewicz

This comment has been minimized.

Copy link
Contributor Author

JonathonMisiewicz commented Feb 24, 2019

It would be better for it not to have a correlated density, but it certainly wouldn't output the correlated density if the correlated density is never built.

Did you just want to note that the cause of the correlated density not entering the FCHK is because the correlated density was probably never constructed, or are you making a larger point?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.