Open ianmkenney opened 5 years ago
@ianmkenney I clarified the description a bit, after our discussion.
Note that this was found because the ChainReader throws an error while the TRRReader on its own seems to take the IOError as the sign to just end iteration. This is bad behavior because one might never learn that one's trajectory is actually damaged and incomplete.
It seems that detecting the end of a TRR is pretty haphazard: https://github.com/MDAnalysis/mdanalysis/blob/f83498ec6b5cc546a0d75598a4d1d6ede6fe2782/package/MDAnalysis/lib/formats/libmdaxdr.pyx#L516-L532
However, the reported error here is float and not integer. Not sure why iteration finishes apparently cleanly.
I think the reason why "end of file" always shows up as a "EINTEGER" is because the reading of the magic integer fails https://github.com/MDAnalysis/mdanalysis/blob/f83498ec6b5cc546a0d75598a4d1d6ede6fe2782/package/MDAnalysis/lib/formats/src/xdrfile_trr.c#L72-L73
We could make a special exception that catches that particular case.
Possibly related to work in #3892
Expected behavior
I have a TRR "000001-00043359.trr" whose last frame is damaged (as shown by
gmx check -f 000001-00043359.trr
.For a TRR trajectory with a damaged frame, iteration
should fail with an error such as
IOError
.It should be the same error that comes up when I access the damaged frame directly:
Actual behavior
Iterating seems to work just fine:
Actually, the last (damaged) frame is ignored and
i
only iterates up to the penultimate frame.EDITS: @orbeckst added a few more details from conversation with @ianmkenney