[gmx-developers] modifing nonbonded interactions

Berk Hess hessb at mpip-mainz.mpg.de
Thu Oct 23 17:21:15 CEST 2008 

Nazish Hoda wrote:
> Hi Berk,
>
> When the solvent is non-uniformly distributed around a molecule (say in a
> poor solvent).
> The dielectric constant in the close vicinity of the molecule is different
> from the far field value.
> This is the physical basis for it. I can not reveal much on an open forum
> regarding the problem.
> Since you have done a similar stuff in the past, I would be happy to discuss
> the problem with 
> you one-on-one. 
>   
I agree with that, although you should speak about dielectric permittivity.
But that the permittivity is different in space, does not mean that you 
can simply
determine the electrostatic interaction as 1/eps(r) r.
The real solution of the electrostatic equation is much more complex.
A clear artifact would be that two charges just beyond r1 would interact 
only
with eps_far, whereas nearly all the medium in between would have eps_near.

> I don't have a good grasp of the full Gromacs source code.
> Making a user table would require much more effort than what I am doing now.
> I want to make sure that the physics is accurately captured before I put
> such an effort.
>   
Making a table file with 7 columns is much simpler than what you are 
doing now.

Berk
> Thanks, Nazish.
>
> -----Original Message-----
> From: gmx-developers-bounces at gromacs.org
> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Berk Hess
> Sent: Thursday, October 23, 2008 10:13 AM
> To: Discussion list for GROMACS development
> Subject: Re: [gmx-developers] modifing nonbonded interactions
>
> Hi,
>
> I don't agree with distance dependent dielectric constants (constant 
> already says it here),
> but many people use it. There is no physical basis for having a distance 
> dependence.
>
> Things like this can be done easily in any functional form with user 
> tables (as long as they are
> distance dependent and not position dependent.
> You can use two epsilons and integrate the force to get a continuous 
> potential.
> But if you make a table, why not directly use tanh (even though I still 
> won't agree?
>
> Berk
>
> Nazish Hoda wrote:
>   
>> Hi Berk,
>>
>> I am doing the second one. I understand your point. But since this a point
>> discontinuity and 
>> the jump is not very huge, integration should not be a problem. More
>> accurate 
>> way of doing this is to use a ``tanh'' function. Which I might implement
>> later ?
>>
>> Thanks, Nazish.
>>
>>
>>
>> -----Original Message-----
>> From: gmx-developers-bounces at gromacs.org
>> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Berk Hess
>> Sent: Thursday, October 23, 2008 6:47 AM
>> To: Discussion list for GROMACS development
>> Subject: Re: [gmx-developers] modifing nonbonded interactions
>>
>> Hi,
>>
>> I don't understand exactly what you want to do here.
>> I can think of two (and maybe more) options:
>>
>> You want to have a different dieletric permittivity in different parts 
>> of space?
>> That requires a complex electrostatics solver that can handle this.
>>
>> r is a distance between particles i and j, in that case you would have a 
>> discontinuity
>> in the force at r_1, which is non-physical and causes problems with the 
>> integration.
>>
>> Berk
>>
>>
>> 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.
>>>
>>> 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?
>>>
>>> Thanks,
>>> Nazish.
>>>
>>> Quoting Mark Abraham <Mark.Abraham at anu.edu.au>:
>>>
>>>     
>>>       
>>>> Nazish Hoda wrote:
>>>>       
>>>>         
>>>>> Thanks for the suggestions.
>>>>> I figured out that some of these subroutines are written in
>>>>> assembly languages, which I have not changed. These are files with
>>>>> extension *.s. I have never done assembly language coding so I am
>>>>> trying to figure this out.
>>>>>
>>>>> These are subroutines in the directory nb_kernel_x86_64_sse and the 
>>>>> Readme file says it is SSE assembly language. If anyone has any 
>>>>> experience with this or knows about any good and easy to follow 
>>>>> reading resource that would
>>>>> be of great help.
>>>>>         
>>>>>           
>>>> Testing your idea in the C or FORTRAN generic kernels first is almost 
>>>> certainly a preferable strategy to learning an assembly language.
>>>>
>>>> There are several ways to force GROMACS not to use these assembly 
>>>> optimized routines - as you'd see in gmx_setup_kernels in 
>>>> src/gmx/nonbonded.c (per my last email) or by looking at the options 
>>>> to "configure".
>>>>
>>>> Also, if you're after useful help, telling people your objective will 
>>>> mean you're more likely to get advice in the right direction. Your 
>>>> first question pre-supposed that the right approach was to modify a 
>>>> generic non-bonded kernel. Already you seem to have learned that the 
>>>> assembly ones supersede them under some circumstances, so your first 
>>>> assumption was flawed. David suggested that you might be better 
>>>> served by using lookup tables if you're trying to modify the form of 
>>>> the nonbonded functions. If you want to benefit from others' 
>>>> expertise, don't constrain their scope by your assumptions :-)
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>       
>>>>         
>>> _______________________________________________
>>> 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 thewww 
>>> interface or send it to gmx-developers-request at gromacs.org.
>>>     
>>>       
>> _______________________________________________
>> 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.
>>
>>
>>
>> _______________________________________________
>> 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.
>>   
>>     
>
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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.
>

More information about the gromacs.org_gmx-developers mailing list