To be clear: Linux-generated Libint2 library source compiled and run on Windows (or Linux or Mac) works fine. This issue is about Windows-generated Libint2 library source compiled and run on Windows (or Linux).
The libint2 compiler generates faulty library code when compiler is built and run on windows. A few characteristics:
correct number of sources files and identical header contents (copied and generated)
some library tests pass, some tests fail
The following tests passed:
libint2/eritest/build
libint2/eritest/run2
libint2/unit/build
libint2/hf/build
libint2/hf++/build
libint2/fortran_example/build
libint2/fortran_example/run
libint2/fortran_test/build
libint2/fortran_test/run
* one can see the same errors whether Windows-generated library source is built on Windows or Linux
* kinetic ints source files have different numbers of flops and missing lines
Granted, fixing this isn't high priority, since, afaik, (number of ppl wanting ERI) (fraction of those building the library) (fraction of those needing to generate the library from compiler src) * (fraction of those needing to do it on Windows) = 0. So this issue is for the record, and in case a solution is apparent to EFV. If anyone wants to play with Windows generated library source tarballs, they are downloadable from the GH Actions tab run for #233 (diff -Z for comparison against linux, or run the src through dos2unix).
To be clear: Linux-generated Libint2 library source compiled and run on Windows (or Linux or Mac) works fine. This issue is about Windows-generated Libint2 library source compiled and run on Windows (or Linux).
The libint2 compiler generates faulty library code when compiler is built and run on windows. A few characteristics:
64% tests passed, 5 tests failed out of 14
Total Test time (real) = 281.11 sec
The following tests FAILED: 2 - libint2/eritest/run0 (Failed) 3 - libint2/eritest/run1 (Failed) 6 - libint2/unit/run (Failed) 8 - libint2/hf/run (Failed) 10 - libint2/hf++/run (Failed)
2: Test command: /psi/gits/libint2-efv/tarballs/genWbldL/build-103/tests/eritest-libint2 "0" "2" 2: Test timeout computed to be: 10000000 2: Testing (ss|ss) : ok 2: Testing (ss|ps) : ok 2: Testing (ss|pp) : ok 2: Testing (ss|ds) : ok 2: Testing (ss|dp) : Elem 0 di= 0 v=0 : ref = 17.0323 libint = 4.11286 relabs_error = 0.758525 abs_error = 12.9194 2: Elem 10 di= 0 v=0 : ref = -5.11289 libint = 3.81277 relabs_error = 1.74572 abs_error = 8.92566 2: Elem 17 di= 0 v=0 : ref = -4.99392 libint = 14.3628 relabs_error = 3.87606 abs_error = 19.3567 2: failed 2: Testing (ss|dd) : Elem 0 di= 0 v=0 : ref = 11.2114 libint = 9.69592 relabs_error = 0.13517 abs_error = 1.51543
8: Overlap Integrals: OK 8: Kinetic-Energy Integrals: 2x too big 8: 58.0064 -0.336022 0 3.20409e-17 0 -0.0168328 -0.0168328 8: -0.336022 1.61626 0 -1.55656e-17 0 0.141035 0.141035 8: 0 0 2.02298 0 0 0.155231 -0.155231 8: 3.20409e-17 -1.55656e-17 0 2.02298 0 0.12128 0.12128 8: 0 0 0 0 2.02298 0 0 8: -0.0168328 0.141035 0.155231 0.12128 0 1.52006 -0.00795947 8: -0.0168328 0.141035 -0.155231 0.12128 0 -0.00795947 1.52006 8: 8: Nuclear Attraction Integrals: OK
Granted, fixing this isn't high priority, since, afaik, (number of ppl wanting ERI) (fraction of those building the library) (fraction of those needing to generate the library from compiler src) * (fraction of those needing to do it on Windows) = 0. So this issue is for the record, and in case a solution is apparent to EFV. If anyone wants to play with Windows generated library source tarballs, they are downloadable from the GH Actions tab run for #233 (
diff -Z
for comparison against linux, or run the src throughdos2unix
).