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

Mark Abraham mark.j.abraham at gmail.com
Wed Jul 3 09:59:00 CEST 2013


Sure, a conducting medium is an interesting special case. Of course,
once you're there, modelling electrostatics at all is a waste of time.

Mark

On Tue, Jul 2, 2013 at 4:58 PM, Mark Tianwu Zang <zangtw at gmail.com> wrote:
> 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.
>
>
>
> --
> 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.



More information about the gromacs.org_gmx-developers mailing list