DSL2 - Genotyping on unmerged libraries

[ilight1542]

Aida mentioned that the default behavior of always collapsing libraries within a single sample for input into genotyping may be inappropriate when mutliple libs have different UDG treatment status/damage models, etc.

Modifying necessary for the input channel generation for genotyping to be able to either get unmerged or merged data.

Unmerged data also necessitates changes to the prefix and tags for all processess where previously only unique sampleIDs would be sufficient.

[TCLamnidis]

@aidaanva @ilight1542
Was looking through the PR for the second time, when I realised I am not entirely sold on the idea. Sorry if this is not the first time you have to explain it (it could be my lack of coffee atm), but I did not see this discussion documented anywhere:

• Is this added complexity actually needed?
• How would this be different from the user tweaking their TSV file to give each library a different Sample_ID? Unless the genotypes from each library get merged to a sample level eventually? But aren't we then back to square one?

[ilight1542]

Pull #1126 is basically 2 main sets of changes - (1) I think should definitely be maintained, (2) I do not have strong opinions on (and the adjustment/functionality is relatively easy for an end user to figure out on their own using a just changes to the input TSV).

1. Removes the dependency of saving damage manipulated (rescaled, masked) bam files from running genotyping

• Users can run all damage tools they wish, and save them independently, without having to figure out that to save any damage manipulation
• The current behavior means that to save any outputs of damage manipulation steps (only one allowed), the user has to designate this for the genotyping input, run genotyping, and save genotyping. None of these parameters would be intuitive to find for an end user who would just want to run damage manipulation.

2. Allows for genotyping library-by-library

• @aidaanva please give your input on this
• Could be useful for niche applications where a single biological sample (eg bone) was sampled across different regions...
• But as @TCLamnidis mentioned to me, it would be easily possible to just adjust the input TSV names for the sample names to instead reflect library names, if the non-merging behavior is desired.

[ilight1542]

If we decide for one or the other -- the changes for 1 and 2 are mostly independent of one another, so it should be easy to walk them back to just do the updates to how damage manipulation is run/saved OR the changes for running genotyping at a lib-by-lib basis :)