errors with Intel 2018 compilers

[loriab]

At least through 2018.0.3, simint 0.7 built with Intel compilers generates incorrect integrals when you run the tests. 2017.0.4 is fine.

Psi4 is working around this problem. Just an FYI.

[huanghua1994]

@loriab I did some tests and narrowed down the source of the problem. When using ICC18 and cc-pvdz, I can get the correct results. When using ICC18 + cc-pvtz, F shell integral results are wrong. Besides, if I use ICC18 with -O1 optimization flag, cc-pvtz also works well. -O2 and -O3 will give wrong results. So I think ICC18 and ICC17 have different optimization behaviors. I will try if I can make ICC18 work correctly.

[bennybp]

I did look at this a while ago. I didn't see a clear answer, as I think it really is a compiler bug.

I was looking at dsps. Does that also fail for you, @huanghua1994 ? If so, I can try getting creduce to give me something to give to Intel.

[loriab]

I think you do have to use a larger basis set to get a high enough AM to see the problem. IIRC, the sto-3g example worked fine for under 2018, but the triple-zeta test showed problems only for integrals with higher AM shells.

[colleeneb]

For what it's worth, I wanted to add that I saw slightly different behavior with multiple threads vs. only one thread.

After compiling with Intel 18.0.1.20171018, and AVX2 on a Haswell node, I got:

$ OMP_NUM_THREADS=44 ./test_eri ../../test/dat/benzene.sto-3g.mol 

          Quartet      MaxErr     MaxRelErr
(  0  0 |  0  0 )     2.220e-15   6.322e-15
(  0  0 |  0  1 )     2.429e-16   2.416e-12
(  0  0 |  1  0 )     2.776e-16   2.550e-12
(  0  0 |  1  1 )     3.886e-16   1.138e-11
(  0  1 |  0  0 )     2.429e-16   2.432e-12
(  0  1 |  0  1 )     1.388e-16   1.276e-12
(  0  1 |  1  0 )     1.665e-16   1.268e-12
(  0  1 |  1  1 )     1.735e-16   3.482e-12
(  1  0 |  0  0 )     2.502e-16   2.511e-12
(  1  0 |  0  1 )     1.110e-16   1.275e-12
(  1  0 |  1  0 )     1.388e-16   1.199e-12
(  1  0 |  1  1 )     1.943e-16   3.994e-12
(  1  1 |  0  0 )     4.441e-16   3.755e-12
(  1  1 |  0  1 )     2.498e-16   3.177e-12
(  1  1 |  1  0 )     1.943e-16   4.692e-12
(  1  1 |  1  1 )     2.880e+03   8.814e+08  ***

Calculated 1679616 contracted integrals

But when I used only one thread, it worked, although it resulted in a segfault:

$ OMP_NUM_THREADS=1 ./test_eri ../../test/dat/benzene.sto-3g.mol 

          Quartet      MaxErr     MaxRelErr
(  0  0 |  0  0 )     2.220e-15   6.322e-15
(  0  0 |  0  1 )     2.429e-16   2.416e-12
(  0  0 |  1  0 )     2.776e-16   2.550e-12
(  0  0 |  1  1 )     3.886e-16   1.138e-11
(  0  1 |  0  0 )     2.429e-16   2.432e-12
(  0  1 |  0  1 )     1.388e-16   1.276e-12
(  0  1 |  1  0 )     1.665e-16   1.268e-12
(  0  1 |  1  1 )     1.735e-16   3.482e-12
(  1  0 |  0  0 )     2.502e-16   2.511e-12
(  1  0 |  0  1 )     1.110e-16   1.275e-12
(  1  0 |  1  0 )     1.388e-16   1.199e-12
(  1  0 |  1  1 )     1.943e-16   3.994e-12
(  1  1 |  0  0 )     4.441e-16   3.755e-12
(  1  1 |  0  1 )     2.498e-16   3.177e-12
(  1  1 |  1  0 )     1.943e-16   4.692e-12
(  1  1 |  1  1 )     3.691e-15   1.776e-11

Calculated 1679616 contracted integrals

Segmentation fault

The segfault from OMP_NUM_THREADS=1 was repeatable (5/5 runs), but the incorrect answers with OMP_NUM_THREADS=44 happened only 3/5 runs (and the integral that was incorrect varied), so it was not completely repeatable.

(Edited to add: with GDB, the backtrace of the segfault is here:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6662418 in _int_free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7_4.2.x86_64
(gdb) bt
#0  0x00007ffff6662418 in _int_free () from /lib64/libc.so.6
#1  0x0000000000419426 in deallocate (this=<optimized out>,
    __p=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/ext/new_allocator.h:110
#2  deallocate (__a=..., __p=<optimized out>, __n=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/alloc_traits.h:442
#3  _M_deallocate (this=<optimized out>, __p=0x7ffff69a2760 <main_arena>,
    __n=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_vector.h:178
#4  ~_Vector_base (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_vector.h:160
#5  ~_Vector_base (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_vector.h:159
#6  ~vector (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_vector.h:427
#7  ~pair (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_pair.h:190
#8  destroy (this=<optimized out>, __p=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/ext/new_allocator.h:124
#9  destroy (__a=..., __p=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/alloc_traits.h:467
#10 _M_destroy_node (this=<optimized out>, __p=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_tree.h:567
#11 _M_drop_node (this=<optimized out>, __p=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_tree.h:575
#12 _M_erase (this=<optimized out>, __x=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_tree.h:1640
#13 clear (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_tree.h:1087
#14 clear (this=<optimized out>)
    at /home/bertoni/CB/gcc-6.3.0/bin/bin/../include/c++/6.3.0/bits/stl_map.h:1044
#15 FreeShellMap (m=...)
    at /home/bertoni/simint-generator/outdir/test/Common.cpp:76
#16 0x000000000041755a in main (argc=-157669536, argv=0x0)
    at /home/bertoni/simint-generator/outdir/test/test_eri.cpp:235

I don't know the code well enough, but maybe some kind of double free? You guys know the code a lot better, so I am just speculating :) )

[bennybp]

@colleeneb It looks like this is being caused by some additions from @huanghua1994 to compute screening statistics. Let me see if I can clear that up

[huanghua1994]

@bennybp please try to allocate 32 more bytes output buffer for each thread in test_eri.cpp. I used these space at the end of the output buffer to carry out screening statistics. This problem was handled separated in another small library when I use Simint from GTFock. I have not used test_eri.cpp for a long time so I did not notice this.

The SIMINT_PRIM_SCREEN_STAT macro is defined at vectorization/intrinsics_avx.h:219 and vectorization/intrinsics_avx512.h:210. I'm not familiar with CMake so I have not make this a compiler flag option in cmake files.

[bennybp]

@huanghua1994 I will see if I can fix that in the next few days. I will make it an option, and disable by default. I will also make it allocate the extra memory when enabled.