Re: AMBER: Binary file curiosities

From: David A. Case <case.scripps.edu>
Date: Fri, 3 Aug 2007 16:21:25 -0700

On Fri, Aug 03, 2007, David LeBard wrote:
>
> I have been playing with reading the various binary AMBER trajectory data
> types lately, and I noticed a few things that strike me as puzzling
> "features" of AMBER. For instance, from what I can tell from mdwrit.f, if
> you choose the option NTRX=1 in sander you get an unformatted file that
> looks exactly like the formatted mdcrd file. However, I do not see the
> option to write these types of files from ptraj, only binpos binary files
> are available (from my inspection of trajectory.c). Also, possibly due to
> my lack of c expertise, I do not see the option to read binary mdcrd files
> within ptraj itself. So my questions are the following: 1) Why such
> inconsistencies with the binary file types across the various sander
> modules? I understand that you must try to be as backward compatible as
> possible, but consistency between file reads and writes would make things
> much easier for the users (including myself). 2) Is the magic number in the
> binpos file type only used only to determine the difference between binpos
> and CHARMM trajectories? 3) Has anyone worked with reading binpos files in
> fortran, particularly using direct access reads? If so, can you please
> provide any examples? 4) Is there any documentation anywhere on the binpos
> file type? I have been looking all over, and only believe I know what is in
> the file because of the "od" command and code/comments inside ptraj.
> Please, if I am missing an obvious reference to the binpos file structure,
> do not hesitate to send it my way.
>

Both the "binpos" and the "ntrx=1" unformatted files are really obsolete.
You can either be a stick-in-the-mud (like me) and use formatted trajectory
files, or a forward-looking-soul and use netcdf. I would recommend against
spending time on other options.

To answer you questions (1) your answer is correct--this is why removing
options always seems harder than adding them; (2) binpos has a magic
number just because (binary) files are "supposed" to have one; there was never
any known connection with CHARMM; (3) binpos never had a fortran API; (4) no.

...dac
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Sun Aug 05 2007 - 06:08:00 PDT
Custom Search