Description of the PHOENICS Simulation Scenario:
The Labyrinth Tutorial

Click here for general information about Simulation Scenarios (also known as apps)
or here for access to the PHOENICS Encyclopaedia.



To whom this tutorial is addressed
  1. Background and Purpose
  2. Labyrinth menu items
    1. General
    2. 3D objects
    3. 2D walls and plates
    4. 2D apertures
    5. Variables solved
    6. Material properties
    7. Models
    8. Boundary conditions
    9. Output
    10. Computational grid
    11. Graphical output
  3. Some further Labyrinth results
    1. Pressure contours
    2. Velocity contours
    3. Temperature contours
    4. Effect of grid settings
    5. Use of VIEWER macros
  4. Concluding remarks

To whom this tutorial is addressed

The present tutorial is (in process of) being written for those who, while having general knowledge of CFD (i.e. Computer Simulation of Fluid Flow and Heat and Mass Transfer), and even of earlier versions of PHOENICS, wish now to learn as swiftly as possible about the new ease-of-use tools of the PHOENICS of 2014.

Some of those readers may be content on finding that a special-application-package which satisfies their needs has already been created, i.e. that the 'app-tree' (see below)

already bears the fruit they desire.

Others, recognising, that many more apps will be needed before all potential beneficiaries from CFD have been supplied, will wish to learn how they may become app-makers themselves. This tutorial is for them also.

1. Background and Purposes

1.1 Background: Input files and how to write them

(1.1 a) Q1 files must be written
All CFD codes need input-data files which tell them what to do. Those of PHOENICS are called Q1 files. They are ASCII files written in the PHOENICS Input Language (abbreviated to PIL).

Please note: throughout this tutorial, hyperlinks such as 'Q1 files' and 'PIL' above allow inquisitive readers to acquire fuller information about the so-marked items. But doing so is not positively advised, lest readers become lost in the (here metaphorical) 'Labyrinth' of the PHOENICS Encyclopedia. The present tutorial is itself designed to be a sufficient 'Ariadne's Thread' for the beginner.

PIL is a created-for-CFD language, and not hard to learn; but it must of course be learned by would-be providers of input to PHOENICS; unless of course some easy-to-use utility can write it for them.

(1.1 b) VRE writes 'pidgin-PIL' Q1 files
Such a utility is the so called Virtual-Reality Editor abbreviated to VRE; but how to use VRE also has to be learned. One of the early aids to learning was a tutorial using flow through a labyrinth as its example. It can be inspected by clicking here.

Strictly speaking, the student of that tutorial, and of others of the same era, are not shown what Q1 is written as a result of his or her efforts. VRE tended therefore to make its users dependent on it; and, PIL being hidden from view, so were PIL's wider powers.

They were tutorials, one might say, on how not to write Q1s, but to let VRE do the job instead. However VRE was able to write what might be called 'pidgin PIL'; i.e. expressions of only the simpler input-data concepts.

(1.1 c) Humans write parameterised Q1 files
PIL is a very powerful language, with variable-declaration, logical and conditional constructs, and formula-expressing capabilities. PIL's beyond-VRE capabilities can however be unleashed only via parameterised Q1s, which humans alone can write.

To teach them to do so, the labyrinth flow was again used, in tutorials which can be viewed by clicking here or here.

In the present tutorial also the labyrinth is being used; partly for the sake of continuity, but partly as a back-drop against which to exhibit the latest features of simulation capability and ease-of-use of PHOENICS 2014. The latter include PHOENICS-Direct and the PQ1 Editor.

1.2 Purpose

Accordingly, this PHOENICS-Direct-based Labyrinth tutorial will provide instructions about how to write parameterised Q1 files which provide input data of all important categories, namely: Chemically-reacting, thermally-radiating and multi-phase flows, which PHOENICS can also simulate, will be discussed elsewhere however.

2. Menu items

2.1 General

The original Labyrinth possessed eight specified rectangular objects, all of which fitted a Cartesian grid. Therefore a first objective of the present tutorial is to show how parameterisation enables their shapes, sizes, positions and orientations to be generalised, with interesting effects, by way of the PHOENICS-Direct menu.

During the course of this exposition, it will be observed that the objects of the original labyrinth tutorial are not all of the same kind. Three of them are truly three-dimensional; but the others are two-dimensional and grid-aligned. Since the beginnings of the 'virtual-reality take-over', nearly two decades ago, the distinction has been somewhat blurred. But it is worth clarifying now because PHOENICS has recently been rendered capable of handling objects which are two-dimensional but not grid-aligned.

Partly for this reason, the General section of the PHOENICS-Direct menu has been provided, as shown below.

This menu provides the opportunity to describe the 2D objects either in the until-now conventional manner, i.e. 'as_vr'; or in another which is both older (because it uses pre-VR terminology) and newer (because it exploits In-Form technology).

Information about the whole-domain dimensions are also introducible here.

2.2 3D Objects

(2.2 a) Parameterisation of objects

When the display button is pressed, immediately on starting the Labyrinth SimScene, the image displayed is as shown here:

This is an image which will be familiar to students of the pre-SimScene tutorials. Eight objects are displayed namely:

The image is produced by behind-the-scenes activation of the VR-Editor, caused by two lines in /phoenics/d_sapps/labyrinth/input/interface.xml which selects the scenario-display device which PHOENICS-Direct is to use in the SimScene.

The lines are:


    %PHOENICS%\d_satell\d_windf\satexe.exe vre

(2.2 a.1) Accessing objects via the menu

In order to facilitate access via PHOENICS-Direct, each kind of object has been gven its own menu, as seen above. Clicking on the box for 3D objects reveals the following:

The parameters relating to object 1 appear first. Those which characterise it, and their default values, appear in the right-hand columns. Explanations of these are:

  1. the object exists ( 'f' replacing 't' would remove it);
  2. it is the one called IN-BLOCK in previous tutorials;
  3. its shape, drawn from the PHOENICS store of '.dat files, is the one called 'cube14'. (Why then is it not truly cubical? See below);
  4. its 'rotation' is being described by the 'one-of-24-possibiliies' method, with index = 1, although as will be seen, any other would do for a 'cube';
  5. because of the 'rot24' choice, the next four entries are not used;
  6. of the next six settings, which indicate the position of (the low-x, low-y and low-z corner of the 'bounding box' of) the object, it should be noted that some are formulated as algebraic expressions involving the dimensions of the whole domain: xul, yvl and zwl; and it is of course the inequality of these quantities which gives rise to the non-cubical actual shape of the object called 'cube14'.
Scrolling down reveals some parameters relating to object 2; and thereafter to object 5.The authors of this tutorial have chosen (when writing the underlying PQ1), not to parameterise this object as copiously as object 1; for attention to one object suffices.

(2.2 a.2) Changing object atttributes

In earlier labyrinth tutorials, the names, shapes, positions and sizes were all fixed by the creators of those tutorials . Thus in the library case core 621 which underlay the second and third of these, are to be found the lines:

> OBJ,    NAME,        IN-BLOCK

> OBJ,    POSITION,    1.000000E+00, 0.000000E+00, 5.000000E-02

> OBJ,    SIZE,        4.000000E-01, TO_END,       6.500000E-01

> OBJ,    DOMCLIP,     NO

> OBJ,    GEOMETRY,    cube14

> OBJ,    ROTATION24,        1

> OBJ,    TYPE,        BLOCKAGE

> OBJ,    MATERIAL,    103,COPPER at 27 deg C

The creators of the present tutorials, by contrast, have provided in the underlying parameterised Q1 file the lines which caused PHOENICS-Direct to exhibit the menus which have just been seen, namely:

if(is_1) then

> OBJ,    NAME,        onam1

> OBJ,    POSITION,    posx1, posy1, posz1

> OBJ,    SIZE,        sizx1, sizy1, sizz1

> OBJ,    GEOMETRY,    :ogeo1:

if(:rotmo1:.eq.rot24) then

> OBJ,    ROTATION24,  orot1


> OBJ,    rot-angle, alpha,beta,theta


> OBJ,    rot-centre,  :rotcen:

> OBJ,    DOMCLIP,     NO

> OBJ,    TYPE,        BLOCKAGE

> OBJ,    MATERIAL,    :mt_1:

> obj,    wireframe,   yes)


Comparison of the above two in-Q1 sequences shows many differences, for example:

  1. In the newer one, the whole is enclosed between if(is_1) then and endif. Evidently it is this which made it possible, in the menu which was shown above, to choose whether the object should or not be present in the scenario. is_1 must be the logical variable which is set true or false by the user of the menu;
  2. within the outer 'if' block there is an inner one which enables the rotation mode to be chosen (of which more below);
  3. numbers have been replaced by character strings, their significances being specified in the parameter-declaration part of the PQ1 by statements such as:
                     Object 1
    char(onam1) ! object 1 name 
    which declares the name of object 1;
    char(ogeo1) ! shape of object 1
    which offers a choice of shapes for object 1;
    ogeo1=cube14 ! sphere;cone;cylinder;half-sphere;half-cone;half-cylinder
    char(rotmo1) ! rotation mode
    which indicates how object 1 should be rotated;
    rotmo1=rot24 ! rotang
    integer(alpha) ! rotation angle about x-axis
    integer(beta) ! rotation angle about y-axis
    integer(theta) ! rotation angle about z-axis
    char(rotcen) ! rotation centre
               wsl=west-south-low, etc.
    integer(orot1) ! rotation index
    which declare rotation parameters for object 1; and so on, to parameters representing position and size.

How to vary these parameters by way of the PHOENICS-Direct menu will be explained below.

(2.2 b) Changing the geometry of a labyrinth object

(2.2 b.1) Positions, sizes and shape

It is time to show some results of simulation; but first the scene will be changed slightly, for two reasons: first, because the results of the unchanged case have already been shown in previous tutorials; and secondly because it presents a good opportunity to show how changes can be introduced into the scene by means of menus.

We are going to change shape, locations and sizes of the in-block object inside the labyrinth as well as its material.

Under '3D objects' tab the box 'shape of object 1" is represented by a list of possible shapes wherein we can find, e.g., the cone and select it.

The objects in the list correspond precisely to the line in the PQ1 file which was already referrred to above, namely

ogeo1=cube14 ! sphere;cone;cylinder;half-sphere;half-cone;half-cyl$

This is because what appeared in the PQ1 has its automatically-created counterpart in the file
namely the lines:
      <param type="list">

        <name>shape of object 1</name>




        <value default="yes">cube14</value>







These lines are written without error (as few humans could do) by the PQ1-editor whenever it saves PQ1; and they are read by the PHOENICS-Direct module when it displays the screen image which has just been shown.
  • The object positions and sizes are given by formulae

    which for simplicity we replace with numbers as follows.

    If we now press the display-scenario button , in the VR Editor, a graphical editor chosen by default, we will see what follows.

    The object called IN-BLOCK, initially rectangular, is now replaced by a cone. This happens because the entries in the menu boxes have already been written into the frommenu.htm file, which is 'included' into the Q1 file which the VR-Editor reads before presenting the scenario image.

    Close the VR Editor window to return to the PHOENICS-Direct window.

    (2.2 b.2) Influence on the computed flow

    Of course, the change of body shape changes the flow pattern entirely as shown below. In the left are shown stream lines when IN-BLOCK retains its rectangular shape; the flow is two-dimensional. Replacement by the cone creates an obviously three-dimensional flow as shown below on the right.


    (2.2 c) Rotation

    Another means of changing geometrical attributes of the object is by rotation. There are two rotation modes provided by the PHOENICS Satellite module; and the image to follow shows how the menu allows either of these to be selected

    The mode chosen by default is rot24. It will be discussed first.

    (2.2 c.2.1) rot24 rotation mode

    This is the mode which was introduced in the early days of the VR-Editor, the menu of which refers to it, somewhat obscurely, as 'old method'. It allows the user to select a 'rotation-index' integer for the object, in the range 1 to 24. The significance of the 24 can be understood by:

    It is not a very useful mode for two reasons:

    The images that follow show orientations of the cone for rotation indices corresponding to the 6 choices of 'floor' introduced in each picture, namely: 1, 5, 9, 13, 17 and 21. There would be no point in displaying intemediate-index images, because a cone looks the same from every side.


    Note that the cones in the above pictures do not all have the same height/diameter ratio. Indeed they are not all, strictly-speaking, cones at all. The reason is that rotations of this kind constrain the object always to lie within the original bounding box; and the x-direction and y-direction sizes are different. Therefore when its symmetry axis lies in the y-direction (rotation index 5 or 17) or in the x-direction (rotation index 9 or 21), the base of the object is an ellipse, not a circle.

    (2.2 c.3) Influence on the computed flow

    Rotation of a cone (except about its symmetry axis) greatly influences the pattern of the flow, The two pictures below illustrate this for the rotation indices of 5 (left) and 9 (right).


    (2.2 c.4) The rotation-angle mode

    The second rotation mode corresponds more closely to what is understood as rotation in normal speech. It will be illustrated by first giving object 1 its rectangular shape again by choosing cube 14 again from the list of possible shapes for object 1, and then choosing rotang rather than rot24 as the rotation mode.

    The menu items then offered include:

    Let us choose, so as to see what happens:
    wsl as rotation centre, and
    rotation about y-axis = 30 degrees.

    Click then on the display-scenario button. Something similar to the following image

    should be revealed. Evidently the block has been tilted 30 degrees to the right as a consequence of the entries into the menu.

    (2.2 c.4) Influence on the computed flow

    Activation of the flow-simulating calculation by clicking the 'Run' button in due course reveals that PHOENICS has taken note of the changes made and has produced a corresondingly different, but still two-dimensional, flow pattern.

    If it is desired to produce by rotation a three-dimensional flow pattern, a further rotation about (say) the z-axis can procure this. Let this then be also 30 degrees. Then the consequent rotation and flow-pattern alterations are as illustrated in the following images.

    2.3 2D walls and plates

    The three objects which are now to be considered have the names wall-w, wall-e and in-plate; and they are numbered respectively 4, 3 and 5. They are grouped together because each exhibits, in the Q1 file, the defining line:
     OBJ,    TYPE,        PLATE
    Their effects on the flow differ in that in-plate has a flow-through-it-inhibiting effect, as well as exerting friction on both of its sides. Wall-w and wall-e do not have to exert this effect because they are situated at domain boundaries.

    The distinction is made plain by what is printed in the RESULT file as a record of the instructions which it has received, as may be seen in the following extract:

     Parent VR object for this patch is: ONAM3         
     PATCH(OB4 ,EWALL , 20, 20, 1, 10, 9, 15, 1, 1)
     COVAL(OB4 ,V1 ,1. ,0. )
     COVAL(OB4 ,W1 ,1. ,0. )
       Parent VR object for this patch is: ONAM4         
     PATCH(OB5 ,WWALL , 1, 1, 1, 10, 1, 8, 1, 1)
     COVAL(OB5 ,V1 ,1. ,0. )
     COVAL(OB5 ,W1 ,1. ,0. )
       Parent VR object for this patch is: ONAM5         
     PATCH(OB6-L ,EWALL , 5, 5, 1, 10, 6, 14, 1, 1)
     COVAL(OB6-L ,U1 , FIXVAL ,0. )
     COVAL(OB6-L ,V1 ,1. ,0. )
     COVAL(OB6-L ,W1 ,1. ,0. )
       Parent VR object for this patch is: ONAM5         
     PATCH(OB6-H ,WWALL , 6, 6, 1, 10, 6, 14, 1, 1)
     COVAL(OB6-H ,V1 ,1. ,0. )
     COVAL(OB6-H ,W1 ,1. ,0. )
    Only ONAM5, viz in-plate, has two patches: of EWALL and WWALL types respectively; and it alone has a set-U1-to-zero line, namely:
    COVAL(OB6-L ,U1 , FIXVAL ,0. )
    The above settings are made by Satellite automatically. That is one of the advantages of the virtual-reality style of object description.

    Settings via the menu

    The parameters of the thin-plate objects which can be set via menus in this Tutorial are shown in the following image:

    The objects appear in the order: wall-w, wall-e and in-plate. For each the x_size is 0.0, confirming their 2D nature. Each is given the shape 'cube11'; but this means no more that that they are rectangular planes, Even more meaningless is the ascribed rotation index 1; for any other of the 24 possibilities would effect no change. Rotations of the 'rotang' mode are not permitted for 2D grid-aligned objects.

    If however the shape is changed from 'cube' to 'wedge', the rotation index does exert an influence, as is shown by the next two images, in which in-plate is given the values 5 and 13 respectively. In order to introduce this change, simply type the word "wedge" in the object 5 geometry box to get what follows.

    Of the three, it is in-plate which has the greatest influence on the flow, as may be seen by performing runs with f rather than t in the top boxes of each object in turn; for it is in-plate which causes the incoming flow to be deflected before flowing over in-block.

    Removal of wall-w and wall-e, by contrast would remove only their modest frictional effects, which incidentally in-plate also exerts.

    2.4 2D apertures

    (2.4 a) Changing the VR shape

    What has been stated about thin plates is true, with obvious differences, about apertures also. The corresponding menu is shown below:

    The following image shows one picture of the flow which ensues when object 7, the inlet, is given the shape 'wedge' and the rotation index remains at 1. This can be done, as we already know, by typing the word "wedge" instead of "cube3t" in the 'shape of object 7' box. The grid is the rather-coarse default; and contours are of x-direction velocity.

    Evidently the flow is entering only through the lower left-hand half of the original inlet aperture.

    In principle, any existing shape of inlet can be constructed in this way; one needs only to be able to call in the .dat file which defines its facets; and to work out which is the appropriate rotation index. Since those conditions (especially the second!) are not always easy to meet, it will now be explained that there are other means of obtaining the same end; and that sometimes they are more convenient. Answering 'as_patch' to the 'inlet_treatment' question of the General menu opens the door.

    (2.4 b) The use of patches as alternatives

    (2.4 b.1) Patches with indices as arguments

    In the early years of PHOENICS, indeed until the arrival of VR, solid objects were represented by way of collections of cells containing some other material than the domain fluid; and their locations were defined by statements in the Q1 of the form:
    wherein ixf,ixl,iyf,ixl etc. were the first and last indices of the cells occupied in the x, y, etc. directions.

    Such PATCH statements appear to this day, as has been seen above.

    Users know where their objects are; but not necessarily where the cells are. However a (post-VR) 'dot-patch' innovation allows them to put a dot in front of the patch_name, and then to employ real (rxf, rxl etc.) rather than indicial arguments, thus:

    or, for a mass- and momentum-source ptach such as an inlet,

    Now a final post-VR innovation must be described: the COVAL function of In-Form. Clicking on the hyperlinks will lead to full explanations of these terms; but here it sufffices to show two examples of their use, and then to explain how they were created.

    (2.4. b.2) In-plate (object 5) as a dot-patch.

    In section 2.3 it was shown how the shape of the in-plate object could be changed by invoking a wedge rather than a cube as the shape. Here another means of doing so will be illustrated. Specifically, the shape of the lower edge will be made sinusoidal.

    How this is done is revealed by the following lines from the underlying PQ1:

    else          ! the dot-patch alternative
    (source of u1 at .:onam5: is coval(1.e10,0.0)!if(:condtn:))
    wherein the first few lines dictate the bounding box of the plate, that beginning 'source ' sets the x-direction velocity to zero when 'condtn' is true, and the line above it, which contains the sine function, dictates where the setting is to be made.

    That these lines are effective is shown by the following image, which displays contours of x-direction velocity just downstream of in-plate, with values of NY and NZ increased from their defaults in order to intensify the effect. Their sinusoidal shape is very clear.

    The 'condtn' formula can of course be varied without limit; therefore any desired shape of plate can be easily created.

    Two comments are needed about the above-shown PQ1 lines, for example:

    namely: the division by yvlast indicates that ryf is a non-dimensional co-ordinate; and the multiplication by 1000 is a not-worth-explaining 'trick' concerned with the inner workings of the Satellite coding.

    (2.4. b.3) Circular inlets and outlets

    A similar technique can be employed for altering the shapes of inlets and outlets. Thus, the following diagrams illustrate, on the left and right respectively: an inlet in which an inner circular section is blocked; and an outlet in which the circular section is open. The grid is uniform, with 40 and 60 intervals in the y- and z-directions respectively. The contour plots are of x-direction velocity; and the chosen planes are close to, but not precisely at, the planes of the apertures.


    The PHOENICS run which produces the just-shown results was launched by way of menus already shown; but, underlying these were some passages in the parameterised Q1 file which will now be discussed. For the inlet they are:

    else          ! the dot-patch alternative
    which desctibe the bounding box of the patch;
    (stored var rgt is 1 !if(
    which define the centre of the circle and its radius (squared), also define the outside-circle condition; and
    (source of p1 at .:onam7: is :invelx: with fixf!if(:condtn:))
    which applies the sources of mass, momentum and thermal energy.

    For the outlet, the statements are identical except that: 8 replaces 7 because that is the object number; and '.lt.' replaces '.gt.' because the active area is now inside rather than outside the circle.

    2.4 c. Reminder of for whom this tutorial is intended

    Some readers, having persisted to this point, may be thinking: "That's all very clever; and perhaps useful; but can an ordinary PHOENICS user be expected to learn all that?"

    A pertinent question; to which the answer is: "Certainly, not!"

    It is the prospective PQ1 writer who should learn it; and who should, if it is relevant to the SimScene which is to be created, enable the 'ordinary user' to exploit the available facilities.

    How is this to be done? Simply by utilising the existing facilities connecting PQ1, scene.xml, and what appears in the user's screen.

    Does the user, interested in circular inlets, wish to choose the centre and radius of the circle? The PQ1 writer should find it is easy, (xcen, ycen, zcen and radsq already having been defined as parameters), if this tutorial has been successful, to know what to do. Readers might wish to ask themselves how they would make this possible before activating and exploring the provisos for radius adjustment already made, in this tutorial, in the menus for the inlet and outlet objects.

    2.5 Variables solved

    This menu group allows the setting of solved-for variables as the following picture shows.

    These are pressure p1 and temperature tem1, as well as the three Cartesian-directon velociy components, u1, v1 and w1.

    They can be set either to "t" (meaning "true") or "f" ("false"). The index "1" indicates that this is a case when only one fluid is used, no provision having been made, in this tutorial, for activating the two-intermingling-fluids capabilities of PHOENICS.

    That individual variables can be set "t" or "f" does not imply that any arbitrary collection of settings is reasonable. Thus presssure should always be solved for; otherwise mass continuity will not be preserved. Solvng for temperature, might be switched off if thermal effects were of no interest; but solving for it alone, although possible, would be unwise unless physically plausible velocity distributions had been imposed.

    That is all that will be said about the topic here.

    2.6 Material properties

    (2.6 a) Properties of solid objects

    A common practice is to select the properties of a material by assigning it an index indicating where, in a so-called PROPS file, its properties are defined. The PHOENICS solver module consults this file; and so can its users if they wish.

    The selection of the material of the solid objects can be selected via the top three boxes of the menu shown below:

    When the drop-down menu of the object 1 box is activated, what is seen is shown below.

    This enables other materials to be selected, with their correspondngly-different densities, thermal conductivities, etc., all being regarded as independent of temperature.

    (2.6 b) Properties of the fluid

    The properties of the fluid can be selected in two ways, namely: The image below shows the names of the fluids which are on offer.

    If one of these is selected, the information, which is drawn from the PHOENICS library of materials, includes how the properties vary with temperature.

    2.7 Models

    A page with this title is provided in most SimScenes in order to alllow the switching on and off of physico-chemical models for processes such as turbulence, radiation, combustion etc. Labyrinth is not rich in this respect, as shown here:

    It allows turbulence to be represented either not at all, or else by the simplest-of-all lvel model. As is clear from the above image none of the models is used at present.

    2.8 Boundary conditions

    The boundary coditions which can be set here are:

    2.9 Computational grid

    The computational grid page contains grid settings,

    i.e the number of grid cells in X-, Y- and Z-directions and also the number of iterations. Increasing the number of iterations it is possible to improve the convergence of the calculation process.

    Note that in this page 3-dimensionality is introduced by making the number of cells in Y-direction equal to 10 rather than to 1 used in the two-dimensonal simulations in the older labyrinth tutorials mentioned above.

    2.10 Graphical Output

    In the graphical output page a user sets his control on the display of streamlines upon termination of the calculation. Here a principal possibility is made evident when in the first box either "t" (true) or "f" (false) is chosen. In case a user chooses to display streamlines, their number is entered in the second box.
    How and where this possibility is realized, will be shown in section 4.

    3. Some further Labyrinth results

    Some results of flow simulations have been presented above, particularly in order to illustrate the effects on the flow of changing object orientations. Some further results will now be presented in order to illustrate other consequences of changed data settings.

    Click on the 'Run' button to start the calculation, and upon its termination click on the "Display results graphically" button to open the VR Viewer.
    We will here present some results of the simulation made.

    3.1 Pressure contours

    Pressure contours on Y-plane look like what follows if you click on the 'Slice Direction Y' button and on the 'Contour toggle' button from the tool bar.

    3.2 Velocity contours

    To present velocity contours on the same plane, click on 'Select velocity' button (V) and you get what follows.

    You might wish to display velocity contours on X-planes; then you will see the following picture.

    Here, for better visibility, we selected the wireframe-display mode by clicking on the 'Wireframe toggle' button;

    and similar representation of velocity contours on the Z-plane will look as follows:

    3.3 Temperature contours

    It is now time to look at temperatures. The following picture is obtained when temperature has been chosen as a variable in question (the box T), contours on Y-plane (i.e. along the labyrinth) and the 'Wireframe' mode being switched off by another click on the 'Wireframe toggle' button.

    Of course, the file \labyrinth\input\scene.xml would have to be brought into line with the new q1.htm, by means of the PQ1editor. Then the new coefficient, cotem, would appear in the relevant menu box immediately below hitem; and any SimScene user could select the value which he or she preferred.

    3.5 Use of Viewer Macros

    As an additional means to the display of results after the calculation has been made is running of the macro which contains the succession of images already specified in the Q1 file in the lines starting with
        write(>u, p;;;;;                        )  
        write(>>u, Start of frame                                                  )
        write(>>u,  * Setting display switches                                     )                                                          )
    Here the 'write' statements contain instructions for the macro file 'u' for the creation of several specific images (frames) shown in a given sequence one after another.
    In order to run a macro,

    4. Concluding remarks

    If you are now reading these lines of our very long Tutorial and have not been embarrassed so far by the information it contains, then most likely our work has not been in vain. Even if at the present moment you have not gained a clear understanding of the information presented in all details, you will no longer be lost in this Labyrinth which has taken so much of your attention. Besides common sense and patience will serve as the best 'Ariadne's Thread' anyone could possibly dream of.