Contents

1. What PRELUDE is
2. What PRELUDE does
3. Who will use PRELUDE
4. Beginners' tutorial 1
5. Beginners' tutorial 2
6. Stand-alone Virtual Wind Tunnel tutorial 1
7. Stand-alone Virtual Wind Tunnel tutorial 2
8. Stand-alone Virtual Wind Tunnel tutorial 3
9. Virtual Wind Tunnel tutorial 1
10. Virtual Wind Tunnel tutorial 2
11. Virtual Wind Tunnel tutorial 3
12. Virtual Wind Tunnel tutorial 4

1. What is PRELUDE?

1.1 PRELUDE is the new pre-processor of PHOENICS.

1. Its single-instance character, by which is meant that:
   • no matter how well-imbued with PIL logic is the Q1 file which it accepts as input;
   • the files which the Editor thereafter creates contain only the instructions to carry out a single calculation.

2. 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;
   • in effect, it loses them.

1.2 The relation between PRELUDE and Satellite

1. 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.

2. 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 environment').

3. 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

1. PRELUDE processes input data provided by one or more of the following:
   • a single-instance Q1 file,
   • a multiple-instance Q3 file,
   • a script containing human-editable commands,
   • input, especially of formulae expressing data-inter-relationships, provided interactively by the user.
   • .dat files defining shapes,
   • .ac files created by AC3D,
   • .stl files
   • .pob files
   This list will be extended to include all file formats required by users.

2. 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.

3. 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 simulations.

4. PRELUDE has 'undo' capabilities of the 'recall previous box contents' kind.

5. 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.)

6. PRELUDE connects its objects in a 'tree' with parent-child relationships

7. 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 invisible;
   • the 'texturing' feature:
   • control of 'eye' position and field of view via script and attribute boxes as well as by mouse movement.

8. PRELUDE can launch a series of PHOENICS runs, with different values of specified parameters, and access the results in an orderly way.

9. PRELUDE treats 'phi-variables' as objects having attributes, in a manner similar to physical objects (except that they have no visual representation).

10. 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

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:

• 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

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