> I'm hoping that this fixes Lachele's problems, as far as bugs in the code
> are concerned.
Yes, and no. Since using ntb=1 gave me a "vacuum rift" ("vacuum bubble" hardly seems a sufficient term), I tried the minimization with ntb=0. And... I can get it to run using the serial version or using the MPI version with only one processor. But, with 2 or 4 processors the run hangs. No complaint. Just hangs. The different MIN.in variants are copied below. Here is a summary of run behavior. This uses the same top & crd files I've sent before.
ntb=0 serial version, 14,000 cycles, 842.86 seconds total
ntb=0 MPI version with np=1, 14,000 cycles, 819.30 seconds
ntb=0 MPI version with np=4, 14 cycles, 0.55 seconds
ntb=0 MPI version with np=4, 14,000 cycles, 2h23m and counting, at step 1
ntb=0 MPI version with np=2, 14,000 cycles, 1h33m and counting, at step 1,400 since <= 4m
ntb=1 MPI version with np=4, 14,000 cycles, 677.49 seconds
Somehow, I get the feeling this is another one of those things that can only happen to me because I'm the only one capable of making just the right typo at just the right stage... Does this happen for anyone else? It's all the same input except that the 14-cycle versions also have ncyc cut from 5,000 to 5 (see below).
> The other weird behavior reported may actually be a correct
> result -- but please chime in if you think there are remaining problems.
Yeah... so I think the calculation is right, but I'm a little puzzled by the starting structure. I just had leap solvate a water molecule using "solvatebox m TP5 10". The resulting box has a density of 0.622 g/cc, according to leap. Should it be that low? That certainly explains the minimization -- the box needs half again as many water molecules in it just to come close to the normal density of water. Am I missing something? I guess there might be reasons this low density is desirable or practical, but it does make minimization using periodic conditions a bit problematic, as I recently found. The reason my other jobs were failing was because the system had become so incredibly inhomogeneous from the minimization.
Here are my MIN.in files -- maybe there is something set wrong?
::::::::::::::
MIN.in
::::::::::::::
Standard minimization protocol (constant volume only, NO shake!)
&cntrl
imin = 1, maxcyc = 14000, ntmin=1, ncyc = 5000,
ntb=0, ntp = 0, ntpr=200,
dielc = 1,SCNB=1.0, SCEE=1.0,
cut = 10.0, nsnb = 25,
icfe=0,
&end
::::::::::::::
MIN.in_ntb1
::::::::::::::
Standard minimization protocol (constant volume only, NO shake!)
&cntrl
imin = 1, maxcyc = 14000, ntmin=1, ncyc = 5000,
ntb=1, ntp = 0, ntpr=200,
dielc = 1,SCNB=1.0, SCEE=1.0,
cut = 10.0, nsnb = 25,
icfe=0,
&end
::::::::::::::
MIN_short.in
::::::::::::::
Standard minimization protocol (constant volume only, NO shake!)
&cntrl
imin = 1, maxcyc = 14, ntmin=1, ncyc = 5,
ntb=0, ntp = 0, ntpr=1,
dielc = 1,SCNB=1.0, SCEE=1.0,
cut = 10.0, nsnb = 25,
icfe=0,
&end
:-) Lachele
--
B. Lachele Foley, PhD '92,'02
Assistant Research Scientist
Complex Carbohydrate Research Center, UGA
706-542-0263
lfoley.ccrc.uga.edu
----- Original Message -----
From: David A. Case
[mailto:case.biomaps.rutgers.edu]
To: amber-developers.scripps.edu
Sent:
Wed, 12 Nov 2008 09:31:29 -0500
Subject: amber-developers: fixup to max14
> I've committed Volodymyr's patch to extra_pts.f to the amber11 tree
> (sorry--I
> deleted his original email.) Also rationalized allocations based on max11,
> max12 and max13 as well.
>
> I'm hoping that this fixes Lachele's problems, as far as bugs in the code
> are
> concerned. The other weird behavior reported may actually be a correct
> result -- but please chime in if you think there are remaining problems.
>
> Thanks to those who worked on this. (And to Volodymyr in particular for
> pitching in to help on a lot of recent problems.)
>
> ...dac
>
>
Received on Fri Dec 05 2008 - 14:34:21 PST
