Menu
▾
▴
Re: [proteowizard-developer] SRMs and wiff files
|
From: Parag M. <spa...@gm...> - 2010-08-09 18:21:36
|
Hiya,
Dumb question - is it slow in the conversion, or in the access? If just access, why couldn't you play the same trick with msConvert?
Thx.
~ Parag M ~
On Aug 9, 2010, at 10:50 AM, Natalie Tasman wrote:
> FYI, mzWiff is about to be officially retired from the TPP
> distribution-- finally, in favor of msconvert! -- , although older,
> unmaintained versions will likely continue to be available on the
> sourceforge project page for sashimi. So you might want to think
> about adding a switch in msconvert to be able to use the older Waters
> API for those that have it (the same audience as could run mzWiff).
>
> Just my 2 cents.
>
> -Natalie
>
>
>
> On Sun, Aug 8, 2010 at 9:42 AM, Brendan MacLean <bre...@pr...> wrote:
>> By the way, I am interested to hear more detail on the source of
>> "the MultiQuant dll which apparently extracts the data much faster". Was it
>> just that you have imported this data into MultiQuant, and the import was
>> much faster? Or does this come from a conversation with AB Sciex on the
>> performance issue you raise? Just curious.
>>
>> On Sun, Aug 8, 2010 at 9:20 AM, Brendan MacLean <bre...@pr...>
>> wrote:
>>>
>>> Hi Jamie,
>>> Yes, this is a known issue with the WiffFileDataReader (from
>>> ProteinPilot), especially if you are working with scheduled transitions.
>>> For scheduled runs there also appears to be some issue with how the data is
>>> getting recorded during acquisition, because a set of WIFF files with the
>>> same number of scheduled transitions as a set of WIFF files containing
>>> unscheduled transitions consume about 6 times as much disk space as the
>>> unscheduled transitions, where other systems tend to scale relative to the
>>> ratio of the scheduling interval to the gradient length. i.e. for a
>>> 5-minute window on a 90 minute gradient, you would expect to see scheduled
>>> files 1/18 the size of the unscheduled files for the same transitions. At
>>> least they should go in that direction and not get larger, as they do with
>>> WIFF files.
>>>
>>> AB Sciex is aware of this issue, and we have been pushing them to get it
>>> fixed both in acquisition and in chromatogram extraction. In December, they
>>> promised a fix in January. In March, we heard it had turned out to be more
>>> complex than expected. In June, their revised estimate was only 'not
>>> soon'. Still we continue to push.
>>>
>>> All that said, however, the Analyst API is able to extract these
>>> problematic chromatograms much quicker than WiffFileDataReader, albeit still
>>> somewhat slower than similar data from Thermo and Waters (Agilent has a
>>> similar performance issue, though not quite as bad). Unfortunately, Analyst
>>> is not freely available, and MultiQuant is even more restricted, though
>>> perhaps they use the same library. How many would AB Sciex have?
>>>
>>> So, the current work-around in use for Skyline is to use mzWiff (from the
>>> TPP) to produce mzXML from these WIFF files, and then reconstruct
>>> chromatograms from the resulting mzXML spectra recorded by mzWiff (which
>>> discards all zero intensity measurements).
>>>
>>> Good luck! I will of course let this alias know, if we see a fix from AB
>>> Sciex for the issue. I would encourage all owners of AB Sciex instruments,
>>> especially owners of 5500 QTraps (evidence of customer loyalty), to contact
>>> AB Sciex and lobby for this fix, as prioritization is critical to delivery.
>>>
>>> --Brendan
>>>
>>> On Fri, Aug 6, 2010 at 2:01 PM, Jamie Sherman <jam...@gm...>
>>> wrote:
>>>>
>>>> I'm hitting performance issues with SRM data.
>>>> I'm attempting to convert 5500 QTrap files to txt in order to analyze
>>>> them in an automated way.
>>>> I wrote a simple program to extract the traces which works however it is
>>>> painfully slow. By painfully
>>>> I mean I have a file with 2000 transitions and it has taken 2 days to
>>>> extract the data. The data collection
>>>> only took an hour and a half.
>>>> If I convert files (slow) then use the program to extract the SRM data,
>>>> the extraction from mzML in fast.
>>>> This makes me suspect it's the ProteinPilot dll that's slow. Are there
>>>> any plans to make use of the
>>>> MultiQuant dll which apparently extracts the data much faster?
>>>> I doubt the code I wrote is the issue but just in case.
>>>> I wrote the function below mirroring the cat call in mscat.cpp. Would I
>>>> do better to use a passive analyzer
>>>> approach? Is there a more clever approach I haven't thought of?
>>>> Thanks in advance for any help / comments.
>>>> --Jamie
>>>>
>>>> Below is the function that I wrote.
>>>> void cat(const char* filename, ostream &myOut)
>>>> {
>>>> // open the data file
>>>> FullReaderList readers; // for vendor Reader support
>>>> MSDataFile msd(filename, &readers);
>>>>
>>>> // verify that we have a SpectrumList
>>>> if (!msd.run.chromatogramListPtr.get())
>>>> throw runtime_error("[mscat] No spectra found.");
>>>>
>>>> ChromatogramList& chromatogramList = *msd.run.chromatogramListPtr;
>>>>
>>>> // check the output file stream
>>>> if (!myOut) {
>>>> throw runtime_error("[srmcat] unable to open/create file for output.");
>>>> }
>>>>
>>>> // iterate through the spectra in the SpectrumList
>>>> for (size_t i=0, size=chromatogramList.size(); i!=size; i++)
>>>> {
>>>> // retrieve the spectrum, with binary data
>>>> const bool getBinaryData = true;
>>>> ChromatogramPtr chromatogram = chromatogramList.chromatogram(i,
>>>> getBinaryData);
>>>> ChromatogramIdentity chromid = chromatogramList.chromatogramIdentity(i);
>>>>
>>>> // check if it's a srm chromatogram
>>>> CVParam chrom =
>>>> chromatogram->cvParam(MS_selected_reaction_monitoring_chromatogram);
>>>> if(chrom == CVID_Unknown){
>>>> vector<CVParam> params = chromatogram->cvParams;
>>>> cerr << "Skipping index(" << i << "), scan descriptors: " << endl;
>>>> for (vector<CVParam>::iterator j = params.begin(), end = params.end(); j
>>>> != end; j++ ) {
>>>> cerr << "\t" << j->name() << endl;
>>>> }
>>>> cerr << endl;
>>>> }
>>>>
>>>> CVParam precursorParam =
>>>> chromatogram->precursor.isolationWindow.cvParam(MS_isolation_window_target_m_z);
>>>> CVParam productParam =
>>>> chromatogram->product.isolationWindow.cvParam(MS_isolation_window_target_m_z);
>>>> if (precursorParam == CVID_Unknown) continue;
>>>>
>>>> myOut << "SIM Scan=" << i
>>>> << " Precursor m/z=" << setprecision(3) << atof(
>>>> precursorParam.value.c_str() )
>>>> << " Fragment m/z=" << setprecision(3) << atof(
>>>> productParam.value.c_str() )
>>>> << " id=\"" << chromid.id << "\"" << endl;
>>>>
>>>> myOut << "BEGIN SIM" << endl;
>>>>
>>>> // fill in MZIntensityPair vector for convenient access to binary
>>>> data
>>>> vector<TimeIntensityPair> pairs;
>>>> chromatogram->getTimeIntensityPairs(pairs);
>>>>
>>>> // iterate through the m/z-intensity pairs
>>>> for (vector<TimeIntensityPair>::const_iterator it=pairs.begin(),
>>>> end=pairs.end(); it!=end; ++it)
>>>> {
>>>> myOut
>>>> << fixed << setprecision(3) << (it->time * 60.0) // time in seconds
>>>> << " "
>>>> << fixed << setprecision(0) << it->intensity << endl;
>>>> }
>>>> myOut << "END SIM" << endl;
>>>> }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by
>>>>
>>>> Make an app they can't live without
>>>> Enter the BlackBerry Developer Challenge
>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>> _______________________________________________
>>>> proteowizard-developer mailing list
>>>> pro...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> proteowizard-developer mailing list
>> pro...@li...
>> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> proteowizard-developer mailing list
> pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
|