-
Notifications
You must be signed in to change notification settings - Fork 747
[WIP] TST: Draft of testing module for new Cython-based DCD file handling #1046
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…e handling interface.
I added a |
| # confirm shape of coordinate data against result from previous | ||
| # MDAnalysis implementation of DCD file handling | ||
| dcd_frame = self.dcdfile.read() | ||
| xyz = dcd_frame[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The dcd_frame is a namedtuple. You can access the coordinates also with dcd_frame.x
|
@tylerjereddy thanks for working on this. |
|
Thanks, all tests except for the unit cell dimensions are passing now. Of course, more tests will be needed. |
|
I've added several more unit tests based on the xdr stuff. Most things pass, except that:
I'm not sure that either of those are really that important, but just so you know. |
|
Hm. I think the libmdaxdr API is wrong. It would be better if the XDRFile classes (and derived classes) only raise IOError like libdcd is doing now. You can change them to IOError. I'll make a change of the libmdaxdr API to raise IOError exclusively. |
…_read_write_mode_file and test_open_wrong_mode.
|
Done, thanks. |
|
Thanks |
Reference: #929
PR for testing various features of the Cython DCD file handling implementation in the above branch. It currently does not closely follow the
libmdaxdrtesting suite as I wanted to just get it going with the test module format I'm familiar with.One of the current test failures is related to reading unit cell dimensions and @kain88-de has already indicated that this is a design feature -- it will be engineered in later for more flexibility.
It might be nice if I could check the current frame after a seek -- this is the only other issue at the moment:
AttributeError: 'MDAnalysis.lib.formats.libdcd.DCDFile' object has no attribute 'current_frame'. I'm probably just not supposed to access that, but how can I conveniently pull out the currently registered frame number otherwise?