Carlos -
I would go back and check on the different machines I have used, if I were
you. Do a short duplicate run on any machine (just 500-1000 steps should do
it), looking for any distinct differences (the trajectory should match for
at least 200-300 steps, depending on various factors of your simulation
(like shake tolerances, how close to equilibrium you were, etc.). What we
are dealing with here is a memory corruption, an overrun of the natex
(excluded atom list) buffer caused by certain conditions in certain systems
(ie., I am not sure this happens for all models, but I recently used one
where the size of the natex list clearly increased past the value of the
"next" variable in the prmtop). Tom D. had originally dimensioned this
stuff to 2*next to be able to double the list, so that in theory protected
him from problems (but now that I think of it, there might still be a
problem in sander...). I did not do the doubled list back into the original
structure, but had a different structure (something with actual record
structure, so it was more sophisticated) for the doubled list, so that is
how I got burned on this. So when the list overflows, there is no telling
what it overwrites. For ifort 8 on my workstations, it apparently overflows
onto things that don't matter, and when the natex list is deallocated in
pmemd with other unnecessary storage, a memory corruption is not noticed
(all tests pass, etc.). But you can't completely rule out that on some
machine with some compiler and some model, something would get overwritten
without causing a crash, but with some amount of data corruption. All this
is a longwinded way to say I would recommend some quick checks, just to be
sure... My best guess is you are okay, but it is only a best guess. Sorry
for the inconvenience.
Regards - Bob
----- Original Message -----
From: "Carlos Simmerling" <carlos.simmerling.gmail.com>
To: <amber.scripps.edu>
Sent: Sunday, August 31, 2008 9:54 AM
Subject: Re: AMBER: Critical patch for pmemd 10 extra points code
> Bob- just to clarify, is the only potential problem a crash? in other
> words, if we have run a lot of sims with this code and gotten no
> crash, is it ok or are the potential problems with the data?
> carlos
>
> On Thu, Aug 28, 2008 at 11:20 AM, Robert Duke <rduke.email.unc.edu> wrote:
>> I have discovered a bug in the pmemd 10 extra points code that will
>> probably
>> in most instances simply cause a segment violation crash, though you may
>> want to double check some of your old results. In initialization of
>> extra
>> points code, a prmtop-related data structure gets rewritten, and under
>> some
>> conditions, more space is needed than initially specified in the prmtop.
>> For
>> some compilers/hardware (like my workstations), the bug has no effect;
>> for
>> others so far I have observed a crash during initialization. I would
>> recommend applying the attached patch if you use the new extra points
>> capabilities (eg., tip4p water) for pmemd 10:
>>
>> Fix: Run this patch from the $AMBERHOME directory, with:
>> $ patch -p0 -N -r patch_rejects < pmemd10.patch1
>>
>> Sorry for any inconvienence; unfortunately testing just didn't expose
>> this
>> one. No other releases of pmemd are affected, and we will also get the
>> patch out on the amber website (amber.scripps.edu) soon.
>>
>> - Bob Duke
>>
>
>
>
> --
> ===================================================================
> Carlos L. Simmerling, Ph.D.
> Associate Professor Phone: (631) 632-1336
> Center for Structural Biology Fax: (631) 632-1555
> CMM Bldg, Room G80
> Stony Brook University E-mail: carlos.simmerling.gmail.com
> Stony Brook, NY 11794-5115 Web: http://comp.chem.sunysb.edu
> ===================================================================
> -----------------------------------------------------------------------
> The AMBER Mail Reflector
> To post, send mail to amber.scripps.edu
> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
> to majordomo.scripps.edu
>
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Wed Sep 03 2008 - 06:07:10 PDT
