inconsistent energies or failures with charged cells
- Dominant language
- C++
- Stars
- 403
- Forks
- 154
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 82
Description
**Describe the bug**
there seems to be a bug when defining charged cells for solids using develop. For a fundamental gap calculation or grand canonical ensemble, we have to add or remove electrons. However, I can getting inconsistent energies or outright failures. I am attaching a file with inputs/outputs of the various test cases.
The example is 8 atom Si, using restricted PBE orbitals and no jastrow, and use a fixed random seed. Therefore one would expect that whether or not I remove an electron from the up or down channel, I would get the same energy. This is not what I see, and depending on the "size" in the sposet builder, it can result in outright failure. There are 4 tests, with outputs/errors/scalar.dats labeled 1-4. This tests the various cases where up channel is the majority/minority spin channel, and in each case whether or not the sposet "size" is set to the size of the majority/minority spin channel.
I would have expected the correct input to be choosing the sposet size = majority spin channel, but these cases fail. If sposet "size" is equal to the minority channel size, it runs but has different energies.
*test 1*:
spin_up is the minority spin channel with 15 electrons.
spin_dn is the majority spin channel with 16 electrons.
sposet size in builder is set to 15.
out_test1 shows there is a BLAS memory issue, however this successfully runs and gives me a scalar.dat and an energy of -31.91(11). err_test1 is the error messages which are empty.
*test 2*:
spin_up is the minority spin channel with 15 electrons.
spin_dn is the majority spin channel with 16 electrons.
sposet size in builder is 16, which is nominally what I want since the max number of orbtials needed is 16.
out_test2 has similar BLAS memory issue, however this one fails and hangs indefinitely. Note the seg fault listed in err_test2. The code also hangs and never even writes a scalar.dat for this test.
*test3*:
spin_up is the majority spin channel with 16 electrons.
spin_dn is the minority spin channel with 15 electrons.
sposet size in builder is 16, which is nominally what I want since the max number of orbitals needed is 16.
out_test3 also has BLAS memory issues, and a less verbose segfault printed to err_test3. This case actually proceeds to write an empty .scalar.dat.
*test4*:
spin_up is the majority spin channel with 16 electrons.
spin_dn is the minority spin channel with 15 electrons.
sposet size in builder is set to 15. This is similar to test1, where the size is set to the minority size.
out_test4 also shows a BLAS memory issue. err_test4 is clean however. This case runs to completion and gives me an energy of -30.515(89), which is quite different than case 1.
In every case I see BLAS memory errors. Choosing the majority spin channel size as the size for the sposet builder results in failures and segfaults. The energy differences are large, but used small number of walkers and small steps/blocks just to see if it could run. I'm testing larger runs to see if they actually do give different energies when doing a production level run.
**To Reproduce**
Steps to reproduce the behavior:
1. git commit 11fe1869b2787a3289bc453dae30f35bcd5b5907
2. spack install qmcpack@develop +complex
3. spack load qmcpack@develop +complex
4. run qmcpack
**Expected behavior**
I would have expected the sposet_size to be set to the majority spin channel, but those fail.
This also should not be giving blas errors on the cases where it does run.
**System:**
spack info:
-- linux-rhel7-broadwell / gcc@8.3.1 ----------------------------
qmcpack@develop\~afqmc+complex\~cuda\~da\~gui\~mixed+mpi+phdf5\~ppconvert+soa\~timers build_type=Release cuda_arch=none
boost@1.73.0+atomic+chrono\~clanglibcpp\~container\~context\~coroutine+date_time\~debug+exception\~fiber+filesystem+graph\~icu+iostreams+locale+log+math\~mpi+multithreaded
\~numpy\~pic+program_options\~python+random+regex+serialization+shared+signals\~singlethreaded+system\~taggedlayout+test+thread+timer\~versionedlayout+wave cxxstd=98 patches
=246508e052c44b6f4e8c2542a71c06cacaa72cd1447ab8d2a542b987bc35ace9,4dd507e1f5a29e3b87b15321a4d8c74afdc8331433edabf7aeab89b3c405d556 visibility=hidden
bzip2@1.0.8+shared
zlib@1.2.11+optimize+pic+shared
fftw@3.3.8+mpi\~openmp\~pfft_patches precision=double,float
openmpi@4.0\~atomics\~cuda\~cxx\~cxx_exceptions+gpfs\~java\~legacylaunchers\~memchecker\~pmi+runpath\~sqlite3+static\~thread_multiple+vt fabrics=none schedulers=none
hdf5@1.10.6\~cxx\~debug\~fortran\~hl+mpi+pic+shared\~\szip\~threadsafe api=none
libxml2@2.9.10\~python
libiconv@1.16
xz@5.2.5
openblas@0.3.9~consistent_fpcsr\~ilp64+pic+shared threads=none
python@3.7.7+bz2+ctypes+dbm\~debug+libxml2+lzma\~nis\~optimizations+pic+pyexpat+pythoncmd+readline+shared+sqlite3+ssl\~tix\~tkinter\~ucs4\~uuid+zlib
expat@2.2.9+libbsd
libbsd@0.10.0
gdbm@1.18.1
readline@8.0
ncurses@6.2\~symlinks+termlib
gettext@0.20.2+bzip2+curses+git\~libunistring+libxml2+tar+xz
tar@1.32
libffi@3.3
openssl@1.1.1g+systemcerts
sqlite@3.31.1+column_metadata+fts\~functions\~rtree
**Additional context**
[Si8_cation.zip](https://github.com/QMCPACK/qmcpack/files/4748868/Si8_cation.zip)
Contributor guide
Assessment
This issue has not been assessed yet.