Overall presentation
[home]


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.
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.
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
Servers may be ignored at this stage, and default save file will be <actionname>.action.xml
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.
Default save file will be <factoryname>.factory.xml.
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.
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 !
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.
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
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...)
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.
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++.

Comments, bugs, fixes to t_chevalier@libertysurf.fr.
 [Home]
|