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
306 stars 139 forks source link

Small finite-size corrections from qmcfinitesize #3343

Open krongch2 opened 3 years ago

krongch2 commented 3 years ago

Describe the bug The finite-size corrections from qmcfinitesize are so small that the corrected energies and uncorrected energies are almost the same as shown in the figure below. (The blue and orange points are on top of each other). image N in the x-axis is the number of primitive cells in a simulation cell. Blue points are uncorrected energies. Orange points are corrected energies. T_LO, V_LO, and V_INT are defined here https://github.com/QMCPACK/qmcpack/tree/develop/src/QMCTools/QMCFiniteSize

To Reproduce The link to the files which reproduced this error is here. https://drive.google.com/file/d/1QisR5R6vhd_HKOaj60re6_9nYy1t6JdZ/view?usp=sharing The outputs of qmcfinitesize have the name dmc0.02/dmc.g00*.s001.finitesize.out. QMCPACK and qmcfinitesize were compiled by executing config/build_olcf_summit.sh from v3.11.0.

Expected behavior I expected the energies to flat out more, meaning that the slope magnitude of the line extrapolated from the corrected energies get closer to zero, similar to the red points in this figure (Holzmann et al. (2016)). image

System Summit.

Additional context @Paul-St-Young suggested that this could be due to the implementation being broken in a 2D system. My system is bilayer graphene simulated using the boundary condition ppn.

Paul-St-Young commented 3 years ago

@krongch2 "broken" is a loaded word. I just meant that the finite-size correction tool was never designed/tested on a ppn simulation.

I think the biggest problem is the vacuum along the z direction. The choice of z can make cell volume arbitrarily large and finite-size correction arbitrarily small. Perhaps the best way to go is to just take the kz=0 slice of S(k) and run a 2D interpolation.

The second big problem is the assumed behavior of S(k) ~ k^2 and Jastrow pair function u(k) ~ 1/k^2 as k->0. The leading corrections (*_LO) are certainly wrong, because they use the above assumptions. However, in 2D S(k) ~ k^{3/2} and u(k) ~ 1/k^{3/2}. The B-splined S(k) correction (V_INT) should be OK (after taking care of the z vacuum problem).

prckent commented 3 years ago

Is there an example in the literature of this formalism being used for a 2D system? As PaulY pointed out, the finitesizetool implements a formalism that is for 3D bulks, and is very likely to be inappropriate for 2D. How to update it is the key question. Provided largely similar terms in the correction are needed it should be a straightforward update.