advanced parameters: all or nothing?
Hello, I was recently adjusting advanced parameters when running Tophat in Galaxy and noticed that when advanced parameters are used, every field is converted and submitted as command line parameter to the tool at runtime. Without changing any of the default values I get a different tophat result than if advanced parameters are left off. I'm curious if the Galaxy team has considered a mechanism for disabling an individual parameter? Or perhaps a way of individually enabling parameters from within the Advanced Parameter block? Just trying to think of a way to use one advanced parameter without using all of them. Cheers, Andrew Warren
On Thu, Feb 9, 2012 at 11:27 PM, Andrew Warren <anwarren@vbi.vt.edu> wrote:
Hello,
I was recently adjusting advanced parameters when running Tophat in Galaxy and noticed that when advanced parameters are used, every field is converted and submitted as command line parameter to the tool at runtime. Without changing any of the default values I get a different tophat result than if advanced parameters are left off.
That sounds like a bug in the wrapper.
I'm curious if the Galaxy team has considered a mechanism for disabling an individual parameter? Or perhaps a way of individually enabling parameters from within the Advanced Parameter block?
Just trying to think of a way to use one advanced parameter without using all of them.
Cheers, Andrew Warren
This should be possible using optional parameters, as of: https://bitbucket.org/galaxy/galaxy-central/issue/403/ https://bitbucket.org/galaxy/galaxy-central/issue/661/ Peter
On Thu, Feb 9, 2012 at 11:27 PM, Andrew Warren <anwarren@vbi.vt.edu> wrote:
Hello,
I was recently adjusting advanced parameters when running Tophat in Galaxy and noticed that when advanced parameters are used, every field is converted and submitted as command line parameter to the tool at runtime. Without changing any of the default values I get a different tophat result than if advanced parameters are left off.
That sounds like a bug in the wrapper.
Recent Tophat versions have changed parameters and default values again. I made the following changes in 3bd8bed55631 to make the wrapper compatible with Tophat 1.4.0: *removed junctions_filter parameter *changed the default value for max-mismatches from 40 to 20 This should ensure that enabling advanced parameters but leaving them untouched yields the same results as using default parameters. J.
On Fri, Feb 10, 2012 at 4:18 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
On Thu, Feb 9, 2012 at 11:27 PM, Andrew Warren <anwarren@vbi.vt.edu> wrote:
Hello,
I was recently adjusting advanced parameters when running Tophat in Galaxy and noticed that when advanced parameters are used, every field is converted and submitted as command line parameter to the tool at runtime. Without changing any of the default values I get a different tophat result than if advanced parameters are left off.
That sounds like a bug in the wrapper.
Recent Tophat versions have changed parameters and default values again. I made the following changes in 3bd8bed55631 to make the wrapper compatible with Tophat 1.4.0:
*removed junctions_filter parameter *changed the default value for max-mismatches from 40 to 20
This should ensure that enabling advanced parameters but leaving them untouched yields the same results as using default parameters.
J.
Wouldn't it be better not to have the default value 40 (or 20) in the wrapper at all? i.e. Leave it out, so that by default that argument isn't used, so that tophat uses the default it wants to use. Peter
Wouldn't it be better not to have the default value 40 (or 20) in the wrapper at all? i.e. Leave it out, so that by default that argument isn't used, so that tophat uses the default it wants to use.
This would work but limits reproducibility and transparency because Galaxy wouldn't have a record of the parameter's actual value. Yes, this is a problem when default parameters are used as well and should be fixed. However, making more use of defaults when advanced setting are used could be especially problematic b/c I imagine that using advanced parameters generally implies that a user cares are default values more so than if using all defaults. FWIW, the Galaxy team has started thinking about how to better handle multiple tool versions and different parameter default values for different tool versions. If anyone has strong feelings, please feel free to start a discussion (in a new thread please) on this challenge. Best, J.
Thanks for the pointer to the updated wrapper and the optional tag. So is the behavior of the optional="true" tag that if the field form is left empty for that parameter then it will not be passed to the tool? I am wondering if a more sophisticated behavior on the UI side of things for the "optional" tag would still allow for recording that the parameter is using the default value for the version of that tool but not actually pass that parameter on the command line in case it influences the behavior of the tool? Thinking of parameters that should have a default value but whose actual presence on the command line changes what happens. Though, I guess this could be done by simply deleting the default value in the optional parameter has one? Maybe if the optional tag enabled the parameter itself to be toggled on/off (grayed out/regular text)? This way a block of advanced parameters could be enabled without requiring that they all be passed to the tool (or deleting all their values if they are marked optional). Just a small note, the update to the tophat wrapper was to the maximum number of alignments instead of mismatches. Thanks again, Andrew On Fri, Feb 10, 2012 at 11:28 AM, Peter Cock <p.j.a.cock@googlemail.com>wrote:
On Thu, Feb 9, 2012 at 11:27 PM, Andrew Warren <anwarren@vbi.vt.edu> wrote:
Hello,
I was recently adjusting advanced parameters when running Tophat in Galaxy and noticed that when advanced parameters are used, every field is converted and submitted as command line parameter to the tool at runtime. Without changing any of the default values I get a different tophat result
On Fri, Feb 10, 2012 at 4:18 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote: than if
advanced parameters are left off.
That sounds like a bug in the wrapper.
Recent Tophat versions have changed parameters and default values again. I made the following changes in 3bd8bed55631 to make the wrapper compatible with Tophat 1.4.0:
*removed junctions_filter parameter *changed the default value for max-mismatches from 40 to 20
This should ensure that enabling advanced parameters but leaving them untouched yields the same results as using default parameters.
J.
Wouldn't it be better not to have the default value 40 (or 20) in the wrapper at all? i.e. Leave it out, so that by default that argument isn't used, so that tophat uses the default it wants to use.
Peter
So is the behavior of the optional="true" tag that if the field form is left empty for that parameter then it will not be passed to the tool?
Optional is enforced at the UI level; a wrapper can choose to handle optional parameters differently.
I am wondering if a more sophisticated behavior on the UI side of things for the "optional" tag would still allow for recording that the parameter is using the default value for the version of that tool but not actually pass that parameter on the command line in case it influences the behavior of the tool? Thinking of parameters that should have a default value but whose actual presence on the command line changes what happens. Though, I guess this could be done by simply deleting the default value in the optional parameter has one?
Maybe if the optional tag enabled the parameter itself to be toggled on/off (grayed out/regular text)? This way a block of advanced parameters could be enabled without requiring that they all be passed to the tool (or deleting all their values if they are marked optional).
There are two issues to consider: (1) Whether the UI is friendly when a tool has many parameters. Clearly, there are improvements to be made, but Galaxy makes it relatively easy to ignore parameters that aren't of interest. A novel UI approach might try to make it easier to hide unwanted parameters from view or selectively set certain parameters. (2) Whether optional parameters should be passed to the wrapper. IMHO, there's no reason not to make all user input available to the wrapper. A tool that doesn't produce the same output when (a) parameter values are not specified and (b) default parameter values are specified is buggy and should be fixed. Best, J.
participants (3)
-
Andrew Warren -
Jeremy Goecks -
Peter Cock