Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    marvinbernhardt
    @marvinbernhardt
    Since you opened an issue for the landing page examples, should I open an issue for the CMake Problem? Or is it somewhere already?
    Guillaume Fraux
    @Luthaf
    Not yet open, feel free to do so!
    Guillaume Fraux
    @Luthaf
    I found a fix ! See chemfiles/chemfiles#252
    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
    marvinbernhardt
    @marvinbernhardt
    i opened an issue already, guess you can close it chemfiles/chemfiles#251
    Guillaume Fraux
    @Luthaf
    =)
    It will be closed when the PR is merged
    marvinbernhardt
    @marvinbernhardt
    ok cool
    will there be a 9.2 or something?
    Guillaume Fraux
    @Luthaf
    Yes!
    there is a bunch of fixes that we need to release
    marvinbernhardt
    @marvinbernhardt
    I have another question: How does chemfiles handle units? Is everything just in the unit from the trajectory or is some unit conversion going on?
    Guillaume Fraux
    @Luthaf
    It depends on the file format. Usually, we try to convert everything to Angstrom for distances, but for formats where no unit is specifyed (such as XYZ), we use the values from the file assuming angtroms
    This message was deleted
    For example, we convert TNG units to Angtroms, and I think a few other formats from GROMACS as well
    marvinbernhardt
    @marvinbernhardt
    And is that also done for velocities?
    Guillaume Fraux
    @Luthaf
    Should be, if not it is a bug =)
    marvinbernhardt
    @marvinbernhardt
    So it seems to be Å / ps, at least for .trr and .gro files. For .lammpstrj I guess it depends on the units you use in lammps, so you could get something different
    I just noticed, that for .lammpstrj that the positions are not shifted into the box. It's not bad, but unexpected i think.
    marvinbernhardt
    @marvinbernhardt

    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.000172609

    becomes

    >>> 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]])
    Guillaume Fraux
    @Luthaf
    You mean wrapped back inside the box? Like the 47.85229874 in the last line should become 3.6581?
    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)
    marvinbernhardt
    @marvinbernhardt
    In this case I guess I would have subtracted 5.7875057153239045 from all coordinates. But yeah you're right, it does not really matter, frame.cell.wrap(vector) can handle it.
    marvinbernhardt
    @marvinbernhardt
    I guess my suggestion would be shifting, not wraping though
    ezavod
    @ezavod
    Hi everybody,
    ezavod
    @ezavod
    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 :)
    Guillaume Fraux
    @Luthaf
    This message was deleted

    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
    Guillaume Fraux
    @Luthaf
    Another possibility would be to have MDAnalysis contributors to the libxdrfile part to agree to release it under another license (BSD, MIT, Apache would be great, MPL ou LGPL could work too)

    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 ?

    Guillaume Fraux
    @Luthaf
    I imported the BSD, GROMACS version here: https://github.com/chemfiles/xdrfile
    Their is a basic Cmake build file that should get you started if you want to use it !
    ezavod
    @ezavod
    Do you know if the MDAnalysis version is very different ?
    The most important difference is, that MDAnalysis supports finding offsets of frames and therefor seeking. The Gromacs lib can not not do that unfortunately.
    ezavod
    @ezavod
    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?
    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?
    Guillaume Fraux
    @Luthaf
    LGPL could work yep
    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
    ezavod
    @ezavod
    Thanks for the effort, I didn't expect that to be so messy. :/ Since the GROMACS version hasn't been updated for so long everybody uses their own fork with different changes.
    Guillaume Fraux
    @Luthaf
    Yeah, that' s unfortunate =/
    b00504029
    @b00504029
    Hi everyone,
    I tried to read a dcd file using the "read_step(#)" command , but I found the larger # is, the more memory is used.
    Thus, it prevents me from reading the information at the certain step. How can I fix it?
    Guillaume Fraux
    @Luthaf
    Hey! This is to be expected, since read_step(#) is implemented for DCD files by reading all the steps up to # and storing them in a vector for future use. This is unfortunately a known limitation of the code, since the DCD reader is based on VMD molfile plugins.
    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
    ezavod
    @ezavod
    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 has_positions: bool).
    Any thoughts on that?
    Guillaume Fraux
    @Luthaf
    This sounds good to me. The issue is similar to the one @frodofine had with SMI, which is a format that only defines topology, and in this case setting positions to zero seems reasonable.