[gmx-developers] modifing nonbonded interactions

[Berk Hess]

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