Problem with mixcr analyze command #1354
-
Hi! I try to make analysis of MiSeq human TCR data with 100bp paired reads both with UMI 12 bp. Last independent attempts had another problem: All of them were interrupted with error But I don't see this mistake Could you help me please to make correct all pipeline commands for my type of data? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 4 replies
-
May be problem is with parsing by ' ' and '\n'? And didn't catch a mistake |
Beta Was this translation helpful? Give feedback.
-
Hi, Also, do you mean that every read (r1 and r2) starts with 12nt UMI? Is it a 5'RACE or multiplex? |
Beta Was this translation helpful? Give feedback.
-
Hi! $ head Control2_TRB_R1.fastq |
Beta Was this translation helpful? Give feedback.
-
It appears the files have undergone processing, including UMI correction, and the reads are merged. I strongly recommend retrieving the original files, so MiXCR can handle the correction internally. The error you've mentioned seems to stem from preprocessing. While I didn't notice Understanding the library preparation protocol is crucial, as it guides the subsequent analysis. Based on the reads you provided, my guess is that you're working with a 5'RACE protocol. Given that R1 has a short sequence that likely only covers the 5'UTR, the original UMI was probably sequenced in R1. Meanwhile, R2 starts with a C gene-specific primer and spans the CDR3 region. As a result, you can disregard the R1 file since it doesn't sufficiently cover the V gene. I suggest using the following command:
Nevertheless, the ideal approach involves locating the original raw FASTQ files and performing UMI correction within MiXCR. Once you have those files and a description of the library structure, I'll be happy to assist further with the command. |
Beta Was this translation helpful? Give feedback.
It appears the files have undergone processing, including UMI correction, and the reads are merged. I strongly recommend retrieving the original files, so MiXCR can handle the correction internally.
The error you've mentioned seems to stem from preprocessing. While I didn't notice
' '
and'\n'
symbols in your initial message, the presence of these symbols could disrupt the original FASTQ format.Understanding the library preparation protocol is crucial, as it guides the subsequent analysis. Based on the reads you provided, my guess is that you're working with a 5'RACE protocol. Given that R1 has a short sequence that likely only covers the 5'UTR, the original UMI was probably sequenced in…