In many types of laboratories the experiment process execution consists of very similar stages. The given experimental process is often recurrent and must be executed many times by some parameters modification to achieve the required results. In this situation the measurement scenarios concept seems to be very useful.
The concept of the measurement scenarios allows defining the process of an experiment in any way, from pre-processing, through executing the experiment, to the post-processing and visualization tasks. Users are also allowed to add their own module as a part of the scenario. Defining the measurement scenario allows to spare a lot of time during computation. The user does not have to wait for the end of a given process stage to submit another one. It is made automatically.

We distinguish the following types of measurement scenarios:
  • static – with a fixed number and types of stages and connections between them,
  • dynamic – with a very elastic mechanism of defining stages and connections between them.

The Static Measurement Scenario (SMS) contains a simple task’s execution chain. It allows connecting particular stages only between themselves. Here, the execution path is specific and the user cannot manipulate it. Initially, we divide the experiment execution process in the SMS into four steps:
  • preprocessing – here the user can prepare data to use as an input source,
  • experiment – two types of experiments can be distinguished; the first is the real experiment executed on a device available in the Grid;
    the second one is a computational experiment running on the execution host,
  • postprocessing – here we can process the output data from the experiment stage,
  • visualization – can be treated as a part of the postprocessing stage;
    we decided to treat it as a separate task due to specific hardware and software needs.

To increase the possibility of the jobs scenario, the Dynamic Measurement Scenario (DMS) was defined. As distinct from the SMS, in the DMS model we distinguish two types of jobs:
  • experimental – a task is submitted to the laboratory devices, the specificity of this device has to be known,
  • computational – a task is submitted to one of the available application servers.

Moreover, both experimental and computational tasks can be divided into: batch mode jobs (user’s interaction is not needed) and interactive mode jobs (user’s interaction is needed).
In the DMS model, besides the definition of the tasks execution sequence, we can also define some extra connections (e.g. loops, parallel connections), conditions on the connections and different lengths of the execution paths. In fact, DMS allows defining many SMS models in one scenario. Thanks to the possibility of the conditions defining on the connections paths, the real path is determined during execution and can depend on computational results.

The creation process of the DMS model is divided into three stages:
  • preparation of the connection diagram,
  • writing down the dependencies diagram,
  • creation of the user DMS coded in the Dynamic Measurement Scenario Language (DMSL)
    (written progressively during creation of the workflow diagram by a user).

On the first stage "preparation of the connection diagram", an expertise from a particular discipline is necessary. It can be done, for example, by a laboratory administrator together with a domain expert. In the figure below we present an exemplary measurement scenario diagram for the Virtual Laboratory of NMR Spectroscopy:

The exemplary measurement scenario diagram

To properly write down the dependencies diagram, the system has to have knowledge about the available applications and about connections which were worked out on the previous stage. To make this operation easier for the final user, a special application can be used. An interface for an exemplary programme is presented below.

The interface for an exemplary programme

In case of a laboratory where the processing software is well known, it seems to be easy. The situation will be more complex when we want to define the DMS model for a wider range of virtual laboratories and we cannot a priori describe all possible execution models. To solve this problem we have defined four files:
  • basic – a file with information about possible applications parameters and possible connections with another applications;
    a list of default output files for a source application and a list of input files for a destination application;
    an additional condition to connect two given applications e.g. special data file conversion,
  • connection – a file with information about connections which were set up by a user between nodes (applications),
  • passage – a file with information about passage conditions which describe each connection link between applications;
    the condition has to be met to go farther along a given path. We can also define Boolean operations like
    "or" (default) and "and" (conditions for all links have to be met) between links,
  • arrangements – a file with parameters which were set up to a given application by a user.

We can say that the first file is an input file which has to be delivered to the application, and the rest of them are output, created by a user during the DMS definition. Files are coded using a special language which we call the Dynamic Measurement Scenarios Language (DMSL) according to an XML standard.