[spctools-discuss] Re: Database SEQUEST search SLOW!
Natalie Yes, I am doing an in house sequest search. I generate the .srf files from .raw files and then use the .srf files to convert them to pep.xml using mspire. This takes much less time than using the pipeline. Good point about the scan numbers in mzXML files and pep.xmlI will make sure they are the same. I will be giving all the search algorithms a try soon... Ali On Jul 17, 6:18 pm, Natalie Tasman natalie.tas...@insilicos.com wrote: Ah, ok, I see that mspire takes Thermo .srf files, which I believe are the newer Sequest search result files (http://mspire.rubyforge.org/tutorial/search_precision/prophet.html). Since this method hasn't been validated by us, you'll want to be sure that the scan numbers in the mzXML files still refer to the scan numbers in the mspire-converted pep.xml. So in your method you *are* doing a search step, and are still using Sequest. You might want to give X!Tandem a try! Natalie On Fri, Jul 17, 2009 at 10:10 AM, Natalie Tasmannatalie.tas...@insilicos.com wrote: Ok. Just to let you know, you will need to do *some* search step in order to make use of the TPP. mspire is a completely independent project and is not supported by the TPP (although looking at their website, it seems that they try to be compatible at least in formats). So I think you're missing the peptide ID phase, which is the info that .pep.xml files should contain. Feel free to educate me about about mspire if I'm wrong. On Fri, Jul 17, 2009 at 6:54 AM, Alia.alsha...@googlemail.com wrote: Hi Natalie I used sequest. I've sort of given up on that. I now convert my .raw files directly to .pep.xml files using mspire. Its not much of a pipeline anymore but it does the job. Regards Ali On Jul 15, 9:19 pm, Natalie Tasman natalie.tas...@insilicos.com wrote: Hi Ali, Greg made some good comments on your post regarding the Sequest search engine. I'm curious as to what search engine you're using. The TPP includes X!Tandem, which is generally significantly faster than Sequest, and is multi-threaded (and free, so you can even consider running it across a cluster-- something we're hoping to make easier in the future). Note, though, all search engines, including X!Tandem, are affected by the search parameters that you use. So a semi-tryptic search will generally always take longer than a full-tryptic search but increase the search space (which is good), so it's always going to be a trade-off. We include some default X!Tandem parameter files; as you get more experience, you might want to play with modifying some of the parameters to optimize your search. Natalie On Fri, Jul 10, 2009 at 6:59 AM, Greg Bowersock bowers...@gmail.com wrote: Sequest is not very fast. The only way to really speed up sequest is to give it more processors, provided you are using sequest in a way that will allow you to use the extra processors. There are many factors that affect the speed of processing though, with the two largest being the type of digestion and the size of the database. The number of modifications also plays a role in the amount of time, so as you can see there isn't any one way to really speed up sequest. Also, 10 hours isn't all that bad, try doing a no-enzyme search on a decent sized database, that can take days on 1-2 processors. On Fri, Jul 10, 2009 at 4:42 AM, Ali a.alsha...@googlemail.com wrote: Hi everyone I am doing some databse search with mzXML files generated from Thermo .raw files against my database. I have a duo core 2GB RAM machine. I understand that TPP does not use multi-threading but one mzXML file seems to take 10 hours to process!! Is there anyway I can speed up this process? Regards Ali --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups spctools-discuss group. To post to this group, send email to spctools-discuss@googlegroups.com To unsubscribe from this group, send email to spctools-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en -~--~~~~--~~--~--~---
[spctools-discuss] Re: trapper fails when large files processed
Hello Ilya,
The error explains the problem error getting spectrum
empty scan object. The error is referring to the follow bit of
code:
215 MH::BDA::IBDASpecData* MHDACWrapper::GetSpectrum
(MH::IMsdrDataReader* pMSDataReader,
216
double retentionTime,
217
MH::MSScanType scanType,
218
MH::IonPolarity ionPolarity,
219
MH::IonizationMode ionizationMode,
220
MH::IMsdrPeakFilter* filter,
221
VARIANT_BOOL* filterOnCentroid)
222 {
223 MH::BDA::IBDASpecData* specData = NULL;
224 COMCHECK(pMSDataReader-GetSpectrum_7(
225 retentionTime,
226 scanType,
227 ionPolarity,
228 ionizationMode,
229 filter,
230 *filterOnCentroid,
231 specData),
232 error getting spectrum);
233
234 return specData;
235 }
The failure is on a COM object call to an Agilent software library
function call. Are you sure there is actual data in the file you are
giving to trapper to convert? Have you opened this data file in an
agilent viewer? Would you mind posting your raw data to our FTP site
(instructions here
http://tools.proteomecenter.org/wiki/index.php?title=TPP:Frequently_Asked_Questions#How_do_I_upload_files_to_the_SPC_tools_team.3F)?
We can then try to reproduce your problem in a debugger to find the
cause of failure.
-David
On Jul 8, 5:32 am, Ilya.Agron ilya.ag...@gmail.com wrote:
Hello.
The last time I've used it the error looked this way:
E:\trappertrapper.exe --mzXML -c E:\trapper\MasKate1-r001.d
single mode file
(got computer name: RIGHT)
ERROR at .\MHDACWrapper.cpp, 227:
HR = -2147024882
error getting spectrum
empty scan object
E:\trapper
What could it be?
May be, it's not memory problem. There's Windows OS.
What's Tranche? Is it free upload resource?
Sure, I can and want to upload it.
Thanks!
On Jul 7, 8:16 pm, David Shteynberg dshteynb...@systemsbiology.org
wrote:
Hello Ilya,
I have not used trapper but in a situation like this a more detailed
description of the failure may be needed. Are there any error
messages produced? What is the system you are running trapper on?
What else have to tried to address this issue? Can you post a problem
file to Tranche and share the key so we can try to reproduce the
problem here?
-David
On Thu, Jul 2, 2009 at 12:26 AM, Ilya.Agronilya.ag...@gmail.com wrote:
There's a question about the trapper in TPP (Win-version).
Now we use trapper to convert .d (Agilent-files, Q-ToF) in mzXML; and
then use Decon2ls to process it into deconvoluted and deisotoped data
for AMT approach. It's our work flow very shortly.
There's problem, that we can't process with trapper large files (as
our4.5Gbchromatograms). It fails during the processing. Is it the
problem of the memory?
May you advise something to solve this problem?
Thanks in advance!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
spctools-discuss group.
To post to this group, send email to spctools-discuss@googlegroups.com
To unsubscribe from this group, send email to
spctools-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/spctools-discuss?hl=en
-~--~~~~--~~--~--~---
[spctools-discuss] Re: What the mean of LIBRA (0),LIBRA (1)..LIBRA (n) in .prot.xml
Hello, You can find this information in the Libra documentation page at: http://sashimi.svn.sourceforge.net/viewvc/sashimi/trunk/trans_proteomic_pipeline/src/Quantitation/Libra/docs/libra_info.html Specifically: *The value 99.99 *indicates that a protein's quantition was calculated using only peptide, and so the standard error is infinite. *The value -9.0 *indicates that no peptides of the protein survived the threshhold filter and outlier removal, so the protein quantitation is undefined. Cheers, --Luis On Thu, Jul 16, 2009 at 11:42 PM, Bright hqz...@gmail.com wrote: Hi everyone I get a result of iTRAQ, I don't know the mean of Libra(0) 114.0: -9.00 ± -9.00 116.0: -9.00 ± -9.00, LIBRA (6) 114.0: 0.48 ± 0.01 116.0: 0.52 ± 0.01 and LIBRA (1) 114.0: 0.45 ± 99.99 116.0: 0.55 ± 99.99 when I check my result in web page. Could you tell how the understand the mean of LIBRA (n), -9.00 ± -9.00 and ± 99.99 if you know. Thank you Bright --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups spctools-discuss group. To post to this group, send email to spctools-discuss@googlegroups.com To unsubscribe from this group, send email to spctools-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=en -~--~~~~--~~--~--~---
