You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Verifying compilation of the latest 2020-R2 public release on various test suites from $GMS_PATH/tests, I found that some tests from "dft-libxc" test-suite failed verification. The total number of failed results was as below:
9 in case of linux64, GNU compilers +OpenBlas, openmpi, Ubuntu 18.04, Xeon SandyBridge CPU
16 in case of linux64, Intel compilers +MKL, openmpi, Ubuntu 18.04, Xeon SandyBridge CPU
Single computing CPU regime was used in all cases.
Looking for reasons I found that seven verification failures are actually caused by inconsistencies in number of parsing results and content of the verification '.json' files. Difference in that "E(1)" values are parsed from output, but it has no values to compare against in the corresponding '.json" file. This means that '*.json files must be updated to include "E(1)" for the following files:
Hopefully, the next GAMESS release will get the '*.json' verification files updated in this part.
The next faulty result, again consistent between both Intel and GNU versions is with test
.tests//dft-libxc/parallel/functionals/udft-CN-REVM06_L-gradient.log
In both cases it ends up with something like this
At line 2448 of file dftgrd.f (unit = 22, file = '/home/buka/tmp/udft-CN-REVM06_L-gradient.F22')
Fortran runtime error: End of file
It looks like an indication of a bug in the listed above file. I wonder if it was spotted jand has been fixed by anybody already.
Others failures are due to the numerical differences in results versus reference files
GNU compilers:
./dft-libxc/parallel/default/udft-HCTH76-gradient.log
Intel compilers:
./dft-libxc/parallel/functionals/rdft-CNm-TH1-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TH1-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS0_2-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS0_DH-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS_QIDH-gradient.log
./dft-libxc/parallel/functionals/udft-CN-HCTH_A-gradient.log
./dft-libxc/parallel/functionals/udft-CN-TH1-gradient.log
Any advise with regard of the overcoming the problem with the dft-libxc verification for tests from the list as shown in Section 2) and 3) above is much appreciated.
Ivan Rostov
NCI Australia, Canberra
The text was updated successfully, but these errors were encountered:
Verifying compilation of the latest 2020-R2 public release on various test suites from $GMS_PATH/tests, I found that some tests from "dft-libxc" test-suite failed verification. The total number of failed results was as below:
9 in case of linux64, GNU compilers +OpenBlas, openmpi, Ubuntu 18.04, Xeon SandyBridge CPU
16 in case of linux64, Intel compilers +MKL, openmpi, Ubuntu 18.04, Xeon SandyBridge CPU
Single computing CPU regime was used in all cases.
Hopefully, the next GAMESS release will get the '*.json' verification files updated in this part.
.tests//dft-libxc/parallel/functionals/udft-CN-REVM06_L-gradient.log
In both cases it ends up with something like this
At line 2448 of file dftgrd.f (unit = 22, file = '/home/buka/tmp/udft-CN-REVM06_L-gradient.F22')
Fortran runtime error: End of file
It looks like an indication of a bug in the listed above file. I wonder if it was spotted jand has been fixed by anybody already.
GNU compilers:
./dft-libxc/parallel/default/udft-HCTH76-gradient.log
Intel compilers:
./dft-libxc/parallel/functionals/rdft-CNm-TH1-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TH1-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS0_2-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS0_DH-gradient.log
./dft-libxc/parallel/functionals/rdft-He-TPSS_QIDH-gradient.log
./dft-libxc/parallel/functionals/udft-CN-HCTH_A-gradient.log
./dft-libxc/parallel/functionals/udft-CN-TH1-gradient.log
Any advise with regard of the overcoming the problem with the dft-libxc verification for tests from the list as shown in Section 2) and 3) above is much appreciated.
Ivan Rostov
NCI Australia, Canberra
The text was updated successfully, but these errors were encountered: