The most important difference is, that MDAnalysis supports finding offsets of frames and therefor seeking. The Gromacs lib can not not do that unfortunately.
Thanks for immediately providing xdrfile with a suitable cmake file. Mine was very rudimentary and not suited for any release.
The main point of my changes were, that they would enable fast reading of not consecutive frames. That part is not easily achievable without the MDA lib that used.
I could try to remove the whole seeking part so that this would work with the gmx version of xdrfile. This wouldn't bring much benefit right now, but would be helpful for the implementation of writing. Any thoughts of that?
The main point of my changes were, that they would enable fast reading of not consecutive frames. That part is not easily achievable without the MDA lib that used.
I could try to remove the whole seeking part so that this would work with the gmx version of xdrfile. This wouldn't bring much benefit right now, but would be helpful for the implementation of writing. Any thoughts of that?
There are some other variants of that out there. MDTraj is GNU LGPL and has a similar seek implementation. Since this is LGPL we might be able to use their stuff?
For people using chemfiles in non open-source code, LGPL might still be an obstacle, so we could have an option to disable LGPL dependencies
I'll try to give a look at how hard a seek implementation could be inside the original GROMACS version
The easiest way for you to fix it would be to split the DCD file in smaller chunks that would fit in memory
The right way to fix it would be to reimplement DCD reader natively. This is something we want to do (see chemfiles/chemfiles#154), but we need to find the time and motivation to do so. If you want to get your hands dirty to do it, I can help you to do so!
In the mean time, I have an idea to get read_step working with VMD molfile while limiting memory usage (only store the last N steps). I'll see if I can make it work, but I don't have a lot of time right now
Hey there, so I'm currently working on implementing the TRR reader with xdrfile. TRR allows box vectors, positions, velocities and forces to be optional. This leads to the following problem: it is possible to have a frame without position data. AFAIK chemfiles doesn't support optional positions in frames. Currently I'm just failing with an error, but that's non-optimal, because IMHO that's is a bit too restrictive. I also think that making positions optional isn't a suitable solution either, because that would break a lot of stuff. My preferred solution is to simply let the positions be zero and set an attribute to the frame (something like
Any thoughts on that?
has_positions: bool).Any thoughts on that?
@/all FYI, the 0.9.2 release is now up and working, including all the bindings! But I found a bug after the release (chemfiles/chemfiles#297), so I am planning to do a 0.9.3 release immediately, including the fix for this bug. After that, we will be able to advertise the new version to the whole world!
I just ran some benchmarks to compare chemfiles to other similar libraries: https://github.com/chemfiles/benchmarks
The good new is we are faster most of the time (between 2 and 40 times faster) !
The bad new is that we are slower than MDAnalysis when reading XTC files, and slower than ASE when reading SDF files =)
If you have time to run these benchmarks on your own computer, I'll be interested to know if you see very different results
@pgbarletta, I used the conda-forge version of openbabel 3.0 to get around this
I'm referring to your discussion with ezavod above.
@Luthaf
No, that's one of the changes @ezavod implemented that is in the 0.9.2 release! See https://github.com/chemfiles/chemfiles/releases/tag/0.9.2
This applies to XTC and TRR formats, but not TRJ
The 0.9.3 version is now released and packaged almost everywhere! :tada:
What is still missing are publishing the Julia bindings (blocked on JuliaPackaging/Yggdrasil#463) and the Python bindings on conda-forge (the code is available as wheels on PyPi)
Thanks everyone involved in this release and 0.9.2, particularly @frodofine and @ezavod! This release contains huge performance improvements and support for more formats. Now is the time to tell everyone about it and share the news =)
That's my impression from your conversation with @marvinbernhardt above. The python package MDAnalysis is also doing something similar, but has an option to turn the unit conversion off.
Again, thanks for the library. It's very useful.
Hi @Luthaf, continuing from the Julia forum (about chemfiles selection language): Yes, I meant something like what you said, something to select, for example, all residues named “HOH” within X angstroms of ANY residues of names Y Z etc. MDAnalysis has this option and several similar ones (https://www.mdanalysis.org/docs/documentation_pages/selections.html). It would be great if chemfiles could do this. This is THE missing piece keeping me away from chemfiles.
Hey @dkonstan, thanks for taking the time to come over discuss this! I think implementing this would be pretty easy to do. We already support a
distance selection, and sub-selections in is_bonded and friends. The syntax would look like resname HOH and distance(#1, resname Y Z) < 12.5. The changes should be relatively simple so if you want to dig a bit into C++ and implement it yourself I would be happy to help you! Else I'll open an issue on the repo and try to do it soon-ish.
Looking through MDA documentation, they also have multiple selections related to the center of geometry of a sub-selection, which would also be interesting to implement, but a bit harder.
Hi!
"[chainname] A" should work, but the issue here is that chainname is a residue property, and only atomic properties are checked when evaluating selection. That something I think we should fix, I'll open an issue. And yes, the docs for the selection language are not very good, sorry about that.
In the mean time, you can modify the parser for the format you are using to store
chainname on atoms too and recompile chemfiles. If you want to go this route, I can help.
Thank you for your answer! I implemented a workaround in the src/selections/expr.cpp. Seems to work, please let me know if there are some caveats.
Chemfiles selection syntax does not seem to allow for ranged numerical properties. Would it be possible to introduce something like
resid 3-17 or resid 3 to 17? Similar syntax exists in vmd, pymol, mdtraj, etc., and it is more compact than chemfiles' resid >=3 and resid <=17. Another option could be 3 <= resid <= 17, but resid 3-17 might be cleaner.
Hey @mdimura, sorry I missed you question here! I agree having some kind of ranged selection could be nicer than
resid >=3 and resid <=17. My favorite alternatives would be 3 <= resid <= 17, or between(resid, 3, 17). Could you open an issue to discuss what syntax this could use? resid 3-17 would clash with resid == 3 - 17 i.e. resid == -14