Library build

[esteinig]

Aim:

Production grade library for pathogen phylodynamics

Ideas:

• XMl wrappers for safe model building in BEAST
• bacterial phylodynamics module:
  • species specific configurations / workflows from raw data (TB, MRSA, Kleb...)
  • clonal expansion coalescent model (CaveDive) [collaboration]
  • birth-death skyline models (BDSky and MTBD) [based on our papers]
• SARS-CoV-2 models for variants and national / subnational configs [collaboration SSI]
• Nanopore preprocessing using Random Forests [based on preprint]
• integration with Nextflow to run BEAST + BEAGLE on GPU

Features:

• pydantic model oriented
• dynamic config of models
• test suites + docs
• user friendly releases
• command line interface

Deployment:

• FastAPI server + Vue
• continuous integration

[esteinig]

I'd like to make model classes that can be inherited to define specific sub-models. Models represent configurations of the BEAST XML and are built from XML blocks (critter.blocks)

from critter.models import BirthDeathSkylineSerial

class MRSA(BirthDeathSkylineSerial):
    pass

Each model inherits from the base Critter class.

[esteinig]

For the terminal client configuration, it'd be cool if we could use YAML templates that configure the model (and can be default configured by users) and let users modify arguments not provided in the file for on-the-fly command line configuration.

I have a template with the base click library for this, but would rather use Typer so need to check out how to modify the context object (since it depends on click it should be managable)

[esteinig]

Updated to reflect YAML configuring the CLI

[Wytamma]

Very cool 😎 I like this idea. I think having the model specification/XML generation separated from any deployment would be very useful for 3rd parties wanting to use this library. Also would it be possible to cut out the YAML and have users directly specify the models in python (eg dataclass)? This would enable easy dynamic model creation.

[esteinig]

Yeah awesome, we should do that! I think the YAML thing still comes from letting users specify their own template for the command line interface, e.g. when users provide a template for a self configured model: configure an empty string for a parameter required to be specified on the command line or the user is prompted in interactive mode (-i)

Does that makes sense? That way users can specify their CLI commands for specific models in a template file. I have updated the image above to reflect that.

param1: default value
param2: ''
param3: null

In the CLI:

Interactive, prompts user for param2

critter -i -t template.yaml

Required command line:

critter -t template.yaml --param2 test

Can you explain the dynamic config? I'm not too familiar! Maybe I'm thinking too much on the interactive user end right now.

[Wytamma]

Yes! I think that’s a great way to do it. I’m just thinking more about it as a library that is consumed by other apps than an application used by users, but both are important. Programmatic control of BEAST config would be very useful and would open up an interface between python and BEAST.