Addressing some issues with the comparison #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dear Colleagues,
I am one of the maintainers of MiXCR and read your preprint with a great interest. I have few modifications and suggestions to make the comparison of different software more fair.
Phred quality scores
Sequencing machines provide sequencing quality scores specifically to address the issue of sequencing errors. MiXCR, compared to many other tools, takes into account Phred quality scores provided by the sequencer. By default, it drops all the reads with low quality in CDR3 (thus with high probability of having a sequencing error), and the default threshold is 20. For fair comparison, one need to switch off this behaviour and allow MiXCR to use low quality reads as other tools do. This can be done with the following option:
This will significantly increase the outcome from MiXCR and make the comparison more fair.
Productive clones
Originally, you use
--only-productive
filter of clonotypes in MiXCR (drop all clones with stop codons and oof's), but the filtering used in/for other tools is different. I suggest to remove this filter in MiXCR for fair comparison or use the same filter across all tools.Total read count comparison
Also, when comparing total read counts reported by different tools, you use different count metrics. The following issues introduce technical differences in the reported values:
-OaddReadsCountOnClustering=true
option on theassemble
step).All in all, I believe this metric can't be used for comparison, or requires thorough normalization procedures to bring all the numbers to the same scale. A simpler and more practical metric would be the number of reported true CDR3 clonotypes.
False positive clones
When comparing clonotypes one need to distinguish between true clones and false positives. In both MiXCR and TRUST you can export raw reads that were used to assemble clonotypes and manually inspect which clones are real and which are obvious false-positive calls.
For example, one of the top clonotypes reported by TRUST from PRJNA812076 sample is:
CDR3 nt:
TGTGCGAACACCGGGGAGCTGTTTTTT
CDR3 aa:
CANTGELFF
This is a false-positive (spurious) clonotype coming from genomic sequences (it is easy to check it by BLASTing raw reads reported by the tool for the clonotype). It is among the top clonotypes, and what is really alarming is that it is reproduced across different samples, which may lead to wrong biological conclusions.
So, right now this clone with high read count is accounted as "advantage" in TRUST while, obviously, this is a great disadvantage of the software, as it may lead you to wrong biological conclusions.
Summarizing, for fair comparison I suggest to use just the number of clones and to carefully distinguish between true and false clonotypes reported by the software, accounting the number of "true" clonotypes as "plus" and "false" clonotypes as "minus".
Will be happy to discuss these suggestions further.
All the above applies to MiXCR 3.0.13, which was the latest version when the preprint was published. If you plan to use MiXCR in other studies for analysis of RNA-Seq or other types of data, I strongly recommend using the latest MiXCR version which is 4.2.0 (at the moment this is written), we continue to put a lot of work in optimizing the algorithms and tuning the parameters, aside from the new feature development.