Ross -
I agree it is a good goal. I don't think it is all that doable due to
emphasis on different platforms, optimizations, etc. SO for me it is not
now a priority. It really is NOT that hard to read the paragraph that
configure throws at you and figure it out. Very regular pattern. I WILL
try to consider using some of the same names though, where it does not get
me in trouble.
Regards - Bob
----- Original Message -----
From: "Ross Walker" <ross.rosswalker.co.uk>
To: <amber-developers.scripps.edu>
Sent: Thursday, January 19, 2006 2:36 PM
Subject: RE: amber-developers: Fw: PMEMD 9 beta checkin
> Dear all,
>
> With regards to the configure options, would it be possible to
synchronise
> pmemd and amber9 such that the options are pretty much the same. This
will
> confuse users less.
>
> E.g. for ifort on em64t we use
>
> ./configure ifort_em64t
>
> for opteron one can use ifort_opteron and for amd64 ifort_amd64
>
> Although these 2 options are just aliases to em64t as the compiler
options
> are the same for all 3 platforms.
>
> For regular P4/AMD we use ifort_ia32 and for Itanium we use ifort_ia64
>
> All the best
> Ross
>
> /\
> \/
> |\oss Walker
>
> | Department of Molecular Biology TPC15 |
> | The Scripps Research Institute |
> | Tel: +1 858 784 8889 | EMail:- ross.rosswalker.co.uk |
> | http://www.rosswalker.co.uk | PGP Key available on request |
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may
not
> be read every day, and should not be used for urgent or sensitive
issues.
>
>> -----Original Message-----
>> From: owner-amber-developers.scripps.edu
>> [mailto:owner-amber-developers.scripps.edu] On Behalf Of Robert Duke
>> Sent: Thursday, January 19, 2006 09:09
>> To: amber-developers.scripps.edu
>> Subject: amber-developers: Fw: PMEMD 9 beta checkin
>>
>> Folks -
>> My mail system said this message was dropped on the floor, so
>> I am retrying;
>> apologies if this constitutes a double-send. - Bob
>>
>> ----- Original Message -----
>> From: "Robert Duke" <rduke.email.unc.edu>
>> To: <amber-developers.scripps.edu>
>> Sent: Thursday, January 19, 2006 11:57 AM
>> Subject: PMEMD 9 beta checkin
>>
>>
>> > Folks -
>> > As Dave Case posted yesterday, I finally did a code drop of
>> the pmemd 9
>> > beta
>> > source. I of course immediately found a couple of problems
>> in testing, so
>> > you need to resync to the source code tree as of late this
>> morning (11:30
>> > EST) (chagall currently is very, very slow). The fixes are
>> 1) a fix in
>> > runmd.fpp to get proper vels in mdvel/restrt under pme when
>> printing of
>> > these files coincides with a COM motion removal step (this
>> was broken
>> > hacking GB into pmemd - it is a relatively minor error you
>> are unlikely to
>> > see, or recognize as a problem if you do, but pick up the
>> fix anyway :-))
>> > 2) rbornstat support was not actually complete, but now is
>> - fixes in
>> > runmd.fpp, gb_ene.fpp, and 3) and trivial printout fix to
>> list alpb in the
>> > mdout (alpb use not yet actually supported).
>> >
>> > Okay, this pmemd drop mostly has:
>> >
>> > 1) Lots of speedup/scaling enhancements for pme.
>> > 2) Various compatibility fixes to match sander 9 behaviour.
>> > 3) Support for Generalized Born, igb versions 1, 2, 5.
>> > 4) Dual cutoffs support - instead of "cut" in the mdin ctrl
>> section, you
>> > can
>> > specify separate vdw_cutoff and es_cutoff, with it understood (and
>> > enforced)
>> > that vdw_cutoff >= es_cutoff. This is a small performance
>> enhancement,
>> > mostly intended to eventually support amoeba.
>> > 5) fftw 3 support. Use double precision fftw of course.
>> This supports
>> > prime factors of 2, 3, 5, and 7 (the 7 is the difference)
>> and should allow
>> > better grid fitting. The auto grid algorithm is a bit more
>> aggressive
>> > about
>> > targetting a grid density of >= 1.0 grids/angstrom by
>> default (so you may
>> > get finer grids and lower pme recip space error); you can also now
>> > directly
>> > specify your fft grid density (as fft_grids_per_ang) in the
>> mdin &ewald
>> > namelist.
>> > 6) There is a -l command line option to name the logfile,
>> and better time
>> > reporting overall. The -l option is mostly useful if you
>> are doing a
>> > bunch
>> > of concurrent runs in one dir (say you are benchmarking...).
>> >
>> > Building -
>> >
>> > In dir pmemd, do a "configure -help".
>> > Do what it says. If you have one of the new 64 bit intel
>> machines (em64t)
>> > and ifort, tell the configure script that you are a
>> linux64_opteron with
>> > ifort. The linux_p4 config files apply to 32 bit machines
>> with a 32 bit
>> > OS.
>> > I'll fix this before long... (waiting to get around to
>> actually using my
>> > em64t machine) If you want to use gfortran or g95, I
>> don't yet support
>> > them; I am not opposed to adding them, but it is a low
>> priority for me,
>> > due
>> > to the fact that these compilers don't produce optimal
>> performance. I am
>> > also a little nervous about how big a support hassle they
>> may turn into
>> > (in
>> > other words, I am open to adding config files for this
>> stuff, but don't
>> > yet
>> > have my machines config'd to support them, so support is "limited").
>> >
>> > Performance -
>> >
>> > Is pretty good. Attached are benchmarks for hfva (193K
>> atoms), fix and
>> > jac.
>> > The scaling is better, and per processor performance is
>> better than pmemd
>> > 8,
>> > especially for the NPT ensemble. These benchmarks were run
>> on a cray xt3
>> > at
>> > psc, and an ibm sp5 and opteron/infiband cluster at nersc.
>> There is a set
>> > of benchmarks (comp) comparing machines; the other 3 files
>> are all the
>> > same
>> > benchmarks on the xt3, for pmemd 9 beta, 8, sander 8, at 3
>> different (lo,
>> > med, hi) processor ranges so you can see low end details or
>> the grand
>> > sweep
>> > of things.
>> >
>> > Performance improvements on small hardware are less
>> apparent in the above
>> > benchmarks. For comparison, though, we are doing
>> significantly better
>> > than
>> > pmemd 8 for my 3.2 GHz 32 bit P4 setup (GB ethernet):
>> >
>> > Factor ix, constant pressure
>> >
>> > #proc pmemd 8 pmemd 9
>> > psec/day psec/day
>> >
>> > 1 86 116
>> > 2 138 182
>> > 4 238 293
>> >
>> > (note that the pmemd 8 times are better than in the
>> original release; this
>> > is probably mostly a compiler/OS issue;
>> > we reported 75 psec/day and 120 psec/day for 1 and 2 procs
>> respectively at
>> > time of amber 8 release - same machine)
>> >
>> > The fftw libraries were used here, in double precision
>> mode, with -sse2
>> > instructions enabled.
>> >
>> > The Generalized Born implementation is not yet optimized,
>> but on the P4 it
>> > is about 10% faster than sander 9. I will work on
>> improving things a bit
>> > more as I get time. I need to add support for MKL, check out other
>> > machines
>> > (especially itanium), etc. etc.
>> >
>> > Any problems, let me know!
>> >
>> > The beta without GB has been made available to select users
>> at psc, nersc,
>> > and ncsa. Let me know if you have access on machines at
>> those facilities
>> > and want the beta (or build it yourself, of course).
>> >
>> > Porting to new machines -
>> > Optimization is a little complex now. Probably best to let
>> me do it if
>> > possible, as I currently do a bake-off between a bunch of different
>> > possible
>> > code paths, depending on the machine. Otherwise, guess
>> what your new cpu
>> > is
>> > most similar to that is supported and use the defines for that as a
>> > starting
>> > point.
>> >
>> > Best Regards - Bob
>> >
>> >
>>
>
>
>
Received on Wed Apr 05 2006 - 23:49:44 PDT
