Hi All,
Can I perhaps offer some thoughts and points for discussion here that we, as
the developers of AMBER, might want to consider.
Look at the example we have here. We have a working code, tleap / xleap that
had some problems and needed some extra stuff adding etc. But instead of
people trying to fix stuff we get a whole new version written from scratch
which has its own problems. Why oh why are we making yet another imperfect
square wheel?
If we keep going down this route we are just going to end up with a ton of
tools that all partially duplicate each other, all of which have problems
and most of which are not properly tested or maintained.
For example, I think we have about 7 different sets of code for parsing
prmtop files, in or out, in the tree right now. None of these work properly
and if we tweak anything in the prmtop file there is a multitude of stuff to
update.
The same goes for things like cpptraj and mdgx etc. Why are we continually
reinventing things? We should be forcing people to fix the existing code not
going off and writing their own version in their own favorite language which
nobody can maintain etc etc. Take mdgx. Is the intention here to make
another dynamics engine that we need to maintain? Or is to replace sander or
pmemd? If so what is the plan for this? If it is a sandbox for testing new
things why aren't you using pmemd for this? - in your own branch and looking
for a way to ultimately incorporate the cool new technology in pmemd so it
benefits from the existing user base and all the other framework? If it is a
sandbox for your own development then why is it being distributed publically
under AMBER in what is essentially an unfinished fashion?
Cpptraj is designed to replace ptraj yes? Otherwise why do we have two codes
that effectively do the same thing? If we truly want to replace ptraj then
there should be agreement from everyone, cpptraj should be developed and
tested locally and it made to support everything ptraj does - unless there
is stuff we agree to deprecate. Then we replace ptraj with cpptraj and go
from there. We don't need 2 copies of it. Really...
Then we have Jason's parmed code, which is great don't get me wrong, but it
is yet another place we have to update if we change anything elsewhere with
prmtops etc. And why is it standalone? - Another program to document and
people to learn. Why was the functionality, which is desperately needed, not
added to ptraj (rdparm)? That would be the logical place for it and would
ultimately give a better use experience and a more consistent interface.
The code bloat these days is getting awful and unmaintainable and I move
that at the developers meeting we should come up with a clear plan for how
we will remove duplication from AMBER and get back to a clean set of tools
that we can maintain going forward, can document efficiently and most
importantly can teach to new graduate students and postdocs without
confusing the hell out them why we have 10 different ways to boil an egg.
Just my $6 for today (price of a pint in San Diego these days!).
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
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.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 15:00:03 PDT
