[gmx-developers] modifing nonbonded interactions
David van der Spoel
spoel at xray.bmc.uu.se
Thu Oct 23 20:40:20 CEST 2008
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
More information about the gromacs.org_gmx-developers
mailing list