search

QMCPACK / qmcpack

Main repository for QMCPACK, an open-source production level many-body ab initio Quantum Monte Carlo code for computing the electronic structure of atoms, molecules, and solids with full performance portable GPU support
http://www.qmcpack.org
Other
296 stars 138 forks source link

Should KECorr be removed? #486

Open prckent opened 6 years ago

prckent commented 6 years ago

Per comment in #482 "we should really remove KECorr. It's formally incorrect without a long-range jastrow."

jtkrogel commented 6 years ago

I don't think it should be removed. It is formally incorrect but it does result in a smaller residual finite size effect when used in practice. I think it should be removed once we have demonstrated that we have access to a better alternative in practice.

prckent commented 6 years ago

( Title edited )

rcclay commented 6 years ago

You bring up a good point, Jaron. KEcorr is probably within the correct order of magnitude, and scales properly with system size. What concerns me is that I strongly suspect that the reasonableness of the current KEcorr is due mainly to unit analysis--the expression does have proper volume factors, numbers of particles, etc., in the right places. In this case, we're basically doing the leading order KE Chiesa correction with a fudge factor. I see three alternatives:

1.) Sit down and try to come up with more reasonable heuristic for estimating 1/k^2 behavior as k->0 other than fitting a 1/k^2 function to a function that goes to a modest constant when k->0. This would at least give us some justification we can point to for our fudge factor that doesn't make people cringe. 2.) Ditch the current way of computing KEcorr and swap it out for the leading order chiesa correction (the one that depends on r_s or the plasma frequency). This will be less accurate, but then again, it's more honest than what KECorr does.
3.) Used in conjunction with (2): Don't compute the higher order chiesa correction unless a long range jastrow is present.

rcclay commented 6 years ago

Regardless, I feel like there are enough issues with this that this should not be a "feature" accessible to the casual QMCPACK user. Right now, it's super easy to pull the KECorr out of the scalar.dat and correct the energy with it (I think that some of our scripts do this), and there are no warnings, caveats, or anything associated with this. I have no doubt that we would use it responsibly, but I don't want a new QMC adoptee publishing a paper with this correction and then have us take flak if it doesn't give the accuracy they expect.

rcclay commented 6 years ago

In this test, I'm showing the sensitivity of KECorr to the 2body jastrow, if a short-ranged jastrow is used. I'm considering a 2x2x2 supercell of FCC Li with a density of 84a0^3/atom. Wigner-Seitz radius for this cell is 4.8 bohr, with 2.4 bohr for the primitive cell. What I do is change the real space cutoff of the 2-body jastrow between these two extremes and reoptimize the jastrow with the new cutoff parameter. I then calculate KECorr for this cell. Here's what I get for KECorr vs. 2body jastrow rcut.

r_c KECorr 2.4 0.00920844 3.6 0.02482221 4.6 0.04520218 4.8 0.05004278

prckent commented 6 years ago

Kayahan writes on google groups:

Thanks for all the replies, I haven't checked if v.3.2.0 prints out KECorr when SOA is not enabled, but in the current development version KECorr column is not printed when compiled with SOA enabled. KECorr is not very important for me, but when I was using qmca to compare the energies from two different qmcpack compilations, I was getting consistently lower energy results, then I found out that KECorr column is all zero in v3.2.0 (with SOA). When KECorr is not printed (in the development version this is the case), qmca does not calculate -q ce quantity now, but says KECorr column is missing. I think this is good enough to realize that this feature is missing, but otherwise if you only use qmca, but not really look at the scalar.dat files, you will end up getting inconsistent results.

jngkim commented 6 years ago

You can simply cut and paste from AoS. There is no SoA dependency.

But, it is a dangerous precedent.

On Fri, Nov 17, 2017 at 1:37 PM, Paul R. C. Kent notifications@github.com wrote:

Kayahan writes on google groups:

Thanks for all the replies, I haven't checked if v.3.2.0 prints out KECorr when SOA is not enabled, but in the current development version KECorr column is not printed when compiled with SOA enabled. KECorr is not very important for me, but when I was using qmca to compare the energies from two different qmcpack compilations, I was getting consistently lower energy results, then I found out that KECorr column is all zero in v3.2.0 (with SOA). When KECorr is not printed (in the development version this is the case), qmca does not calculate -q ce quantity now, but says KECorr column is missing. I think this is good enough to realize that this feature is missing, but otherwise if you only use qmca, but not really look at the scalar.dat files, you will end up getting inconsistent results.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/QMCPACK/qmcpack/issues/486#issuecomment-345372354, or mute the thread https://github.com/notifications/unsubscribe-auth/AJCzBjFIyS76SNYKMZTggDdTGhUJyUOAks5s3fyhgaJpZM4QZmw8 .