[BioC] NucleR: processReads/solveUserSEW0 - Error

[Stefanie Ververs]

I got some new information, recently:
A statistical report on the converted SAM-file says:

16512892 in total
0 QC failure
0 duplicates
16512892 mapped (100.00%)
16512892 paired in sequencing
8256446 read1
8256446 read2
16512892 properly paired (100.00%)
16512892 with itself and mate mapped
0 singletons (0.00%)
0 with mate mapped to a different chr
0 with mate mapped to a different chr (mapQ>=5)


Seems, as if line 16512893 is the last one or somehow corrupt.
Additionally, I need to use some "cleaning" tools on our data, so I'll 
do that and try to run NucleR/RangedData later again.
Thanks for your help so far!

Steffi


On 03.11.2011 14:39, Martin Morgan wrote:
> On 11/03/2011 06:14 AM, Oscar Flores wrote:
>> So this error happens here, no?
>>
>> res = RangedData(IRanges(start=position(ar),width=width(ar)),
>> strand=strand(ar),space=ar at chromosome)
>
> better to use the accessor chromosome(ar). The error
>
> > Fehler in solveUserSEW0(start = start, end = end, width = width) :
> > solving row 16512893: range cannot be determined from the supplied
> > arguments (too many NAs)
>
> suggests that position(ar)[16512893] and / or width(ar)[16512893] is 
> NA. You could filter these out, e.g., ar[!is.na(position(ar)) & 
> !is.na(position(ar))] or identify why these are read in in the first 
> place using the 'param' argument as described on ?readAligned.
>
> Martin
>
>>
>> If this is the case the problem is not in nucleR, maybe there are some
>> rows in a strange format in the AlignedRead (could be due the multiple
>> format changes) that may avoid the conversion to the RangedData. Maybe I
>> can detect them and skip those cases, but I would need to see what's
>> happening in that odd case.
>>
>> Let me know if there's something I can do.
>>
>> Regards,
>>
>> Oscar
>>
>>
>> El 03/11/2011 13:58, Stefanie Ververs escribió:
>>> Hi Oscar,
>>>
>>> thanks for your quick answer - I think I would have contacted you, if
>>> there were no answers on the bioconductor-mailinglist.
>>>
>>> I just tried the workaround as you suggested, but I got the same error
>>> again:
>>> Fehler in solveUserSEW0(start = start, end = end, width = width) :
>>> solving row 16512893: range cannot be determined from the supplied
>>> arguments (too many NAs)
>>> Calls: RangedData -> is -> IRanges -> solveUserSEW0 -> .Call
>>>
>>> I'll think about how to show you the data (it's hosted and processed
>>> with Galaxy, so it might be possible to share it.)
>>>
>>> Regards,
>>>
>>> Steffi
>>>
>>> On 03.11.2011 13:16, Oscar Flores wrote:
>>>> Hi Stefanie,
>>>>
>>>> I'm the developer of nucleR, so let's see if I can help you ;)
>>>>
>>>> After the processing, processReads converts the input data to a
>>>> RangedData
>>>> object for a easier manipulation later, so this error is occurs at
>>>> the last
>>>> step of the call, but data can be messed in previous steps. It's
>>>> hard to tell what is happening without having a look to the input 
>>>> data,
>>>> which I guess is huge...
>>>>
>>>> I would like to have a look to the raw data, but I know it is 
>>>> difficult
>>>> to send it if it's not in a public repository. Maybe you can 
>>>> contact me
>>>> directly about that (oflores at mmb.pcb.ub.es)...
>>>>
>>>> Meanwhile, if you want to try a workaround, you can directly 
>>>> convert the
>>>> imported reads to RangedData format (which is the other format 
>>>> supported
>>>> by processReads):
>>>>
>>>> (being "ar" your imported AlignedReads object)
>>>>
>>>> res = RangedData(IRanges(start=position(ar),width=width(ar)),
>>>> strand=strand(ar),space=ar at chromosome)
>>>>
>>>> reads_pair = processReads(res, type="paired", 
>>>> fragmentLen=fragment_len)
>>>>
>>>> This should work, but will be nice to have a look to your data
>>>> to fix a possible problem in the AlignedReads method.
>>>>
>>>> Regards,
>>>>
>>>> Oscar
>>>>
>>>> _______________________________________________
>>>> Bioconductor mailing list
>>>> Bioconductor at r-project.org
>>>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>>>> Search the archives:
>>>> http://news.gmane.org/gmane.science.biology.informatics.conductor
>>>
>>
>
>