Gromacs-2023.2 fails to build properly but 2023.1 and 2023 builds do

GROMACS version: 2023 & 2023.1 & 2023.2
GROMACS modification: No
System: Apple m2 mac

Hello, I was trying to install Gromacs using the most recent 2023.2 build with GPU (OpenCL) support, and after a lot of testing I was unable to succeed. I tried different compilers, different cmake options, and every option under the sun. Eventually, however, I found that I could compiler and run a simulation using the 2023 and 2023.1 builds. The issue was only with the 2023.2 build.

I tried to post the outputs here, but there was a character limit…

The cmake command (with gmake for building) was:

Summary

cmake …/ -DGMX_MPI=ON -DREGRESSIONTEST_DOWNLOAD=ON -DGMX_BUILD_OWN_FFTW=ON -DCMAKE_C_COMPILER=/opt/homebrew/bin/gcc-13 -DCMAKE_CXX_COMPILER=/opt/homebrew/bin/g+±13 -DGMX_GPU=opencl

Hi!

What exactly do you mean by “fails to build properly”? Does it fail to configure, compile, or do the test fail?

Have you seen another thread discussing issues with GROMACS 2023.2 and OpenCL on macOS, and have you tried the workaround mentioned there? Failing energy minimization with 2023.2+gcc on apple silicon

Hi, sorry for the confusion. I meant that when running “gmake check” it will fail the tests in various methods that seemed to be related with opencl (though sometimes the output would suggest that openmpi might be related, but I think this was in the error output just due to the hand-off to the GPU). This only occurred when trying to compile with opencl. One of the errors thrown was “invalid opencl permissions”. The regressions tests in particular would always fail multiple tests. I just looked through the logs and posted one of the tests that failed below (The entire output for all failed tests in beyond the word limit)

Summary

28/89 Test #28: EwaldUnitTests …Subprocess aborted***Exception: 0.09 sec
dyld[83094]: Symbol not found: __Z14pme_gpu_spreadPK6PmeGpuP20GpuEventSynchronizerPPfPP18gmx_parallel_3dfftbbfbPN3gmx24PmeCoordinateReceiverGpuEbP13gmx_wallcycle
Referenced from: <703D6E90-1126-3F0E-9372-67F61C6EE52F> /Users/owner/Desktop/test/gromacs-2023.2/build/bin/ewald-test
Expected in: <45C57FDB-56AC-38A1-999A-FB5093157A8F> /usr/local/gromacs/lib/libgromacs_mpi.8.0.0.dylib

Though, once again, everything works fine in 2023.1.

Also, I saw the other post you linked (and the other one they linked in theirs), I also was able to reproduce those results. But this was fixed (as far as I know) by updating everything thing I could and forcing to build with gcc/g++ 13 and MOST IMPORTANTLY not using fftw installed via homebrew. For some reason, homebrew only installs fftw on my system for doubles instead of floats (though this could be fixed by downloading the ruby script associated and adding appropriate flags). This, or perhaps something else, caused issues. I fixed this by just using the Gromacs provided/built fftw.

You can attach the logs as files, or upload them to an external server like Google Drive or Pastebin. Please include everything, starting from a cmake invocation in a clean directory. There are a lot of ways to set up the environment (as you yourself described with the fftw installation), so it is helpful to see it from the beginning till the end.

Also, one of the things listed in the thread requires modifying GROMACS source code with a work-in-progress patch (hopefully to be part of the next, 2023.3, release). Have you applied that patch?

Aw, the patch worked this time. I applied it previously but it might have been before I discovered the fftw3 double-precision issue. Thanks for the help. The patch allowed 2023.2 to pass all tests and run a simulation successfully. Thanks.

1 Like

Great that you got it working!

The OpenCL patch is added to 2023.3 (to be released this week), so it will work without any manual changes.