{bio}[foss/2023b] GROMACS v2024.2 w/ CUDA 12.5.0 #20809
Conversation
|
Test report by @boegel edit: |
| sources = [SOURCELOWER_TAR_GZ] | ||
| patches = [ | ||
| 'GROMACS-2023.1_set_omp_num_threads_env_for_ntomp_tests.patch', | ||
| 'GROMACS-2023.1_fix_tests_for_gmx_thread_mpi.patch', |
There was a problem hiding this comment.
I was recently looking into GROMACS 2024.2 as well, and was wondering if this patch is still required. https://gitlab.com/gromacs/gromacs/-/merge_requests/4093 may solve the same or at least similar issue. Looks like @akesandgren added this patch, so maybe he knows?
There was a problem hiding this comment.
GROMACS-2023.1_fix_tests_for_gmx_thread_mpi.patch should still be relevant as long as it passes patching.
Especially the "Don't drop relevant PYTHONPATH and LD_LIBRARY_PATH settings." part is vital.
I haven't looked at 2024.2 but I assume they haven't fixed those parts yet.
And GROMACS-2023.1_set_omp_num_threads_env_for_ntomp_tests.patch is just an extra precaution to keep OMMP_NUM_THREADS and --ntomp in sync.
|
Test report by @boegel edit: Timeout for |
|
Not setting |
|
Maybe we should always use I think the issue in my case is that I'm running in a Slurm job that's asking for a partial node, and I'm not getting lucky w.r.t. which cores are assigned for the job, which makes this particular tests quite slow... |
|
Test report by @bedroge |
|
Test report by @branfosj |
I'm now running it in a Slurm job on an Icelake+A100 node (the successful test report was done on an interactive node without Slurm), and that one also seems to get stuck or something. The test step of the first iteration has been running for more than an hour, while it only took 18 minutes for the interactive V100 build. |
|
@boegelbot please test @ jsc-zen3-a100 |
|
@SebastianAchilles: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... - notification for comment with ID 2178169901 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
Test report by @akesandgren |
|
Test report by @akesandgren |
|
Test report by @akesandgren |
|
Test report by @akesandgren |
|
I had no problem building this for an A40 on a broadwell node in a non-interactive batch job. |
| @@ -74,7 +74,8 @@ exts_default_options = { | |||
|
|
|||
| exts_list = [ | |||
| ('gmxapi', '0.4.2', { | |||
| 'preinstallopts': 'export CMAKE_ARGS="-Dgmxapi_ROOT=%(installdir)s -C %(installdir)s/share/cmake/gromacs_mpi/gromacs-hints_mpi.cmake" && ', | |||
| 'preinstallopts': 'export CMAKE_ARGS="-Dgmxapi_ROOT=%(installdir)s ' + | |||
| '-C %(installdir)s/share/cmake/gromacs_mpi/gromacs-hints_mpi.cmake" && ', | |||
| 'source_tmpl': 'gromacs-2023.3.tar.gz', | |||
There was a problem hiding this comment.
This should correspond to the current version (and the version of gmxapi needs to be bumped as well).
There was a problem hiding this comment.
@boegel what about the gmxapi version? I'm not completely sure what the correct version number should be. https://gitlab.com/gromacs/gromacs/-/blob/v2024.2/python_packaging/gmxapi/pyproject.toml?ref_type=tags has 0.4.1 (?!), but https://gitlab.com/gromacs/gromacs/-/blob/v2024.2/python_packaging/gmxapi/src/gmxapi/version.py?ref_type=tags and https://manual.gromacs.org/2024.2/gmxapi/index.html say 0.5.0a1. So I guess the latter??
…g for GROMACS 2024.2
|
Test report by @boegel |
|
Test report by @boegel |
(created using
eb --new-pr)requires: