New module: BEAST

[jsbrittain]

A module to launch (or resume) a BEAST (v1) analysis is provided.

To run directly:

• Clone this repo, change to the BEAST folder, then run snakemake --cores 1 --use-conda (remember to prefix with CONDA_SUBDIR=osx-64 if running on Apple arm64 hardware).

To run through grapevne

• Add jsbrittain/snakeshack into the repo list, Get Remote Modules, then filter by Utility. Drag BEAST into onto the canvas and inspect.

Resolves: #8

[jsbrittain]

@joetsui1994 Here's the BEAST module. Now is a good time to consider any further user-facing information (e.g. extending the docstring), or changes to the exposed parameters that we would want to make. Feel free to comment on this thread (or directly on the files); I can push further changes to the module to this PR before we agree that it is ready to merge.

[joetsui1994]

Is there an option to not write a state file to disk (which I think is the default setting if the save_every argument is not given)?

[jsbrittain]

Is there an option to not write a state file to disk (which I think is the default setting if the save_every argument is not given)?

@joetsui1994 I've modified the Snakefile so that the user can disable state file output by setting the save_every parameter to 0. Note that this will disable 'resuming', which is now reflected in the docstring.

[joetsui1994]

I noticed that this is currently running BEAST v1.10.4. I'm wondering how this is done, and if it is a straightforward task to switch between different version of BEAST, or would you create a different module for each version (for example, for quite a few of the analyses we are running, we are using the v1.10.5 version)?

The only thing I would add to the docstring is probably the version number, so

This module can start and/or resume a BEAST (v1.10.4) analysis by saving a state file at regular intervals (this option can be disabled, see below).

Otherwise this looks good I think. @rhysinward

[jsbrittain]

I noticed that this is currently running BEAST v1.10.4. I'm wondering how this is done, and if it is a straightforward task to switch between different version of BEAST, or would you create a different module for each version (for example, for quite a few of the analyses we are running, we are using the v1.10.5 version)?

@joetsui1994 That's a great question. Briefly, the BEAST version is specified in the conda environment file (I had actually left this unpinned, but have pinned it now to use 1.10.4 and mentioned this in the docstring). I haven't considered adjustable version numbers in general, but in principle we could set up different environment files for different versions and link to the version specified by the user (e.g. provide a dropdown list of supported versions [1.10.4, 1.10.5] and let the user select which one to use; these could then link to environment files [beast_1_10_4.yml, beast_1_10_5.yml]; I tried this out briefly and it seems viable). This would also take care of dependency lists, and would not require any changes in GRAPEVNE, but the problem with this approach is that the parameters fed into the software itself might change, so could be implemented in each module as desired. For BEAST 1.10.5 in particular, I notice that it has been in pre-release for many years now and is not on bioconda, so may be better placed in a separate 'pre-release' module. I think I will open a discussion post, or add this as a concept into the GRAPEVNE docs so that we don't forget about the idea.

[joetsui1994]

A dropdown list of supported versions sounds like a great idea, and potentially we can adjust the list according to whether there are substantial differences in the required parameters. For BEAST specifically, from experience the difference is minimal (or none) since it is mostly the inner calculations that are being updated/changed. But this feature should be relevant to a lot of other packages.