[gmx-users] GPU

Szilárd Páll szilard.pall at cbr.su.se
Wed Jun 13 14:51:07 CEST 2012


On Wed, Jun 13, 2012 at 3:59 AM, Mark Abraham <Mark.Abraham at anu.edu.au>wrote:

> On 12/06/2012 10:49 PM, Ehud Schreiber wrote:
>
>> Message: 4
>>> Date: Mon, 11 Jun 2012 15:54:39 +1000
>>> From: Mark Abraham<Mark.Abraham at anu.edu.**au <Mark.Abraham at anu.edu.au>>
>>> Subject: Re: [gmx-users] GPU
>>> To: Discussion list for GROMACS users<gmx-users at gromacs.org>
>>> Message-ID:<4FD5881F.3040509@**anu.edu.au <4FD5881F.3040509 at anu.edu.au>>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> On 11/06/2012 2:32 AM, ifat shub wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> If I understand correctly, currently the Gromacs GPU acceleration does
>>>> not support energy minimization. Is this so? Are there any plans to
>>>> include it in the 4.6 version or in a later one (i.e. to allow, say,
>>>> integrator = steep or cg in mdrun-gpu)? I would find such options
>>>> extremely useful.
>>>>
>>> EM is normally so quick that it's not worth putting much effort into
>>> accelerating it, compared to the CPU-months that are spent doing
>>> subsequent MD.
>>>
>>> Mark
>>>
>> Currently, my main use of Gromacs entails running multiple minimizations
>> on an ensemble of states.
>> Moreover, these states are not obtained using molecular dynamics but
>> rather using the Concoord algorithm.
>> Therefore, for me the bottleneck is not md but rather minimizations
>> (specifically, cg) and so their acceleration on GPUs would be very
>> advantageous.
>> If such usage is not totally idiosyncratic, I hope the development team
>> would reconsider GPU accelerating also minimizations.
>> I suspect this would not be technically too complex given the work
>> already done on dynamics.
>>
>
> I suspect the upcoming 4.6 release will have GPU-accelerated EM available
> as a side effect of the new Verlet pair-list scheme for computing
> non-bonded interactions. This development is unrelated to previous GPU
> efforts, I


It does work and has been tested extensively. We are working on the final
details,  but you can get the code from the nbnxn_hybrid_acc branch -- it's
pretty safe to use it for non-production purposes!

The pages Mark linked are the resources you want to start with before you
start using the NxN kernels.

Cheers,
--
Szilárd


> understand. See http://www.gromacs.org/**Documentation/Acceleration_**
> and_parallelization<http://www.gromacs.org/Documentation/Acceleration_and_parallelization>and
> http://www.gromacs.org/**Documentation/Cut-off_schemes<http://www.gromacs.org/Documentation/Cut-off_schemes>for some advance details. When you hear a call for alpha testers in the
> next few

months, you might want to spend some time on that so that you're sure
> GROMACS will best meet your future needs. :-)



>
>
> Mark
>
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-users<http://lists.gromacs.org/mailman/listinfo/gmx-users>
> Please search the archive at http://www.gromacs.org/**
> Support/Mailing_Lists/Search<http://www.gromacs.org/Support/Mailing_Lists/Search>before posting!
> Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/**Support/Mailing_Lists<http://www.gromacs.org/Support/Mailing_Lists>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20120613/e0b7f1ac/attachment.html>


More information about the gromacs.org_gmx-users mailing list