[gmx-developers] modifing nonbonded interactions

Nazish Hoda nazish at umich.edu
Thu Oct 23 19:44:21 CEST 2008 

Yes, Nazish.

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