Yes, pmemd builds okay with netcdf for both pgi (tested on the cray xt3)
and
pathscale (tested on jacquard at nersc). I don't know what you guys are
doing to get all caps mod names out of sander; I saw it when I was doing
some benchmarking on jacquard I believe, but I perhaps incorrectly assume
I
am not the first to hit problems with sander. I managed to hack around it
by renaming mod files instead of doing it correctly. On pathscale, I
allow
the user to select one of two different options for name mangling, and the
selection also selects how I name my (few) internal c files. I was okay
on
jacquard, but that may be because the nersc folks chose the more
compatible
name mangling option; I don't remember which way it goes at utah vs.
nersc,
but they have the two options covered (ie., they do it differently; if it
can be done differently, it will...). By the way, on benchmarking, I ran
a
series of gb_mb benchmarks on an array of large platforms - sp5 (bassi),
opteron (jacquard), altix (cobalt), cray xt3 (bigben) as well as small p4
clusters; pmemd was outperforming sander at every single test point,
though
typically by no more than 10-15%, sometimes less (this is out to 128 procs
where practical). I'll post the benchmarks when I get time, but in the
meantime, kindly retest the released pmemd before stating that it is
slower
than sander for gb...
Thanks - Bob
----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: <amber-developers.scripps.edu>
Sent: Friday, March 31, 2006 11:14 AM
Subject: amber-developers: pathscale, gfortran and pgf90 problems
> On Fri, Mar 31, 2006, Thomas E. Cheatham, III wrote:
>>
>> p.s. DAC, I can get accounts for Ross and Mike if this will help with
>> pathscale access...
>
> Please do that. How about one for me?
>
> In general, you should try out pmemd as well (with the -bintraj option).
> Bob ostensibly has this stuff working for pathf90 and pgf90 compilers.
> Maybe that will provide a clue as to what you should do with
sander/ptraj.
>
>>
>> ** pentium, pgf90, -bintraj (configure -bintraj pgf90)
>>
>> -- bintraj.f cannot find typesizes.mod
>
> We need to find the cause of this problem. Is pgf90 naming its mod
files
> something different? What is the name of the netcdf mod file? Is there
> a "netcdf.mod" file in src/sander when bintraj is being compiled? Is
> there a NETCDF.mod file? The latter is trivial to fix: see how sgi_mips
> is handled.
>
>>
>> ** opteron, gfortran, -bintraj (configure -bintraj gfortran)
>>
>> -- mismatch with underscores between netcdf and amber
>> tried and did not work:
>> (1) remove -fno-second-underscore everywhere
>> (2) selectively add -fsecond-underscore
>> (3) change -Df2cfortrain to -DpgiFortran
>
> John may be able to help here. But again, some details would help.
What
> is an example of a mismatch? I never understood why the configure has
> -DPGIFortran anyway. Which version of gcc are you using?
>
>>
>> ** opteron | pentium, pathscale, -bintraj
>>
>> -- configure for netcdf fails; pathf90 does not produce an executable,
>> down the road you get messages like:
>>
>> make[4]: Entering directory
>>
`/uufs/inscc.utah.edu/common/home/cheatham/snapshot/icebox/pathscale-bintr
aj/amber9/src/netcdf/src/fortran'
>>
>> pathcc -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -O1
-I../libsrc
>> -DNDEBUG -DpgiFortran fort-attio.c
>> In file included from fort-attio.c:6:
>> ncfortran.h:27:42: NF_INT_IS_C_... not defined: No such file or
>> directory
>
> How about using gcc instead of pathcc?
>
>>
>> Problem 2: No setting of NETCDF.mod
>
> See the "netcdf" and "netcdflib" variables in configure. Can't you do
the
> same thing that is done for sgi_mips? (That compiler also creates
> NETCDF.mod
> rather than netcdf.mod.)
>
>>
>> SOLUTION4: Add NETCDF.mod:: dependency like netcdf.mod
>
> Where?? This is already done in src/sander/Makefile. It looks like it
is
> also
> needed in src/ptraj/Makefile.
>
>>
>> ** opteron | pentium, pathscale (-bintraj or no -bintraj)
>>
>> pathf90-1542 pathf90: WARNING XFORM_MPOLE_MATRIX, File =
>> _amoeba_multipoles.f, Line = 851, Column = 8
>> Initializing a named common block member in a program unit other than
a
>> block data is not legal for this architecture.
>>
>> data hind4 /1,2,3,2,3,1,3,1,2,2,3,3,3,3,2/
>> ^
>
> We get these on SGI as well, be they seem to not be fatal. The other
Tom
> has
> even less time than you do, so it's going to have to be a fatal error to
> get
> any attention from him.
>
>>
>> ** opteron, gfortran (no -bintraj)
>>
>> -- compiles fine, but test error with ./Run.noesy
>> [I do not know how to fix this]
>
> Same problem as with absoft: it apparently cannot read 2-dimensional
> arrays
> in a namelist, or the required syntax is different that I expect.
Someone
> could play with this, but I am frankly amazed that gfortran works at
> all....
>
> Can I assume you will be sending me patches?
>
> ...dac
>
> --
>
> ==================================================================
> David A. Case | e-mail: case.scripps.edu
> Dept. of Molecular Biology, TPC15 | fax: +1-858-784-8896
> The Scripps Research Institute | phone: +1-858-784-9768
> 10550 N. Torrey Pines Rd. | home page:
> La Jolla CA 92037 USA | http://www.scripps.edu/case
> ==================================================================
>
Received on Wed Apr 05 2006 - 23:49:32 PDT
