[gmx-developers] function gmx_pme_do will cause segmentation fault for mdp option: epsilon-r=0

[Mark Tianwu Zang]

Hi Mark,
Thanks for the response. I found that problem when I tried to see how
system will behave with a time-dependent dielectric constant. I added some
pieces of code to let the coefficient change with time, and although the
function is totally "virtual" in my case, I think there are some systems in
nature corresponding to an infinite dielectric constant(like prefect
conductor).


On Tue, Jul 2, 2013 at 6:36 AM, Mark Abraham <mark.j.abraham at gmail.com>wrote:

> The real question is what you were trying to achieve with epsilon_r =
> 0 and coulombtype= PME?
>
> Mark
>
> On Tue, Jul 2, 2013 at 10:53 AM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
> > Thanks for the report. It turns out the problem is much more
> > pervasive. I have opened http://redmine.gromacs.org/issues/1297
> > accordingly.
> >
> > I would guess that you can wrap a similar test for zero around the
> > lines that inappropriately divide by zero and achieve what you want.
> > Clearly, this has not been tested!
> >
> > Mark
> >
> > On Mon, Jul 1, 2013 at 11:23 PM, Mark Tianwu Zang <zangtw at gmail.com>
> wrote:
> >> Dear all,
> >> I found that in force.c line 1324(for gromacs-4.5.7) or line 1966(for
> >> gromacs-4.6.2), a variable called "eterm"(for gromacs -4.5) or elfac(for
> >> gromacs-4.6) is defined as
> >>
> >> eterm = ONE_4PI_EPS0/pme->epsilon_r*tmp1[kx]*denom[kx];
> >>
> >> or
> >>
> >> elfac = ONE_4PI_EPS0/pme->epsilon_r;
> >>
> >> where pme->epsilon_r = ir->epsilon_r, which corresponds to the mdp
> option:
> >> epsilon-r.
> >> I have not tested on gromacs-4.6 yet but I have already tested on
> >> gromacs-4.5, and as expected, if epsilon-r is made zero in *.mdp, a
> >> segmentation fault will appear at function gmx_pme_do. (Since the two
> pieces
> >> of code above are almost the same, I think I probably get the same
> result
> >> for groamcs-4.6).
> >> The physical meaning of epsilon-r=0 is that I am only interested in an
> >> infinite dieletric system(no Coulomb interactions despite non-zero
> charges).
> >>
> >> On the other hand, in forcerec.c:2623(version 4.5) or 1609(verion 4.6),
> >> there is another factor: fr->epsfac defined as below:
> >>
> >> if(fr->epsilon_r != 0)
> >>  fr->epsfac = ONE_4PI_EPS0/fr->epsilon_r;
> >> else
> >>  fr->epsfac = 0;
> >>
> >> which has already considered this possible situation.
> >>
> >> However, although the meaning of fr->epsfac is the same as the ones of
> >> variable eterm(the first half) and elfac, this factor (fr->epsfac) will
> only
> >> be used for calculating non-bonded (short-range) Coulomb interaction,
> bonded
> >> 1-4 Coulomb interaction and long-range interaction using reaction field
> >> method. For long-range interaction using PME/Ewald method, fr->epsfac
> will
> >> never be used, and the introduction(actually recalculation..) of
> eterm/elfac
> >> causes the failure of computing PME.
> >>
> >> Thanks,
> >> -Mark
> >>
> >>
> >>
> >> --
> >> gmx-developers mailing list
> >> gmx-developers at gromacs.org
> >> http://lists.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://lists.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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130702/31a2f174/attachment.html>