Re: what about users?

[Al Gilman <asgilman@iamdigex.net>]

The following is from a thread which can be found in the archives of the
models-wg list.  In it someone raised questions as to how much Grid users
need performance and how much they need convenience.  I responded that a)
what users need is to control the decisions which determine the
performance/convenience balance in outcomes, and b) the gce-wg will be an
activity involved in capturing and defending requirements like this.

Al

-- copy of message to models-wg

At 04:32 AM 2000-08-08 +0200, Torsten Fink wrote:
>Hi,
>
>I am doing my Ph.D. in the area of Metacomputing (defined as
>wide-area-computing) and would like to share and discuss some thoughts
>here. 
>
>I really liked the write-up from Craig Lee and found it very
>interesting because it gives a good overview about technical
>approaches for a grid programming model. But I missed a little bit a
>discussion about the needs of the users.
>
>I have the impression that the users can be divided into 2 groups:
>
>- One group needs performance.
>
>- The other group wants convenience.

All users need some of each.

The reason we don't simply apply price theory (the user's preference is
described as the exchange ration between performance and convenience at
which the user doesn't care which way the solution slides on the exchange
trajectory) is that the science of human/computer interaction is not so
advanced as to give us cardinal-number metrics for convenience.  What we
are trading performance where we have cardinal number metrics with
convenience where we have at best a partial ordering; given two user
interface alternatives, we can usually say which is more convenient, but
this is not even true for all users.  The usability ratings vary between
users.  This is spectacularly true when one enters the arena of usability
by people with disabilities.  Your proudest visualization may be useless
for a blind user.

What we are left with is that we need late binding to choices that affect
or determine the performance/convenience balance.  The user working through
the problem solving environment must have sufficient choices to go to all
performance/convenience balance regimes that the underlying (i.e. available
to a job-building planner tool) computational resource pool supports.
The supply side (supercomputer, metacomputer, ...) has to provide
flexibility over which the demand side (user and client-side software)
retains control.

There will be some ordering in how the system presents itself and the
consumer tunes it.  The defaults that the system presents "out of the box"
must be highly usable and the extremes of performance or interface
adaptation may take more user effort to reach.

>
>I personally think the second (convenience-)group is larger and more
>important for the grid approach. The reason is that the first group
>always needs the best technical equipment at best with exclusive
>access. IMHO grid programming is more for the masses. 
>
>One conclusion of these assumptions is to stress transparency for a
>grid programming model (PM), because transparency is very closely related
>to convenience.

>

Here we encounter a terminology problem.  I fear that what you mean by
transparency is the reverse of what I would mean.  I think you mean
transparency is when the computational details are hidden from the user.  I
call that the opacity of the interface.  In our case the user needs to
retain control of whether they see a summary or detailed depiction of the
computational plan, and to exercise manual overrides (with system-applied
checks) at all levels within the structure of that computational plan.

The user needs to retain control over whether they see a black-box or
white-box view of any realization/expansion in the what:how mapping of of
the solution strategy.  The what:how mapping is a multilevel graph
transformation that links a pure-problem-statement description of what is
being solved with a pure-computation-domain description of what is being
computed and communicated.

[Aside:  I have a "master view" in wich application, computation, and
interaction domains are three _related views_.  That is to say each is
subject to constraint relations linking it to each of the other two.  This
three-view graph is the master model.  There is no "master _model_" which
is in one view an ancestor schema or ontology from which all the other
three are derived as projections.]

>A complete grid-transparent PM of course has some negative
>drawbacks. Therefor there should be interfaces for breaking
>transparency. For example:
>- specify reliability issues (e.g. hot/cold standby)
>- specifying the security demands of the application
>- if the use of remote resource is not for free -> specifying a
>  maximum amount of e-cash

Yes, the solution components bring with them their own constraints which
have to be factored into the problem statement that the job planner has to
solve.  In the end the job plan solves a problem composed of constraints
contributed both by the user and by the resources.

The incremental discovery of constraints attached to selected resources did
come up in the Scheduling WG sessions at GF4 but it is probably not widely
obvious.

>
>Just some thoughts.

Good thoughts.  

Al

PS:  There was, at GF4, a decision to organize a "user environments"
Working Group in the Grid Forum.  I am expecting this to be the maintainer
of statements about what the user needs from the rest of the Grid
Infrastructure, such as how the resource creator and resource binder (job
planner, e.g.) share the progressive binding of decisions that the user
cares about.  Sometimes the maximum performance will require a custom
compile on all nodes, but not often.  Even then we need one 'configure'
tools that builds the makefiles for all the compiles.

[as we speak my "welcome to gce-wg@gridforum.org" message arrives.]

The trend is quite the other way.  The tools group in NPACI has gone in the
direction of making link-interchangeable variant compiles of low-level
modules with different performance and dependency profiles so that late
binding to different environmental constraints is achieved by a simple
pick-from-list of object module choices in the library.


>
>Regards,
>
>	Torsten Fink
>