@leucinw found a "core-dump" in Tinker9 dynamic program. It turned out the problem was an invalid memory access in the udirect2b Fortran routine. It was trigger by keyword OPENMP-THREADS 12, so the temporary workaround is to remove this keyword from the key file, or setting the value to 1.
A fix (pull request #81) has been sent out for review.
Tinker9 depends on a libtinker.a binary file that was compiled without OpenMP, therefore the nthread variable should not have been modified by the keyword OPENMP-THREADS in Tinker9. I speculate that this keyword will cause crashes in serial Tinker8 as well.
With 1 thread, the shapes of ilocal and dlocal arrays in udirect2b would be long and thin. If nthread was set to a bigger number, these arrays would be shorter but thicker. Meanwhile, the serial program would still attempt to access the arrays as if they were longer, it eventually crashed.
@leucinw found a "core-dump" in Tinker9 dynamic program. It turned out the problem was an invalid memory access in the
udirect2bFortran routine. It was trigger by keywordOPENMP-THREADS 12, so the temporary workaround is to remove this keyword from the key file, or setting the value to 1.A fix (pull request #81) has been sent out for review.
Tinker9 depends on a libtinker.a binary file that was compiled without OpenMP, therefore the
nthreadvariable should not have been modified by the keywordOPENMP-THREADSin Tinker9. I speculate that this keyword will cause crashes in serial Tinker8 as well.With 1 thread, the shapes of
ilocalanddlocalarrays inudirect2bwould be long and thin. Ifnthreadwas set to a bigger number, these arrays would be shorter but thicker. Meanwhile, the serial program would still attempt to access the arrays as if they were longer, it eventually crashed.