Gromacs EDR reader

[orbeckst]

At the moment, the native Gromacs energy (EDR) files have to be converted to XVG files.

Instead we should also offer a EDR parser.

@jbarnoud wrote https://github.com/jbarnoud/panedr which reads a EDR into a dataframe. This would interact nicely with alchemlyb.

panedr is published under LGPL so we would be able to link (import) it in alchemlyb (BSD!) but we cannot integrate the code itself. For that to work, panedr needs to become available as a pip-installable (and eventually conda-installable) package.

If we want to go in this direction then we can fork panedr and contribute to its development.

[mrshirts]

Let me check with current plans in GROMACs for data output. If the EDR format is planned for change in the next 1-2 years, it wouldn't make sense.

Generally, I think this is low priority, as the current workflow requires gromacs binaries, which someone who is using gromacs will have.

[jbarnoud]

Note that panedr is already pip and conda-installable.Le 15 nov. 2018 9:01 PM, Michael Shirts <notifications@github.com> a écrit :Let me check with current plans in GROMACs for data output. If the EDR format is planned for change in the next 1-2 years, it wouldn't make sense. Generally, I think this is low priority, as the current workflow requires gromacs binaries, which someone who is using gromacs will have. —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[orbeckst]

In my experience, calling Python library functions is always preferable to os.system('gmx something'). Therefore, even if EDR is perhaps not the final format it would be very useful to have a reader, especially if there's already a library. (For example, the TNG format is supposedly the new trajectory format but it seems very difficult to support anywhere outside of Gromacs itself. Therefore, I wouldn't bet on EDR being obsolete any time soon...)

…

Am Nov 15, 2018 um 13:01 schrieb Michael Shirts ***@***.***>: Generally, I think this is low priority, as the current workflow requires gromacs binaries, which someone who is using gromacs will have.

[orbeckst]

@VOD555 please feel free to work on this!

[orbeckst]

Let me check with current plans in GROMACs for data output. If the EDR format is planned for change in the next 1-2 years, it wouldn't make sense.

Sure, let us know. But in my experience I would not change my own plans based on possible developments elsewhere.

Generally, I think this is low priority, as the current workflow requires gromacs binaries, which someone who is using gromacs will have.

Yes, but conversion is actually painful and slow in workflows. In our case, we would love to be able to read our EDR files directly, instead of processing them into XVGs. We might just do it because it annoys us...

[IAlibay]

@orbeckst @jbarnoud given the upcoming MDA GSoC on energy readers, it might be good to revive this and consider how we can de-duplicate efforts here?

@richardjgowers @dotsdl - long term this would be a lot more effective than having to ship around xvg files with the results store

[orbeckst]

I am not sure how to do this. I wouldn’t want MDA to be a dependency of alchemlyb (even ignoring license status). The simplest approach would be to for @BFedder to dual-license his code. It’s also possible that the special case for FEP EDR is so much simpler than the general reader and it will be just simpler to write two versions, ie, the code duplication is not too bad.

…

Am 5/26/22 um 13:04 schrieb Irfan Alibay ***@***.***>:  @orbeckst @jbarnoud given the upcoming MDA GSoC on energy readers, it might be good to revive this and consider how we can de-duplicate efforts here? @richardjgowers @dotsdl - long term this would be a lot more effective than having to ship around xvg files with the results store — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[richardjgowers]

Panedr is lgpl which might be ok. Not sure we’ll need the mda version/bindings to that.

…

On Thu, May 26, 2022 at 22:16, Oliver Beckstein ***@***.***> wrote: I am not sure how to do this. I wouldn’t want MDA to be a dependency of alchemlyb (even ignoring license status). The simplest approach would be to for @BFedder to dual-license his code. It’s also possible that the special case for FEP EDR is so much simpler than the general reader and it will be just simpler to write two versions, ie, the code duplication is not too bad. > Am 5/26/22 um 13:04 schrieb Irfan Alibay ***@***.***>: > >  > @orbeckst @jbarnoud given the upcoming MDA GSoC on energy readers, it might be good to revive this and consider how we can de-duplicate efforts here? > > @richardjgowers @dotsdl - long term this would be a lot more effective than having to ship around xvg files with the results store > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned. — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSGB6CJENEJI4MDDUDGQTVL7S3PANCNFSM4GEIDWCA> . You are receiving this because you were mentioned.Message ID: ***@***.***>