Hi!
One of our users have a input set that is generating "inf" in
the call vdinvsqrt(icount, cache_r2, cache_df) in short_ene line 392
This is caused by cache_r2 containing a 0 coming from the code in
ew_directp.h
delx = imagcrds(1,n) + xktran(1,itran)
dely = imagcrds(2,n) + xktran(2,itran)
delz = imagcrds(3,n) + xktran(3,itran)
delr2 = delx*delx + dely*dely+delz*delz
delr2 ends up as 0 which is of course < filter_cut2
This is then propagated to a NaN in the
cache_r2(1:icount) = dxdr*cache_df(1:icount) * cache_r2(1:icount)
(short_ene.F90 line 393)
This then propagates to
force(1,i) = force(1,i) - dumx
where dumx/y/z is NaN
And so are all the v.. variables, ee_vir_iso, and finally eedvir.
Eventually this problem propagates down to fill_charge_grid where
fr1/2/3 are all NaN, causing k0, j00, i00 to become 2147483645, or there
about, and finally i0 is used as index into q causing a segfault.
pmem (Amber16) is also throwing a segfault on the same input so i
suspect that the same type of code exists there.
I wonder if the delr2 < filter_cut2 in ew_directp.h should check that
delr2 != 0 too?
--
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: ake.hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14
Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri May 19 2017 - 01:00:02 PDT