UMIs artificial diversity eliminated is high

[NoELJ22]

Hello,

I would like your opinion on the quality control of our results, because we have the impression of having lost a lot of clonotype after the UMI correction.

We're working on human PBMC cultured in vitro. The first sample is not stimulated (D0_1-355_NS) and the second is stimulated with an Ag and recovered 7 days later (D7_1-355_M10).
For sequencing, the NEBNext® Immune Sequencing was used. I used mixcr 4.5 with the preset neb-human-rna-xcr-umi-nebnext

Code used :
#Sample D0_1-355_NS :

mixcr analyze neb-human-rna-xcr-umi-nebnext \
   --remove-step exportClones \
   D0_1-355_NS_S1_L001_R1_001.fastq.gz D0_1-355_NS_S1_L001_R2_001.fastq D0_1-355_NS.gz

mixcr exportReports D0_1-355_NS.clns D0_1-355_NS.report.txt 
mixcr qc exportReports D0_1-355_NS.clns  D0_1-355_NS.report.txt  

#Sample D7_1-355_M10 :

mixcr analyze neb-human-rna-xcr-umi-nebnext \
   --remove-step exportClones \
   D7_1-355_M10_S4_L001_R1_001.fastq.gz D7_1-355_M10_S4_L001_R2_001.fastq.gz

mixcr exportReports D7_1-355_M10.clns D7_1-355_M10.report.txt 
mixcr qc exportReports D7_1-355_M10.clns  D7_1-355_M10.report.txt  

The reports for sample D0_1-355_NS indicate :

#Fichier .qc.txt
   Successfully aligned reads:                           79.73% [WARN] 
   Reads used in clonotypes:                             72.67% [WARN]
   UMIs artificial diversity eliminated:                 89.64% [ALERT]
#Fichier .report.txt
Final clonotype count: 2097
IGH chains: 58 (2.77%)

For sample D7_1-355_M10 :

#Fichier .qc.txt
   Successfully aligned reads:                           84.41% [WARN]
   Reads used in clonotypes:                             78.48% [WARN]
  UMIs artificial diversity eliminated:                 90.88% [ALERT]
#Fichier .report.txt
Final clonotype count: 3959
IGH chains: 166 (4.19%)

In the doc, it's said that this may be due to poor sequencing quality, but the quality on the fastQC seems good.

Do you think there's a problem we've missed, or do the results seem reliable ?

I attach the report and fastQC files via filesender:
D0_1-355_NS.qc.txt
D0_1-355_NS.report.txt
D7_1-355_M10.qc.txt
D7_1-355_M10.report.txt
FastQC : https://filesender.renater.fr/?s=download&token=1fe2dcf4-71b4-40cc-b893-72da88425698

Thank you for your help

[mizraelson]

The UMI barcode here is located at the beginning of R2, and we can see some drops in sequencing quality within this region:

My guess is that might be the reason. Nevertheless, in you report files:

  UMI output diversity: 24927 (10.36%)
  UMI output reads: 7514686 (99.27%)
 .
 .
 .
  Filter report:
    Number of groups: 24927
    Number of groups accepted: 12365 (49.6%)
    Total records weight: 7514686
    Records weight accepted: 7487967 (99.64%)
    Operator #0:
      Effective threshold: 20.0
      Nested thresholds:
        #0: 20
        #1: 384

Despite the fact that UMI diversity was severely corrected, the number of lost reads is minimal, around 1%, indicating that around 90% of the UMIs have been supported by a very low number of reads. This is an example of how important this step of the pipeline is. I would say the results are reliable, and you didn't lose much data, while correcting a lot of artificial UMI sequences.

The Alignment failed: no hits (not TCR/IG?): 1622984 (17.08%) is relatively high, but we have observed such numbers for this protocol in some cases. If necessary, you can manually inspect such non-aligned reads by adding --output-not-used-reads to the mixcr analyze command.

[NoELJ22]

Thank you for your help.
We were surprised because we had already used the same protocol for another project, which gave radically different results, with better diversity.
We're going to redo the tests to make sure there were no problems during sample preparation before sequencing.