[gmx-developers] modifing nonbonded interactions

David van der Spoel spoel at xray.bmc.uu.se
Thu Oct 23 19:23:47 CEST 2008


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



More information about the gromacs.org_gmx-developers mailing list