[gmx-developers] Re: Segmentation fault switching from group to verlet cutoff shceme
hess at kth.se
Mon Mar 18 15:19:42 CET 2013
To be more specific, you need to change lines 323 and 326 of
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
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
On 03/17/2013 06:48 PM, hess at kth.se wrote:
> 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.
> ----- 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
> > will be dropped in the future versions of GROMACS. If user defined
> > 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:
> > Sent from the GROMACS Developers Forum mailing list archive at
> 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
> 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...
More information about the gromacs.org_gmx-developers