[gmx-developers] Re: Segmentation fault switching from group to verlet cutoff shceme

[Berk Hess]

Hi,

To be more specific, you need to change lines 323 and 326 of 
src/mdlib/nbnxn_cude/nbnxn_cuda_kernel.cuh
F_invr  = inv_r6 * (c12 * inv_r6 - c6) * inv_r2;
E_lj_p  = int_bit * (c12 * (inv_r6 * inv_r6 - lj_shift * lj_shift) * 
0.08333333f - c6 * (inv_r6 - lj_shift) * 0.16666667f);

As I said, it might be an issue that you only have c6 and c12 available 
as parameters.
If for your case you can live with just one (combined) parameter for 
repulsion, you can (mis-)use c12 for that.
Use exp() for exponent and add f to floats, i.e. not 1.0, but 1.0f

Cheers,

Berk

On 03/17/2013 06:48 PM, hess at kth.se wrote:
> Hi,
>
> I didn't mean to say "drop" when I said low priority.
> Changing GPU kernels is nearly trivial and much easier than changing 
> optimized CPU kernels. The main work for most special types of 
> interactions is passing the parameters. If you can live with just two 
> variable parameters, like LJ, for your Buckingham application, 
> implementing this is very easy.
>
> Cheers,
>
> Berk
>
>
> ----- Reply message -----
> From: "David van der Spoel" <spoel at xray.bmc.uu.se>
> To: "Discussion list for GROMACS development" <gmx-developers at gromacs.org>
> Subject: [gmx-developers] Re: Segmentation fault switching from group 
> to verlet cutoff shceme
> Date: Sun, Mar 17, 2013 17:33
>
>
> On 2013-03-17 17:08, Bu wrote:
> > David van der Spoel wrote
> >> On 2013-03-16 23:24, Bu Wang wrote:
> >>> Hi Berk,
> >>>
> >>> It might be rare in biological simulations, but for simulations of
> >>> inorganic materials, it is very common. I think it is a shame that the
> >>> scope of GROMACS is limited to biomaterials. Lots of researches in my
> >>> field could benefit from the GROMACS' efficiency and 
> functionality. And
> >>> some small improvements would enable that.
> >>>
> >>> Anyway, I guess we will have to invest some effort to figure this out
> >>> ourselves. To help us get started, do we need cuda programing
> >>> experiences to modify this part of the code?
> >>
> >> How about support for tables on GPU?
> >
> > That would be great. We do use other non-bonded potential forms. But 
> I hope
> > you are not suggesting that Buckingham as a standard non-bonded 
> potential
> > will be dropped in the future versions of GROMACS. If user defined 
> potential
> > can be supported, adding Buckingham as a standard potential would 
> not be a
> > big hassle, right?
> No, rather the diversity will be increased. However I know nothing about
> GPU programming and for me this has low priority, now anyway, although
> this may change if multicore chips and GPUs become more commonplace.
>
> In particular I am interested in the Buckingham variant in this paper
> http://pubs.acs.org/doi/abs/10.1021/ct300826t as it does not have the
> singularity at short distance.
>
> >
> >
> >
> > --
> > View this message in context: 
> http://gromacs.5086.n6.nabble.com/Segmentation-fault-switching-from-group-to-verlet-cutoff-shceme-tp5006353p5006386.html
> > Sent from the GROMACS Developers Forum mailing list archive at 
> Nabble.com.
> >
>
>
> -- 
> David van der Spoel, Ph.D., Professor of Biology
> Dept. of Cell & Molec. Biol., Uppsala University.
> Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.
> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130318/d9b9dcc7/attachment.html>