Dear Jason,
Following your advices, we changed the amber12 code to be able to run it
with systems that have more than 60 atom types.
Here is the list of the changes we made :
- in parms.F90 :
line 12 : BC_PARMR 46150 (instead of 24560)
line 30-35 : size of arrays cn1, cn2, cn3, cn4, cn5 : 5050 instead of 1830
- in rdparm.F90
line 108 nttyp > 5050 (instead of 1830)
It runs fine when we run on 2 cores (1 per VB state), but as soon as we
try to run on more (e.g. 4 cores, 16 cores), it crashes. We did a test
with exactly the same system, the same input files and job files, and it
runs fine on 2 cores but it crashes on 4. that is the typical error we get
:
"node14:31240] *** Process received signal ***
[node14:31240] Signal: Segmentation fault (11)
[node14:31240] Signal code: Address not mapped (1)
[node14:31240] Failing at address: 0x20990af74"
We first thought it was a problem with the compilation, but we did a test
on a different system, containing less than 60 atom types, using the same
sander.MPI, the same modules, and it runs totally fine on 16 cores. That
is why we think it may again be an issue with having more than 60 atom
types.
Could you please help us to find out where it could come from ?
Thank you again for your help,
Elise Duboué-Dijon
> On Tue, Nov 27, 2012 at 9:32 AM, Elise Duboué-Dijon <
> elise.duboue-dijon.ens.fr> wrote:
>
>> Dear Jason,
>>
>> Thank you very much for drawing our attention to this point.
>> We just have one additional question: with respect to amber11, in
>> amber12
>> the
>> 'rparms' common block now includes the cn3, cn4 and cn5 arrays but the
>> BC_PARMR
>> value has not changed. Is this normal ?
>> Thank you again for your help.
>>
>
> I actually just noticed this when responding in another thread earlier
> today. I'll repeat myself here since you were (understandably) most
> likely
> not following that other thread:
>
> If you plan to use sander.MPI, though, you will also have to change the
> value of BC_PARMR from 24560 to the sum of all array lengths in the rparms
> common block. (It's actually incorrect right now, it should be 30050 in
> order for the 'new vdw model' to work in parallel).
>
> However, I don't know that CN3, CN4, or CN5 are used or tested outside of
> PB simulations in sander (it was a PBSA dev that added that code). Since
> PB simulations don't run in parallel inside sander, this 'bug' would never
> really surface.
>
> HTH,
> Jason
>
> FWIW, I fixed that bug in the developer branch, although hopefully that
> whole common block structure with hard-coded array lengths will be
> replaced
> with variable length (dynamically-allocated) arrays for the next release.
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Feb 28 2013 - 06:30:03 PST
