[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