Deletion state parameterization

[yashpatel6]

Description

Adding customization option for which states to delete with the metapipeline

Testing Results

Outputs: /hot/software/pipeline/pipeline-recalibrate-BAM/Nextflow/development/unreleased/yashpatel-parameterize-deletion-by-state

• '/delete_both/' - delete both normal and tumor BAMs
• /delete_tumor_only/ - delete only tumor BAM

Checklist

• I have read the code review guidelines and the code review best practice on GitHub check-list.

• I have reviewed the Nextflow pipeline standards.

• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].

• I have set up or verified the branch protection rule following the github standards before opening this pull request.

• I have added my name to the contributors listings in the manifest block in the nextflow.config as part of this pull request, am listed
  already, or do not wish to be listed. (This acknowledgement is optional.)

• I have added the changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

• I have updated the version number in the metadata.yaml and manifest block of the nextflow.config file following semver, or the version number has already been updated. (Leave it unchecked if you are unsure about new version number and discuss it with the infrastructure team in this PR.)

• I have tested the pipeline on at least one A-mini sample.

[tyamaguchi-ucla]

Looks good! Was this requested by an end user or more for debugging purposes? @yashpatel6

[yashpatel6]

This is actually to resolve users running metapipeline with 1 normal, multiple tumors in paired mode; in that case, call-gSNP deletes the normal BAM after the first tumor and we end up getting an error with the next tumor since it requires the normal BAM.

[Faizal-Eeman]

If this is meant as a customizable option, wouldn't it be better to move this to template.config or add a placeholder in template.config for users to define if they want to delete tumor or normal?

[yashpatel6]

Generally, this option is for customization but not for general users; it's meant for customization through the metapipeline to handle the issue in my comment above

A user running this pipeline shouldn't be using the metapipeline_* params since they would end up deleting input BAMs anyways; these options are specifically to handle deletion for metapipeline to optimize /scratch usage

[Faizal-Eeman]

gotcha!

[Faizal-Eeman]

looks good

[tyamaguchi-ucla]

This is actually to resolve users running metapipeline with 1 normal, multiple tumors in paired mode; in that case, call-gSNP deletes the normal BAM after the first tumor and we end up getting an error with the next tumor since it requires the normal BAM.

Ah, now I recall the context. Did the user who encounter the error open an issue? (maybe the user used the metapipeline-repo?) If not, We would want to keep a record of the actual example.

[yashpatel6]

This is actually to resolve users running metapipeline with 1 normal, multiple tumors in paired mode; in that case, call-gSNP deletes the normal BAM after the first tumor and we end up getting an error with the next tumor since it requires the normal BAM.

Ah, now I recall the context. Did the user who encounter the error open an issue? (maybe the user used the metapipeline-repo?) If not, We would want to keep a record of the actual example.

I'm the user who encountered the issue during testing, with the same samples I use for the multi-sample testing, just in paired mode 👀

[tyamaguchi-ucla]

This is actually to resolve users running metapipeline with 1 normal, multiple tumors in paired mode; in that case, call-gSNP deletes the normal BAM after the first tumor and we end up getting an error with the next tumor since it requires the normal BAM.

Ah, now I recall the context. Did the user who encounter the error open an issue? (maybe the user used the metapipeline-repo?) If not, We would want to keep a record of the actual example.

I'm the user who encountered the issue during testing, with the same samples I use for the multi-sample testing, just in paired mode 👀

Got it. This is still related to the Mutect2 issue that we recently fixed, right? Just wanted to understand the context a bit more.

[yashpatel6]

Not exactly related; this is just a case (multi-tumor run in paired mode) that we haven't encountered since adding the metapipeline input deletion to call-gSNP so it's coming up now and will be included when I update metapipeline to split call-gSNP

[tyamaguchi-ucla]

Not exactly related; this is just a case (multi-tumor run in paired mode) that we haven't encountered since adding the metapipeline input deletion to call-gSNP so it's coming up now and will be included when I update metapipeline to split call-gSNP

Got it. Thanks for the clarification!