On Tue, Dec 3, 2013 at 12:59 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> Hi,
>
> I was able to reproduce the segfault using code compiled from a recent GIT
> pull, using the same system (110 TIP3P waters) but different input. The
> error occurs in the same place (nonbond_list.F90:860) but I don't think the
> problem is in the calculation of jj, at least not in my case (otherwise
> valgrind would complain about nlogrid and nhigrid). The issue appears to be
> that atmlist is allocated for total number of atoms (natom), but in some
> cases the indexing variable numlist becomes greater than natom (note that
> an error is triggered for array itran also, which fits).
>
>
I thought that at first too, but then I convinced myself that they really
are intended to be size natom.
The jj's index "little sub-boxes" and the m1,m2 iterate over atoms within
the sub-box.
The problem is not "the value of jj is out of range". The problem is that
a value of jj should
be considered only once, but it is encountering the same jj's multiple
times.
The nlogrid and nhigrid arrays provide the atom indexes within a sub-box
and their
usage for inserting natom elements into atmlist and itran is consistent
with what appears
in the "upper-part" of if IF-block we are discussing.
> run a system with pmemd that segfaulted with sander it either finishes
nicely or complains about the parameters and exits gracefully.
>
>
My main concern is what happens in constant pressure simulations.
If the smallest box length instantaneously fluctuates below 3x the cutoff
at the time the nonbond list is generated, does that mean the simulation
should be considered invalid from that point on?
If that's the case, I'd prefer a segfault or a straight IF ( UH-OH ) STOP
than
have possibly-hard-to-detect garbage.
It's not even clear to me that a segfault would necessarily occur in the
state
that it is in. Maybe it will segfault if it is overwriting memory in a
mis-aligned way,
but it will "gracefully" continue if not. Maybe it's compiler dependent
too.
I notice that when I run it in valgrind, valgrind will keep it going and
you start
to see "vlimit" warnings. Maybe intel compilers will act similarly.
> All this being said, no 'legal' combo of input/topology/coordinates should
> generate a segfault. I think the long-term solution may be adding some
> extra checks for unit cell params + cutoff size to sander along the lines
>
Yeah. Keeping in mind that the unit cell params can change....
>
> PS - Is there a specific reason you are explicitly setting ewald
> parameters? In general the code tries to pick optimal values. Using
> NFFTX=30 for a small system and/or order=6 will certainly slow your
> calculations down for I think not much benefit.
>
>
Yes. Yes, there is ;)
-Tim
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Dec 02 2013 - 22:30:04 PST
