Hi, I need to cut 27 nt in R1 is it normal that --clip_r1 27 also cuts 27nt in R2 ? It is problematic because it remove my c primer which is at the beginning of R2. Thank you in advance for your help

Hi @Justine, it shouldn’t be the case, I just double checked and seems like the code for it is ok and there is no accidental swap of r1 - r2. We use fastp for that. Do you have any adapters in your data? You could try also passing the `--trim_fastq false`param, in case that adapter trimming is creating this issue.

Thanks for your answer. Apart from this sequence of 27nt at the beginning of R1 just before the UMI + race linker no. If I use --trim_fastq false, this will prevent cutting the first 27 nt of my R1, won't it? I've tested by taking umi_lenght = actual length of UMI + 27nt and it works. Is there any contraindication to doing it this way?

Hi Justine,

--trim_fastq

controls adapter trimming,

--clip_r1 / r2

controls read clipping. So with

--clip_r1

now everything is fine and only R1 reads are clipped? Or is there still an issue with the R2 read clipping?

Hi @Gisela Gabernet, thanks for the explanations. --umi_length 18 --clip_r1 27 --trim_fastq false keep cut also 27nt in R2.

ok I see, I will fix it in the next version of the pipeline to also provide

--trim_front2 0

. Meanwhile, you can fix this in your case by providing a custom configuration file that specifies the necessary params for fastp. Instead of providing the extra clip params to the airrflow command provide this:

-c custom.config

And then inside the custom config you can provide the fastp necessary params:

process{
  withName: FASTP{
    ext.args = "--trim_front1 27 --trim_front2 0 --trim_tail1 0 --trim_tail2 0"
  }
}

Thank you very much for your reply, It works but I lose a lot of sequences because in some cases the upstream sequence is truncated by a few bases and so it shifts the search of my race linker after the 18 nt of the UMI in R1. I try to use fastp --adapter_sequence=GACTAGGCAGTGGTGTGACCGCAGAGT but it doesn't cut.