Updated Fri Mar 2 00:17:56 2001

Presentation

  1. Introduction
  2. Designing the steps of the process
  3. ackaging elements of the process
  4. Designing the process
  5. Checking the Action Factory and generating the wrapper
  6. Implement the behaviour of individual actions
  7. Run the process

Introduction

Action factory's VPE will enable you to design an executable specification of your computational path, to test it, and then to generate the C++ ActionFactory CORBA wrapping required to easily implement your specification.
A further improvement, yet to be published, will enable generation of a Python or C++ batch process controller, equivalent to the interactive data-flow process controller graphically designed.

In the following discussions, we will define 3 different type of people :

  • Users, which are mainly in charge of running numerical simulations and analysing the results
    They often prefer explaining their needs as a process (sequence of actions, executed in a specific order), which they would like to be automated (computationnal path / data-flow approach).
  • Integrators, which are mainly in charge of providing users with automated 'meta-tools', perfectly suited to the problem they are facing, so that they may concentrate on the physics.
    These 'meta-tools' will be assembled from current available numerical simulation tools (modelers, mesh generators, solvers, post-processors, visualizers, databases front-ends...)
  • Developpers, which are mainly in charge of providing the core of the simulation tools the integrators will wrap into components for a better usability.
    They often prefer structure their developments in modules and classes, to ease development and maintenance (object-oriented approach).

The Action Factory system is designed to help integrators filling easily the gap between developpers and users, by providing a clean data-flow to object oriented mapping, and enabling a quick and mostly automated way to build actions and computational pathes on top of existing developer's components.
While the Action Factory system is somewhat developer's oriented, the Action Factory's VPE is more user oriented. It is designed to help users and integrators to build and check actions (the steps of the process to be automated), to provide the Action Factory tools the specification they need.
Interestingly, as we will see, the specification will became directly executable as soon as the underlying implementation will be available.

Designing the steps of the process

This step may be performed directly by users

First fill the name of the step in the process, ans its description
Then interactively specify incoming and outcoming data for this step of the process
In the ActionFactory's jargon, the step is called an action, and incoming and outcoming data are exchanged through typed input and output ports of the action.

ActionEditor - Defining ports

Interactively specify parameters of that step of the process
In the ActionFactory's jargon, parameters of a step are called the parameters of the action
Then save your action description to file

ActionEditor - Defining parameters

Servers may be ignored at this stage, and default save file will be <actionname>.action.xml

Packaging the elements of the process

This step may be performed directly by users

First fill the name of the process, ans its description
Then interactively specify or load the steps (actions) of the process
In the ActionFactory's jargon, all the steps (actions) of the process are packaged in an action factory.
Then save your action factory description to file.

FactoryEditor - Definition

Default save file will be <factoryname>.factory.xml.

Designing the process

This step may be performed directly by users

Load your action factory in specification mode, to specify how various steps of your process interact : by connecting upstream action output ports to downstream action input port, you specify the order of execution and the data transmitted.

MapEditor

Type of transmitted data is checked, and you may test your computationnal path to get a print report of how it will behave once implemented.

Save your specification: You will directly use it for running your real simulation
as soon as the underlying implementation will be available !

Checking the Action Factory and generating the wrapper

This should be performed by integrators

Check that type names are consistent with implementation type names available
For each action, list the components you'll need to implement the action
In the ActionFactory's jargon, all the components required to perform a step are called servers.
Then generate your action factory wrapper.

FactoryEditor - Definition

In the directory specified for wrapper generation, you'll find that all the requested IDLs, headers, sources and Makefiles have been generated.
You'll find in the source directory, source files for each specified action.

An alternate simple too may be used to generate/regenerate already checked factories

FactoryGenerator - Definition

Implement the behaviour of individual actions

This should be performed by integrators

In each of the action implementation source file generated, look for the part to be completed : input objects are already allocated and filled, parameters too, output objects are already declarated but NOT created, and all requested servers are already bound through CORBA.
You just have to invoke the appropriate methods on the servers you've asked for, to implement the behaviour of each action.
Compile your actions and the generated action factory, and package a script for your users to launch it : you're all set !

Of course, you may need to upgrade some components, or build new ones, if you have not the appropriate tools to execute the action : there's no miracle, and there will be the work of the core developpers !
The idea is that if you have the existing underlying code, capable of performing what's required by the user, it should be very easy to package it the way the user wants it (appropriate granularity / level of abstraction, appropriate level of parametrization...)

Run the process

This step may be performed directly by users

Start your action factory : because it inherit from the generic action factory, it will register itself in the naming service. If there's no naming service available, it will dump it's IOR string which you will be able to use for direct connection.

You may then from the MapEditor, in execution mode, directly select your factory within the ones available in the naming service (or connect directly by pasting the IOR).
The MapEditor will dynamically discover which actions are available in the server, which are the same than the one in the specification.

You may now load your saved computational path. You will have to specify on which host you want each action to be executed, by filling the 'server' area of each action.
Select '1' for portname if you want dynamic invocation of the underlying servers, or specify the real portnumber if you want to connect to a specific already running server.

MapEditor

You may now run directly the process you specified

Soon, you'll be able, once satisfied with the interactive testing of your process, to generate a batch version directly from the MapEditor, in Python or C/C++.