[gmx-developers] modifing nonbonded interactions

[Nazish Hoda]

> OK. While the simplest way to implement this is to modify the inner  
> loop of the kernels to do such a comparison, this will severely hurt  
> performance. If one was already dropping from the optimized kernels  
> to a generic kernel, then the additional drop is probably not so  
> severe, but I'd expect still noticeable.

This is what I have done. It is definetely slower. I am more  
interested in checking the physics. If this works then I will think of  
implementing the other idea you gave; that would require more effort.  
The big plan is to perform implict solvent simulations for charged  
systems that can mimic full atomistic simulations.

I have posted these queries on a regular basis for two weeks now,  
since I started to work on this. But no one use to respond. I did not  
wanted to
spend much time going through the full source code because I needed to
add just few lines. I was lucky today that I got some responses.

I would like to thank you once more, it really saved me lots of time, Nazish.


Quoting Mark Abraham <Mark.Abraham at anu.edu.au>:

> Nazish Hoda wrote:
>> Hi Mark,
>>
>> I really appreciate your help.
>> Let me first describe what I am planning to do.
>> I want to implement a position dependent dielectric constant:
>> \epsilon = \epsilon_near  r < r_1,
>> \epsilon = \epsilon_far   r > r_1.
>
> OK. While the simplest way to implement this is to modify the inner  
> loop of the kernels to do such a comparison, this will severely hurt  
> performance. If one was already dropping from the optimized kernels  
> to a generic kernel, then the additional drop is probably not so  
> severe, but I'd expect still noticeable.
>
> Much better would be to hijack the twin-range cut-off machinery to  
> create different groups of nonbonded interactions which get sent to  
> unmodified nonbonded kernels with different epsilon values. This way  
> the  distance test is done once per (charge-group) interaction  
> during the neighbour-searching, and you get to keep the optimized  
> kernels. See section 4.6.3 of the GROMACS 3.3 manual for some  
> introductory information.
>
> Better still would be to find that some other simulation code  
> already has such a mechanism implemented.
>
>> Regarding your suggestions, I now understand that I can force it  
>> not to use the optimized subroutines. Though I did not undertand  
>> what David means that I will be better served by using lookup  
>> tables; is he referring to the numbering scheme for LJ, Coloumbic,  
>> and water optimized functions, and how to use this information to  
>> refer to the correct kernel functions?
>
> They don't vary the kernels, that's the point. Once you supply a  
> table, the table-lookup kernels will be used. See section 6.6 of the  
> 3.3 manual. Such an approach isn't useful to you, since you want  
> what amounts to a different functional form depending on the value  
> of r. This underscores why you should have been describing your  
> objective, so that people trying to help you don't have to make  
> shots in the dark - or ignore you until you ask a "right" question  
> :-).
>
> Mark
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.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.
>
>
>