Hi Paul, sorry for the delay in replying.
The problem was due to byte ordering (little vs big endian) and since
I never work on Macs or the like I never saw the issue. In short
because the bytes were not being read the "correct" way ptraj was
coming up with incorrect numbers and failing out.
The attached patch should fix the problem. I have tested it on a Mac
PowerPC G4 running OSX 10.4 and GNU4.4.4. Let me know if it doesn't
work or if there are any remaining issues.
-Dan
On Fri, Jun 25, 2010 at 7:55 PM, Paul S. Nerenberg <psn.berkeley.edu> wrote:
> 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
>
--
-------------------------
Daniel R. Roe
Postdoctoral Associate
SAS - Chemistry & Chemical Biology
610 Taylor Road
Piscataway, NJ 08854
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 08 2010 - 13:00:04 PDT
