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

[Mark Abraham]

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.