Thursday May 30, 2002
Hi,
> > First of all it decides, autonomously, to open also the mdvel file (NB:
> > ntwv=0), and moreover it never writes anything in mdcrd and mden!
>
> Weird. Assuming that ntwv really is zero at the beginning, it sounds like
> something is being over-written in memory. The file open happens in
> routine OUTOPN() in dynlib.f. You might put some debugging statements there
> to trace what happens with the opens.
I'll try it.
What could the cause of this be?
Could it be a problem with some "mis-alignment" in commons, or stuff like that?
Again, I really don't know how the code change its behavior in this way,
without even being pushed to the limit.
Meanwhile, this is the input namelist:
------------------------------------------------------------------------------
#
# input file for SANDER ( MD )
# 1 1 1 1 1 1 1
1
&cntrl
timlim = 999999. , irest = 0, ibelly = 0, kform = 1, ichdna = 1,
imin = 0,ntx = 1,ntxo = 1,ig = $r,tempi =0.0,
heat = 0.0,ntb = 0,iftres = 1,nrun = 20,ntt = 5,temp0 = $j,
dtemp = 25.,
iewald = 0,
tautp = 0.2,tauts = 0.2,ntp = 0,pres0 = 1.0,comp = 44.6,taup = 0.2,
npscal = 0,ndfmin = 0,ntcm = 1,nscm = 1000,nstlim = 120000,init = 3,
ntu = 1,t = 0.0,dt = 0.005,ntc = 1,tol = 0.0005,ntf = 1,ntid = 0,
ntnb = 1,nsnb = 99999,idiel = 1,imgslt = 0,cut = 1000.0,scee = 1.2,
dielc = 1.0,ntpr = 1,ntwx = 1,ntwv = 0,ntwe = 1,ntwxm = 0,
ntwvm = 0,ntwem = 0,ioutfm = 0,ntr = 0,ntrx = 1,scnb = 10000.,
taur = 0., nmrmax = 0, isftrp = 0, rwell = 0., pencut = .01,
ivcap = 0,fcap = 0.0,
maxcyc = 50,ncyc = 10,ntmin = 1,dx0 = 0.01,dxm = 0.5,dele = 0.0001,
drms = 0.0001
&end
&wt type='END' &end
------------------------------------------------------------------------------
As you can see "ntwv = 0".
This set of parameters always worked fine, and it does work fine on other
proteins on the SAME machine, with the SAME executable!
> In this case, I would suggest just using the Fortran lapack libraries
> provided (i.e. don't use the optimized library). Sander doesn't make much
> use of LAPACK anyway, so there should not be much of a performance hit.
What about the 'blas' libraries?
Are they used a lot?
> You could also replace the amber "second()" routine with a different name
> whereever it occurs. We'll probably do that in the next release, to avoid
> name conflicts like the one you report.
I checked the occurrences of 'second' in the source tree.
Basically, there are 176 cases of "call second(TVAR)" and 2 like "VAR=second()".
Is there any difference between the plain "call second(VAR)" calls, and the
"VAR=second()" calls?
I mean, second is defined as a subroutine, and I did not know that one could
call a subroutine with this syntax, or in the latter case the program invokes
a different function.
Bottom line: if I decided to rename all the "second" in the source tree...
should I leave these few "VAR=second()" occurrences as they are?
Thank you very much.
Have a great day,
Giovanni
------------------------------------------------------------------------------
Dr. Giovanni Fossati +---------------------------+
Dept. of Physics and Astronomy, MS 108 | Ph : (713)-348-3425 |
Rice University | Fax : (713)-348-5143 |
6100 Main street, Houston, TX 77005, USA | e-mail: gfossati_at_rice.edu |
-------------------------------------------------+---------------------------+
Received on Thu May 30 2002 - 10:05:22 PDT
