by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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.
    Guillaume Fraux
    @Luthaf
    @/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!
    Guillaume Fraux
    @Luthaf
    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
    German P. Barletta
    @pgbarletta
    I'm having some issues with the OpenBabel python bindings, I guess I have to reinstall openbabel 3.0 from source. I'll try again at the end of the day and let you know
    Jonathan Fine
    @frodofine
    ASE doesn't read the Bonds in an SDF file! https://gitlab.com/ase/ase/-/blob/master/ase/io/sdf.py
    Guillaume Fraux
    @Luthaf
    Well, that might explain the difference :smiley:
    @pgbarletta, I used the conda-forge version of openbabel 3.0 to get around this
    Diaz Arcrossito
    @darcrossito_gitlab
    Hi Guillaume, I wonder if chemfiles still store every frames of gromacs' trajectory files in memory? Like .xtc, .trr files.
    I'm referring to your discussion with ezavod above.
    @Luthaf
    Guillaume Fraux
    @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
    Diaz Arcrossito
    @darcrossito_gitlab
    Glad to hear that. Thanks for the library @Luthaf. And thanks for the work @ezavod. I find trrio.h and trxio.h of gromacs are a bit difficult to use. But xtcio.h is fine, imo.
    Guillaume Fraux
    @Luthaf

    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 =)

    Diaz Arcrossito
    @darcrossito_gitlab
    Hi @Luthaf, any plan to give an option to turn off unit conversion? Or perhaps we can do that already?
    Guillaume Fraux
    @Luthaf
    I am not sure what you are talking about here. Do you mean the nm => A conversion when reading XTC files ?
    Diaz Arcrossito
    @darcrossito_gitlab
    Yes, like from standard gromacs unit nm to angstrom when reading .xtc/.trr files. And vice versa when writing to them. Doesn't it happen?
    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.
    Diaz Arcrossito
    @darcrossito_gitlab
    Oh, don't worry. The current version is perfectly fine for me. I just want to read gromacs's trajectories, and calculate some values. Because I can't turn off the conversion, I just need to be a bit more careful with the units.
    Again, thanks for the library. It's very useful.
    dkonstan
    @dkonstan
    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.
    Guillaume Fraux
    @Luthaf
    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.
    Guillaume Fraux
    @Luthaf
    I opened chemfiles/chemfiles#327 to track this feature =)
    Mykola Dimura
    @mdimura
    Hi, everyone! How do I properly specify a property in a selection string? I tried "[chainname] A", but it gives an empty selection. Sorry, could not find an exmaple in the docs.
    Guillaume Fraux
    @Luthaf
    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.
    Guillaume Fraux
    @Luthaf
    See chemfiles/chemfiles#331, and thanks for the report!
    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.
    Mykola Dimura
    @mdimura
    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.
    Mykola Dimura
    @mdimura
    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.
    Guillaume Fraux
    @Luthaf
    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
    Mykola Dimura
    @mdimura