Hi,
On Thu, Nov 3, 2011 at 5:45 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> 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...
At the last developer's meeting in March I tried to address these
points. Yes Cpptraj and Ptraj do have some functional overlap, but I
would argue that Cpptraj is far from a Ptraj clone. What initially
spurred me to develop Cpptraj was that I wanted the ability to work
with two different topology files at the same time (I had a file
containing a ligand structure I wanted to use as a reference for
comparing to a complex trajectory). In order to implement this in
ptraj I would have had to do a major rewrite since the parm
information is so ingrained (a vestige from the original rdparm
incarnation I believe). I had already started rewriting the trajectory
portions of the ptraj code because it was spread across two files
(ptraj.c and trajectory.c) and multiple functions, which made it
difficult to maintain and add on to. Over the years I have spent quite
a lot of time in the ptraj code, adding functionality and fixing bugs,
so I know just how steep the learning curve can be to adding new
functionality.
Cpptraj is now just over a year old, has a good amount of the
functionality of ptraj (with more being added all the time), in
addition to a lot of enhanced functionality (multiple parmtops,
multiple reference structures, multiple output trajectories, NA
structure analysis, surface area calculation, multiple data output
formats, native gzip/bzip2 support etc etc) and is for the most part
faster. In addition, the code has been tested at every step of
development for agreement with Ptraj results, as well as tested for
memory leaks with valgrind and optimized for speed where possible.
Also, and I would argue this is just as important, the code is better
organized (e.g. every action is in its own file, every traj format
reader/writer in its own file, etc) and all classes/functions are
documented; I'm currently converting all the in-code documentation to
a doxygen-readable format which will be even better, and I have a
developers guide in the works as well. As as side benefit, porting
over functionality from Ptraj to Cpptraj has allowed me to find and
correct existing bugs in the Ptraj code.
Now in an ideal world I would have Cpptraj supporting and doing the
same things as Ptraj already. However, as I'm sure my boss will agree
:-) I probably already spend too much time working on the code, so I'm
limited as to how fast I can get it all done. I think that eventually
Cpptraj could be a replacement for Ptraj, but obviously that time has
not yet come. You ask why have two codes that effectively do the same
thing? Why do we have Sander / Pmemd? There is quite a bit of overlap
between those two as well, but of course Pmemd is the Ferrari 599 GTO
to Sander's Toyota Corolla. Now granted Cpptraj doesn't have same the
major performance enhancements as Pmemd does vs Sander, but I would
argue that the spirit is the same. Functional overlap is nothing new
in Amber (remember carnal? :-D ), but I think necessary during
transitions.
However, your overall point I think is a good one. If the developer
community at large does not find Cpptraj functionally better to some
degree, or agree that further development of Cpptraj is useful, then
in continuing I'd essentially be tilting at windmills. The general
feedback I've received from people using Cpptraj so far has been
positive, but it would certainly be good to get a general consensus,
either at the developer's meeting or perhaps before.
Phew - all done.
Take care,
-Dan
--
-------------------------
Daniel R. Roe, PhD
Postdoctoral Associate
BioMaPS Institute, Rutgers University
610 Taylor Road
Piscataway, NJ 08854
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 19:30:03 PDT
