<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      To be more specific, you need to change lines 323 and 326 of
      src/mdlib/nbnxn_cude/nbnxn_cuda_kernel.cuh<br>
      F_invr&nbsp; = inv_r6 * (c12 * inv_r6 - c6) * inv_r2;<br>
      E_lj_p&nbsp; = int_bit * (c12 * (inv_r6 * inv_r6 - lj_shift * lj_shift)
      * 0.08333333f - c6 * (inv_r6 - lj_shift) * 0.16666667f);<br>
      <br>
      As I said, it might be an issue that you only have c6 and c12
      available as parameters.<br>
      If for your case you can live with just one (combined) parameter
      for repulsion, you can (mis-)use c12 for that.<br>
      Use exp() for exponent and add f to floats, i.e. not 1.0, but 1.0f<br>
      <br>
      Cheers,<br>
      <br>
      Berk<br>
      <br>
      On 03/17/2013 06:48 PM, <a class="moz-txt-link-abbreviated" href="mailto:hess@kth.se">hess@kth.se</a> wrote:<br>
    </div>
    <blockquote cite="mid:514601fc.ea67700a.42af.ffffbbd0@mx.google.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <span style="font-family: Arial;">Hi,<br>
        <br>
        I didn't mean to say "drop" when I said low priority.<br>
        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.<br>
        <br>
        Cheers,<br>
        <br>
        Berk<br>
        <br>
        <br>
        ----- Reply message -----<br>
        From: "David van der Spoel" <a class="moz-txt-link-rfc2396E" href="mailto:spoel@xray.bmc.uu.se">&lt;spoel@xray.bmc.uu.se&gt;</a><br>
        To: "Discussion list for GROMACS development"
        <a class="moz-txt-link-rfc2396E" href="mailto:gmx-developers@gromacs.org">&lt;gmx-developers@gromacs.org&gt;</a><br>
        Subject: [gmx-developers] Re: Segmentation fault switching from
        group to verlet cutoff shceme<br>
        Date: Sun, Mar 17, 2013 17:33<br>
        <br>
      </span><br>
      On 2013-03-17 17:08, Bu wrote:<br>
      &gt; David van der Spoel wrote<br>
      &gt;&gt; On 2013-03-16 23:24, Bu Wang wrote:<br>
      &gt;&gt;&gt; Hi Berk,<br>
      &gt;&gt;&gt;<br>
      &gt;&gt;&gt; It might be rare in biological simulations, but for
      simulations of<br>
      &gt;&gt;&gt; inorganic materials, it is very common. I think it is
      a shame that the<br>
      &gt;&gt;&gt; scope of GROMACS is limited to biomaterials. Lots of
      researches in my<br>
      &gt;&gt;&gt; field could benefit from the GROMACS' efficiency and
      functionality. And<br>
      &gt;&gt;&gt; some small improvements would enable that.<br>
      &gt;&gt;&gt;<br>
      &gt;&gt;&gt; Anyway, I guess we will have to invest some effort to
      figure this out<br>
      &gt;&gt;&gt; ourselves. To help us get started, do we need cuda
      programing<br>
      &gt;&gt;&gt; experiences to modify this part of the code?<br>
      &gt;&gt;<br>
      &gt;&gt; How about support for tables on GPU?<br>
      &gt;<br>
      &gt; That would be great. We do use other non-bonded potential
      forms. But I hope<br>
      &gt; you are not suggesting that Buckingham as a standard
      non-bonded potential<br>
      &gt; will be dropped in the future versions of GROMACS. If user
      defined potential<br>
      &gt; can be supported, adding Buckingham as a standard potential
      would not be a<br>
      &gt; big hassle, right?<br>
      No, rather the diversity will be increased. However I know nothing
      about <br>
      GPU programming and for me this has low priority, now anyway,
      although <br>
      this may change if multicore chips and GPUs become more
      commonplace.<br>
      <br>
      In particular I am interested in the Buckingham variant in this
      paper <br>
      <a class="moz-txt-link-freetext" href="http://pubs.acs.org/doi/abs/10.1021/ct300826t">http://pubs.acs.org/doi/abs/10.1021/ct300826t</a> as it does not have
      the <br>
      singularity at short distance.<br>
      <br>
      &gt;<br>
      &gt;<br>
      &gt;<br>
      &gt; --<br>
      &gt; View this message in context:
<a class="moz-txt-link-freetext" href="http://gromacs.5086.n6.nabble.com/Segmentation-fault-switching-from-group-to-verlet-cutoff-shceme-tp5006353p5006386.html">http://gromacs.5086.n6.nabble.com/Segmentation-fault-switching-from-group-to-verlet-cutoff-shceme-tp5006353p5006386.html</a><br>
      &gt; Sent from the GROMACS Developers Forum mailing list archive
      at Nabble.com.<br>
      &gt;<br>
      <br>
      <br>
      -- <br>
      David van der Spoel, Ph.D., Professor of Biology<br>
      Dept. of Cell &amp; Molec. Biol., Uppsala University.<br>
      Box 596, 75124 Uppsala, Sweden. Phone: +46184714205.<br>
      <a class="moz-txt-link-abbreviated" href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a> &nbsp; &nbsp;<a class="moz-txt-link-freetext" href="http://folding.bmc.uu.se">http://folding.bmc.uu.se</a><br>
      -- <br>
      gmx-developers mailing list<br>
      <a class="moz-txt-link-abbreviated" href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
      <a class="moz-txt-link-freetext" href="http://lists.gromacs.org/mailman/listinfo/gmx-developers">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
      Please don't post (un)subscribe requests to the list. Use the <br>
      www interface or send it to <a class="moz-txt-link-abbreviated" href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>