Hi Dave,
Thanks for the pmemd exception. I have a lot of good stuff in my pmemd
"baseline" right now, but things that really enhance scaling in a big way
are still very much in progress. I think I have a nice architecture coming
for the fft "pencils" implementation (I am calling them blocks, more-or-less
to emphasize that they have 3 dimensions themselves), complete with an
auto-initial optimization and loadbalancing scheme (ultimately the user will
be able to be dumb as a box of rocks about fft performance issues). I also
have tentative attacks planned for a bunch of other scaling bottlenecks.
All this stuff will definitely not be done early, though, as it is fairly
complex. One thing that is currently working well is the "don't do virials
and energies if you don't need them" code - this has a significant impact on
nvt and nve ensembles, as one might expect. A ton of other work I did on
trajectory error analysis was intended to allow optimization of pme params
as well as showing that respa and cutoff (even smooth) methods are typically
outperformed by pme and some combination of params; full exploitation of
this work may or may not occur in the 10 timeframe. Other single processor
work I did included a running implementation of "image runs" direct force
evaluation, but here the tradeoff in inner loop size and loss of the ability
to cache the "image i" information in registers basically cost about what
you gained through better L1 cache utilization. Careful evaluation of
assembler dumps also led to the conclusion that at least for the intel
architecture, opportunities to speed things up via assembly language
programming are limited. I do believe we will see an impressive boost in
overall scaling, but I expect to be doing that work until at least the end
of the year, rather intensively. I will try to work in some GB stuff near
the end; the new pseudo-residue fragments division scheme will help with
this as well as overall highend pme scaling, though it was originally
implemented to allow an efficient extra points implementation. I have
recently acquired friendly user access to a new xt4 with over 19,000
processors at nersc, so that is going to help with some of the really high
scaling work. I will need to coordinate with Tom D. on some minor fixes to
the way things are done in sander with regard to net force corrections -
fixes need to be applied to sander for both extra points code and respa code
in this area.
Best Regards - Bob
----- Original Message -----
From: "David A. Case" <case.scripps.edu>
To: <amber-developers.scripps.edu>
Sent: Wednesday, September 26, 2007 11:41 AM
Subject: amber-developers: First Amber10 code submission deadline
> Hi everyone:
>
> As I have mentioned before, we need to work harder than we have in the
> past to
> get new code for Amber10 submitted in a timely fashion.
>
> The basic code deadline for Amber 10 is October 15, 2007.
>
> I really want to have things in a week before the developers' meeting, so
> that
> problems can be identified *before* that meeting, and we can try to fix
> things
> up *during* the meeting. We can also make decisions at the meeting about
> which
> post-deadline code to accept.
>
> After the meeting, acceptance of new code will probably be limited to
> clean-ups and bug fixes; exceptions to this policy will be considered on a
> case-by-case basis.
>
> The above deadline does not apply to pmemd: this code has been very solid
> in
> the past, and changes Bob makes don't disrupt other parts of Amber.
>
> As always, comments and suggestions are welcome.
>
> ...dac
>
>
Received on Sun Sep 30 2007 - 06:07:13 PDT
