On Jul 23, 2014, at 5:59 PM, Raik Grünberg <raik.gruenberg.gmail.com> wrote:
> OK, thanks a lot. I will give it a try then... was just worried
> because the manual describes cpptraj behaviour as "similar" rather
> than the same. Let's see how my wrappers and parsers etc fare with
> that.
I've had to migrate a couple applications from using ptraj to cpptraj, so I'll relay my experiences.
The migration is *mostly* painless. cpptraj implements everything ptraj did (except maybe some clustering algorithms, but I'm not sure on that), and the syntax for using all of the commands is the same, with the notable exception of hbond as Dan points out. The data output is also similar enough that no parsers should need to change.
However, the behaviors are _not_ all the same, and they can potentially trip you up if you're not expecting it. One notable example is printing files with only one structure -- if you tried to trajout as a restart file and you only print 1 frame, ptraj will append a ".1" to the name whereas cpptraj won't. That will kill some scripts. Also, outputting a PDB now prints a PDB trajectory (each frame listed as separate MODELs), rather than printing a separate PDB for each frame with a ".#" appended to it -- this will kill some scripts as well (you need to add the keyword "multi" to the trajout command to restore the original behavior).
There is also a lot more flexibility in cpptraj with regards to how it generates, prints, and analyzes datasets (and of course its ability to process multiple topologies simultaneously). It also has a lot more functionality that make certain tasks much simpler, as well as more analyses (especially wrt replica exchange simulations).
That ptraj lasted as long as it did is a testament to its effective design combining a good balance of flexibility and ease-of-use. cpptraj is a clear improvement and refinement of the ideas behind ptraj informed by years of experience of what did and didn't work well with ptraj.
In summary, what I've found is that the migration is often painless, but can require some interface changes to handle differences in how cpptraj operates. In the end, I think it's a worthwhile endeavor that should not take long to implement.
I hope this helps,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jul 23 2014 - 19:30:02 PDT
