Brian,
I've just had a second look and found the reason the conversion stops at
scan 99999:
The default upper scan number in the options struct is set to 99999:
MzXML2Search.cxx:117
iLastScan = 99999;
Then just before the main loop it's used to set the value used to
terminate the main loop:
MzXML2Search.cxx:344
if (iAnalysisLastScan > options.iLastScan)
iAnalysisLastScan = options.iLastScan;
If the option default is changed to a higher value then the
outputMGF(..) function would need to be changed to write >5 digit scan
numbers. Don't know whether this would have an effect downstream :-(
If you would still like the mzML file as an example let me know where I
can upload it. It's 1.5GB gzipped.
Cheers,
DT
Brian Pratt wrote:
> Returning to the behavior of mzXML2Search, just eyeballing the code I don't
> see any reason it should fail at scan numbers > 99999. Perhaps the problem
> is actually downstream from mzXML2Search? While mzXML2Search should quite
> happily emit 6 digit MGF scan numbers, I can imagine a consumer of MGF might
> not see that coming.
>
> Perhaps you could furnish an example of the msconvert output that's giving
> you trouble? Eyeballing the code only gets one so far, it's ideal to see it
> actually running in the debugger.
>
> Brian Pratt
>
> On Tue, Nov 17, 2009 at 6:33 AM, Dave Trudgian
> <[email protected]<mailto:[email protected]>> wrote:
>
> Matt,
>
> We just apply a (low) absolute threshold. Different values for different
> instruments, but it's most critical on the Agilent and Water's QTOFs, as
> without any threshold there are 1000s of peaks.
>
> Look forward to seeing the filtering in msconvert.
>
> DT
>
>
> Matt Chambers wrote:
>> What kind of thresholding do you do? Enabling that in msconvert is
>> overdue - the backend code to support it is already in place.
>>
>> MzXML2Search is failing because it depends on a strict DTA name scheme
>> with 5 digits. This is going to break with long LTQ Velos runs so it
>> needs to be fixed regardless of the Agilent scanId issue. It's ironic
>> that a Thermo file is the one to break the Thermo-centric assumptions. :P
>>
>> -Matt
>>
>>
>> dctrud wrote:
>>> MzXML2Search conversion to mgf fails for me on mzXML / mzML created
>>> using msconvert from Agilent 6520 QTOF data.
>>>
>>> Trapper numbers spectra using an index starting at 1, whilst msconvert
>>> uses the Agilent scan ID (can be a very large number). MzXML2Search
>>> conversion of the resulting file into mgf then fails once it reaches a
>>> scan ID > 99,999.
>>>
>>> Have seen similar problems with other programs and contacted Matt
>>> Chambers who said that the numbering would stay the same, and that
>>> it's better if programs which can't cope with the large numbers are
>>> fixed. Is this possible (desirable?) for MzXML2Search and any other
>>> TPP tools that might be affected?
>>>
>>> I can't use Trapper as I need to extract Profile MS + Centroid MS/MS
>>> from a dual mode file (msconvert supported). I can't directly convert
>>> to mgf with msconvert as I need to do peak thresholding to get file
>>> sizes down to a reasonable level.
>>>
>>> Cheers,
>>>
>>> DT
>>
>
>
> --
> Dr. David Trudgian
> Bioinformatician in Proteomics
> University of Oxford
>
> Mon-Thu: CCMP, Roosevelt Drive
> Tel: (+44) (01865 2)87784
>
> Friday : Dunn School of Pathology, S. Parks Rd.
> Tel: (+44) (01865 2)75557
>
>
>
> >
>
--
Dr. David Trudgian
Bioinformatician in Proteomics
University of Oxford
Mon-Thu: CCMP, Roosevelt Drive
Tel: (+44) (01865 2)87784
Friday : Dunn School of Pathology, S. Parks Rd.
Tel: (+44) (01865 2)75557
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"spctools-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/spctools-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
