I have no problem with retiring a code once development on it has ebbed,
and if its requested functionality is already part of another code. We
should focus on one brand of leap, as well as condense other programs.
However, I don't feel that this pressure to maintain or update existing
codes should preclude a rewrite. In the private sector, that would be
called a predatory monopoly.
I started writing mdgx rather than contributing to pmemd because for a
time I was discouraged from editing pmemd. I submitted mdgx into the
AmberTools package upon the recommendations of Dave Case. I've not been
saying this loudly, but I'm getting increasingly convinced that the way
mdgx is doing things has the potential to outscale pmemd unless that code
gets a major rewrite. Some of the new features in mdgx work very well in
the way they were intended, but would not be attractive to incorporate
into pmemd because a lot of effort is spent making up for limitations of
the prmtop format and tleap. If the prmtop format is upgraded for more
virtual site support, tleap is improved to incorporate them, and pmemd is
upgraded to do dynamics with them, then these features of mdgx can go
away. I did not set out to modify all of those programs from the
beginning because it was unclear what the best way to implement the
virtual sites would be, how many of them we would want, and what
challengers I might be facing on several fronts.
As for contributors preferring to play in sander rather than mdgx, look at
each code and look at the extent to which it is commented. There are some
places where mdgx makes a few twists and turns, has #ifdefs, or dense
code, but this is for optimization and I have sought to enable speed
without sacrificing the overall comprehensibility of the code. It is
simply not possible to have a version of the code that compiles without
MPI if we do not wrap MPI calls in #ifdefs; it is much more efficient to
make branches of the inner loop than decide with each interaction whether
to compute a virial. Given the development that mdgx has undergone in the
past six months, and the avenues for further optimization and filling out
the scope of its capabilities, I expect that mdgx will surpass sander as
the development engine of choice sometime between the next two release
cycles, and could surpass pmemd as the simulation engine of choice with
some dedicated professional programming.
Dave
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 19:00:03 PDT
