hi all. Are there any plans/developments to support Element Aviti data in sarek going forward. I'm working with this data. I believe GATk wont accept PL tag of `element`so I was thinking of adding this to the meta (in via samplesheet) to potentially use that in modules to switch between aviti and illumina command options . Or via params to switch between illumina and element workflow options as required. eg running lofreq viterbi (only for illumina data) & indelqual upstream of lofreq call or not. Any thoughts would be great.....

That would be great, we did some superficial benchmarking a couple years ago and didn't run into this, but we might have been lucky. Looks like the samtools spec have it? https://samtools.github.io/hts-specs/SAMv1.pdf Do you know if any particular GATK versions are affected, or any minimal version which might have changed the behavior from what we saw? Either way, if this is the case, would the sequencing_platform parameter already cover this, or do you have different PL tags per sample?

Thanks for fast reply Rike. For me, I can happily add seq_platform param of 'ELEMENT', . But I'm not using GATK functionality in my sarek configuration/workflow. I thought if using the GATK elements in sarek (eg MArkduplicates or recalibration) it may fail as wont accept

PL:ELEMENT

according to brief internet search - although I haven't tested this and you seem to indicate this isn't the case.. Anyway, I've been playing with a lofreq_comp custom module, which has lofreq viterbi and lofreq indelqual upstream of lofreq call (in one module for path of least resistance currently) . So I may then use the seq_platform param to switch on/off the viterbi task (don't want this for element data) . I had thought it would be good to have the platform added to the meta (via the samplesheet), but that may not work?

I think it would techinically be possible to switch the param to a meta, especially if people are mixing samples from different platforms and need to handle this in the pipeline, which it sounds like you might have?

Yeh I can see your point about switching to meta, which was my thought too. I'm not mixing in same run currently myself though, but would be more flexible for others if that was an option.. Just tried it and seems to be fine.

that would be great. Adding @Simon Pearce for umi and consensus calling

I did add some options for UMI extraction using fastp

hi Simon. I think we had a bit of a message exchange on that a while back. I needed/thought best (for our needs at least) to have the trimming inside the umi workflow (before the grouping/consensus stuff), and using cutadapt rather than fastp, which allows more involved trimming such as that I have at 5' end of our particular libraries (phased adopter after the umi ).

Yeah, that sounds familiar

Ok. If you want to see what I've done, I should be able to share (i'll check internally). Caveat is that I've added quite a few bits to our pipeline base in same git feature currently (it's a nfcore-sarek fork ).