Dear Natalia,
The current mdrun-gpu (which btw uses OpenMM) is capable to run a
single simulation, on a single node, using a single GPU only.
Cheers,
--
Szilárd
On Fri, Mar 4, 2011 at 6:28 PM, Nathalia Garces wrote:
> Hello,
> I want to know if it is possible to use "mdrun-gpu" with the comma
Hi,
What is the error you are getting? What is unfortunate about
temperature coupling?
Have you checked out the part of the documentation, especially the
supported features on GPUs part
(http://www.gromacs.org/gpu#Supported_features)?
--
Szilárd
On Mon, Mar 7, 2011 at 3:43 PM, kala wrote:
>
> 1- I am wondering for each interval say
>
> Interval 2:
> init_lambda = 0.05
> foreign_lambda = 0 0.1
>
> how this foreign_lambda 0 is related to the init_lambda = 0 from interval 1
> and the same for foreign_lambda = 0.1 in interval 2 and init_lambda = 0.1 in
> interval 3? Is there a physical me
> I am a bit confused on the g_bar part, when it says -f expects multiple
> dhdl files. Do we need to run still multiple independent simulations
> using different foreign_lambda values? I do not see why we should run
> independent simulations, if we use for couple-lambda0 and couple-lambda1
> vdw-q
Hi Jordi,
I've never seen this error or anything similar, but I can give you hints.
The CMake build system first generates binaries in the build directory
which are also runnable from there (are linked against libs located in
the build three). When you do a "make install[-mdrun]", howerver,
these
ctory:
>
> -rwxr-xr-x 1 root root 3433307 Mar 29 08:31 mdrun-gpu
>
> I attach also the CMakeCache list if it can help.
>
> Thanks for any advise!
>
> jordi inglés
>
> El 28/03/11 21:50, Szilárd Páll escribió:
>>
>> Hi Jordi,
>>
>> I've never
gt;
> Jordi Inglés
>
> El 29/03/11 13:00, Szilárd Páll escribió:
>>
>> Hi,
>>
>> I've diff-ed the cache file you sent me against the one I generated
>> and I couldn't see anything relevant. Neither does the verbose CMake
>> output suggest anything
Hi,
As Justin said, it's probably the imbalance which is causing the
slowdown. You can take a look at the statistics at the end of the log
file. One simple thing you could do is to compare the log file of your
long, gradually slowing down run with a shorter run to see which part
takes more time.
Hi Sebastian,
Are you sure that the NVIDIA driver works and is compatible with the
CUDA version you have? What does "nvidia-smi -L -a" output? Have you
tried running something, for instance an SDK sample?
Cheers,
--
Szilárd
2011/4/18 SebastianWaltz :
> Dear gromacs user,
>
> I have some proble
Hi,
> Thanks for the reply. The part I modified is the implicit solvent
> part, particularly the Still model. Also I modified a part of nonbonded
> kernel, not sse ones. So I assumed I have to link GROMACS with OPENMM
> using customGBforce?
You mean that you modified the CUDA kernel inside OpenMM
Hi Claus,
> be supported in future versions. Yet, in the openmm website,
> the new version of openmm (3.0 that is) is supposed to support both cuda and
> opencl framework alongside gromacs:
> (https://simtk.org/project/xml/downloads.xml?group_id=161)
What do you mean by "alongside gromacs"?
> 1)
Hi,
> Is there any common problem for an compilation with the intel compiler
> suite 12.0 and FFTW 3.2.2/Gromacs 4.5.4
Not that I know of, I've never had/head about such issues.
I just checked and I couldn't reproduce your issue. Tried with both
autoconf and CMake and with:
Intel Compilers: v12.
Hi,
Good that managed to solve the issue!
Even though it might have been caused by a bug in the autoconf
scripts, as these are the final days for the autoconf support in
Gromacs, I see a very slim change that it will get
investigated/fixed.
--
Szilárd
On Tue, May 10, 2011 at 4:19 PM, wrote
Just some hints:
- Does the target platform (32/64 bit) or the fftw libs and Gromacs
build match?
- Try to do a make clean first and (/or?) and reconfigure with
--enable-shared. Not sure that it will help, but I vaguely remember
something.
- Try CMake.
Cheers,
--
Szilárd
On Tue, May 10, 2011
> nstlist is more directly related to dt, and is often connected to the force
> field, as well. Values of 5-10 are standard. Setting nstlist = 1 is
> usually only necessary for EM, not MD. Excessive updating of the neighbor
> list can result in performance loss, I believe.
Not only can, but it
Hi,
You should really use fftw, it's *much* faster! (Btw: fftpack comes
with Gromacs.)
I'm not sure what versions of Gromacs are available through the RHEL
packages, but as installing from source is not very difficult
(especially for a sysadmin) you might be better of with getting a
fresh install
Hi Matt,
Just wanted to warn you that AFAIK Gromacs 4.5.x was not tested with
gcc 4.0.1, we've done testing only with 4.1 and later. This doesn't
mean that it shouldn't work, but if you encounter anything strange,
the first thing you should do is to get a newer gcc.
Also, your tMPI errors might b
Hi Hsin-Lin,
Your problem are caused by a missing header file which is included by
the nobonded SSE kernels which is indicated by the first error in your
output:
nb_kernel400_ia32_sse.c:22:23: emmintrin.h: No such file or directory
This header is needed for SSE and SSE2, but for some reason you
Hi,
That compiler is ancient (thought it might have SSE2 support) as well
as the OS, I guess (RHEL 3?). Still, the CPU does support SSE2 so if
you can get a gcc 4.1 or later on it you should still be able compile
and run the code without a problem.
--
Szilárd
2011/5/26 Hsin-Lin Chiang :
> Hi,
Dear Andrew,
Compiling on Windows was tested only using MSVC and I have no idea if
it works or not under cygwin. You should just try, both cmake and gcc
is available for cygwin so you might be lucky and get mdrun-gpu
compiled without any additional effort.
All binaries on the Gromacs webpage _are
Hi,
Teslas should be superior when it comes to reliability, but otherwise,
for Gromacs 4.6 GeForce cards are perfectly fine and no Tesla-specific
features will provide performance benefits. The only exception is
GPUDirect for InfiniBand which might not work with consumer boards --
, although I don
Hi,
Most of those are just warnings, the only error I see there comes from
the shell, probably an error in your script.
Cheers,
--
Szilárd
On Wed, Jan 18, 2012 at 12:27 PM, aiswarya pawar
wrote:
> Hi users,
>
> Am running mdrun on gpu . I receive an error such as=
>
> WARNING: This run will g
yone knows what's going wrong.
>>
>>
>> No, but you should start trying to simplify what you're doing to see where
>> the problem lies. Does normal mdrun work?
>>
>> Mark
>>
>>
>> Thanks
>> Sent from my BlackBerry® on Reliance Mo
19, 2012 at 8:45 PM, aiswarya pawar
> wrote:
>>
>> Has the tesla card got to do anything with the error. Am using Nvidia
>> Tesla S1070 1U server.
>>
>>
>> On Thu, Jan 19, 2012 at 8:37 PM, Szilárd Páll
>> wrote:
>>>
>>> And sort
HI Adam,
> I'm trying to run a mdrun-gpu simulation on a 64-bit Ubuntu system.
> I'm using a 15GB GTX 580 NVIDIA GPU card with all the appropriate drivers
> and cuda toolkit.
> However, when I run the command:
>
> mdrun-gpu -s inpufile.tpr -c inputfile.gro -x outputfile.xtc -g
> outputfile.log -n
Hi,
First I thought that there might be a memory leak which could have
caused this if you ran for really long time. However, I've just ran
the very same benchmark (dhfr with PME) for one hour, monitored the
memory usage and I couldn't see any change whatsoever (see the plot
attached).
I've attach
Hi Efrat,
It indeed looks like a memory leak.
Could you please file a bug on redmine.gromacs.org?
Cheers,
--
Szilárd
On Sun, Mar 4, 2012 at 12:21 PM, Efrat Exlrod wrote:
> Hi Szilard,
>
> Thanks for your reply.
> I used your script and I think it does look as a memory leak. Please look at
>
Hi,
That sounds like a memory leak. Could you please file a bug report in
redmine preferably with:
- configure options (+config.log or CMakeCache.txt would be ideal)
- compiler version, external library versions (fft, blas, lapack)
- input (tpr at least)
- full mdrun command line
Cheers,
--
Szilá
Hi,
Could you compile in Debug mode and run mdurn-gpu in gdb, it will tell
more about the location and type of exception.
--
Szilárd
On Mon, Mar 12, 2012 at 8:47 AM, TH Chew wrote:
> Hi all,
>
> I am trying to get the GPU version of gromacs running. I manage to install
> OpenMM, compile and i
I fully agree with David, it's great to have independent benchmarks!
In fact, already the the previous version of the report has been of
great use for us, we have referred to the results in a few occasions.
--
Szilárd
On Thu, Mar 15, 2012 at 2:37 PM, Hannes Loeffler
wrote:
> Dear all,
>
> we
Hi Sara,
The bad performance you are seeing is most probably caused by the
combination of the new AMD "Interlagos" CPUs, compiler, operating
system and it is very likely the the old Gromacs version also
contributes.
In practice these new CPUs don't perform as well as expected, but that
is partly
The docs actually tells you:
"Native GPU acceleration is supported with the verlet cut-off scheme
(not with the group scheme) with PME, reaction-field, and plain
cut-off electrostatics."
(http://www.gromacs.org/Documentation/Parallelization_and_acceleration#GPU_acceleration)
Use the cutoff-scheme
Hi Hubert,
> With a coworker, we recently developed a plugin Vi to manipulate easily
> Gromacs files.
> It enables syntax highlighting for Gromacs files. For the moment, it works
> with mdp, gro, top/itp and ndx files.
> It contains also macros to comment/uncomment easily selections of a file.
Th
Just try and you'll see, it's not like -v is a dangerous command line option!
--
Szilárd
On Fri, Mar 30, 2012 at 1:10 AM, Acoot Brett wrote:
> Dear All,
>
> There is a tutorial says the function of "-v" in mdrun is to make the md
> process visible in the screen, which is correct.
>
> However fr
On a single quad 16-core Interlagos node with system size 34k atoms I
get 55-60 ns/day and even with 24k atoms ~70 ns/day (solvated protein
amber99 + tip3p) . On three of these nodes I think you can get close
to 100 ns/day, but it will be close to the scaling limit.
Have you considered vsites with
Hi,
> thought you can help with this...
I'd appreciate if you kept future conversation on the mailing list.
> The GROMACS website says Geforce GTX 560 Ti is supported. How about GTX 560?
Yes, they are. All Fermi-class cards are supported.
--
Szilárd
> Thanks,
> G
>
> --
> Gaurav Goel, PhD
>
On Wed, Apr 11, 2012 at 6:16 PM, Mark Abraham wrote:
> On 12/04/2012 1:42 AM, haadah wrote:
>>
>> Could you clarify what you mean by "Sounds like an MPI configuration
>> program.
>> I'd get a test program running on 18 cores before worrying about anything
>> else."? My problem is that i can't get
2012/4/17 Pedro Alexandre de Araújo Gomes Lapido Loureiro :
> Hi,
>
> I've come across a discussion about the "single X double precision" issue in
> a NAMD users list e-mail
> (http://www.ks.uiuc.edu/Research/namd/mailing_list/namd-l/9166.html).
> I would like to know what do you think about these
árd.
>
> Do you know where (say, in a piece of code or some documentation) I can be
> sure about that?
> Cheers,
>
> Pedro.
> Em 17 de abril de 2012 15:43, Szilárd Páll
> escreveu:
>
>> 2012/4/17 Pedro Alexandre de Araújo Gomes Lapido Loureiro
>> :
>&g
On Wed, Apr 25, 2012 at 11:43 AM, SebastianWaltz
wrote:
> Dear all,
>
> will the new version 4.6 work together with CUDA 4.2? Would be good to
> know, since this is needed for the new NVIDIA Gemini cards with Kepler
> technology.
Yes it will. I would like to point out that the "needed" part is no
On Wed, May 2, 2012 at 11:51 AM, melichercik wrote:
> Hi people,
> we plan to buy some computer mostly for gromacs, so I want to ask you for
> some hints. I'd tried to do some research, but no success. :(
>
> Have someone ever compared AMD Bulldozer and Sandy/Ivy Bridge architectures?
> Are there
On Wed, May 2, 2012 at 12:17 PM, Thomas Evangelidis wrote:
> For CPU performance comparison look at:
>
> www.spec.org/cpu2006/results
>
> for each CPU look at the statistics for floating point operations, namely
> for SPECfp_base2006 score for the programs of interest (GAMESS, GROMACS,
> NAMD, etc
On Wed, May 2, 2012 at 5:44 PM, Peter C. Lai wrote:
> When considering compute hardware today, you're gonna have to shop like a
> gamer. A rig that can get high Battlefield 3 or Arma 2/3 framerates should
> also be able to get you some nice ns/day.
>
(To a great extent) wong! While many if not m
On Wed, May 2, 2012 at 6:13 PM, Mirco Wahab <
mirco.wa...@chemie.tu-freiberg.de> wrote:
> Hello Peter,
>
> Am 02.05.2012 17:44, schrieb Peter C. Lai:
>
>
> You can wait for ivy bridge, then stick some Kepler GPUs (nvidia gtx
>> 680) in it. That should max the performance. asm is pretty much stagn
On Fri, May 4, 2012 at 8:58 PM, Oliver Stueker wrote:
> Hi all,
>
> This week Nvidia has also announced the GeForce GTX 690 with two
> Kepler Chips [1].
> That will make a total of 3072 CUDA cores @ 915MHz to 1019MHz and will
> perform like two GTX 680s in SLI mode [2], but more energy efficient.
On Fri, May 4, 2012 at 9:20 PM, Roland Schulz wrote:
>
>
> On Wed, Apr 25, 2012 at 9:38 AM, Szilárd Páll
> wrote:
>>
>> On Wed, Apr 25, 2012 at 11:43 AM, SebastianWaltz
>> wrote:
>> > Dear all,
>> >
>> > will the new version 4.6 work
Hi,
Due to a mistake during commit cleanup we had to rewrite part of the
history of the nbnxn_hybrid_acc branch. As a consequence, pulling from
branches that track nbnxn_hybrid_acc will not work (it will result in
conflicts) and a forced update will be required:
$ git branch
nbnxn_hybrid_acc #
Or you can just use the git version.
--
Szilárd
On Wed, May 30, 2012 at 5:51 PM, Stephen Cox wrote:
> Hi Justin and Mark,
>
> Thanks once again for getting back.
>
> I've found the problem - it's actually a known bug already:
>
> http://redmine.gromacs.org/issues/901
>
> The dispersion correctio
Hi,
The fact that GPUs are detected at configure-time does not imply that these
GPUs will also work fine at run-time and you see this in action in your
case. The current CMake configure script only looks at whether there is any
NVIDIA GPU device connected, but does not check other conditions that
Hi,
That unfortunately tell exactly about the reason why mdrun is stuck. Can
you reproduce the issue on another machines or with different launch
configurations? At which step does it get stuck (-stepout 1 can help)?
Please try the following:
- try running on a single GPU;
- try running on CPUs o
gt; gen_seed= -1; Use random seed for velocity generation
> (integer; -1 means seed is calculated from the process ID number)
> ; Centre of mass (COM) motion removal relative to the specified groups
> nstcomm = 1 ; COM removal frequency (ste
etting has been fixed recently.
If the above doesn't help, please file a bug report and attach a tpr so we
can reproduce.
Cheers,
--
Szilárd
On Mon, Dec 17, 2012 at 6:21 PM, Albert wrote:
> On 12/17/2012 06:08 PM, Szilárd Páll wrote:
>
>> Hi,
>>
>> How about GPU e
On Mon, Dec 17, 2012 at 7:56 PM, Mark Abraham wrote:
> On Mon, Dec 17, 2012 at 6:01 PM, Albert wrote:
>
> > hello:
> >
> > I reduced the GPU to two, and it said:
> >
> > Back Off! I just backed up nvt.log to ./#nvt.log.1#
> > Reading file nvt.tpr, VERSION 4.6-dev-20121004-5d6c49d (single precisi
Hi James,
Don't use the OpenMM accelerated mdrun for explicit solvent simulations.
For such runs any modern CPU with 4-8 cores will probably be as fast or
faster than most GPUs.
However, do consider the 4.6 *native* heterogeneous GPU-accelerated code.
This new efficient code can provide 2-4x spee
t
> > true how I should compilate such new gpu-based gromacs? In the
> > gromacs-4.6-beta-3 folder I've found instructuon for the standart
> > installation via cmake
> >
> > cmake PATH_TO_SOURCE_DIRECTORY -DGMX_OPENMM=ON -DGMX_THREADS=OFF
> >
> >
&g
nt it ATM, but as GROMACS is OSS anyone is
welcome to contribute it.
And let me reiterate, if you're running explicit solvent you should be
using the native GPU acceleration as you've been told before.
Cheers,
Szilard
> James
>
> 2013/1/9 Szilárd Páll :
> > On Tue, Jan 8, 2
e sollutions.
> >
> > by the way is it possible to compilate gromacs-4.6 agains other
> > platgorm ( e.g openCL) ? I have no problems with the compatibility of
> > the openCL and openMM.
> >
> > James
> >
> > 2013/1/9 Szilárd Páll :
> >
n-openmm that platform cuda was not detected (gromacs
> >> was compilated without any errors).
> >>
> > with the natived gpu implementation (GMX_GPU) cuda 5.0 works fine.
> >
> >
> >> by the way is it possible to compilate gromacs-4.6 agains other
> >> platg
two MPI processes on the GPU
(mpirun -np 2 mdrun -gpu_id 00) and using the -nb gpu_cpu mode which will
execute part of the nonbonded on the CPU, but this might not help.
Cheers,
--
Szilárd
On Wed, Jan 9, 2013 at 8:27 PM, James Starlight wrote:
> Dear Szilárd, thanks for help again!
&g
least not without *carefully* checking whether a shorter LJ cut-off
makes sense and that it does not break the physics of your simulation.
Although we advise you to consider decreasing your cut-off - mostly because
these days a large number of simulations are carried out with overly long
cut-off cho
Hi,
Note that the CUDA NxN non-bonded kernels are programmer and
performance-tuned in such a way that they have very high compute/memory
access ratio and therefore are not sensitive to GPU memory performance.
Hence with the native GPU acceleration you won't see any improvement from
turning off ECC
an
my earlier suggestions, there isn't much you can do to eliminate the idling
on the CPU (I assume that's what bugs you) - except getting a faster GPU.
Btw, have you tried the hybrid GPU-CPU mode (although I expect it to not be
faster)?
Cheers,
--
Szilárd
>
>
> Thanks
Hi,
Please try to run the very same simulation that crashes on CPUs only (-nb
cpu). If that also crashes, please file a bug report because we surely have
a software bug.
If that does not crash, we will have to dig a bit deeper into what could be
causing the issue.
Log files from the two runs wo
Hi Floris,
Great feedback, this needs to be looked into. Could you please file a bug
report, preferably with a tpr (and/or all inputs) as well as log files.
Thanks,
--
Szilárd
On Tue, Jan 15, 2013 at 3:50 AM, Floris Buelens wrote:
> Hi,
>
>
> I'm seeing MD simulation running a lot slower with
t: Re: [gmx-users] >60% slowdown with GPU / verlet and sd
> > > integrator
> > > > From: jmsstarli...@gmail.com
> > > > To: gmx-users@gromacs.org
> > > >
> > > > Hi all!
> > > >
> > > > I've also done some calcu
Hi,
Not sure why, but it looks like libcudart.so is linked against a glibc that
not compatible with what you have (perhaps much newer)?
Alternatively you could try adding "--add-needed" to the linker flags, but
I doubt it will help.
Cheers,
--
Szilárd
On Mon, Jan 21, 2013 at 5:09 PM, James St
certain
solution.
> compilation. By the way where I could provide --add-needed option ?
CMAKE_EXE_LINKER_FLAGS=-wl,--add-needed
Cheers,
Szilárd
>
>
> James
>
>
> 2013/1/21 Szilárd Páll :
> > Szilárd
> --
> gmx-users mailing listgmx-users@gromacs.org
> http:
>>
>> Cheers,
>>
>> Christoph
>>
>
>
>
> I also had this problem, and found that (manually) updating GCC to version
> 4.6 or higher has fully solved some installation issues with GROMACS 4.6.
> Please note that, for older linux dists, updating via cons
Hi,
Here's a bit more explanation, hopefully a bit more practical and give for
you and others a better view of what's going on under mdrun's hood.
thread-MPI, or in other contexts referred to as "thread_mpi" or abbreviated
as "tMPI", is functionally equivalent with the standard MPI you'd use on
On Thu, Jan 24, 2013 at 3:28 PM, Justin Lemkul wrote:
>
>
> On 1/24/13 9:23 AM, James Starlight wrote:
>
>> oh that was simply solved by upgrading of G++ :)
>>
>> the only problem which remains is the missing of support of mu GPU :(
>> That time I've tried to start simulation on simply 2 cores CP
(plus these cards are anyway
slower), but it *might* be worth a try!
Feel free to drop me a mail if anybody is interested.
Cheers,
--
Szilárd
On Thu, Jan 24, 2013 at 3:48 PM, Szilárd Páll wrote:
> On Thu, Jan 24, 2013 at 3:28 PM, Justin Lemkul wrote:
>
>>
>>
>> On 1/24
On Thu, Jan 24, 2013 at 7:09 PM, Christoph Junghans wrote:
> > Date: Thu, 24 Jan 2013 01:07:04 +0100
> > From: Szil?rd P?ll
> > Subject: Re: [gmx-users] Problem with gromacs-4.6 compilation on
> > Debian
> > To: Discussion list for GROMACS users
> > Message-ID:
> > xwqyn3xwoeujj
Hi,
Typically, the fastest the GPU the better. On a more detailed level, less
multiprocessors (that's not "cores"!) with faster clock speeds help in
achieving higher performance with small systems. As GPUs are highly
parallel processors, 20-30k atoms/GPU can be considered small-ish -
especially wi
On Mon, Jan 14, 2013 at 7:20 PM, James Starlight wrote:
> 1)As I understood from nvidia site at present time GPU's from the
> tesla serie are the best for the calculations like md. For instasnce
> NVIDIA Tesla C2075 have performance ~ 1 TFLOPS in the
> single-precission calculations. I wounder to
Hi,
Earlier in the development of 4.6 I have tried Open64 (4.5.1, I guess)
hoping that it would help with testing/improving Bulldozer support, but I
quickly found a compiler bug or two that prevented me from being able to
actually use it. I reported the bugs to AMD so they might have fixed them,
b
On Tue, Jan 29, 2013 at 4:39 PM, Susan Chacko wrote:
>
> Sorry for a newbie question -- I've built several versions of Gromacs in
> the
> past but am not very familiar with the new cmake build system.
>
> In older versions, the procedure was:
> - build the single-threaded version
>
FYI there is
Great discussion!
While (seemingly) small changes in cut-off can give considerable
performance improvements and therefore it is worth considering such tweaks
in simulation settings, these finding highlight the importance of not
changing settings blindly.
Cheers,
--
Szilárd
On Wed, Jan 30, 2013
On Sat, Feb 2, 2013 at 2:38 PM, Tomek Wlodarski
wrote:
> On Sat, Feb 2, 2013 at 12:34 PM, Mark Abraham >wrote:
>
> > On Sat, Feb 2, 2013 at 1:00 AM, Justin Lemkul wrote:
> >
> > >
> > >
> > > On 2/1/13 5:26 PM, didymos wrote:
> > >
> > >> Hi Justin!
> > >>
> > >> I had the same problem and I use
appart from:
>
> -- Check size of bool - failed
> -- Performing Test _isfinite_compile_ok - Failed
> -- Performing Test _finite_compile_ok - Failed
>
> I do not know if those are related to building errors..
> Thanks!
> Best!
>
> tomek
>
>
> On Sat, Feb 2, 2013 at 3:40 PM, Szi
On Sat, Feb 2, 2013 at 10:12 PM, Mark Abraham wrote:
> On Sat, Feb 2, 2013 at 8:48 PM, Tomek Wlodarski
> wrote:
>
> > Thanks Szilárd, good idea:)
> > I tried to build gromacs and I got errors..:
> >
> > /tmp/ccBvi1my.s: Assembler messages:
> > /tmp/ccBvi1my.s:110: Error: no such instruction: `vpcm
On Sat, Feb 2, 2013 at 10:16 PM, Tomek Wlodarski
wrote:
> On Sat, Feb 2, 2013 at 10:12 PM, Mark Abraham >wrote:
>
> > On Sat, Feb 2, 2013 at 8:48 PM, Tomek Wlodarski
> > wrote:
> >
> > > Thanks Szilárd, good idea:)
> > > I tried to build gromacs and I got errors..:
> > >
> > > /tmp/ccBvi1my.s: As
On Wed, Feb 6, 2013 at 6:03 PM, Richard Broadbent <
richard.broadben...@imperial.ac.uk> wrote:
> Dear All,
>
> I would like to compile gromacs 4.6 to run with the correct acceleration
> on the compute nodes on our local cluster. Some of the nodes have intel
> sandy-bridge whilst others only have s
On Thu, Feb 7, 2013 at 10:16 AM, Albert wrote:
> Hello:
>
> I got a workstation with two GTX590 which have two core for each GPU. I
> can submit gromacs GPU jobs with command:
>
> mpirun -np 4 mdrun .
>
> with such running, I can get 26ns/day for Gromacs-4.6 beta version.
>
> However, I fou
your driver.
Cheers,
--
Szilárd
On Thu, Feb 7, 2013 at 5:08 PM, Albert wrote:
> On 02/07/2013 01:34 PM, Szilárd Páll wrote:
>
>> Please make sure that nvididia-smi or the deviceQuery SDK tool show all
>> four GPUs. If that is the case and mdrun still shows only two, please file
>>
Additionally to the new non-bonded SIMD kernels:
- Bonded force calculation got some SIMD acceleration which should
considerably improve performance;
- There have been be major improvements in PME (courtesy of Berk Hess &
Roland Schulz), you should see anywhere between up to 1.5-2x performance
impr
On Sat, Feb 23, 2013 at 3:41 AM, Mirco Wahab <
mirco.wa...@chemie.tu-freiberg.de> wrote:
> On 23.02.2013 01:59, toma0...@umn.edu wrote:
>
>> Hello,
>> I am trying to install Gromacs 4.6 on a Windows workstation under
>> cygwin. After I install everything, when executing g_luck I come up with
That's strange, it seems that mdrun gets stuck somewhere. This should not
happen, but as we don't actively test cygwin, we can't be sure what's
happening. It would be great if you could help us figure out what is going
wrong.
Could you try doing the following:
- run with -ntmpi 1 -ntomp 1 (i.e sin
Hi,
That is a likely cause. I can not comment with full certainty on the use of
MARTINI with the Verlet scheme & without shifts, but I know that it is a
topic that's being investigated and hopefully other can comment on it.
However, the hanging should definitely not happen, but instead an error
s
on your output it seems that only
one is used. Could you please verify this? I am not sure whether this is an
inherent problem with cygwin or a bug (and as I don't have access to cygwin
I can't test).
Cheers,
--
Szilárd
On Tue, Feb 26, 2013 at 10:55 PM, Szilárd Páll wrote:
> Hi,
&
Hi,
Yes, it can. If you use the MIC in symmetric mode, it will just look and
behave like another compute node. However, the performance will be
horrible, because we don't have optimized kernels for MIC. Work on porting
the new SIMD-friendly Verlet NxN kernels to MIC ins ongoing, but it is
highly
Jesmin,
First of all, have you read the following pages?
http://www.gromacs.org/Documentation/Acceleration_and_parallelization
http://www.gromacs.org/Documentation/Cut-off_schemes
To summarize:
- OpenMP parallelization is supported in Verlet scheme for the full mdrun
and for separate PME nodes al
Hi,
Thanks for the detailed information!
The only reason why cygwin is cumbersome is that we are not testing it
actively, have we had a developer or contributor working with cygwin there
would be no issues.
In any case, especially because there is performance involved, we should
try to get the A
PS: If you have fftw in the standard location it should be picked up by
cmake; otherwise, -DCMAKE_PREFIX_PATH=/usr/local should work as well.
--
Szilárd
On Wed, Feb 27, 2013 at 9:21 PM, Szilárd Páll wrote:
> Hi,
>
> Thanks for the detailed information!
>
> The only reaso
HI,
That looks like the driver does not work or is incompatible with the
runtime. Please get the SDK, compile a simple program, e.g. deviceQuery and
see if that works (I suspect that it won't).
Regarding your machines, just FYI, the Quadro 4000 is a pretty slow card
(somewhat slower than a GTX 46
Hi George,
As I said before, that just means that most probably the GPU driver is not
compatible with the CUDA runtime (libcudart) that you installed with the
CUDA toolkit. I've no clue about the Mac OS installers and releases, you'll
have to do the research on that. Let us know if you have furthe
Hi,
There are some clarifications needed and as this might help you and other
understand what's going on, I'll take the time to explain things.
Affinity setting is a low-, operating system-level, operation and "locks"
(="pins") threads to physical cores of the CPU preventing the OS from
moving th
On Tue, Mar 5, 2013 at 8:14 PM, Mark Abraham wrote:
> *Hi GROMACS users,
>
> GROMACS 4.6.1 is officially released. It contains numerous bug fixes, some
> simulation performance enhancements and some documentation updates. We
> encourage all users to upgrade their installations from 4.6.
>
> You ca
On Thu, Mar 7, 2013 at 2:02 PM, Berk Hess wrote:
>
> Hi,
>
> This was only a note, not a fix.
> I was just trying to say that what linear algebra library you use for
> Gromacs is irrelevant in more than 99% of the cases.
> But having said that, the choice of library should not complicate the
> co
elp out other
> users!
> >
> > As an aside, I found that the OpenMP + Verlet combination was slower for
> > this particular system, but I suspect that it's because it's almost
> > entirely water and hence probably benefits from the Group scheme
> > optimi
As Mark said, we need concrete details to answer the question:
- log files (all four of them: 1/2 nodes, 4.5/4.6)
- hardware (CPUs, network)
- compilers
The 4.6 log files contain much of the second and third point except the
network.
Note that you can compare the performance summary table's entrie
1 - 100 of 302 matches
Mail list logo
