X!Tandem parameter file: variable N-terminal modifications

[ulrich-eckhard]

Hey folks,

not sure as no results yet, but I am a bit confused about the X!Tandem parameter file - but it may be right (couldn't check anymore as I have to leave the lab now and fly to Europe tomorrow).

That are my SearchGUI settings:

why does it translate to:

-> I understand the first three, so fixed cmCys & TMT6@K, and variable Met-Ox.

but I don't understand the variable N-terminal ones. i guess the pyro-ones are handled by the quick-pyrolidone function, but what happens to the N-terminal acetyl and TMT? why do they end up in the "potential modification motif"? (on a sidenote, the quick acetyl option in X! Tandem only works for something like the first 50 aminoacids in a protein (but don't know the exact number), and is thus not sufficient in our cases. any idea?

all the best u

[ulrich-eckhard]

just remembered something ... think X! Tandem allows only one variable modification per residue (at least the TPP version couldn't). thus I wouldn't be able to do what I wanted with the current SearchGUI setup. the way to circumvent that at least within TPP was the following:

<!-- N-free w/ TMT@ Lys -->
<note type="input" label="residue, modification mass">+57.021464@C,+229.162932@K</note>

<!-- N-TMT w/ TMT@Lys-->
<note type="input" label="residue, modification mass 1">+57.021464@C,+229.162932@K,+229.162932@[</note>

<!-- N-acetylation w/ TMT@ Lys -->
<note type="input" label="residue, modification mass 2">+57.021464@C,+229.162932@K,+42.010565@[</note> 

so to do 3 iterative searches. not a perfect solution, but the best what we could came up with back then (and which also worked! ;-) ).

Not sure if a similar solution could be feasible for SearchGUI.

[mvaudel]

Hi Ulrich,

The most recent versions of X!Tandem support multiple modifications on the same residue, but it is at another place in the xml file. Same for terminal modifications. Can you attach the entire file?

Best regards,

Marc

2015-12-23 5:08 GMT+01:00 Ulrich Eckhard notifications@github.com:

just remembered something ... think X! Tandem allows only one variable modification per residue (at least the TPP version couldn't). thus I wouldn't be able to do what I wanted with the current SearchGUI setup. the way to circumvent that at least within TPP was the following:

+57.021464@C,+229.162932@K +57.021464@C,+229.162932@K,+229.162932@[ +57.021464@C,+229.162932@K,+42.010565@[

so to do 3 iterative searches. not a perfect solution, but the best what we could came up with back then (and which also worked! ;-) ).

Not sure if a similar solution could be feasible for SearchGUI.

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-166798915.

[ulrich-eckhard]

here we go ... didn't spot something obvious but guess that doesn't mean that much at 2am! ;-)

<?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="tandem-input-style.xsl"?>

list path parameters default_input.xml This value is ignored when it is present in the default parameter list path. taxonomy_searchGUI.xml spectrum parameters 0.05 15.0 15.0 yes Daltons The value for this parameter may be 'Daltons' or 'ppm': all other values are ignored ppm The value for this parameter may be 'Daltons' or 'ppm': all other values are ignored monoisotopic values are monoisotopic|average spectrum conditioning parameters 100.0 The peaks read in are normalized so that the most intense peak is set to the dynamic range value. All peaks with values of less that 1, using this normalization, are not used. This normalization has the overall effect of setting a threshold value for peak intensities. 50 If this value is 0, it is ignored. If it is greater than zero (lets say 50), then the number of peaks in the spectrum with be limited to the 50 most intense peaks in the spectrum. X! tandem does not do any peak finding: it only limits the peaks used by this parameter, and the dynamic range parameter. 6 no 500.0 200.0 8 12 1000 residue modification parameters 57.021464@C ,229.162932@K Carbamidomethylation of C,TMT 6-plex of K 15.994915@M Oxidation of M 42.010565@229.162932@ The format of this parameter is similar to residue, modification mass, with the addition of a modified PROSITE notation sequence motif specification. For example, a value of 80@[ST!]PX[KR] indicates a modification of either S or T when followed by P, and residue and the a K or an R. A value of 204@N!{P}[ST]{P} indicates a modification of N by 204, if it is NOT followed by a P, then either an S or a T, NOT followed by a P. Positive and negative values are allowed. protein parameters all This value is interpreted using the information in taxonomy.xml. [R]|{P} this setting corresponds to the enzyme trypsin. The first characters in brackets represent residues N-terminal to the bond - the '|' pipe - and the second set of characters represent residues C-terminal to the bond. The characters must be in square brackets (denoting that only these residues are allowed for a cleavage) or french brackets (denoting that these residues cannot be in that position). Use UPPERCASE characters. To denote cleavage at any residue, use [X]|[X] and reset the scoring, maximum missed cleavage site parameter (see below) to something like 50. yes 17.002735 +1.007825 yes yes no 0.0 0.0 no if yes, an upper limit is set on the number of homologues kept for a particular spectrum model refinement parameters no 20 yes 0.01 yes no no no no The format of this parameter is similar to residue, modification mass, with the addition of a modified PROSITE notation sequence motif specification. For example, a value of 80@[ST!]PX[KR] indicates a modification of either S or T when followed by P, and residue and the a K or an R. A value of 204@N!{P}[ST]{P} indicates a modification of N by 204, if it is NOT followed by a P, then either an S or a T, NOT followed by a P. Positive and negative values are allowed. scoring parameters 4 1 no yes no no yes no no if yes, cyclic peptide sequence permutation is used to pad the scoring histograms no if yes, then reversed sequences are searched at the same time as forward sequences output parameters no output.xml spectrum values = protein|spectrum (spectrum is the default) yes values = yes|no tandem-style.xsl yes values = yes|no yes values = yes|no yes values = yes|no no values = yes|no yes values = yes|no no values = yes|no no values = yes|no, set to yes to produce only one copy of each protein sequence in the output xml all values = all|valid|stochastic 1.0 value is used in the valid|stochastic setting of output, results 50 values any integer greater than 0. Setting this to '1' makes cutting and pasting histograms into spread sheet programs easier. ADDITIONAL EXPLANATIONS Each one of the parameters for X! tandem is entered as a labeled note node. In the current version of X!, keep those note nodes on a single line. The presence of the type 'input' is necessary if a note is to be considered an input parameter. Any of the parameters that are paths to files may require alteration for a particular installation. Full path names usually cause the least trouble, but there is no reason not to use relative path names, if that is the most convenient. Any parameter values set in the 'list path, default parameters' file are reset by entries in the normal input file, if they are present. Otherwise, the default set is used. The 'list path, taxonomy information' file must exist. The directory containing the 'output, path' file must exist: it will not be created. The 'output, xsl path' is optional: it is only of use if a good XSLT style sheet exists.

On Wed, Dec 23, 2015 at 1:46 AM, Marc Vaudel notifications@github.com wrote:

Hi Ulrich,

The most recent versions of X!Tandem support multiple modifications on the same residue, but it is at another place in the xml file. Same for terminal modifications. Can you attach the entire file?

Best regards,

Marc

2015-12-23 5:08 GMT+01:00 Ulrich Eckhard notifications@github.com:

just remembered something ... think X! Tandem allows only one variable modification per residue (at least the TPP version couldn't). thus I wouldn't be able to do what I wanted with the current SearchGUI setup. the way to circumvent that at least within TPP was the following:

+57.021464@C ,+229.162932@K +57.021464@C ,+229.162932@K,+229.162932@[ +57.021464@C ,+229.162932@K,+42.010565@[

so to do 3 iterative searches. not a perfect solution, but the best what we could came up with back then (and which also worked! ;-) ).

Not sure if a similar solution could be feasible for SearchGUI.

— Reply to this email directly or view it on GitHub <https://github.com/compomics/searchgui/issues/72#issuecomment-166798915 .

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-166849231.

[ulrich-eckhard]

any updates/ideas on that? haven't checked with the updated SearchGUI though.

[mvaudel]

Nope sorry, we have been busy with other issues :) Will come back to this one next week!

2016-01-15 5:02 GMT+01:00 Ulrich Eckhard notifications@github.com:

any updates/ideas on that? haven't checked with the updated SearchGUI though.

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-171866714.

[ulrich-eckhard]

identified a 2nd issue along the line:

instead of N-terminal TMT and TMT@K, X!Tandem seems to do 2x TMT@K and thus PeptideShaker loses one of the two ...

[hbarsnes]

instead of N-terminal TMT and TMT@K, X!Tandem seems to do 2x TMT@K and thus PeptideShaker loses one of the two

As far as I remember this is simply the way that X!Tandem reports terminal modification, i.e. there is no special annotation and it just puts them on the first residue (it's the same for some of the other search engines as well). The challenge is how to interpret it in cases such as the one above.

It all seems to be ok if both modifications are fixed, but the problem occurs if one of them is fixed and the other variable, as all the properties of the modifications are identical and it becomes impossible to tell them apart.

So I assume that in your case one of them is fixed and the other variable?

[hbarsnes]

but I don't understand the variable N-terminal ones. i guess the pyro-ones are handled by the quick-pyrolidone function, but what happens to the N-terminal acetyl and TMT? why do they end up in the "potential modification motif"? (on a sidenote, the quick acetyl option in X! Tandem only works for something like the first 50 aminoacids in a protein (but don't know the exact number), and is thus not sufficient in our cases. any idea?

The "Quick Acetyl" option (http://www.thegpm.org/TANDEM/api/pqa.html) only covers the protein n-term and should not interfere with your peptide acetylation PTM. (I don't see any limitation to the first 50 amino acids though? But you can always disable the "Quick Acetyl" option in the X!Tandem advanced parameters to be sure.)

If I use the same PTMs as the ones in your screenshot above I get the following:

<note type="input" label="residue, modification mass">57.021464@C,229.162932@K</note>
        <note>Carbamidomethylation of C,TMT 6-plex of K</note>
<note type="input" label="residue, modification mass 1">57.021464@C,229.162932@K,229.162932@[</note>
        <note>Carbamidomethylation of C,TMT 6-plex of K,TMT 6-plex of peptide N-term</note>
<note type="input" label="residue, modification mass 2">57.021464@C,229.162932@K,42.010565@[</note>
        <note>Carbamidomethylation of C,TMT 6-plex of K,Acetylation of peptide N-term</note>
<note type="input" label="residue, potential modification mass">15.994915@M</note>
        <note>Oxidation of M</note>

Which seems to be correct and in line with your suggestion from TPP? Maybe you were looking at the wrong parameter file?

[ulrich-eckhard]

yep, TMT@K is fixed, TMT@Nter is variable. shall I contact Ron Beavis and ask to change that so that nter modifications are reported as @[? or can you? or wouldn't that fix the problem ? On Jan 17, 2016 4:17 AM, "Harald Barsnes" notifications@github.com wrote:

instead of N-terminal TMT and TMT@K, X!Tandem seems to do 2x TMT@K and thus PeptideShaker loses one of the two

As far as I remember this is simply the way that X!Tandem reports terminal modification, i.e. there is no special annotation and it just puts them on the first residue (it's the same for some of the other search engines as well). The challenge is how to interpret it in cases such as the one above.

It all seems to be ok if both modifications are fixed, but the problem occurs if one of them is fixed and the other variable, as all the properties of the modifications are identical and it becomes impossible to tell them apart.

So I assume that in your case one of them is fixed and the other variable?

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-172318583.

[ulrich-eckhard]

yeah, i noticed that yesterday. with the newer SearchGui the parameter file looks good. but still didn't get any acetylated or pyro peptides (both with the quick option). but didn't have time to fully follow up on that yet. but will tmw. On Jan 17, 2016 4:43 AM, "Harald Barsnes" notifications@github.com wrote:

but I don't understand the variable N-terminal ones. i guess the pyro-ones are handled by the quick-pyrolidone function, but what happens to the N-terminal acetyl and TMT? why do they end up in the "potential modification motif"? (on a sidenote, the quick acetyl option in X! Tandem only works for something like the first 50 aminoacids in a protein (but don't know the exact number), and is thus not sufficient in our cases. any idea?

The "Quick Acetyl" option (http://www.thegpm.org/TANDEM/api/pqa.html) only covers the protein n-term and should not interfere with your peptide acetylation PTM. (I don't see any limitation to the first 50 amino acids though? But you can always disable the "Quick Acetyl" option in the X!Tandem advanced parameters to be sure.)

If I use the same PTMs as the ones in your screenshot above I get the following:

57.021464@C,229.162932@K

    <note>Carbamidomethylation of C,TMT 6-plex of K</note>

57.021464@C,229.162932@K,229.162932@[

    <note>Carbamidomethylation of C,TMT 6-plex of K,TMT 6-plex of peptide N-term</note>

57.021464@C,229.162932@K,42.010565@[

    <note>Carbamidomethylation of C,TMT 6-plex of K,Acetylation of peptide N-term</note>

15.994915@M

    <note>Oxidation of M</note>

Which seems to be correct and in line with your suggestion from TPP? Maybe you were looking at the wrong parameter file?

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-172321491.

[hbarsnes]

yep, TMT@K is fixed, TMT@Nter is variable. shall I contact Ron Beavis and ask to change that so that nter modifications are reported as @[? or can you? or wouldn't that fix the problem ?

Would indeed be better to have the terminals annotated differently in the X!Tandem results file, but as this would alter the format I don't find it very likely that Ron Beavis would want to make this change, but feel free to ask him of course. But in any case we'll try to come up with a fix on our side.

[hbarsnes]

yeah, i noticed that yesterday. with the newer SearchGui the parameter file looks good. but still didn't get any acetylated or pyro peptides (both with the quick option).

Strange. With your settings (i.e. the ptms listed in the screenshot) I get both acetylated peptides and pyro peptides (all three types) with the two quick options turned on for a small TMT test dataset.

[ulrich-eckhard]

i am currently having some other issues too. same file giving different results (comet) when searched right after each other. maybe a Sunday phenomenon, no idea. will do some fresh installs tmw just to be sure ... On Jan 17, 2016 10:38 AM, "Harald Barsnes" notifications@github.com wrote:

yeah, i noticed that yesterday. with the newer SearchGui the parameter file looks good. but still didn't get any acetylated or pyro peptides (both with the quick option).

Strange. With your settings (i.e. the ptms listed in the screenshot) I get both acetylated peptides and pyro peptides (all three types) with the two quick options turned on for a small TMT test dataset.

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-172363103.

[ulrich-eckhard]

ok ... can confirm that now SearchGUI 2.3.5 is working now also with both my mgf-files, not sure what went wrong but restarting the computer helped.

I also figured out the different results when using comet. i had one difference in my searches or better peptide shaker imports: The Precursor Accuracy was set in one case to 20ppm and the other time ignored. Thought it shouldn't matter as the search setting was plus/minus 15. Opened a SearchGUI issue: https://github.com/compomics/peptide-shaker/issues/114 - hope it is not just a problem on my side again.

will continue testing X!Tandem as soon as Comet is running for me perfectly again.

On a side note: Also in contact with Jimmy again as depending on the mgf format I am getting different results using comet. He could reproduce that and is currently trying to figure out the problem (mgf #1 has the MS intensity and the 2nd one not; and the first file format has partly charges assigned for the fragment ions).

and sorry for hijacking my own thread.

[ulrich-eckhard]

Running now X! Tandem over night on one of my datasets:

decided to do TMT@Nter and Acetyl@Nter as variable modification but the pyro-ones as "quick pyrolidone" as in the parameter file it looked like that with pyroE/Q/Cm as variable modifications X!Tandem would otherwise search for "-17" and "-18" for all n-termini and not only for the one with N-terminal E/Q/Cm.

fingers crossed, will report later tomorrow - but the parameter file looks really promising!

[hbarsnes]

I found and fixed some issues on how we handle the combination of fixed and variable modifications targeting the same terminal residue when parsing X!Tandem results. We will release a new version as soon as we've had the chance to look at the other reported issues.

BTW, please try to keep the issue reports specific to single problems (as far as possible). As otherwise it becomes very difficult for us to keep track of all the issues and to know when to close them...

[ulrich-eckhard]

will give my best - sorry for that.

and big big thanks!

On Tue, Jan 19, 2016 at 2:38 AM, Harald Barsnes notifications@github.com wrote:

I found and fixed some issues on how we handle the combination of fixed and variable modifications targeting the same terminal residue when parsing X!Tandem results. We will release a new version as soon as we've had the chance to look at the other reported issues.

BTW, please try to keep the issue reports specific to single problems (as far as possible). As otherwise it becomes very difficult for us to keep track of all the issues and to know when to close them...

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-172812890.

[hbarsnes]

The issues should have been fixed with the release of SearchGUI 2.5.0 and PeptideShaker 1.5.0. If not, please open a new issue.

[ulrich-eckhard]

fear the problem is somehow back again - but haven't figured out yet what it is exactly. tried to first rule out that it was linked with the latest X! Tandem release, but it seems it doesn't.

it seems to be linked with the N-terminal modification that I create within the modification editor. somehow the "at peptide or protein N-terminus" is not getting "translated" correctly.

thus I get in the Tandem parameter file: `... 28.0313@ which lacks the "["

can you check if you have the same behavior on your side? or if I am doing something wrong when creating the modification.

thanks.

curiosity question: for which kind of searches do you use the "Dimethylation of peptide N-term K" - so that the dimethyl is fixed to a N-terminal K. wouldn't you expect then both dimethylation of K and N-ter? or is it for something else? or is the "K" accidentally there?

`

[ulrich-eckhard]

forgot ... for the latest SearchGUI (2.7.1) I get endless "Gs" for X! Tandem? any idea why?

[hbarsnes]

forgot ... for the latest SearchGUI (2.7.1) I get endless "Gs" for X! Tandem? any idea why?

Don't see the same on my side. Perhaps something special with your input of settings. Maybe you can contact the X! Tandem developers?

it seems to be linked with the N-terminal modification that I create within the modification editor. somehow the "at peptide or protein N-terminus" is not getting "translated" correctly.

Again, I don't see the this on my side. Only tried with "Acetylation of peptide N-term" so far though. Maybe you could send me your search settings?

curiosity question: for which kind of searches do you use the "Dimethylation of peptide N-term K" - so that the dimethyl is fixed to a N-terminal K. wouldn't you expect then both dimethylation of K and N-ter? or is it for something else? or is the "K" accidentally there?

I don't think that we use this modification ourselves. All I can do is refer to the Unimod term (http://www.unimod.org/modifications_view.php?editid1=36), and from there it could seem that the 'K' indeed should not be there? I guess it would be the same for "Dimethylation of peptide N-term K 2H(4)" as well then?

[hbarsnes]

for the latest SearchGUI (2.7.1) I get endless "Gs" for X! Tandem? any idea why?

BTW, is this when running X! Tandem or when processing the results?

[ulrich-eckhard]

when running XTandem On Mar 10, 2016 8:11 AM, "Harald Barsnes" notifications@github.com wrote:

for the latest SearchGUI (2.7.1) I get endless "Gs" for X! Tandem? any idea why?

BTW, is this when running X! Tandem or when processing the results?

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-194928977.

[ulrich-eckhard]

can you test again with a NEW nterminal modification and then check the X! Tandem parameter file? it worked for me for the ones that where in, but not the one i created new. but will try again later today and on another computer. On Mar 10, 2016 8:33 AM, "Ulrich Eckhard" ulrich.eckhard@gmail.com wrote:

when running XTandem On Mar 10, 2016 8:11 AM, "Harald Barsnes" notifications@github.com wrote:

for the latest SearchGUI (2.7.1) I get endless "Gs" for X! Tandem? any idea why?

BTW, is this when running X! Tandem or when processing the results?

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-194928977 .

[ulrich-eckhard]

finally found time to look into this again ...

when I use the dimethylation options that "ship with" SearchGUI (eg. 2H(6)), all is good: Note that we have three separated searches (as intended): "modification mass, modification mass 1, and modification mass2"".

but as soon as I create a NEW N-terminal dimethylation modification - e.g. the following:

then the X! Tandem parameter file looks like this: Note: we only have one "separate search", and the acetylation is now a "potential modification". which is somewhat ok, but the N-terminal dimethylation is now a "potential modification motif", and I guess more important, it lacks the "[" after the "@".

and X! Tandem gives me within the SearchGUI window all the "Gs" but I think that is may due the messed up modification motif - potentially at least (I don't get it when using the internally saved N-terminal 2H(6) modification.

thus I assume it is rather a SearchGUI problem at the "modification creation" stage, and not really a X! Tandem problem, no? but I can definitely contact the X! Tandem people if we think the problem is on their side.

cheers and thanks, hope my screenshots help u

[hbarsnes]

thus I assume it is rather a SearchGUI problem at the "modification creation" stage, and not really a X! Tandem problem, no? but I can definitely contact the X! Tandem people if we think the problem is on their side.

It was a bug in how we handled terminal user PTMs without a specific target. Has now been fixed. Still don't get why this would result in the endless G's printed by X! Tandem though, probably some debug code inside X! Tandem (and I did check that I also got these when running X! Tandem outside SearchGUI, so clearly from X! Tandem and not from SearchGUI), but I guess it does not matter as they are gone after fixing the SearchGUI issue.

I will try to get the time to release a new version tomorrow, just need to finish this one first: https://github.com/compomics/searchgui/issues/95.

Note that you will have to recreate the user PTMs with this issue to fix the problem.

[ulrich-eckhard]

thanks a lot Harald!!!

On Thu, Mar 10, 2016 at 12:24 PM, Harald Barsnes notifications@github.com wrote:

thus I assume it is rather a SearchGUI problem at the "modification creation" stage, and not really a X! Tandem problem, no? but I can definitely contact the X! Tandem people if we think the problem is on their side.

It was a bug in how we handled terminal user PTMs without a specific target. Has now been fixed. Still don't get why this would result in the endless G's printed by X! Tandem though, probably some debug code inside X! Tandem (and I did check that I also got these when running X! Tandem outside SearchGUI, so clearly from X! Tandem and not from SearchGUI), but I guess it does not matter as they are gone after fixing the SearchGUI issue.

I will try to get the time to release a new version tomorrow, just need to finish this one first: #95 https://github.com/compomics/searchgui/issues/95.

Note that you will have to recreate the user PTMs with this issue to fix the problem.

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-195032059.

[ulrich-eckhard]

i should add one more thing ... I know PS doesn't support MS1 quantitation, but it would be still great if it would be possible to evoke e.g. in X! Tandem and Comet (for the two I know it is possible), that let's say dm0@K and dm0@Nter are searched together, and dm6@K and dm6@Nter likewise. do you see a way to implement that?

[hbarsnes]

I know PS doesn't support MS1 quantitation, but it would be still great if it would be possible to evoke e.g. in X! Tandem and Comet (for the two I know it is possible), that let's say dm0@K and dm0@Nter are searched together, and dm6@K and dm6@Nter likewise. do you see a way to implement that?

I think X! Tandem is the only search engine supporting something like this. That is if you mean something similar to the SILAC strategy shown here:http://www.thegpm.org/TANDEM/api/rmm.html?

But in any case, I don't see us implementing support for this in the near future. Does not make all that much sense until we also support MS1 quantification?

[ulrich-eckhard]

think comet can also do it with the binary groups - see http://comet-ms.sourceforge.net/parameters/parameters_201502/variable_mod01.php (very bottom)

but your point is totally valid of course. maybe an easier solution: would it be possible to include something like a "Checkpoint" before the actual searches start. So more or the less right after all the parameter files are written, but before the searches are started? So that I could check the parameter quickly, and if needed, e.g. adapt them (ie use options that are not covered by SearchGUI)?

[hbarsnes]

think comet can also do it with the binary groups - see http://comet-ms.sourceforge.net/parameters/parameters_201502/variable_mod01.php (very bottom

Yup, you're right. I forgot about that one.

but your point is totally valid of course. maybe an easier solution: would it be possible to include something like a "Checkpoint" before the actual searches start. So more or the less right after all the parameter files are written, but before the searches are started? So that I could check the parameter quickly, and if needed, e.g. adapt them (ie use options that are not covered by SearchGUI)?

Sounds like a very customized setup for something that most users won't need. An easier solution that you can already try out is to start the search as normal and then cancel it has soon as the wanted search engine has started. You can then inspect or alter the parameter files and then run the search engine via the command line instead. The exact command line to use will have been printed to the SearchGUI log file. I agree that it's not a very generic or user friendly solution, but at least it should give you the ability to test some more uncommon setups? And the results should still be compatible with PeptideShaker.

[ulrich-eckhard]

if that works, that is definitely good enough for me right now ... will definitely give that a try.

On Fri, Mar 11, 2016 at 11:37 AM, Harald Barsnes notifications@github.com wrote:

think comet can also do it with the binary groups - see http://comet-ms.sourceforge.net/parameters/parameters_201502/variable_mod01.php (very bottom

Yup, you're right. I forgot about that one.

but your point is totally valid of course. maybe an easier solution: would it be possible to include something like a "Checkpoint" before the actual searches start. So more or the less right after all the parameter files are written, but before the searches are started? So that I could check the parameter quickly, and if needed, e.g. adapt them (ie use options that are not covered by SearchGUI)?

Sounds like a very customized setup for something that most users won't need. An easier solution that you can already try out is to start the search as normal and then cancel it has soon as the wanted search engine has started. You can then inspect or alter the parameter files and then run the search engine via the command line instead. The exact command line to use will have been printed to the SearchGUI log file. I agree that it's not a very generic or user friendly solution, but at least it should give you the ability to test some more uncommon setups? And the results should still be compatible with PeptideShaker.

— Reply to this email directly or view it on GitHub https://github.com/compomics/searchgui/issues/72#issuecomment-195515306.