[ptp-dev] PE Attribute Dependencies

[Dave Wootton <dwootton@xxxxxxxxxx>]

Randy
There are several different variations on attribute dependencies for PE.

My assumption is that good GUI design should prevent the user from 
selecting invalid values for options, or from selecting invalid 
combinations of options so the the user does not try to invoke an 
application with an invalid set of parameters only to have it fail. 
However, we cannot be totally successful in preventing the user from 
invoking an application with invalid parameters. For instance, if I try to 
invoke an application with a host file containing a list of nodes where 
the application is to run, and I specify node(s) that I do not have 
authorization to run on, I don't have a quick and easy way to validate 
that the host file is correct, and so the invocation will fail.

I think that means that we try to protect the user from invalid 
invocations where we can without having to perform expensive validations 
and without making the GUI hard to use for normal operations. Where we 
can't reasonably validate, we attempt the invocation and let it fail. I 
don't think this is so much a problem for interactive execution, where 
feedback for the failure should be quick. Where this could be a problem is 
where the user submits a job for batch execution intending it to run 
overnight, only to find out the next day that it failed due to incorrect 
setup.

So, here are some samples

1) Mutual exclusion. I can specify either a resource pool (MP_RMPOOL) or 
host file (MP_HOSTFILE) to control node allocation, where I need to 
specify one or the other, but not both. My first thought in handling this 
is that both MP_RMPOOL and MP_HOSTFILE should be enabled. When the user 
chooses one or the other, in this case, by entering something in the 
corresponding text field, the other one gets disabled. 

The problem with this approach is that if there are many options that can 
be specified, or those options are spread across several panels, of say, a 
tabbed view, then the user may not be certain what he has to 'blank out' 
or 'de-select' in order to get the option he wants to use enabled. For 
instance, it may not be clear that I need to blank out MP_HOSTFILE to use 
MP_RMPOOL.

The other option is to not disable anything and let the invocation fail. 

I'd think the better option is to disable options that are no longer 
allowable.

2) Range checking of a set of options. One way tasks can be mapped to 
nodes includes setting three environment variables, MP_PROCS (total number 
of tasks), MP_NODES (number of nodes to run the application) and 
MP_TASKS_PER_NODE (number of tasks on each node). Ove rule for these is 
that if all three are set, then MP_NODES * MP_TASKS_PER_NODE must equal 
MP_NODES or the application terminates.

I would handle this validation at the point where the 'run' button is 
clicked and pop up an error dialog or a message in the status line. An 
alternative, which I don't think I'd do, is to handle the validation as 
fields lose focus and display the error or popup at that point. I'm 
concerned doing this could be annoying.

3) Varying defaults. Some PE options have different default values. For 
instance, MP_ADAPTER_USE, which specifies how the communication adapter 
should be used has two allowable values, 'dedicated' or 'shared'. 
Depending on which type of communications adapter is specified, the 
default value can be dedicated or shared.

I'm thinking that we don't worry about the PE defaults, assuming that for 
every attribute that has a field on the panel, if the attribute's field 
has no value, or is disabled, then we would not pass across across to the 
resource manager/proxy, and if a value is specified in a failed, and it 
ois not disabled, then we pass the value to the resource manager/proxy. I 
think defaults are a 'one time' problem anyway, since once run is clicked, 
PTP is going to save the values for fields anyway. Also, I think trying to 
track each field to remember if a value has been entered by the user, and 
if not, to update the default value for that field based on other 
selections could be difficult.

Another question is whether it is possible to somehow generalize the panel 
management and validation code. Maybe a class, or set of classes, where a 
method is registered to be called any time a field loses focus. These 
methods could then handle the enable/disable of panel fields and also 
handle validation when 'run' is clicked.

Dave