Hi all,
Just to add to my original message from Friday -- I'm seeing the same
behavior after compiling AT 1.4 with bugfix.4 using either gcc 4.3.5
or gcc 4.4.4 on my machine. (I did this to exclude gcc 4.5 as being
the source of trouble.) For what it's worth, the prmtop and mdcrd
files in question were generated with AMBER 10 (and gzipped) on a
couple of different clusters, but I don't think that should really
matter...
Best,
Paul
On Jun 25, 2010, at 4:55 PM, Paul S. Nerenberg 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
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Jun 28 2010 - 15:00:03 PDT
