what dose the "N" mean in the targetSequences filed?

[Angieiscute]

I've observed that the exported tsv files contain numerous reads with 'N' in the sequence. I utilized the exportAlignmentsPretty function to examine the original reads from VDJCA file and noticed that the positions with 'N' just differ from the germline sequence. Wouldn't it be more appropriate to use a lowercase letter instead of inserting 'N' in these positions?

Thanks!

Such as,

GGAGGTCTCAGAGAGGAGCCTTAGCCCTGGACTCCAAGGCCTTTCCACTTGGTGATCAGCACTGAGCACAGAGGACTCACCATGGAATTGGGGCTGATCTGGGTTTTCCTTGTTGCTGTTTTAGAAGGTGTCNAGTGNNANNNNCGNNGAGTCGCGTATAATGTAGTCTTGGNNNNNGNGGNNNC,TAAACCCTGATAGAAGTGAATTCTATGTGGACTCTGTGAAGGGCCGATTCACCATCTCCAGAGACAACGGCAAGAACTCACTGTATCTGCAAATGAATAGCCTGAGAGTCGAGGACTCGGCTGTATATTACTGTGCAAAAGAAGCAGGAACCCACTGGGGCCAGGGAACCCTGGTCACCGTCTCCTCAGCATCCCCGACCAGCCCCAAGGTCTTCCCGCTGAG

[mizraelson]

Hi,

Does the original read include the 'N' nucleotides? An alignment displays how the original read sequence matches up to the reference. If the sequence has 'N' nucleotides, they will appear in the target sequence of the alignment. This mismatch (an unidentified nucleotide in this context) will impact the alignment score. However, this ambiguity might be resolved during clone assembly if multiple reads covering the same position clearly identify a specific base pair there.

Sincerely,
Mark

[Angieiscute]

Hi Mark,

Looks like the original reads don't contain N nucleotides, I have compared the exportClones files with exportAlignmentsPretty file as shown below,

seems like it's just a mismatch but not N.

Thanks!

[mizraelson]

I see, the N nucleotides present in the clonotype table and not in alignments. In that case most likely there was an ambiguity between different alignments that comprise the clone. You can backtrack all alignments that were assembled into the clone and check the nucleotide at this position. If most alignments would have reported the same nucleotide at this spot (even if it is a mismatch relative to the reference) you would have seen this nucleotide in the clonal sequence.

[mizraelson]

MiXCR 3 followed the same logic in clonotype assemble. If its possible to share with us the raw file and the command you used, I can take a look and give a more detailed answer.

[Angieiscute]

oh, yes, could you please share an email and I will share the raw files with you by Google Drive link. Thanks!

[mizraelson]

support@milaboratories.com

[Angieiscute]

Hi, I have emailed you the raw files. Thanks!

[Angieiscute]

Hi, is -OdiscardAmbiguousNucleotideCalls (Discard ambiguous calls (no use of 'N's).
) the option to turn the function off? If yes, how do I use this option?

mixcr assembleContigs -f -OdiscardAmbiguousNucleotideCalls=null alignment.clna alignment.clns ?

Thanks!

I tried the above command, it turns out the error,

picocli.CommandLine$ExecutionException: Error while running command assembleContigs java.lang.IllegalArgumentException: Multiple matches of parameter discardAmbiguousNucleotideCalls
at com.milaboratory.mixcr.cli.Main.registerExceptionHandlers$lambda-12(SourceFile:340)
at picocli.CommandLine.execute(CommandLine.java:2088)
at com.milaboratory.mixcr.cli.Main.main(SourceFile:98)
Caused by: java.lang.IllegalArgumentException: Multiple matches of parameter discardAmbiguousNucleotideCalls
at com.milaboratory.o.BU.a(SourceFile:87)
at com.milaboratory.o.BU.a(SourceFile:83)
at com.milaboratory.o.BU.a(SourceFile:1070)
at com.milaboratory.o.k.invoke(SourceFile:122)
at com.milaboratory.o.ea.invoke(SourceFile:42)
at com.milaboratory.cli.CommandWithParametersKt$sam$com_milaboratory_cli_POverride$0.apply(SourceFile)
at com.milaboratory.o.s.resolve(SourceFile:188)
at com.milaboratory.o.s.resolve$default(SourceFile:171)
at com.milaboratory.mixcr.cli.CommandAssembleContigs$Cmd.run1(SourceFile:174)
at com.milaboratory.mixcr.cli.MiXCRCommandWithOutputs.run0(SourceFile:69)
at com.milaboratory.mixcr.cli.MiXCRCommand.run(SourceFile:37)
at picocli.CommandLine.executeUserObject(CommandLine.java:1939)
at picocli.CommandLine.access$1300(CommandLine.java:145)
at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
at com.milaboratory.mixcr.cli.Main.registerLogger$lambda-26(SourceFile:447)
at picocli.CommandLine.execute(CommandLine.java:2078)

[mizraelson]

Hi,

In that case the 'N' nucleotides originate from the assembleContigs command. The algorithms for this command have undergone a complete revision, and several critical bug fixes have been implemented since version 3. There are various reasons why 'N' nucleotides may arise, such as low quality, which is deemed unreliable, too few data to resolve into different clonotypes (for example, if you have two alignments with a different nucleotide at a certain position, there isn’t enough information to confirm they are indeed two different clones), or the discrepancy may be outside of the subcloning region (the region where ambiguous nucleotides lead to splitting into two clones). Given how the function operates, it becomes quite challenging to simply substitute all 'N' nucleotides with the most abundant nucleotides, and doing so would not be the correct approach. For instance, if there are two 'N' nucleotides close to each other, and we know they are covered by a single read, we cannot just substitute these 'N' nucleotides independently.

You are correct; you can use -OdiscardAmbiguousNucleotideCalls=true. In this case, 'N' nucleotides will be replaced by a germline.