Adding consensus_count / umi_count filter

[lauratwomey]

Description of feature

Hi!

Thanks so much for this amazing pipeline, love it! It works seamlessly so far and everything is really clean and tidy.

I have been processing different data types with Immcantation suite for a few years now and I'm used to filtering out sequences with very low umi counts / consensus counts. I guess it's sometimes hard to distinguish sequencing errors vs real SHM in rare clonotypes, but I prefer to err on the side of conservatism and remove sequences that don't have enough reads to back them up.

I believe the pipeline already removes sequences that have < 2 representative sequences (the documentation says it's in "presto/10-splitseq" but I think for bulk it's in the trust4 folder? ). However, I'm referring to a later step, once the final clonotypes are assembled, before they are piped into the clonal analysis. You already apply quite a few filters based on sequence quality, productive or not, etc, but I was wondering whether it would be easy enough for you to add an optional "consensus_count" and/or "umi_count" filter (you could set the default to 0).

I've implemented this in a local copy of
/researchers/laura.twomey/Tools/omics_tools/nf-core/nf-core-airrflow/5_1_0/bin/reveal_mod_3_junction.R
(attached), but it would be probably cleaner if this were a separate module.

Just a suggestion! If this is not something you recommend I'd also would like to know your opinion on it - do you trust sequences with only 1 count // 1 umi ?

Thanks so much!

Laura

reveal_mod_3_junction.txt

[Vivian0105]

Hi @lauratwomey. For bulk data, we already have the step to remove sequences with less than 2 consensus count for protocol with UMI or to remove sequences with less than 2 dupcount for protocol without UMI. It's by module presto_splitseq and you can find the default configuration of the module here:

You can customize the configuration by providing customized ext.args for that specific step.

[lauratwomey]

Ah, thanks so much @Vivian0105 ! It took me a while to figure this out, but I think the issue is that since my data is bulk RNA-seq without UMIs (i.e., not a targeted amplicon library with primers), the pipeline correctly routed me through TRUST4 rather than either pRESTO branch. So pRESTO doesn't run at all, which is why I was getting clonotypes with very low read counts at the end of the pipeline.

1. I can't find an airrflow parameter to filter TRUST4 sequences by consensus count - did I miss it? The only thing I can think of is TRUST4's parameter "--contigMinCov" which is by default 0. It could be provided as --ext.args, but wondering if this is the right filtering parameter and at the right step.
2. If it is, would it be possible for you to provide this filtering parameter (as well as pRESTO's dupcount/conscount) as an nf-core parameter? I feel like it's quite useful and it's easier to just add it to the nf-core params.yml file with other common custom settings!
3. And just for my sake - wondering if you could help me as I am not sure where to find a full list of parameters for airrflow - I've checked the nextflow.config or nextflow_schema.json files already but not sure if they include everything.

Thanks so much!

[Vivian0105]

Hi @lauratwomey. If you are talking about bulkRNAseq, it's a different story. I'd like to have some investigation and inner discussion before giving you a thoroughly reply.

[lauratwomey]

Hi @Vivian0105 , no problem, looking forward to your reply!

[Vivian0105]

Hi, @lauratwomey. I viewed TRUST4 document carefully and I don't think the parameter "--contigMinCov" is the one you are looking for. It ignores contigs that have bases covered by fewer than INT reads.

[Vivian0105]

@lauratwomey As to the question on full list of nf-core/airrflow parameters, you can find them here:
https://nf-co.re/airrflow/5.1.0/parameters/

[Vivian0105]

@lauratwomey We are considering adding additional step to filter out sequence on "consensus_count" and/or "umi_count" mainly for TRUST4 processed data in our next nf-core/airrflow release.

[lauratwomey]

Thanks so much for looking into this @Vivian0105 !

You're totally right about the --contigMinCov - that's not really what we want.
And yes, I knew about the parameters page, but I guess I was referring to a more complete list of parameters, some of which may only be available as ext.args.
Great to know - looking forward to the next release so!