On Tue, Dec 3, 2013 at 1:21 AM, Timothy Giese <timothyjgiese.gmail.com>wrote:
> 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.
>
>
Sorry. I can say this more clearly.
atmlist is size natom
Every atom is a part of 1 sub-box
To fill atmlist, you must loop over each sub-box once, and insert each atom
from that sub-box into atmlist
By looping over each sub-box and each atom within each sub-box, you thus
have looped over all atoms once.
Alternatively, if you loop over a sub-box more than 1-time, then you are
double-counting atoms.
numlist is the current number of atoms that have been looped over.
If the same sub-box is encountered more than 1 time, then numlist will
become greater than natom.
The error from valgrind thus appears when numlist is used to index atmlist,
but the problem is not
atmlist nor numlist, but the number of times that the loop is encountered.
Phew. OK. I think that's more clear.
-Tim
> 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 - 23:00:03 PST
