[vistrails-dev] [VisTrails Trac] #523: Default values for parameters not showing
tickets at vistrails.org
Sat Jan 21 20:24:33 EST 2012
#523: Default values for parameters not showing
Reporter: dakoop | Owner: dakoop
Type: defect | Status: new
Priority: major | Milestone: version 2.0
Component: core | Version: master
Resolution: | Keywords:
Comment (by dakoop):
Replying to [comment:2 juliana]:
> Adding Juliana's reply to [comment:1 dakoop] to the trac:
> > Should the defaults always be written out when the parameter is
selected or only when values are changed from the defaults?
> If the default values are used when the workflow is run, for the
provenance to be complete, they should be stored.
To be clear, this does not happen for most VisTrails modules. We have
explicit support for defaulting a port value in a module's compute method
(forceGetInputFromPort), and these values are not persisted on a per-run
basis. Note that ability to default a port value (the original bug) is
currently separate from any defaults in the compute method. Thus,
specifying a default in the port definition means that the value will be
shown when the user clicks that parameter, but if the user does not set
the parameter, the defaulting in the compute method could set the value to
a different value. For example, a port's default value could be specified
as 2 at the interface level, and also default to 0 at the code level. The
default value used then depends on whether the user clicks the parameter.
This is something we should probably fix, but there could be code-based
"defaults" that depend on other variables (see later comment).
> > For example, if I change a module to work with Kelvin temperatures
instead of Celsius, my defaults will also likely change, but it is not
valid to compare the two values (whether they are defaults or not) because
the parameters are different. Thus, one needs to look at the code to
properly interpret the provenance anyway...
> But in this scenario, you are changing the semantics of the module in a
way that is not visible to VisTrails.
> If C or K are parameters, then the analysis would work---you would be
able to see the values as well as the scale.
I don't understand the point here. I agree that it would certainly be
better if there were C or K parameters, but this assumes significant
forethought, and I don't think that careful code could alleviate all cases
where a default would change in this way. Are you suggesting that having
the default values '''may''' help in more such analyses? It seems that
there is no way to ensure a comparison is valid unless you do code
analysis to check that semantics have not changed.
> > I am also thinking about VTK here, where there are default values that
are not currently specified as VisTrails defaults.
> Is it hard to show the defaults that are used? Maybe a compromise here
we could do what you suggest: explicitly distinguish in the interface
values set by the user from the default values. (Or maybe, if the
interface becomes to cluttered, users could be given the option to hide
The problem with VTK is that defaults are currently not visible at
VisTrails level. To add them, we would probably would need to pull the
default values from C++ header files. However, we certainly could and
probably should differentiate default values from actual user-set values
if we are showing more of them.
> > Thus, keeping a parameter "unset" means that this default value is
used, but here as well, the provenance does not reflect the use of such
> I think the provenance should reflect the results.
The problem is, as described above, that these values are baked into C++
header files, and while we could poll the modules at execution time, this
seems inefficient as they won't change unless the underlying library
changes. Also, there is an issue when a variable's value depends on
whether another variable is set. For example, the initial position of a
vtkPlaneWidget will be set based on the input if it exists, but will
otherwise be set to a default position specified by default values.
> > Here, the size of the provenance would dramatically increase if
defaults were specified and written out each time because there are a
large number of parameters (and defaults) for each module.
> I think that if this indeed becomes a problem, we could try to do some
normalization. For example, save default parameters only once for a
Yes, this is a good point.
Ticket URL: <https://www.vistrails.org/ticket/523#comment:3>
VisTrails Trac <https://www.vistrails.org/>
More information about the vistrails-dev