-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improving GROMACS performance #89
Comments
Just to clarify, you mention binding free energy calculations, but are seeing poor performance solely for an equilibration? Thoughts / questions below:
I'll update this comment if I come up with any more ideas. (I would try running on our cluster here, but it isn't optimised for GPU simulations since we can't enable certain kernel features that allow acceleration through overclocking. When I tried tweaking options and command-line parameters to improve the speed of the ethane-methanol simulations I saw no improvement regardless of what I tried.) |
The cluster is being used now, but I can see what I can post. Equilibration run (attached as equib.tar.gz)
lambda=0.00 run same system, but running a perturbed molecule:
Slurm submission file:
|
Finished there slightly too early. If I run the same script, but do not update the gromacs commandline arguments, i.e.
and not add:
I get the following performance:
|
Interesting, I tried explicitly adding Looking at the output above...
... it looks like it has only chosen to do short-ranged and bonded interactions on the GPU. I notice that you also explicitly set the I also notice that you set the number of threads with
I'm a little confused by the second output above (with the unmodified arguments) since it seems to be missing some info at the start of the log, e.g. the GROMACS version info and detected hardware. |
For reference, here are the relevant sections from a GROMACS log for one of the free legs of an ethane-methanol perturbation on BlueCrystal 4:
As you can see, GROMACS correctly detected the CPUs and GPU on the node without needing additional command-line arguments. The only concern that it raises is the lack of NVML support, but this can't be used on our cluster anyway. For this system, I see no improvement in performance if I set |
I also noticed that our GROMACS version isn't compiled to use |
So I see better performance if I only use one GPU rather than 4. I am not sure setting the gpu_id is necessary I was just playing around with that option when I hadn't figured out to restrict the visible GPUs with a slurm script. You get 68 ns/day on Blue crystal for non perturbed equilibrations? |
No, my results are for the actual lambda = 0 stage of the free leg, so it's not a direct comparison. I was just showing how GROMACS auto hardware detection seemed to work for me. I've not got data for the equilibration part, since it was run in a temporary working directory. I'd be happy to test performance here if you give me your input files, although BC4 seems to be totally unresponsive today. |
Changed to a more appropriate issue title. From poking around it seems like this isn't a specific BioSimSpace problem. We should use this thread to debug and document reliable ways of getting good Gromacs performance. |
for a bound FEP simulation with gromacs/20.4 (TYK2 in a 20nm waterbox) I was seeing similar behaviour on our cluster (presumably the same as @ppxasjsm is referring to). What helped in my case was using MPIRUN with a single copy, i.e.
|
Update Gromacs to the latest version might help, from its release note:
My output of a system with 54016 atoms on A100 GPU: Equilibration:
Production (free energy=yes):
|
Thanks for reporting, that's good to know. Since we don't bundle a version of GROMACS it's hard to provide settings that are optimised for any version (and hardware environment). I'm glad the free energy kernels are improving, though. |
Default settings for a 200 ps equilibration simulation with a system of 50k atoms takes more than 24 hours to complete on a typical GPU cluster with an optimised Gromacs installation for Binding free energy calculations.
The text was updated successfully, but these errors were encountered: