Help for hypermutation lineage trees reconstruction interpretation

[NoELJ22]

Hello,

I have an interpretation question about the hypermutation lineage trees reconstruction

In my BCR analysis, i have 2 timepoints, Day0 and Day7. The .clns files were merged at the findShmTrees step.
When I constructed the lineage trees, i had trees with D7 Ig not connected to D0 ig.
So I don't understand the origin of these D7 Ig.

Thank you for your help

[PoslavskySV]

Hi,

thank you for reaching us. Could you please elaborate more about your analysis: source material, prep protocol / kit, MiXCR commands and reports. That will greatly help us to answer your question.

[amikelov]

Hi @NoELJ22

Thanks for sharing, your have a very nice script, which however can be improved a bit.
Here are several tips:

1. First of all, you are using a preset for CDR3 clonotype assembly, while you need a preset for full-length assembly. You should have used a much simpler command with a full-length preset. There is no need for any additional parameters, tag-pattern and everything is already included in the preset.

mixcr analyze takara-human-bcr-full-length                    \
   --prepend-export-alignments-field uniqueTagCount UMI   \
    in1.fastq.gz     in2.fastq.gz   output_prefix

This is the full equivalent of your upstream command, which is within the cycle.

2. Actually the problem with this data is not at the trees step or interpretation.
   You have quite low clonotype count and extremely low fraction of reads used, e.g.
   Reads used in clonotypes, percent of total: 11737 (0.54%), which is due to the fact that many of the reads are dropped due to the lack of clonal sequence.
   Reads dropped due to the lack of a clone sequence, percent of total: 1337308 (61.57%)
   Here is the non-obvious part. You have 300*300 and totally correct assembly feature, and everything should be fine.
   But if we take a look at the align report we can see that number of overlapped reads is extremely low.
   Overlapped: 250498 (11.53%)
   and that there was a lot of conflicts at the ends:
   Paired-end alignment conflicts eliminated: 1060905 (48.85%)
   Which suggests that you have some issues with the sequencing quality at the ends of your reads.
   So it would be great to take a look at fastQC reports for your reads.

3. If my suggestion is true and there are quality issues, you can try running mixcr analyze command, turning on quality-based read trimming and loosing the requirements for read overlapping. You can do this by adding these options to the analyze command:

  -Malign.trimmingQualityThreshold=10 \
  -Malign.parameters.mergerParameters.identityType=MinimalQualityWeighted \
  -Malign.parameters.mergerParameters.minimalIdentity=0.7 \

Hope this helps. If you can attach the fastQC reports, I guess, we could tell for sure what is the root of the problem.

[PoslavskySV]

FYI - you don't need to use --prepend-export-alignments-field uniqueTagCount UMI, UMI count is exported by default

[NoELJ22]

Thank you very much for your clear answers.

I attach the FastQC reports :

fastqc_data_Lib31J0_S8_L001_R1_001.txt
fastqc_data_Lib31J0_S8_L001_R2_001.txt
fastqc_data_Lib34J7_S11_L001_R1_001.txt
fastqc_data_Lib34J7_S11_L001_R2_001.txt

I tried to restart the mixcr analysis with your recommendations. I slightly increase the clonotype count. I also attach the new alignment reports.
Lib31_214_J0.assemble.report.txt
Lib34_214_J7.assemble.report.txt

If I look at tree id13 (formerly 51) I see that there are more Igs connected but still no D0.

treeId	nodeId	isObserved	parentId	DistanceFromGermline	cloneId	fileName	readCount	readFraction
13	0	false		0
13	4	false	0	13
13	14	true	4	91	276	Lib34_214_J7.reassigned.clns	124	0.000532312209697
13	42	true	4	18	0	Lib34_214_J7.reassigned.clns	17877	0.076743107844737
13	42	true	4	18	679	Lib34_214_J7.reassigned.clns	13	5.58069252101345E-05
13	52	false	42	56
13	53	true	52	67	695	Lib34_214_J7.reassigned.clns	12	5.1514084809355E-05
13	54	true	53	70	548	Lib34_214_J7.reassigned.clns	24	0.000103028169619
13	55	true	52	59	602	Lib34_214_J7.reassigned.clns	18	7.72711272140324E-05
13	56	true	42	20	482	Lib34_214_J7.reassigned.clns	36	0.000154542254428

I'll see if by working on the settings -Malign.trimmingQualityThreshold and -Malign.parameters.mergerParameters.minimalIdentity, I can improve that.

Thanks again.

[amikelov]

Hi, how is it going? any news on tweaking the trimming and overlap parameters?

Sequencing looks actually quite bad, I wonder if your sequencing provider could redo it - seems that the problem was on their side.
I also thought about a different option - you can try use a discontinuous assembly feature with a gap in the middle, e.g. -OassemblingFeatures=["{FR1Begin:CDR2End(+20)},{CDR3Begin:FR4End}"]. MiXCR can infer alleles and build trees even in such configuration.

On the other hand, the situation when you don't observe the members of the same lineage in d0 may be pretty normal, especially if the donor is naive for this antigen. I believe that at this depth even if memory B-cells were present at steady state the chances that you have not sampled are quite high.
Take a look at a guide from our webinar for the B-cell lineage tracing.
https://docs.milaboratories.com/mixcr/guides/b-cell-lineages-webinar/#visualizations

This is PBMC replicates comparison. Each dot is a lineage here,while lineage abundance is on the axes.
As you can see that replicability in steady state is not that great actually, even though our sample size was not small, PBMCs from ~10 ml of blood as I remember.

Hope this helps, would be interested to hear any updates about the case :)

[amikelov]

By the way you could use mixcr exportAlignmentsPretty command to export the alignments in human-readable format to see where there are problems in overlap and it could help you to select the best feature if you are up to trying a discontinuous assembly feature as I suggested in my previous post.

[NoELJ22]

Hello,

After testing different values and -OassemblingFeatures, the parameters

-Malign.trimmingQualityThreshold=10 \
  -Malign.parameters.mergerParameters.identityType=MinimalQualityWeighted
  -Malign.parameters.mergerParameters.minimalIdentity=0.7

allow to give the best results without loosing too much alignment quality.

Normally the PBMC used comes from donor who has already met the virus. So the donor shouldn't be naive for this antigen.

We did a test with Vidgil, and we found a D0 clone with the same sequence as clone id 0 D7 (in the tree id 13). Vidgil doesn't use UMI, but this D0 clone had few raw counts, so UMI must be even less.

So the fact that some D0 Ig have low counts and that we have a quality problem, means that we have probably lost some D0 Ig in the lineage trees reconstruction.

In any case, thank you very much for your time and your help

[NoELJ22]

Hello,

I tried to add-OassemblingFeatures=["{FR1Begin:CDR2End(+20)},{CDR3Begin:FR4End}"]option to improve the assembly step. But we still with Reads used in clonotypes, percent of total: 217680 (10.02%) in D7 sample. I attach the reports :

Is there any other option to try to improve the number of reads sed in clonotypes, in the assemble step ?

Lib31_214_J0.report.txt
Lib34_214_J7.report.txt

Thank you.

[PoslavskySV]

Hi,

it does not look like you can improve much with the software, as it is definitely wet lab problem. E.g. for J7 file the number of overlapped reads is very low (~40%) (for good quality 300+300 Takara kit we typically see ~90% of overlapped reads); at the same time 90% of reads are aligned which means that even alignments can't be overlapped unambiguously. Potential reason is really bad sequencing quality. You can try to make a more aggressive quality trimming. Also, if you can share raw data with us, we will provide you a more detailed reasons (you can reach us at [email protected] to share raw data).

Stan

[NoELJ22]

Thank you,
I will send my raw data at [email protected]

Thank you a lot for your help.

[PoslavskySV]

Hi,

thank you for sharing the data.

We've inspected alignments manually with exportAlignmentsPretty and the reason became obvious. You can also check pretty alignments on your end and will see everything right on the spot. Sequencing was completely failed (as the FastQC report also suggests), and the quality of reads is extremely low resulting in a very high rate of sequencing errors. As result it's not possible to align full-length of VDJ receptor or even to overlap R1 and R2 (as it should be for 300+300 Takara kit). Thus, it's not possible to extract reliable clones from this data and especially it's not possible to do any kind of somatic analysis.

There is nothing else can be done here on the data analysis side. Takara BCR kit is a very good choice for such task and UMIs are "must have" for SHM and lineage analysis. The only one solution to obtain results which one can trust is to re-do sequencing.

Please, feel free to reach us if you have any further questions both regarding data analysis and wet lab parts.

[NoELJ22]

Ok, thanks a lot for your times and your help