PS I would be very happy to test the feature out on my libraries if that would help.
On Mon, 20 May 2019 at 02:44, Henry Lam <[email protected]> wrote: > Matt, > > I got your point. Indeed you are trying to map one set of iRT to another, > through the use of some common marker peptides. > > As I said, this is really a new feature, and I am not sure the original > regression code would work properly anyway, even if I "enable" it. The > current code looks at the "RT" field to perform the linear regression, not > the "iRT" field. What you need, as I understand it, is to use the "iRT" > values from the downloaded library, treat them as the RT, and perform the > linear regression with another set of markers (provided in your file > presumably), then overwrite the iRTs. We also need to worry about all the > possible error cases. > > It seems like a worthwhile feature to add, but it will take some effort to > program this into SpectraST. Would you mind waiting? I probably can't find > time to work on it until after mid-June. > > Henry > > > On Friday, May 17, 2019 at 10:02:33 PM UTC+8, Matthew Russell wrote: >> >> Dear Henry >> >> Thank you for your e-mail. You raise some really good points about the >> dangers of re-calibrating the iRT which I hadn't fully considered. >> >> My use case is that raw data was acquired at another lab using a set of >> index peptides that we do not use. I believe the spectrast library was >> compiled using this index, so all RTs from multiple runs should be mapped >> to a single iRT space. That iRT space is not the one we use to collect our >> SWATH data. So I want to apply a regression to move from one iRT to the >> biognosis iRT space. >> >> I have found peptides shared between the new library and the Aebersold >> "pan-human" library which is in the biognosis iRT space. So although the >> biognosis iRT peptides are not present in new library I do have a set of >> marker peptides along with their iRT score in biognosis iRT space. So I >> think it would be legitimate to use these as markers. >> >> I agree with you that this should not be attempted in a library in which >> multiple runs and multiple sources have been combined without standardising >> to an iRT space because run-run comparison is not possible. However I think >> if an iRT standardisation was used with the original import then this kind >> of transposition should be legitimate. >> >> Would it be possible to enable this tool but through up an error if the >> original library was not scaled to an iRT? >> >> Best wishes >> >> Matt >> >> >> >> >> >> On Fri, 17 May 2019 at 02:29, Henry Lam <[email protected]> wrote: >> >>> Matt, >>> >>> As the Wiki stated, this option -c_IRT only works when you import a >>> pep.xml file. It does not work on an existing library (.splib). >>> >>> The reason is because the iRT values are computed by linear regression >>> from real retention times of peptides IN THE SAME MS RUN, and the >>> information about which MS run the spectrum comes from is already lost if >>> you do not have the .pep.xml file. >>> >>> Although you might have used the same chromatography for all the data >>> you used to generate this library, SpectraST is designed for the general >>> use case where a spectral library is built from data acquired on many >>> different setups (and potentially from downloaded data). A spectral library >>> also might not record the real retention times (again depending on where >>> the data comes from), or the retention times might have been some aggregate >>> value of many different replicates (in the case of consensus spectra). >>> Because of this, doing an iRT normalization on a spectral library is >>> problematic and could lead to meaningless results. From my point of view, I >>> would rather limit the functionality than risk producing questionable >>> results that a researcher might unwittingly rely on to perform future >>> experiments. >>> >>> May I ask what you put into newiRTfile.txt? Are they a new set of >>> spike-in iRT peptides with their iRT values? And your .splib file already >>> has iRT values (but computed from another set of spike-in iRT peptides)? If >>> so, what you are trying to do is quite different from the intended use of >>> this option. I suppose it could be a new feature to enable this kind of >>> update from one iRT normalization to another, but it needs some thoughts >>> how to do it right. >>> >>> If you want to get around this hurdle and do not mind some scripting, >>> you can consider parsing the .sptxt file to get the old iRT values, do your >>> own regression to calculate the new iRT values, and then replace the iRT >>> values in the .sptxt file. After the edit, you can re-import the .sptxt >>> into a spectral library. >>> >>> Hope it helps, >>> >>> Henry >>> >>> >>> >>> On Thursday, May 16, 2019 at 10:38:46 PM UTC+8, Matthew Russell wrote: >>>> >>>> I am trying to update the iRT index in a pre-existing .splib file. >>>> Unfortunatly I do not have access to the .pep.xml files initially used to >>>> create the library and cannot build from them as documented. >>>> >>>> Ideally I would do: >>>> >>>> spectrast.exe -cNnewiRT_lib -c_IRTnewiRTfile.txt -cM old_iRT.splib >>>> >>>> Except of course that doesn't work as is clearly documented on >>>> http://tools.proteomecenter.org/wiki/index.php?title=Software:SpectraST >>>> . >>>> >>>> Is there any work around to make this possible? IF there isn't is there >>>> any way this could be made a feature? >>>> >>>> Thanks >>>> >>>> Best wishes >>>> >>>> Matt >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "spctools-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/spctools-discuss. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/spctools-discuss/f2e8d111-c1a1-4ade-ba98-95616b44abb5%40googlegroups.com >>> <https://groups.google.com/d/msgid/spctools-discuss/f2e8d111-c1a1-4ade-ba98-95616b44abb5%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "spctools-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/spctools-discuss. > To view this discussion on the web visit > https://groups.google.com/d/msgid/spctools-discuss/ada7872c-ff29-46b7-b59c-92e79e1b8348%40googlegroups.com > <https://groups.google.com/d/msgid/spctools-discuss/ada7872c-ff29-46b7-b59c-92e79e1b8348%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/spctools-discuss. To view this discussion on the web visit https://groups.google.com/d/msgid/spctools-discuss/CADOFuMETxu4XW-DHbzBEZkOUcNDjhqgusfPPE6Jteo7M5AWbrg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
