PRELUDE, the Relational-Input Module for PHOENICS
the power-point presentation of 2008
- What PRELUDE is
- What PRELUDE does
- Who will use PRELUDE
- Beginners' tutorial 1
- Beginners' tutorial 2
- Stand-alone Virtual Wind Tunnel tutorial 1
- Stand-alone Virtual Wind Tunnel tutorial 1
- Virtual Wind Tunnel tutorial 1
- Virtual Wind Tunnel tutorial 2
- Virtual Wind Tunnel tutorial 3
- Virtual Wind Tunnel tutorial 4
1. What is PRELUDE?
1.1 PRELUDE is the new pre-processor of PHOENICS.
Why does PHOENICS need a new pre-processor?
The answer is that, because the existing pre-processor, the
VR-Editor, along with its many valuable
and user-agreeable features, has two main deficiencies, namely:
- Its single-instance character, by which is meant that:
- no matter how well-imbued with PIL logic is the Q1 file which it accepts
- the files which the Editor thereafter creates contain only the
instructions to carry out a single calculation.
- Its obliterating tendencies, by which is meant that:
- Although the PHOENICS Input Language (PIL) allows new variables to be
declared by the user, and used in complicated ways for the definition of
sources, initial values and properties, the VR-Editor, while accepting
the results of such declarations, makes no record of them;
effect, it loses them.
1.2 The relation between PRELUDE and Satellite
- PRELUDE and Satellite work in tandem. PRELUDE can pass its output
to the Satellite in the form of one or more Q1 files, which the
Satellite may simply pass to the solver for execution as a series of
single-instance calculations, by way of eardat and facetdat files.
- The activation of Satellite, solver and viewer is achieved from
within PRELUDE, which thereby acts as an environment (although it may
itself have been activated from the Commander, in its role of 'outer
- Interactive users of the Satellite can, if they wish, modify the
data on its way to the solver, by way of the VR-Editor.
2. What PRELUDE does
2.1 A list of main features
- PRELUDE processes input data provided by one or more of the
This list will be extended to include all file formats required by users.
- a single-instance Q1 file,
- a multiple-instance Q3 file,
- a script containing human-editable commands,
- input, especially of formulae expressing
provided interactively by the user.
- .dat files defining shapes,
- .ac files created by AC3D,
- .stl files
- .pob files
- PRELUDE allows relationships to be typed into boxes, whereafter they are
acted upon instantly. This is probably the most important of all the
features of PRELUDE.
- PRELUDE can record the results of an interactive-input session
in the form of a Q3 file, which, because it preserves the
algebraically-expressed relationships between the data elements, can be
used for the creation of an unlimited number of individual-instance
- PRELUDE has 'undo' capabilities of the 'recall previous box
- PRELUDE is capable of summoning not-hitherto-existing shapes by
passing parameters to Shapemaker, which generates them as required. It
will thus enable the contents of the OBJECTS folders of PHOENICS to be
greatly reduced, being indeed limited to those shapes (e.g. 'man' or
'horse' which Shapemaker cannot yet make.)
- PRELUDE connects its objects in a 'tree' with parent-child
- PRELUDE has visual-display features which are not yet possessed by
the VR-Editor or Viewer. Notable among these are:
- the 'clipper' which enables which parts of the scene to be made
- the 'texturing' feature:
- control of 'eye' position and field of view via script and
attribute boxes as well as by mouse movement.
- PRELUDE can launch a series of PHOENICS runs, with different values
of specified parameters, and access the results in an orderly way.
- PRELUDE treats 'phi-variables' as objects having attributes, in a
manner similar to physical objects (except that they have no visual
- PRELUDE also treats as objects 'models' such as IMMERSOL, k-epsilon,
and solid-stress, which appear on the 'object-tree as children of the
'domain' object and as parents of their associated 'phis'.
3. Who will use PRELUDE?
3.1 Users of the Gateway approach to PHOENICS
Gateways allow users to perform simulations of pre-defined kinds, with
the minimum of difficulty.
Such users are presented with all that they need, but no more; and they
are not required to make CFD-specific decisions.
A Gateway consists of:
- a script which sets up an initial scenario;
- a 'store-cupboard' containing a set of objects with attributes which
the user is is expected to need ;
- a script embodying a tutorial which enables the new user to learn
what to do;
- some exemplary Q3s.
Examples of Gateways by means of which CHAM and its agents could create
new business are:
The first two of these exist already.
- Virtual Wind Tunnel;
- Heating, ventilating, air-conditioning and smoke movement;
shell-and-tube heat exchangers;
- steam condensers;
- coal-fired furnaces:
- CVD reactors.
- electronic equipment (HOTBOX):
- football stadia;
- F1 for schools
- Hall-cells for electrolysis.
3.2 The makers of Gateways
Gateways may be made by any sufficiently knowledgeable users for their
However, they will normally be made by such people for the use of those who
possess less knowledge, for example:
- CHAM and CHAM-J staff, for narrow-sector PHOENICS users;
- Consultants, for their clients;
- lecturers, for their students.
3.3 Skilled users of PHOENICS
In due course, it is expected that PRELUDE, because of its relational
capabilities, will become the preferred preprocessor of all users.