[gmx-developers] modifing nonbonded interactions

Nazish Hoda nazish at umich.edu
Thu Oct 23 21:55:11 CEST 2008 

This is what I am thinking. I know it is an approximation, but I don't know
how bad would this be.
Let me know what you people think.
In PME,
E_coul = E_coul^SR +  E_coul^LR. (and the same holds for force) 

My cut off for dielectric permittivity, which I call r_1, is very small, and
would 
only affect E_coul^SR (F_coul^SR). So what I think is that just changing
E_coul^SR (F_coul^SR) 
might work. 
 


-----Original Message-----
From: gmx-developers-bounces at gromacs.org
[mailto:gmx-developers-bounces at gromacs.org] On Behalf Of David van der Spoel
Sent: Thursday, October 23, 2008 2:40 PM
To: Discussion list for GROMACS development
Subject: Re: [gmx-developers] modifing nonbonded interactions

Nazish Hoda wrote:
> Yes, Nazish.
Not possible. Since your LR function is 1/r and your "coulomb" function 
is 1/r^2, the SR would have to be 1/r^2-1/r which is not short range 
anymore.

Distance dependent dielectric is completely non-physical, the energy 
becomes a force and the force the curvature of the potential... Why not 
use a RF (pretty bad but at least with some physical background) or 
normal PME?
> 
> -----Original Message-----
> From: gmx-developers-bounces at gromacs.org
> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of David van der
Spoel
> Sent: Thursday, October 23, 2008 1:43 PM
> To: Discussion list for GROMACS development
> Subject: Re: [gmx-developers] modifing nonbonded interactions
> 
> Nazish Hoda wrote:
>> Thanks! I got your point.
>> Can I now do PME ? Nazish.
> PME with distance-dependent dielectric?
> 
>>
>> -----Original Message-----
>> From: gmx-developers-bounces at gromacs.org
>> [mailto:gmx-developers-bounces at gromacs.org] On Behalf Of David van der
> Spoel
>> Sent: Thursday, October 23, 2008 1:24 PM
>> To: Discussion list for GROMACS development
>> Subject: Re: [gmx-developers] modifing nonbonded interactions
>>
>> Nazish Hoda wrote:
>>>> 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.
>>>
>>> That is true. This is a poor approximation in the outer shell close to
>> r_1. 
>>> For r>r_1, this effect would be very small (r_1 is small).  
>>>
>>>> Making a table file with 7 columns is much simpler than what you are 
>>>> doing now.
>>> I will try this. Though, I don't know from which subroutine do I need to
>>> call this table file. 
>>>
>> If you make a table you don't need to write any code because it is 
>> already there! Check the example tables in your distribution 
>> (share/gromacs/top).
>>
>>> 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 11:21 AM
>>> To: Discussion list for GROMACS development
>>> Subject: Re: [gmx-developers] modifing nonbonded interactions
>>>
>>> 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.
>>>>   
>>> _______________________________________________
>>> 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.
>>
> 
> 


-- 
David van der Spoel, Ph.D., Professor of Biology
Molec. Biophys. group, Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205. Fax: +4618511755.
spoel at xray.bmc.uu.se	spoel at gromacs.org   http://folding.bmc.uu.se
_______________________________________________
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