Hi all,
I recompiled AmberTools 1.4 today after applying the latest bugfixes
and this seems to have somehow broken ptraj's ability to analyze
gzipped trajectory files. When running "make test", this build passed
everything fine (zero reported errors), but I'm not sure what, if any,
compressed trajectories are encountered by ptraj during those tests.
Here is the typical error message I get upon opening a gzipped
trajectory:
PTRAJ: trajin ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
Checking coordinates: ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
Could not process trajectory ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
...eventually dies due to no input trajectory...
If I first gunzip any of these trajectories myself, however, it reads
and analyzes the uncompressed trajectories with no problem (although
it does gives the "there is a problem" output):
PTRAJ: trajin ./mdcrd/ala3_wat_prod2_s1.mdcrd
Checking coordinates: ./mdcrd/ala3_wat_prod2_s1.mdcrd
checkCoordinates(): Could not predict number of frames for AMBER
trajectory file: ./mdcrd/ala3_wat_prod2_s1.mdcrd
If this is not a compressed file then there is a problem
Rank: 0 Atoms: 2396 FrameSize: 58248 TitleSize: 81 NumBox: 3 Seekable 0
...snip...
PTRAJ: Successfully read the input file.
Coordinate processing will occur until EOF (unknown number of
frames).
Summary of I/O and actions follows:
...lots of output...
If I go back to the original AmberTools 1.4 source code (i.e., no
bugfixes) and recompile, then ptraj reads both compressed and
uncompress trajectories just fine:
[compressed...yes, this does look the same as the uncompressed above]
PTRAJ: trajin ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
Checking coordinates: ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
checkCoordinates(): Could not predict number of frames for AMBER
trajectory file: ./mdcrd/ala3_wat_prod2_s1.mdcrd.gz
If this is not a compressed file then there is a problem
Rank: 0 Atoms: 2396 FrameSize: 58248 TitleSize: 81 NumBox: 3 Seekable 0
...snip...
PTRAJ: Successfully read the input file.
Coordinate processing will occur until EOF (unknown number of
frames).
Summary of I/O and actions follows:
...lots of output...
OR
[uncompressed]
PTRAJ: trajin ./mdcrd/ala3_wat_prod2_s1.mdcrd
Checking coordinates: ./mdcrd/ala3_wat_prod2_s1.mdcrd
Rank: 0 Atoms: 2396 FrameSize: 58248 TitleSize: 81 NumBox: 3 Seekable 1
...snip...
PTRAJ: Successfully read the input file.
Coordinate processing will occur on 50000 frames.
Summary of I/O and actions follows:
...lots of output...
Altogether this behavior suggests to me that bugfix.4 may have
actually broken something (else) with compressed trajectory files.
Post-bugfix.4, it appears to be acting like compressed files are
garbage and uncompressed files are compressed, while pre-bugfix.4, the
behavior is normal. Have any others noticed similar problems since
applying bugfix.4?
Thanks,
Paul
P.S. Just some details on my system: MacOS 10.5.8 (dual Xeon machine),
gcc 4.5.0 (rev 4), and the latest versions of gmp, gperf, mpfr,
libmpc, etc. available from MacPorts.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jun 25 2010 - 17:00:03 PDT
