new workflow: subsample_by_metadata_with_focal #161
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new WDL workflow,
subsample_by_metadata_with_focal
, which provides a functionality I've been doing manually/offline until recently. This subsets an externally provided dataset of sequences to a more manageable sample size with even representation across metadata-defined categories (e.g. geographic). It does so by splitting the external dataset into two categories: one termed focal and one termed global, and applying different sample count limits (and bin resolutions) to each, before remerging. Current defaults are based on GISAID column headers and use North America as a focal region--but these defaults might be removed in the future to remain data source and user base agnostic.This workflow can optionally accept a "priorities" matrix so that the random sampling is biased towards the user's genomes of interest. However, a future version of this workflow should just accept the user's genomes of interest instead and compute the priorities matrix for them.
This PR additionally includes adjustments to the
filter_subsample_sequences
WDL task to convert theinclude_where
andexclude_where
input types fromString?
toArray[String]?
, which better reflects how they would be used, and keeps a cleaner way of describing input values with spaces and special characters, which are better tolerated now.