[gmx-users] steered md - pushing
Hi, I have a protein with four domains. I know the conformation of the full protein in one state. In the other state I know only the conformation of two of the domains. I would like to move the two domains, whose positions are known in both conformations, and observe movements in the other two domains. That would be nice to do steered MD. However, the I need not to pull but push the two domains. What do you suggest, what should I try? I have no experiences in enhanced sampling MD. I see two potential possibilities: 1. Try pulling with pull-coord1-type: constant-force This case I might be able to set "negative" force for pulling with option pull-coord1-k. 2. Try targeted MD, if gromacs has the possibility to perform it not only for the full protein, but for two selections (domains). In addition I have seen some posts on targeted MD with gromacs stating that it is not a real/best targeted MD implementation. ??? Thanks for your help and suggestions in advance, Tamas -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] gmx 5.1.4, cuda9, Unsupported gpu architecture 'compute_20'
Hi, I have to rerun a simulation done in gmx 5.1.4 to save also the water and ions. First, I took the equilibrated gro and the modified mdp to generate the input tpr for the production run using gmx 2018.1. The results are significantly different (I think that this is ok). But I would like to rerun also with gmx 5.1.4. However, I have to compile the old version and there is cuda9 on the system I use. I get the nvcc fatal : Unsupported gpu architecture 'compute_20' error. After running cmake I tried to delete all -gencode;arch=compute_20,code=sm_20; from the files listed below. However, they are regenerated after issuing make and make stops with the same error. How can I resolve this issue? Thanks for your help and suggestion, Tamas gromacs-5.1.4/build: CMakeCache.txt src/buildinfo.h src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda_data_mgmt.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda_data_mgmt.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/gpu_utils/libgromacs_generated_gpu_utils.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/gpu_utils/libgromacs_generated_gpu_utils.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_pmalloc_cuda.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_cudautils.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_pmalloc_cuda.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_copyrite_gpu.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_cudautils.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_copyrite_gpu.cu.o.cmake.pre-gen -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] gmx 5.1.4, cuda9, Unsupported gpu architecture 'compute_20'
Hi, I do not do an mdrun -rerun. I think that I can not do it, since I have a trajectory with protein only. And I aimed to have a trajectory with the protein, water, and ions. Do I misunderstand something? On 06/04/2018 10:45 PM, Mark Abraham wrote: Hi, On Mon, Jun 4, 2018 at 10:40 PM Tamas Hegedus wrote: Hi, I have to rerun a simulation done in gmx 5.1.4 to save also the water and ions. First, I took the equilibrated gro and the modified mdp to generate the input tpr for the production run using gmx 2018.1. The results are significantly different (I think that this is ok). But I would like to rerun also with gmx 5.1.4. I am not aware of a good reason to want to do this, but if you did, you can use a CPU-only build. gmx mdrun -rerun does not get the full benefit of GPU offload, anyway. However, I have to compile the old version and there is cuda9 on the system I use. I get the nvcc fatal : Unsupported gpu architecture 'compute_20' error. After running cmake I tried to delete all -gencode;arch=compute_20,code=sm_20; from the files listed below. However, they are regenerated after issuing make and make stops with the same error. How can I resolve this issue? GROMACS 5.1.4 supported hardware that CUDA used to support, however the much more recently released CUDA 9 does not. Either use a newer GROMACS version, build without CUDA support, or build with an older CUDA version. Mark Thanks for your help and suggestion, Tamas gromacs-5.1.4/build: CMakeCache.txt src/buildinfo.h src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda_data_mgmt.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda_data_mgmt.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/mdlib/nbnxn_cuda/libgromacs_generated_nbnxn_cuda.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/gpu_utils/libgromacs_generated_gpu_utils.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/gpu_utils/libgromacs_generated_gpu_utils.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_pmalloc_cuda.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_cudautils.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_pmalloc_cuda.cu.o.cmake.pre-gen src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_copyrite_gpu.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_cudautils.cu.o.Release.cmake src/gromacs/CMakeFiles/libgromacs.dir/gmxlib/cuda_tools/libgromacs_generated_copyrite_gpu.cu.o.cmake.pre-gen -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org. -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] AMD vs Intel, nvidia 20xx
Hi, I am planning to buy 1 or 2 GPU workstations/servers for stand alone gromacs and gromacs+plumed (w plumed I can efficiently use only 1 GPU). I would like to get some suggestions for the best performance/price ratio. More specifically, some info on the correlation between PCI lines and performance. Based on google, gmx mail list, and my experience I think that * i9 with 44PCI lines * 4 gtx 1080Ti are OK and fits the budget. However, there are several upcoming issues: 1. I expect the 4 GPUs running at 70% (1PME and 3PP) with 16 cores. I do not know if the 44PCI lines are limiting or not? 2. 4x8 channel are OK? Should I look for a mother board with a PLX chip that makes 64 virtual pci lines? Do you have experience with this type of mobo? I have red that the average will be better than 4x8, but others say that its makes the system slower. 3. An option might be go with AMD CPUs with higher PCI line, but I do not trust AMD when high CPU performance is needed. But this might come from the past and I should forget this. Have you used recent AMD processors with gromacs with GPU acceleration? 4. I have the feeling using gmx 2018 that I would not gain performance with (physical) 32 cores and 4 GPUs, since 16 already is sufficient and the 70% GPU usage is not because waiting for the CPU. I do not know about this (how to check this). What is your experience? 5. I am afraid to buy more GPU power than necessary. It might be better to buy 2 faster and 2 slower GPU or only 3 newer GPUs to optimize the system. However, I most likely can not get 1070Ti. In addition, is better for the system not to run at 100%. BUT: there will be new RTX 20xx out and likely I can get lower version number for less power consumption and the same computing capacity (e.g. 2070 instead of 1080). BUT: it seems for me that RTX2070 has much less cores (2304) than 1080Ti and 2080Ti has more cores than 1080Ti. 1080, 4*3584 cores, 64 PCI lines 2080, 3*4352 cores, 48 PCI lines However, in the letter case more PP may run on the GPU and again the CPU/GPU communication may become the limiting factor. Thanks for all the opinion and suggestion, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] AMD vs Intel, nvidia 20xx
Dear Milan, Thanks for your valuable notes. Tamas On 09/19/2018 12:43 PM, melicher...@leaf.nh.cas.cz wrote: Hi Tamas, I've put several notices in text... I can't help ypu with exact hardware optimisations cause I don't have experiences with more than 1 GPU per CPU. On Wed, Sep 19, 2018 at 10:50:42AM +0200, Tamas Hegedus wrote: Hi, I am planning to buy 1 or 2 GPU workstations/servers for stand alone gromacs and gromacs+plumed (w plumed I can efficiently use only 1 GPU). I would like to get some suggestions for the best performance/price ratio. More specifically, some info on the correlation between PCI lines and performance. Based on google, gmx mail list, and my experience I think that * i9 with 44PCI lines * 4 gtx 1080Ti are OK and fits the budget. I'm not sure you are able to put 4 (at least dual-slot) GPUs to single ATX board - you don't have enough space between PCIe slots. May be in some server board, but I'm not sure you can get 4 Geforce instead of some Tesla/Quadro. However, there are several upcoming issues: 1. I expect the 4 GPUs running at 70% (1PME and 3PP) with 16 cores. I do not know if the 44PCI lines are limiting or not? 2. 4x8 channel are OK? Should I look for a mother board with a PLX chip that makes 64 virtual pci lines? Do you have experience with this type of mobo? I have red that the average will be better than 4x8, but others say that its makes the system slower. 3. An option might be go with AMD CPUs with higher PCI line, but I do not trust AMD when high CPU performance is needed. But this might come from the past and I should forget this. Have you used recent AMD processors with gromacs with GPU acceleration? AMD CPUs are OK. I have several Ryzen with Radeon Nano (Fiji GPU) and they are working nicely. Coleagues from another Lab has 16-core Threadripper and they are happy with it (using VASP and CPU-pnly calculations). The question is how NUMA access to memory will influence the performance with new Threadrippers with 24 and 32 cores. I didn't seen any results about this. BTW Xeon Gold 6xxx would be nice, cause it has two AVX pipelines (see some tests at www.servethehome.com page), but it's price... 4. I have the feeling using gmx 2018 that I would not gain performance with (physical) 32 cores and 4 GPUs, since 16 already is sufficient and the 70% GPU usage is not because waiting for the CPU. I do not know about this (how to check this). What is your experience? 5. I am afraid to buy more GPU power than necessary. It might be better to buy 2 faster and 2 slower GPU or only 3 newer GPUs to optimize the system. I have the feeling the best is to have same GPUs (calculating the same job). If you would use it for several jobs parallel, may be. But there is question, if not to split the whole computer to several a little smaller (e. g. 8 core + 1-2 GPUs) and get more of them. However, I most likely can not get 1070Ti. In addition, is better for the system not to run at 100%. BUT: there will be new RTX 20xx out and likely I can get lower version number for less power consumption and the same computing capacity (e.g. 2070 instead of 1080). BUT: it seems for me that RTX2070 has much less cores (2304) than 1080Ti and 2080Ti has more cores than 1080Ti. 1080, 4*3584 cores, 64 PCI lines 2080, 3*4352 cores, 48 PCI lines However, in the letter case more PP may run on the GPU and again the CPU/GPU communication may become the limiting factor. I thing you cannot calculate only CUDa cores, but their frequency is also important. However I don't know what is better - more cores with lower frequency or otherwise. And probably it depends on system size anyway. But comparing the values from wikipedia, I don't think there will be huge jump in calculating power (CUDA cores and frequency). And the power consumption is more or less the same (cca. 5-20 W) And this anyway is changing with cooling performance etc. It would be different if Gromacs could use Tensor cores or even Raytracing cores. I don't know anything about this, so could someone bring some light into this? Thanks. Best, Milan Thanks for all the opinion and suggestion, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org. -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto
[gmx-users] lipid / -OH oscillation period
Hi, I have a protein/lipid system. Using charmm36 ff and gromacs5.1.4. I set constraints = h-bonds because of charmm. 1. After that grompp complains about the oscillation between an O and H in the lipid. Why? It should not. Possible explanations I can imagine: - does gromacs constrain only protein h-bonds? - atom names are not recognized as an O-H? 2. Moreover, it complains only 1O2 1HO2 and not 1O3 1HO3. Why? It usually collect NOTEs upto a pretty large number of notes and I do not expect to stop after this one. 3. What can I do? What should I do? My system is large (~700,000 atoms), so I do not want to decrease the time step. I would like to increase it (use the standard 0.002 ps). NOTE 2 [file topol.top, line 38]: The bond in molecule-type BDM between atoms 8 1O2 and 9 1HO2 has an estimated oscillational period of 9.1e-03 ps, which is less than 10 times the time step of 1.0e-03 ps. Maybe you forgot to change the constraints mdp option. Thanks for your help and suggestion, Tamas -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] AMD 32 core TR
Please provide more information. If you use gmx 2018 then I think that gmx limits the gcc version to 6 and not cuda 10. You did not specify what type of and how many GPUs you use. In addition, the choice of gmx for distributing computation could be also informative - you find this info in the log file. It is also not clear what do you mean of 10% improvement: 8ns/day to 26ns/day are the only numbers but it corresponds to 3x faster simulations and not 1.1x In addition, I think if you have 49.5 ns/day for 137K atoms than 26ns/day seems to be ok for 300K. Bests, Tamas On 1/3/19 6:11 PM, pbusc...@q.com wrote: Dear users, I had trouble getting suitable performance from an AMD 32 core TR. By updating all the cuda drivers and runtime to v10 and using gcc,g++ -6 from v5 -- I did try gcc-7 but Cuda 10 did not appreciate the attempt -- and in particular removing CUDA v7 runtime.), I was able to improve a 300k atom nvt run from 8 ns/day to 26 ns/day . I replicated as far as possible the Gromacs ADH benchmark with 137000 atoms-spc/e. I could achieve an md of 49.5 ns/day. I do not have a firm grasp if this is respectable or not ( comments ? ) but appears at least ok. The input command was simply mdrun ADH.md -nb gpu -pme gp ( and not using -ntomp or ntmpi which in my hands degraded performance ) . To run the ADH I replaced the two ZN ions in ADH file from PDB ( 2ieh.pdb ) with CA ions since ZN was not found in the OPLS data base in using pdb2gmx. The points being ( 1) Gromacs appears reasonably happy with the 8 core and 32 core Ryzen although ( again in my hands ) for these smallish systems there is only about a 10% improvement between the two, and (2) , as often suggested in the Gromacs literature, use the latest drivers possible -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] AMD 32 core TR
Paul, I agree with Mark, since most likely the cause of the small increase in performance is because the workload of the CPU and GPU. In your case the performance is limited by the GPU. It likely runs at 100% with 8CPU. Then adding extra CPUs does not help. I am experiencing with 16 CPUs (2950X) and 2-4 1080Ti. I have the feeling that approx 16CPU and 2 of 1080Ti produce a max (best, optimal) performance for a system of 150-200K atoms. And it is around 50-60 ns/day. The same is 60-70ns for 16CPU/1080Ti, but the GPUs run only around 50-60% (the gain most likely comes from not overloading the PCI lanes). So I think that the performance of your simulations are OK, this is the max for your hardware setup. I am not sure but I expect about 50ns/day for 1CPU/1GPU using Desmond. But I have not experiences with Desmond and I tried it only for a smaller system. Tamas On 2019. 01. 04. 4:18, paul buscemi wrote: Tamas, thanks for the response. In previous posts I mention using a single gtx 1080ti, sorry for not making it clear in the last post. On the 8 core AMD and an Intel 6 core I am running Cuda 10 with Gromacs 18.3 with no issues. I believe the larger factor in the slowness of the 32 core was in having the runtime Cuda 7 with the cuda 10 drivers. On the 8 core, runtime cuda 9.1 and cuda 10 drivers work well together - all with Gromacs 18.3. Now with Gromacs v19 , Cuda 10 and the 410 nvidia drivers, the 8 core and 32 core systems seem quite content. I have been tracing results from the log, and you are correct in what it can tell you. It was the log file that actually brought my attention to the Cuda 7 runtime issue. Also the PP PME distributions were noted with the ntomp/ntmpi arrangements. I have been experimenting with those as suggested in the Gromas acceleration hints. By 10% I meant that the 32 core unit ( in my hands ) ran 10% faster in ns/day than the 8 core AMD using the same model system and the the same 1080ti GPU. Gromacs points out that 150k to 300k atom systems are on the rather small side and so not to expect tremendous differences from the CPU. The reason for using the 32 core is the eventual addition of a second GPU and the subsequent distribution of threads. With a little OC and tweeking of the fourier spacing and vdw cutoffs in the npt I edged the 137k atom AHD model to 57 ns/day, but this falls short of the Exxact corp benchmarks of 80-90 ns/d — assuming they are using a 1080ti. Schrodinger’s Maestro- with the 8 core AMD and 1080ti - runs a 300k membrane model at about 15 ns/d but a 60k atom model at 150 ns/day implying 30 ns/day for 300k atoms. . In general, if I can indeed maintain 20-25 ns/day for 300k atoms I’d be satisfied. The original posts were made because I was frustrated seeing 6 to 8 ns/d with the 32core machine and the 8 core was producing 20 ns/day. As I mentioned the wounds were self inflicted with the installation of Cuda runtime 7 and at one point compilation with g++-5. As far as I am concerned it’s imperative that the latest drivers and Gromacs versions be used or at least the same genre of drivers and versions be assembled. Again, I’d like to point out that in using four different machines, 4 different Intel and AMD CPU’s, 5 different MBs, 5 different GPU’s, now 4 progressive versions of Gromacs, and model systems of 200-300 k particles, I’ve not run across a single problem associated with the software or hardware per se but rather was caused by the my models or my compilation methods. Hope this addresses your questions and helps any other users contemplating using a Ryzen TR. Paul On Jan 3, 2019, at 2:09 PM, Tamas Hegedus wrote: Please provide more information. If you use gmx 2018 then I think that gmx limits the gcc version to 6 and not cuda 10. You did not specify what type of and how many GPUs you use. In addition, the choice of gmx for distributing computation could be also informative - you find this info in the log file. It is also not clear what do you mean of 10% improvement: 8ns/day to 26ns/day are the only numbers but it corresponds to 3x faster simulations and not 1.1x In addition, I think if you have 49.5 ns/day for 137K atoms than 26ns/day seems to be ok for 300K. Bests, Tamas On 1/3/19 6:11 PM, pbusc...@q.com wrote: Dear users, I had trouble getting suitable performance from an AMD 32 core TR. By updating all the cuda drivers and runtime to v10 and using gcc,g++ -6 from v5 -- I did try gcc-7 but Cuda 10 did not appreciate the attempt -- and in particular removing CUDA v7 runtime.), I was able to improve a 300k atom nvt run from 8 ns/day to 26 ns/day . I replicated as far as possible the Gromacs ADH benchmark with 137000 atoms-spc/e. I could achieve an md of 49.5 ns/day. I do not have a firm grasp if this is respectable or not ( comments ? ) but appears at least ok. The input command was simply mdrun ADH.md -nb gpu -pme gp
Re: [gmx-users] AMD 32 core TR
It also comes into my mind that the AMD 32 core has not a double performance of AMD 16 core. Because of manufacturing the 4 dies (4x8 cpu units), it does not have the same bandwidth to the RAM. But this is told to affect only memory hungry applications. Thus at this moment I think that this does not effect much gmx runs. I hope to try an RT 2990WX (amd 32core) in 1-2 months. On 2019. 01. 04. 4:18, paul buscemi wrote: Tamas, thanks for the response. In previous posts I mention using a single gtx 1080ti, sorry for not making it clear in the last post. On the 8 core AMD and an Intel 6 core I am running Cuda 10 with Gromacs 18.3 with no issues. I believe the larger factor in the slowness of the 32 core was in having the runtime Cuda 7 with the cuda 10 drivers. On the 8 core, runtime cuda 9.1 and cuda 10 drivers work well together - all with Gromacs 18.3. Now with Gromacs v19 , Cuda 10 and the 410 nvidia drivers, the 8 core and 32 core systems seem quite content. I have been tracing results from the log, and you are correct in what it can tell you. It was the log file that actually brought my attention to the Cuda 7 runtime issue. Also the PP PME distributions were noted with the ntomp/ntmpi arrangements. I have been experimenting with those as suggested in the Gromas acceleration hints. By 10% I meant that the 32 core unit ( in my hands ) ran 10% faster in ns/day than the 8 core AMD using the same model system and the the same 1080ti GPU. Gromacs points out that 150k to 300k atom systems are on the rather small side and so not to expect tremendous differences from the CPU. The reason for using the 32 core is the eventual addition of a second GPU and the subsequent distribution of threads. With a little OC and tweeking of the fourier spacing and vdw cutoffs in the npt I edged the 137k atom AHD model to 57 ns/day, but this falls short of the Exxact corp benchmarks of 80-90 ns/d — assuming they are using a 1080ti. Schrodinger’s Maestro- with the 8 core AMD and 1080ti - runs a 300k membrane model at about 15 ns/d but a 60k atom model at 150 ns/day implying 30 ns/day for 300k atoms. . In general, if I can indeed maintain 20-25 ns/day for 300k atoms I’d be satisfied. The original posts were made because I was frustrated seeing 6 to 8 ns/d with the 32core machine and the 8 core was producing 20 ns/day. As I mentioned the wounds were self inflicted with the installation of Cuda runtime 7 and at one point compilation with g++-5. As far as I am concerned it’s imperative that the latest drivers and Gromacs versions be used or at least the same genre of drivers and versions be assembled. Again, I’d like to point out that in using four different machines, 4 different Intel and AMD CPU’s, 5 different MBs, 5 different GPU’s, now 4 progressive versions of Gromacs, and model systems of 200-300 k particles, I’ve not run across a single problem associated with the software or hardware per se but rather was caused by the my models or my compilation methods. Hope this addresses your questions and helps any other users contemplating using a Ryzen TR. Paul On Jan 3, 2019, at 2:09 PM, Tamas Hegedus wrote: Please provide more information. If you use gmx 2018 then I think that gmx limits the gcc version to 6 and not cuda 10. You did not specify what type of and how many GPUs you use. In addition, the choice of gmx for distributing computation could be also informative - you find this info in the log file. It is also not clear what do you mean of 10% improvement: 8ns/day to 26ns/day are the only numbers but it corresponds to 3x faster simulations and not 1.1x In addition, I think if you have 49.5 ns/day for 137K atoms than 26ns/day seems to be ok for 300K. Bests, Tamas On 1/3/19 6:11 PM, pbusc...@q.com wrote: Dear users, I had trouble getting suitable performance from an AMD 32 core TR. By updating all the cuda drivers and runtime to v10 and using gcc,g++ -6 from v5 -- I did try gcc-7 but Cuda 10 did not appreciate the attempt -- and in particular removing CUDA v7 runtime.), I was able to improve a 300k atom nvt run from 8 ns/day to 26 ns/day . I replicated as far as possible the Gromacs ADH benchmark with 137000 atoms-spc/e. I could achieve an md of 49.5 ns/day. I do not have a firm grasp if this is respectable or not ( comments ? ) but appears at least ok. The input command was simply mdrun ADH.md -nb gpu -pme gp ( and not using -ntomp or ntmpi which in my hands degraded performance ) . To run the ADH I replaced the two ZN ions in ADH file from PDB ( 2ieh.pdb ) with CA ions since ZN was not found in the OPLS data base in using pdb2gmx. The points being ( 1) Gromacs appears reasonably happy with the 8 core and 32 core Ryzen although ( again in my hands ) for these smallish systems there is only about a 10% improvement between the two, and (2) , as often suggested in the Gromacs literature, use the latest
Re: [gmx-users] ramachandran plot
Hi, I use the python MDAnalysis packages for this. https://github.com/MDAnalysis/mdanalysis/issues/1335 https://www.mdanalysis.org/mdanalysis/documentation_pages/analysis/dihedrals.html Have a nice day, Tamas On 01/09/2019 10:30 AM, za...@tezu.ernet.in wrote: Dear Users Can anyone suggest me any available tool to analyze ramachandran plot timewise for a trajectory? Thank You Regards Zaved Hazarika Research Scholar Dept. Of Molecular Biology and Biotechnology, Tezpur University, India * * * D I S C L A I M E R * * * This e-mail may contain privileged information and is intended solely for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail in error and destroy it from your system. Though considerable effort has been made to deliver error free e-mail messages but it can not be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, delayed, or may contain viruses. The recipient must verify the integrity of this e-mail message. -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] different nvidia-smi/gmx GPU_IDs
Hi, I have a node with 4 nvidia GPUs. From nvidia-smi output: 0 Quadro P6000 1 GeForce RTX 208 2 GeForce GTX 108 3 GeForce RTX 208 However, the order of GPUs is differently detected by gmx 2018.3 Number of GPUs detected: 4 #0: NVIDIA GeForce RTX 2080 Ti #1: NVIDIA GeForce RTX 2080 Ti #2: NVIDIA Quadro P6000 #3: NVIDIA GeForce GTX 1080 Ti Why is this? This makes difficult to plan/check the running of two gmx jobs on the same node. Thanks for your suggestion. Tamas -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org --- This email has been checked for viruses by AVG. https://www.avg.com -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] different nvidia-smi/gmx GPU_IDs
Thanks! On 1/14/19 7:06 AM, Mark Abraham wrote: Hi, Looks like something that NVIDIA did differently some time in the past, and unlikely to change :-( https://stackoverflow.com/questions/26123252/inconsistency-of-ids-between-nvidia-smi-l-and-cudevicegetname Mark On Sun., 13 Jan. 2019, 14:27 Tamas Hegedus, wrote: Hi, I have a node with 4 nvidia GPUs. From nvidia-smi output: 0 Quadro P6000 1 GeForce RTX 208 2 GeForce GTX 108 3 GeForce RTX 208 However, the order of GPUs is differently detected by gmx 2018.3 Number of GPUs detected: 4 #0: NVIDIA GeForce RTX 2080 Ti #1: NVIDIA GeForce RTX 2080 Ti #2: NVIDIA Quadro P6000 #3: NVIDIA GeForce GTX 1080 Ti Why is this? This makes difficult to plan/check the running of two gmx jobs on the same node. Thanks for your suggestion. Tamas -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org --- This email has been checked for viruses by AVG. https://www.avg.com -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org. -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] gmx 2019 running problems
Hi, I tried to install and use gmx 2019 on a single node computer with 4 GPUs. I think that the build was ok, but the running is... There is only workload on 4 cores (-nt 16) and there is no workload on the GPUs at all. gmx 2018 was deployed on the same computer with the same tools and libraries. CPU 16cores + 16threads GPU 1080Ti cmake -j 16 -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6 -DCMAKE_INSTALL_PREFIX=$HOME/opt/gromacs-2019-gpu -DGMX_GPU=ON -DCMAKE_PREFIX_PATH=$HOME/opt/OpenBLAS-0.2.20 -DFFTWF_LIBRARY=$HOME/opt/fftw-3.3.7/lib/libfftw3f.so -DFFTWF_INCLUDE_DIR=$HOME/opt/fftw-3.3.7/include ../ | tee out.cmake -- Looking for NVIDIA GPUs present in the system -- Number of NVIDIA GPUs detected: 4 -- Found CUDA: /usr (found suitable version "9.1", minimum required is "7.0") make -j16 make -j16 install # note: a lot of building happened also in this step ** gmx mdrun -nt 16 -ntmpi 4 -gputasks 0123 -nb gpu -bonded gpu -pme gpu -npme 1 -pin on -v -deffnm md_2 -s md_2_500ns.tpr -cpi md_2.1.cpt -noappend +-+ | NVIDIA-SMI 390.48 Driver Version: 390.48 | |---+--+--+ | GPU NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===+==+==| | 0 GeForce GTX 108... Off | :02:00.0 Off | N/A | | 0% 28CP819W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 1 GeForce GTX 108... Off | :03:00.0 Off | N/A | | 0% 28CP8 8W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 2 GeForce GTX 108... Off | :83:00.0 Off | N/A | | 0% 28CP8 9W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 3 GeForce GTX 108... Off | :84:00.0 Off | N/A | | 0% 27CP8 9W / 250W |237MiB / 11178MiB | 0% Default | +---+--+--+ +-+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=| |0 20243 C gmx 161MiB | |1 20243 C gmx 161MiB | |2 20243 C gmx 161MiB | |3 20243 C gmx 219MiB | +-+ Thanks for your suggestions, Tamas -- Tamas Hegedus, PhD Senior Research Fellow MTA-SE Molecular Biophysics Research Group Hungarian Academy of Sciences | phone: (36) 1-459 1500/60233 Semmelweis University | fax: (36) 1-266 6656 Tuzolto utca 37-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary| http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] gmx 2019 running problems
Hi, Thanks for the feed-backs. Yes, I could build gmx 2019 on a hosts running with nvidia driver 4.10 Tamas On 01/14/2019 09:06 PM, Tamas Hegedus wrote: Hi, I tried to install and use gmx 2019 on a single node computer with 4 GPUs. I think that the build was ok, but the running is... There is only workload on 4 cores (-nt 16) and there is no workload on the GPUs at all. gmx 2018 was deployed on the same computer with the same tools and libraries. CPU 16cores + 16threads GPU 1080Ti cmake -j 16 -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6 -DCMAKE_INSTALL_PREFIX=$HOME/opt/gromacs-2019-gpu -DGMX_GPU=ON -DCMAKE_PREFIX_PATH=$HOME/opt/OpenBLAS-0.2.20 -DFFTWF_LIBRARY=$HOME/opt/fftw-3.3.7/lib/libfftw3f.so -DFFTWF_INCLUDE_DIR=$HOME/opt/fftw-3.3.7/include ../ | tee out.cmake -- Looking for NVIDIA GPUs present in the system -- Number of NVIDIA GPUs detected: 4 -- Found CUDA: /usr (found suitable version "9.1", minimum required is "7.0") make -j16 make -j16 install # note: a lot of building happened also in this step ** gmx mdrun -nt 16 -ntmpi 4 -gputasks 0123 -nb gpu -bonded gpu -pme gpu -npme 1 -pin on -v -deffnm md_2 -s md_2_500ns.tpr -cpi md_2.1.cpt -noappend +-+ | NVIDIA-SMI 390.48 Driver Version: 390.48 | |---+--+--+ | GPU NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===+==+==| | 0 GeForce GTX 108... Off | :02:00.0 Off | N/A | | 0% 28CP819W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 1 GeForce GTX 108... Off | :03:00.0 Off | N/A | | 0% 28CP8 8W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 2 GeForce GTX 108... Off | :83:00.0 Off | N/A | | 0% 28CP8 9W / 250W |179MiB / 11178MiB | 0% Default | +---+--+--+ | 3 GeForce GTX 108... Off | :84:00.0 Off | N/A | | 0% 27CP8 9W / 250W |237MiB / 11178MiB | 0% Default | +---+--+--+ +-+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=| |0 20243 C gmx 161MiB | |1 20243 C gmx 161MiB | |2 20243 C gmx 161MiB | |3 20243 C gmx 219MiB | +-+ Thanks for your suggestions, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] gmx 2019 performance issues
Hi, I do not really see an increased performance with gmx 2019 using -bonded gpu. I do not see what I miss or misunderstand. The only thing I see that all cpu run at ~100% with gmx2018, while some of the cpus run only at ~60% with gmx2019. There are: 196382 Atoms Speeds comes from 500 ps runs. From one of the log files: Mapping of GPU IDs to the 4 GPU tasks in the 4 ranks on this node: PP:0,PP:0,PP:2,PME:2 PP tasks will do (non-perturbed) short-ranged and most bonded interactions on the GPU PME tasks will do all aspects on the GPU -- 16 cores 4 GPUs gmx 2018 48ns/day gmx 2019 54ns/day gmx mdrun -nt 16 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -pme gpu -npme 1 -gputasks 0123 gmx mdrun -nt 16 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0123 Since the GPUs are not utilized well (some of them are below 50%), my objective is run 2 jobs/node with 8 CPUs and 2 GPUs with higher usage. -- 8 cores 2 GPUs gmx 2018 33 ns/day gmx 2019 35 ns/day gmx mdrun -nt 8 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -pme gpu -npme 1 -gputasks 0033 gmx mdrun -nt 8 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0022 gmx mdrun -ntomp 2 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0022 Changing -nt to -ntomp did not help to increase performance. And the GPUs are not utilized much better. 1080Ti runs max 60-75% -- The main question: * I use 16 core AMD 2950X with 4 high end GPUs (1080Ti, 2080Ti). * GPUs does not run at 100%, so I would like load more on them and possibly run 2 gmx jobs on the same node. I see two options: * cheaper: decrease the cores from 16 to 8 and push bonded calculations to gpu using gmx 2019 * expensive: replace the 16core 2950X to 32core 2990WX 2950X 16 cores 2 GPUs gmx 2018 43 ns/day gmx 2019 43 ns/day 33 ns/day (8core/2GPUs) <<<< 54 (16core/4GPUS) 43 ns/day << 54 (16core/4GPUS) So this could be a compromise if 16/32 cores works similarly as 16/16 cores. E.g. 2990 has slower memory access compared to 2950; I do not expect this to influence gmx runs too much. However, if it decreases by 10-15 percentage then most likely it does not worth to invest into the 32 core processor. Thanks for your feedbacks. Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] gmx 2019 performance issues
Thanks for the inputs! * I will go with the cheaper CPU * I am looking forward to the gpu-only gromacs; impatiently On 01/15/2019 01:55 PM, Mark Abraham wrote: Hi, On Tue, Jan 15, 2019 at 1:30 PM Tamas Hegedus wrote: Hi, I do not really see an increased performance with gmx 2019 using -bonded gpu. I do not see what I miss or misunderstand. Unfortunately that is expected in some cases, see http://manual.gromacs.org/documentation/current/user-guide/mdrun-performance.html#gpu-accelerated-calculation-of-bonded-interactions-cuda-only. Much of the gain is that it is more feasible to spend less on the CPU, so gains in performance per $, rather than in raw performance. The only thing I see that all cpu run at ~100% with gmx2018, while some of the cpus run only at ~60% with gmx2019. QED, probably :-) There are: 196382 Atoms Speeds comes from 500 ps runs. From one of the log files: Mapping of GPU IDs to the 4 GPU tasks in the 4 ranks on this node: PP:0,PP:0,PP:2,PME:2 PP tasks will do (non-perturbed) short-ranged and most bonded interactions on the GPU PME tasks will do all aspects on the GPU -- 16 cores 4 GPUs gmx 2018 48ns/day gmx 2019 54ns/day gmx mdrun -nt 16 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -pme gpu -npme 1 -gputasks 0123 gmx mdrun -nt 16 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0123 Since the GPUs are not utilized well (some of them are below 50%), my objective is run 2 jobs/node with 8 CPUs and 2 GPUs with higher usage. -- 8 cores 2 GPUs gmx 2018 33 ns/day gmx 2019 35 ns/day gmx mdrun -nt 8 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -pme gpu -npme 1 -gputasks 0033 gmx mdrun -nt 8 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0022 gmx mdrun -ntomp 2 -ntmpi 4 -pin on -v -deffnm md_test -nb gpu -bonded gpu -pme gpu -npme 1 -gputasks 0022 Changing -nt to -ntomp did not help to increase performance. And the GPUs are not utilized much better. 1080Ti runs max 60-75% Single simulations are unlikely to get much higher utilization, except perhaps paired with high-clock CPUs. Multi-simulations are still the way to make optimal use of your resources, if throughput-style runs are appropriate for the science. -- The main question: * I use 16 core AMD 2950X with 4 high end GPUs (1080Ti, 2080Ti). * GPUs does not run at 100%, so I would like load more on them and possibly run 2 gmx jobs on the same node. I see two options: * cheaper: decrease the cores from 16 to 8 and push bonded calculations to gpu using gmx 2019 * expensive: replace the 16core 2950X to 32core 2990WX 2950X 16 cores 2 GPUs gmx 2018 43 ns/day gmx 2019 43 ns/day 33 ns/day (8core/2GPUs) <<<< 54 (16core/4GPUS) 43 ns/day << 54 (16core/4GPUS) So this could be a compromise if 16/32 cores works similarly as 16/16 cores. E.g. 2990 has slower memory access compared to 2950; I do not expect this to influence gmx runs too much. However, if it decreases by 10-15 percentage then most likely it does not worth to invest into the 32 core processor. I would suggest the cheaper CPU. We are working actively to implement a pure GPU implementation in an upcoming version (but no promises yet!) Mark Thanks for your feedbacks. Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37 <https://maps.google.com/?q=Tuzolto+utca+37&entry=gmail&source=g>-47 | mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org. -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] pinoffset w LINCS error
Hi, I have two servers with AMD2950X (16 physical cores). One with 16Gb RAM and RTX2080Ti, the other 32Gb RAM and GTX1080Ti. I use gromacs 2018.3, compiled on the same way on both of the servers. I wanted to run two simulations on the same host (8+8cores and GPU0 and GPU1). They are OK on the 32GbRAM and GTX1080Ti computer. * One job with pinoffset fails on the 16Gb computer with LINCS errors. It runs without problem without pinoffset. * If I run only a single job but with pinoffset then it also fails. The error in case: cannot settle water molecule These indicate for me that memory, file naming, and setting parameters (pinoffset, gpuid) are OK and some magical problem exists. Do you have any suggestion? Thanks, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] slurm, gres:gpu, only 1 GPU out of 4 is detected
Hi, I run gmx 2019 using GPU There are 4 GPUs in my GPU hosts. I have slurm and configured gres=gpu 1. If I submit a job with --gres=gpu:1 then GPU#0 is identified and used (-gpu_id $CUDA_VISIBLE_DEVICES). 2. If I submit a second job, it fails: the $CUDA_VISIBLE_DEVICES is 1 and selected, but GPU #0 is identified by gmx as a compatible gpu. From the output: gmx mdrun -v -pin on -deffnm equi_nvt -nt 8 -gpu_id 1 -nb gpu -pme gpu -npme 1 -ntmpi 4 GPU info: Number of GPUs detected: 1 #0: NVIDIA GeForce GTX 1080 Ti, compute cap.: 6.1, ECC: no, stat: compatible Fatal error: You limited the set of compatible GPUs to a set that included ID #1, but that ID is not for a compatible GPU. List only compatible GPUs. 3. If I login to that node and run the mdrun command written into the output in the previous step then it selects the right gpu and runs as expected. $CUDA_DEVICE_ORDER is set to PCI_BUS_ID I can not decide if this is a slurm config error or something with gromacs, as $CUDA_VISIBLE_DEVICES is set correctly by slurm and I expect gromacs to detect all 4GPUs. Thanks for your help and suggestions, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] slurm, gres:gpu, only 1 GPU out of 4 is detected
I had the misconception that I have to set gpuid by CUDA_VISIBLE_DEVICES set by slurm. However, slurm exposes the gpu for gromacs by a different mechanism. On 11/13/19 4:55 PM, Tamas Hegedus wrote: Hi, I run gmx 2019 using GPU There are 4 GPUs in my GPU hosts. I have slurm and configured gres=gpu 1. If I submit a job with --gres=gpu:1 then GPU#0 is identified and used (-gpu_id $CUDA_VISIBLE_DEVICES). 2. If I submit a second job, it fails: the $CUDA_VISIBLE_DEVICES is 1 and selected, but GPU #0 is identified by gmx as a compatible gpu. From the output: gmx mdrun -v -pin on -deffnm equi_nvt -nt 8 -gpu_id 1 -nb gpu -pme gpu -npme 1 -ntmpi 4 GPU info: Number of GPUs detected: 1 #0: NVIDIA GeForce GTX 1080 Ti, compute cap.: 6.1, ECC: no, stat: compatible Fatal error: You limited the set of compatible GPUs to a set that included ID #1, but that ID is not for a compatible GPU. List only compatible GPUs. 3. If I login to that node and run the mdrun command written into the output in the previous step then it selects the right gpu and runs as expected. $CUDA_DEVICE_ORDER is set to PCI_BUS_ID I can not decide if this is a slurm config error or something with gromacs, as $CUDA_VISIBLE_DEVICES is set correctly by slurm and I expect gromacs to detect all 4GPUs. Thanks for your help and suggestions, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] multidir, Segmentation fault
Hi, I ran two equilibration simulations to generate two production tpr with different velocities. mdrun_mpi runs fine with each tpr (no explosion, the systems are stable). However, if I set the multidir option, I get segmentation fault. My system: Debian Buster, GROMACS 2018.6 Thanks for your suggestions, Tamas [myhost:39226] Signal: Segmentation fault (11) [myhost:39226] Signal code: Address not mapped (1) [myhost:39226] Failing at address: 0x7f94b42e0008 [myhost:39226] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f94ab991730] [myhost:39226] [ 1] /usr/lib/x86_64-linux-gnu/pmix/lib/pmix/mca_gds_ds21.so(+0x2936)[0x7f94a9f72936] [myhost:39226] [ 2] /usr/lib/x86_64-linux-gnu/libmca_common_dstore.so.1(pmix_common_dstor_init+0x9d3)[0x7f94a9f62733] [myhost:39226] [ 3] /usr/lib/x86_64-linux-gnu/pmix/lib/pmix/mca_gds_ds21.so(+0x25b4)[0x7f94a9f725b4] [myhost:39226] [ 4] /usr/lib/x86_64-linux-gnu/libpmix.so.2(pmix_gds_base_select+0x12e)[0x7f94aa0a946e] [myhost:39226] [ 5] /usr/lib/x86_64-linux-gnu/libpmix.so.2(pmix_rte_init+0x8cd)[0x7f94aa06188d] [myhost:39226] [ 6] /usr/lib/x86_64-linux-gnu/libpmix.so.2(PMIx_Init+0xdc)[0x7f94aa01dd7c] [myhost:39226] [ 7] /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext2x.so(ext2x_client_init+0xc4)[0x7f94aa113fe4] [myhost:39226] [ 8] /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_ess_pmi.so(+0x2656)[0x7f94aade3656] [myhost:39226] [ 9] /usr/lib/x86_64-linux-gnu/libopen-rte.so.40(orte_init+0x29a)[0x7f94aaedc11a] [myhost:39226] [10] /usr/lib/x86_64-linux-gnu/libmpi.so.40(ompi_mpi_init+0x252)[0x7f94ae62] [myhost:39226] [11] /usr/lib/x86_64-linux-gnu/libmpi.so.40(PMPI_Init_thread+0x55)[0x7f94abbea2d5] [myhost:39226] [12] /opt/gromacs-2018.6/bin/mdrun_mpi(+0x41e585)[0x55efb99a9585] [myhost:39226] [13] /opt/gromacs-2018.6/bin/mdrun_mpi(+0x3da4d9)[0x55efb99654d9] [myhost:39226] [14] /opt/gromacs-2018.6/bin/mdrun_mpi(+0xff6f9)[0x55efb968a6f9] [myhost:39226] [15] /opt/gromacs-2018.6/bin/mdrun_mpi(+0xff919)[0x55efb968a919] [myhost:39226] [16] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f94ab7e209b] [myhost:39226] [17] /opt/gromacs-2018.6/bin/mdrun_mpi(+0xd4b7a)[0x55efb965fb7a] [myhost:39226] *** End of error message *** -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
[gmx-users] gromacs 2020, bug? high total energy
Hi, There might be some bug(?) in gromacs 2020. I can not decide. I just installed 2020.1 today using the same script (and libraries) what I have used for gromacs 2019. After energy minimization, in the nvt equilibration run, it stops: Fatal error: Step 0: The total potential energy is 1.99295e+23, which is extremely high. The LJ and electrostatic contributions to the energy are 73028.7 and -712615, respectively. A very high potential energy can be caused by overlapping interactions in bonded interactions or very large coordinate values. Usually this is caused by a badly- or non-equilibrated initial configuration, incorrect interactions or parameters in the topology. I tried two different systems (two different soluble proteins, ff charmm-36m). However, if I start the simulations with 2019.4, there is no problem at all. Have a nice day, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
Re: [gmx-users] gromacs 2020, bug? high total energy
Hi, It was not gromacs 2020, but my fault and mixing up various tools (grompp, mdrun) from 2019 and 2020 versions. I am sorry. Bests, Tamas On 4/14/20 4:44 PM, Tamas Hegedus wrote: Hi, There might be some bug(?) in gromacs 2020. I can not decide. I just installed 2020.1 today using the same script (and libraries) what I have used for gromacs 2019. After energy minimization, in the nvt equilibration run, it stops: Fatal error: Step 0: The total potential energy is 1.99295e+23, which is extremely high. The LJ and electrostatic contributions to the energy are 73028.7 and -712615, respectively. A very high potential energy can be caused by overlapping interactions in bonded interactions or very large coordinate values. Usually this is caused by a badly- or non-equilibrated initial configuration, incorrect interactions or parameters in the topology. I tried two different systems (two different soluble proteins, ff charmm-36m). However, if I start the simulations with 2019.4, there is no problem at all. Have a nice day, Tamas -- Tamas Hegedus, PhD Senior Research Fellow Department of Biophysics and Radiation Biology Semmelweis University | phone: (36) 1-459 1500/60233 Tuzolto utca 37-47| mailto:ta...@hegelab.org Budapest, 1094, Hungary | http://www.hegelab.org -- Gromacs Users mailing list * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before posting! * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists * For (un)subscribe requests visit https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or send a mail to gmx-users-requ...@gromacs.org.
