feat: aligners & variant callers - #282
adthrasher wants to merge 214 commits into
Conversation
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
a-frantz
left a comment
There was a problem hiding this comment.
phew 😮💨 a lot of code to go through. Still skimmed a good chunk of the code, but wanted to get another round of comments out. This asks a lot of questions again.
There was a problem hiding this comment.
nothing off the shelf we could find for this one?
There was a problem hiding this comment.
Biocontainers has a single old tag (4.0.1: https://quay.io/repository/biocontainers/ngsep?tab=tags) and the project, itself, just provides a Dockerfile (https://github.com/NGSEP/NGSEPcore/blob/master/Dockerfile).
I think this is another tool we can consider just dropping. I only implemented the SingleSampleVariantsDetector method, but it is an entire Java framework for next-gen sequencing data.
|
|
||
| The following list is sorted alphabetically: | ||
|
|
||
| ## af-only-gnomad.hg38.chrY_chrM.vcf.gz |
There was a problem hiding this comment.
is this VCF suitable for general use? I don't see any reason in this description we can't plop it in the existing fictures/vcfs dir and use as a test in non-mutect2 tests (not suggesting you add it to existing tests, but if its in the repo a future PR might want to add it for an extra case)
There was a problem hiding this comment.
It's gnomAD stripped to just the allele frequency field for hg38. I further stripped it down to chrY and chrM. In theory another tool could try to use it, but I think that would be a bad idea. It's a custom Broad reference file used for this specific pipeline
https://gatk.broadinstitute.org/hc/en-us/articles/360050722212-FAQ-for-Mutect2:
Finally, "af-only-gnomad.hg38.vcf" is a copy of the gnomAD VCF stripped of all unnecessary INFO fields.
| } | ||
| } | ||
|
|
||
| task sort { |
There was a problem hiding this comment.
we don't already have this one?
There was a problem hiding this comment.
It appears not. We have sort tasks in picard, sambamba, and mako.
There was a problem hiding this comment.
Is there a reason you've added this instead of using one of those?
At this point I'd call the picard sort battle-tested, and given what we know of bioinformatics tools, I wouldn't be totally surprised if there's some niche edge case where samtools sort hogs resources or otherwise fails.
Not objected to adding the sort task for completeness, but I think it makes sense to use one of the other implementations in workflow calls. Picard for being reliable, sambamba or mako for performance. Basically I don't see any reason to use samtools sort over one of those.
| output_format: { | ||
| description: "The output format for alignments", | ||
| options: [ | ||
| "gam", | ||
| "gaf", | ||
| "json", | ||
| "tsv", | ||
| "SAM", | ||
| "BAM", | ||
| "CRAM", | ||
| ], | ||
| } | ||
| preset: { | ||
| description: "vg giraffe preset for alignment", | ||
| options: [ | ||
| "chaining-sr", | ||
| "default", | ||
| "fast", | ||
| "hifi", | ||
| "r10", | ||
| "srold", | ||
| ], | ||
| } |
| } | ||
| } | ||
|
|
||
| task calmd { |
There was a problem hiding this comment.
I'm guessing there are other options not exposed here? Can we log that somewhere? Maybe a meta field acknowledging "minimum working implementation"?
| bam: "Input BAM format file to sort" | ||
| sort_order: { | ||
| description: "Order by which to sort the input BAM", | ||
| choices: [ |
There was a problem hiding this comment.
should we drop the choices convention when there's an enum?
There was a problem hiding this comment.
To me, it depends on what sprocket doc does? If it in-lines the enum, then I'd favor removing choices, but if it doesn't, I think having the choices listed in the task doc is good. Though it means maintaining two lists.
There was a problem hiding this comment.
sprocket dev doc --open will show you what it currently does (and any complaints, I am returning to work on the doc command soon so they can be addressed soon-ish)
It doesn't inline the variants, but it does link to the page with the enum definition
|
|
||
| requirements { | ||
| container: "google/deepvariant:1.10.0-gpu" | ||
| #container: "google/deepvariant:1.10.0" |
There was a problem hiding this comment.
| #container: "google/deepvariant:1.10.0" |
| output_prefix: "Prefix for output VCF and gVCF files" | ||
| model_type: { | ||
| description: "Type of model to use for variant calling", | ||
| choices: [ |
There was a problem hiding this comment.
same here about dropping the choices field
| @@ -0,0 +1,83 @@ | |||
| version 1.3 | |||
|
|
|||
| enum SortOrder[String] { | |||
There was a problem hiding this comment.
do these need doc comments, and should sprocket lint be checking for doc comments?
| requirements { | ||
| container: "quay.io/biocontainers/vg:1.70.0--h9ee0642_0" | ||
| cpu: ncpu | ||
| memory: "120 GB" |
There was a problem hiding this comment.
Real world data without VCF files
index (1 attempt)
#0 completed wall 54m00s queued 30.2s 4 cpu, 111.8 GiB peak 82.6 GiB, cpu 87m26s
I am also running with VCF files from 1000genomes.
There was a problem hiding this comment.
In progress run with VCF files:
MEMLIMIT SWAPLIMIT
111.7 G 111.7 G
MEMORY USAGE:
MAX MEM: 98.9 Gbytes; AVG MEM: 18.5 Gbytes; MEM Efficiency: 88.54%
Note that our LSF submission ends up allocating less RAM than specified in the WDL.

Adds new WDL task implementations:
hisat2NGSEPI also created a new evaluation directory under workflows (maybe it should be placed somewhere else) that has workflows for running a sample through multiple analyses in parallel for comparison purposes.
Before submitting this PR, please make sure:
scripts/ordocker/directories, please ensure any image versions have been incremented accordingly!