@orbeckst @harlor @danijoo
I think it might be good to have a discussion about the future of flamel and its relationship with alchemlyb, before committing to it.
My vision of the alchemlyb would be that it would have two parts, the library part and the workflow part.
The workflow part currently only have the ABFE workflow (alchemistry/alchemlyb#114), which provides the same interface as the alchemical-analysis.
>>> workflow = ABFE(units='kT', software='Gromacs', dir=dir,
>>> prefix='dhdl', suffix='xvg', T=298, skiptime=10,
>>> uncorr='dhdl', threshold=50,
>>> methods=('mbar', 'bar', 'ti'), out='./',
>>> resultfilename='result.out', overlap='O_MBAR.pdf',
>>> breakdown=True, forwrev=10, log='result.log')
The goal of Flamel will be to transform this python interface into CLI.
There are obviously reasons against this assignment as it would be a departure from the alchemlyb philosophy & principles
It includes functions for parsing data from formats common to existing MD engines, subsampling these data, and fitting these data with an estimator to obtain free energies.
These functions are simple in usage and pure in scope, and can be chained together to build customized analyses of data.
alchemlyb seeks to be as boring and simple as possible to enable more complex work.
However, there are also reasons for this assignment.
The first would be to avoid code duplication. From what I can see, the decorrelation part will be a duplication of the alchemistry/alchemlyb#98.
The second is that when more workflows are available, it will be easier to move part of the code that is used by many workflow (e.g. the unit conversion) from the workflow part to the library part, instead of moving the code from one Github repo to another repo.
The third reason is that it will be easier to release Flamel. The current Flamel has a plugin structure that mimics alchemlyb. So there are two questions, do we want to write the doc for each plugins and do we want to test these plugins? Once alchemistry/alchemlyb#114 is merged, the Flamel could be refactored into a simple CLI and we might not need tests and dedicated docs to release it.
@orbeckst @harlor @danijoo
I think it might be good to have a discussion about the future of flamel and its relationship with alchemlyb, before committing to it.
My vision of the alchemlyb would be that it would have two parts, the library part and the workflow part.
The workflow part currently only have the ABFE workflow (alchemistry/alchemlyb#114), which provides the same interface as the alchemical-analysis.
The goal of Flamel will be to transform this python interface into CLI.
There are obviously reasons against this assignment as it would be a departure from the alchemlyb philosophy & principles
However, there are also reasons for this assignment.
The first would be to avoid code duplication. From what I can see, the decorrelation part will be a duplication of the alchemistry/alchemlyb#98.
The second is that when more workflows are available, it will be easier to move part of the code that is used by many workflow (e.g. the unit conversion) from the workflow part to the library part, instead of moving the code from one Github repo to another repo.
The third reason is that it will be easier to release Flamel. The current Flamel has a plugin structure that mimics alchemlyb. So there are two questions, do we want to write the doc for each plugins and do we want to test these plugins? Once alchemistry/alchemlyb#114 is merged, the Flamel could be refactored into a simple CLI and we might not need tests and dedicated docs to release it.