ERROR: Unknown combination found when converting to basespace: [M] & [T]

[GoogleCodeExporter]

the documentations doest describe what this error means, or where it comes 
from, and if the sequence tag causing it can by skipped.

What version of the product are you using? On what operating system?
1.0.1307 Ubuntu 8.10 x86_64

Original issue reported on code.google.com by justin.n...@gmail.com on 15 Oct 2009 at 9:19

[GoogleCodeExporter]

Thanks Justin. This is definitely a bug dealing with colorspace/basespace 
conversion
in the presence of IUPAC ambiguity codes. I'll check into the problem tomorrow 
at work.

Original comment by snowneb...@gmail.com on 16 Oct 2009 at 2:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Looking over the code, this error should never happen during normal 
circumstances.
This error implies that the current colorspace base was M with and the T is 
encoded
for the colorspace transition 4.

Look over the command-line options. It seems as if you may have used the 
basespace
reference with the -ia parameter and the colorspace reference with the -ibs
parameter. That's the only scenario that seems to make sense in this case.

If this is not the case, maybe you can provide me with the command-line that 
was used.

Cheers,

// Michael

Original comment by snowneb...@gmail.com on 16 Oct 2009 at 3:07

• Changed title: ERROR: Unknown combination found when converting to basespace: [M] & [T]

[GoogleCodeExporter]

I checked the -ia/ibs parameters and it looks like the correct references are 
being passed. To 
make sure i reversed the parameters, which resulted in no alignments.

The command line i entered is:
MosaikAligner -in r35l1.dat -out r35l1.mosaik -ibs hg18.genomic.um.csdat -ia 
hg18.genomic.um.dat -m unique -mm 10 -mmp 0.5 -mhp 2 -bw 25 -j hg18.genomic.um 
-p 15

I'm using 50bp Solid reads against hg18 unmasked. I suspect there are cetain 
tags causign the 
error, but have no way to located the input sequnce, since Mosaik doesnt report 
the input that 
caused ther error. 

My crude fix was to split up my input csfasta data and align in smaller 
batches, and skipping 
the batch that causes Mosaik to die. If i get a chance ill try to narrow in on 
a smaller batch 
of data and upload a sample for you. Using this file splitting method i get an 
average of 25% 
unique and 43% non-unique (which is expected for our RNA-seq when aligning 
genomically), so i know it works on at least some of the data.

Thanks again for your help

Original comment by justin.n...@gmail.com on 16 Oct 2009 at 3:41

[GoogleCodeExporter]

Thanks Justin!

Whenever you have the chance, I would be more than happy to investigate the 
batch
that is invoking the bug.

Original comment by snowneb...@gmail.com on 16 Oct 2009 at 4:11

[GoogleCodeExporter]

I have a similar problem. When I am running Mosaikaligner on SOLiD-mate pairs 
(4 different libraries) it aborts every single time, while SOLiD fragments work 
fine.

A typical command that generates the error is:
MosaikAligner -in rd13.dat -out rd13_aligned.dat -ia Gallus_gallus_2.1_cs.dat 
-ibs Gallus_gallus_2.1.dat -hs 15 -mm 6 -mhp 100 -act 25 -j gg.15 -p 8 -m all  
-rur rd13.unmapped.reads 

 typical error messages:
Aligning read library (163626211):
 0% [                                     ]                                  |ERROR: Unknown combination found when converting to basespace: [N] & [N]

Aligning read library (158462097):
 0% [                                     ]                                  |ERROR: Unknown combination found when converting to basespace: [A] & [-]

Aligning read library (156532778):
 0% [                                     ]                                  |ERROR: Unknown combination found when converting to basespace: [T] & [-]

Original comment by carl.ru...@gmail.com on 6 Jul 2010 at 6:08

[GoogleCodeExporter]

We realized the bug occurs when converting color-space alignments to base-space 
ones. We have fix the bug in 1.0.1388 version.

Original comment by WanPing....@gmail.com on 1 Oct 2010 at 8:57

• Changed state: Fixed

[GoogleCodeExporter]

the issue seems fixed for 1.0.1388 but persists for 1.1.0014.

Original comment by carl.ru...@gmail.com on 20 Oct 2010 at 11:29

[GoogleCodeExporter]

1.1.0014 cannot handle IUPAC codes in the reference.
Is the same issue in your cases?

Original comment by WanPing....@gmail.com on 20 Oct 2010 at 2:09

• Changed state: Accepted