[vistrails-dev] [VisTrails Trac] #523: Default values for parameters not showing

VisTrails Trac 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
 default parameters).

 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/>
VisTrails Project

More information about the vistrails-dev mailing list