[gmx-developers] Implementing a new type of VdW interaction

[Lee-Ping Wang]

Dear Mark,

>Why is such differentiation necessary? On what basis are some 
interactions going to do one thing, and others another?

It's because my new interaction is similar to Buckingham but the functional
form is different - there is no singularity at the origin.  Thus, a new set
of formulas are required for computing the interaction.  You are correct
that I only need to choose one functional form per simulation run, and I'm
using the "combination_rule" for slightly more than its intended purpose.  

To clarify, I don't check the combination_rule in the nonbonded kernel.
That is, I use the same ifunc but a different ivdw.  I added
combination_rule to mtop->ffparams (so it's on the same footing as fudgeQQ),
and in init_forcerec I pass the information to a new Boolean variable as you
suggest.  

In nonbonded.c, I set:

    else if(fr->bBHAM)
    {
      if (fr->bMyBHAM) {
        ivdw = 4;
      }
      else {
        ivdw = 2;
      }
    }

In force.c, I set:

    if (fr->nbfp == NULL) {
        fr->ntype = mtop->ffparams.atnr;
        fr->bBHAM = (mtop->ffparams.functype[0] == F_BHAM);
        fr->bMyBham = (fr->bBHAM && mtop->ffparams.combination_rule == 2);
// This is the line I added
        fr->nbfp  = mk_nbfp(&mtop->ffparams,fr->bBHAM);
    }

Thanks for answering my question.  Once I've tested the new interaction
function, and after we've agreed on whether the new interaction function is
a worthy addition to Gromacs, then I'll probably add a new ifunc.  

- Lee-Ping

-----Original Message-----
From: gmx-developers-bounces at gromacs.org
[mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Mark Abraham
Sent: Friday, May 06, 2011 8:37 AM
To: Discussion list for GROMACS development
Subject: Re: [gmx-developers] Implementing a new type of VdW interaction

On 6/05/2011 9:55 PM, Lee-Ping Wang wrote:
> Dear Mark,
>
>> If you've only got your modified form, then what's the problem with
> letting grompp do the combining? With or without a new VDW ifunc type?
>
> I do let grompp do the combining; that is, grompp does pass the combined
> parameters into mdrun.  Essentially I want to use the "combination_rule"
> integer for differentiating between two functional forms within the same
> ifunc.

Why is such differentiation necessary? On what basis are some 
interactions going to do one thing, and others another?

>> Defining a new interaction type is easy. Crafting combination rule
> machinery into mdrun when it's already found in grompp is hard. See the
> files I pointed out.
>
> Implementing a new ifunc is intrinsically not hard, I agree.  However, the
> "BHAM" ifunc is a bit unusual and if statements like "if (fr->bBHAM)"
appear
> everywhere in the code.  I thought it would be easier to use the existing
> "BHAM" ifunc, and use the combination_rule to trigger the new functional
> form.

No, because that's a barrier to high performance. The kernels other than 
the generic one are all hard-coded for a particular icoul and ivdw, and 
the neighbour lists are constructed to use a matching kernel. This is 
because branching when testing for the value of some integer in inner 
loops leads to terrible performance. nb_generic does such tests, but 
it's intended as a test bed for ideas, and/or reference code, not to run 
fast. Once the usefulness of a new ifunc -> ivdw type is demonstrated 
there, now it becomes reasonable to consider making it work fast, and 
accordingly you don't want to have to re-engineer the whole solution. So 
use a new ivdw and ifunc. Yes, you'll be doing similar things when 
fr->bBHAM is checked, but the performance and coding cost for testing 
fr->bYourBHAM where appropriate is negligible. Maybe only code that 
deals with setting and testing ivdw has to care that there are now two 
Buckingham-like interaction types.

> I will look into implementing a new ifunc, all the same.  It should be
> reasonable to turn on fr->bBHAM with more than one ifunc.  Maybe in the
end
> it will be the more natural solution. :)

Mark

> Thanks,
>
> - Lee-Ping
>
> -----Original Message-----
> From: gmx-developers-bounces at gromacs.org
> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Mark Abraham
> Sent: Friday, May 06, 2011 1:52 AM
> To: Discussion list for GROMACS development
> Subject: Re: [gmx-developers] Implementing a new type of VdW interaction
>
> On 5/05/2011 8:26 PM, Lee-Ping Wang wrote:
>> Dear Mark,
>>
>> Thanks for your help.  Last night, I did an early implementation that
>> doesn't use the tables.  I put the combination rule into "gmx_mtop_t" as
a
>> temporary solution.
>>
>> I do need a full implementation as the testing of my method will include
> an
>> automatic force-matching parameterization, which tunes the parameters
>> automatically (see my article on the method,
>> http://dx.doi.org/10.1063/1.3519043).
>>
>> I think I understand your explanation, but I can't find the combination
> rule
>> stored in idef.  The interaction type is indeed passed, but I need more
> than
>> that.
> You need "more than that" only if you want more than one VDW interaction
> functional form to be able to be used in the simulation system (e.g.
> normal Buckingham and your form).  And even if you do have multiple VDW
> functional forms (and it will not be easy to use any existing machinery
> to do this), it's already the job of grompp to do all the combining for
> all possible atom-type pairings, so the path of least resistance should
> be to make grompp do that for both functional forms, and mdrun only
> needs machinery to match the pre-combined parameters to the functional
form.
>
> If you've only got your modified form, then what's the problem with
> letting grompp do the combining? With or without a new VDW ifunc type?
>
>>     I wish to pass the combination rule in addition to the interaction
>> type, because it would be very convenient to use the existing "BHAM" type
>> rather than defining an entirely new one (Remark: I have implemented a
new
>> interaction type for fluctuating charge force fields; please let me know
> if
>> you're interested in adding this to the main version.)
> Defining a new interaction type is easy. Crafting combination rule
> machinery into mdrun when it's already found in grompp is hard. See the
> files I pointed out.
>
>> The reason is because my proposed interaction is Buckingham-like; it will
>> never be used at the same time as the normal Buckingham potential.  The
>> functional form is similar to Buckingham and the number of parameters is
> the
>> same, but there is no singularity at r=0.  This should allow us to model
>> somewhat softer repulsions without worrying about the singularity in the
>> normal Buckingham potential.  Also, the parameters are given using sigma,
>> epsilon, and gamma (a measure of the repulsive strength), which is a
> little
>> more intuitive than the combination of A, b, and c.
>>
>> Since the functional form is different, I need to add a new case
statement
>> in the nb_generic.c kernel, and I don't know how to do that without (1)
>> defining a new interaction type, which seems quite cumbersome or (2)
> passing
>> the combination rule from grompp into the forcerecord.
> By the time code gets into the kernels, the neighbour lists have been
> constructed pre-filtered for interaction type. See init_neighbor_list in
> src/mdlib/ns.c. You either have to hijack the existing Buckingham ivdw
> value, or craft a new one. Either way, I see no value in combining
> parameters in mdrun.
>
>> The head of my parameter file looks like this:
>>
>> [ defaults ]
>> 2    2    no        0.5  0.5
>>
>> [ atomtypes ]
>> H    1    1.0080    0.0000    A    2.655e-01  4.602e-01  1.000e+01
>> O    8   15.9950    0.0000    A    3.405e-01  5.648e-02  9.000e+00
>>
>> Note the second "two" in the defaults section, I want to use this as the
>> trigger for the new code.  Also note the order of magnitude of the
>> parameters, they are different than for the normal Buckingham
interaction.
> OK, so I infer you plan to have only this VDW interaction type available.
>
>> The relevant part of gmxdump looks like this:
>>
>>      ffparams:
>>         atnr=2
>>         ntypes=6
>>            functype[0]=BHAM, a= 3.40500000e-01, b= 5.64800000e-02, c=
>> 9.00000000e+00
>>            functype[1]=BHAM, a= 3.03000000e-01, b= 1.61220644e-01, c=
>> 9.50000000e+00
>>            functype[2]=BHAM, a= 3.03000000e-01, b= 1.61220644e-01, c=
>> 9.50000000e+00
>>            functype[3]=BHAM, a= 2.65500000e-01, b= 4.60200000e-01, c=
>> 1.00000000e+01
>>            functype[4]=MORSE, b0= 9.71554431e-02, cb= 2.76414222e+02,
beta=
>> 2.85560502e+01
>>            functype[5]=UREY_BRADLEY, theta= 1.15666551e+02, ktheta=
>> 3.64462646e+02, r13= 6.69829626e-02, kUB= 9.21828916e+03
>>         fudgeQQ              = 0.5
>>
>> I don't see the combination rule.  Am I looking in the wrong place?
> You're looking for the wrong thing. I said "grompp records [the
> parameters] together with their type". So above you have BHAM type
> (which later provokes the right ivdw type) with pre-combined parameters
> for O-O, O-H, H-O and H-H interactions (deduced from the values).
>
> I'm not sure why the hetero interactions are duplicated.
>
> Mark
>
>> Thanks!
>>
>> - Lee-Ping
>>
>> From: gmx-developers-bounces at gromacs.org
>> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Mark Abraham
>> Sent: Thursday, May 05, 2011 2:02 AM
>> To: Discussion list for GROMACS development
>> Subject: Re: [gmx-developers] Implementing a new type of VdW interaction
>>
>>
>>
>> On 05/05/11, Lee-Ping<leeping at MIT.EDU>   wrote:
>> Dear all,
>>
>> I would like to implement a new type of vdW interaction.  It's similar
>> to the Buckingham interaction, so I was thinking of adding the
>> interaction in nb_generic.c with ivdw set to 4.
>>
>> First, test the idea with the nonbonded interaction tables - see manual
> and
>> webpage. Don't get hands dirty unnecessarily
>>
>>
>>
>> ivdw will be set to four when the Buckingham interaction is turned on
>> with the combination rule set to 2 (currently this is unused).
>> Unfortunately, it seems like the integer corresponding to the
>> combination rule (comb) is used only in grompp, and when we get to mdrun
>> it is lost.
>>
>> For LJ parameters, I understand why this makes sense; because grompp
>> does all the parameter processing, and the nonbonded kernels always see
>> c6 and c12 and then apply the same formula; they don't care about the
>> user input because grompp takes care of all that.
>>
>> Right, but grompp records them together with their type. Check out
gmxdump
>> on a .tpr
>> and compare with stuff in src/gmxlib/ifunc.c
>>
>>
>>
>> Since my interaction function actually uses a different functional form,
>> I can't simply combine the parameters differently in grompp and pass
>> them into the Buckingham kernel.  I need a switch in the forcerecord
>> that decides between whether to call the normal Buckingham interaction
>> or my custom one.
>>
>> Use of Buckingham is triggered by mdrun noticing the types recorded in
the
>> .tpr, so you can do a similar thing.
>>
>> Mark
>>
>>
>> Is my analysis correct?  How do I pass the combination rule into "mdrun"
>> so I can trigger my custom VdW interaction?
>>
>> (My current idea is to add the variable into the main gmx_mtop_t
>> topology.  Please let me know if there's a better idea.)
>>
>> Thank you,
>>
>> - Lee-Ping
>>

-- 
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.