A slightly less hacky way to make it work with you current installation is to add
set_target_properties(chemfiles PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include") after add_library(chemfiles SHARED IMPORTED) in <CONDA_PREFIX>/lib/cmake/chemfiles/chemfiles-targets.cmake
It will be closed when the PR is merged
will there be a 9.2 or something?
there is a bunch of fixes that we need to release
This message was deleted
For example, we convert TNG units to Angtroms, and I think a few other formats from GROMACS as well
I just noticed, that for .lammpstrj that the positions are not shifted into the box. It's not bad, but unexpected i think.
for example
ITEM: TIMESTEP
0
ITEM: NUMBER OF ATOMS
8
ITEM: BOX BOUNDS pp pp pp
5.7875057153239045e+00 4.9981685536401990e+01
5.7875057153239045e+00 4.9981685536401990e+01
5.7875057153239045e+00 4.9981685536401990e+01
ITEM: ATOMS id type x y z vx vy vz
1 1 22.6897 27.2382 42.3331 0.00212723 -0.00133751 -0.00473526
2 1 19.7944 27.3012 38.1954 -0.00155793 -0.0001728 0.000206937
3 1 14.7928 8.75791 7.60697 -0.0038742 0.000208492 0.00405365
4 1 17.011 13.066 7.22215 0.00400915 -0.00129347 0.000352075
5 1 11.531 18.6935 12.137 0.00208111 -0.001776 -0.000353107
6 1 17.0727 21.6433 13.3758 -0.00153847 -0.00319836 -2.84675e-05
7 1 49.8093 10.553 36.9704 -0.00247091 -0.000231973 -0.00138922
8 1 43.9927 22.449 47.8523 0.00190328 -0.000307742 -0.000172609becomes
>>> frame.cell
UnitCell(44.19417953491211, 44.19417953491211, 44.19417953491211, 90.0, 90.0, 90.0)
>>> positions
array([[22.68969917, 27.23819923, 42.33309937],
[19.79439926, 27.30120087, 38.19540024],
[14.79279995, 8.75790977, 7.60696983],
[17.01099968, 13.06599998, 7.22214985],
[11.53100014, 18.69350052, 12.13700008],
[17.0727005 , 21.6432991 , 13.37580013],
[49.80929947, 10.55300045, 36.97040176],
[43.99269867, 22.4489994 , 47.85229874]])
This is intentional, as some analysis algorithm needs the real, unwrapped coordinates. If you need the wrapped ones, you can use
frame.cell.wrap(vector)
I'm using GROMACS for my simulations, therefor I'm dealing with mostly .xtc and .trr files. My file size is typically ~100 GB. This seems to bee somewhat of a problem, because the current implementation in chemfiles stores every frame in memory. My unpacked trajectories are double or even triple the size of the compressed files, but I don't have that much mem available :(
Since this seems to be due to the use of molfiles for reading I set out to try an alternative...
I'm using the libxdrfile from MDAnalysis and this works OK for me. This lib allows sequential reads and write just like molfiles, but also supports seeking, which is very handy if one just want to look an every nth frame.
However before making a PR (if you want so) I have some general questions:
a) Don't know much about licensing, so can/want we use the implementation made by MDAnalysis? How do we reference their code appropriately?
b) I have just a very basic cmake file to build this additional lib and don't know much about this either. I'm probably the wrong person to try to incorporate versioning and other stuff into the cmake file for libxdrfile...
When that's done I am looking forward to contribute my code :)
Since this seems to be due to the use of molfiles for reading I set out to try an alternative...
I'm using the libxdrfile from MDAnalysis and this works OK for me. This lib allows sequential reads and write just like molfiles, but also supports seeking, which is very handy if one just want to look an every nth frame.
However before making a PR (if you want so) I have some general questions:
a) Don't know much about licensing, so can/want we use the implementation made by MDAnalysis? How do we reference their code appropriately?
b) I have just a very basic cmake file to build this additional lib and don't know much about this either. I'm probably the wrong person to try to incorporate versioning and other stuff into the cmake file for libxdrfile...
When that's done I am looking forward to contribute my code :)
a) Don't know much about licensing, so can/want we use the implementation made by MDAnalysis? How do we reference their code appropriately?
Yeah, unfortunely MDAnalysis code being GPL licensed, we can't use it in chemfiles (which is BSD) without changing our license to GPL too.
The library provided by GROMACS (http://www.gromacs.org/Developer_Zone/Programming_Guide/XTC_Library) is distributed under BSD (the website says LGPL, but the archive contains the BSD license) so that would be a better choice
Do you know if the MDAnalysis version is very different ? Unfortunely due to this license issue, we can not even look at their code to bring over patches. But we can try to re-implement such patches ourself
b) I have just a very basic cmake file to build this additional lib and don't know much about this either. I'm probably the wrong person to try to incorporate versioning and other stuff into the cmake file for libxdrfile...
I am not sure I understand you here =) Are you saying that you have a cmake file, but don't know how to make it work inside chemfiles' build system ?
Their is a basic Cmake build file that should get you started if you want to use it !
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?