Encyclopaedia Index

ASAP Arbitrary Source (or Solid) Allocation Procedure

ASAP - Simulating Complex Flows with a Cartesian Mesh


D B Spalding and Q Zhang

Presentation at PHOENICS Conference, Tokyo, 1996

Update 1999: ASAP-like features still exist in PHOENICS; but they have become part of the PARSOL facility.


  1. Introduction
  2. General description of ASAP
  3. Some examples of the use of ASAP
  4. Future developments
  5. Conclusions


ASAP is an abbreviation for:

Arbitrary Source (or Solid) Allocation Procedure.

It is an add-on to PHOENICS which permits sources and solid objects to be placed within pre-defined grids, their presence being signalled by the attachment of the corresponding fluxes and material-property values to the appropriate cells.

ASAP therefore allows the user to set up his flow-simulation problems wholly in geometrical terms, without considering the grid.

The paper describes the basic theory in genral terms, and the method of setting up problems in more detail.

Examples of the use of ASAP are then presented, ranging in complexity from a simple cylinder to a Formula-1 racing car.

The prospects and plans for the further development of ASAP are discussed.

1. Introduction

1.1 The growing complexity of modern flow-simulation problems

Now that computational fluid dynamics has become an accepted tool of engineering and science, the flow-simulation problems which its users attempt to solve become more and more complex.

Quite apart from the complexities associated with the physical and chemical processes involved, the geometrical shapes of the boundaries of the flow domain, and of solid objects placed within that domain, become ever more complex.

Further, the flow-determining sources of mass, momentum and energy may be defined in complicated ways.

A realistic example exhibiting these complexities is that of a fire-fighting vehicle, moving among blazing buildings and projecting jets of water in continuously-changing directions. Other examples are:-

Such flow-simulation tasks are often attempted with the aid of moving body-fitted coordinates; but this approach is attended by considerable difficulties, and there is no general-purpose computer code which is currently able to solve them routinely.

ASAP has been devised so as to enable the general-purpose PHOENICS code to simulate flows of great complexity as easily as simple ones.

1.2 The ASAP idea

(a) Fitting data into a prescribed grid

ASAP is a software package which transfers information about the presence of sources and solids into the cell-wise-organised data structure of PHOENICS, without the user's having to be aware of that structure.

The grid can indeed be a cartesian one, the fineness of which the user can certainly control; but he concerns himself only with the construction of the objects and sources which constitute his physical problem. ASAP does the rest.

The objects are constructed from a sufficiently (for the time being) varied set of elementary shapes and materials, the selection, sizing and location of which are the user's main tasks.

He is helped in the performance of this task by an interactive graphical package, based on but differing from PHOTON.

(b) Questions of accuracy, grid-fineness, and economy

Of course, the accuracy with which PHOENICS simulates the phenomenon will depend on the fineness of the grid which is used; and it may well be that ASAP will need a larger number of cells to achieve a given accuracy than a well-designed body-fitted-coordinate grid.

However, the man-time and computer-time required for the creation of such a BFC grid are often great; and cartesian-grid computations are usually faster and less memory-intensive than BFC ones.

It may therefore often be the case that the balance of advantage lies with the conceptually and practically simpler ASAP approach.

ASAP was first conceived (by the first author) and implemented (by the second author) early in 1995. Since that time it has, been used successfully in several highly-demanding consultancy tasks.

CHAM's judgement is therefore that the technique is sufficiently well-proven to be generally released.

1.3 Outline of the remainder of the paper

In the remainder of the paper, section 2 explains how ASAP works, in general terms, and then focusses attention on the aspects which most concern the user, namely:

The last topic is by far the most important; therefore its principles are explained in some detail.

In the interests of brevity, however, the fully exhaustive treatment of this file and its syntax is relegated to Appendix 1.

Section 3 then introduces some applications of ASAP. Two of them, namely the cylinder in cross-flow and the Tee-junction, are rather simple. The last three however exbibit considerable complexity.

2. General description of ASAP

2.1 How ASAP works: Basic principles

The user is required to describe the solid objects and their associated sources in terms of their locations in Cartesian space, and the magnitudes of their quantitative attributes.

He does this by creating a GEOMDA file which contains details of the objects and then attaches this GEOMDA file to the bottom of the Q1 file. The detail of how to attach the GEOMDA file to the Q1 file will be explained in Section 2.4 below. The geometry data in the Q1 file are read by the ASAP attachment to EARTH, which converts the information into the grid-related terms understood by PHOENICS.

The reading of geometry data, and the allocation of the necessary storage, are effected in Group 1, Section 1 of the special GROUND, GXASAP, via :


Then a call to ASAPZZ is made in Group 11, whereafter EARTH performs the simulation in the usual way.

When, as is usual for ASAP, the chosen grid is either Cartesian or cylindrical polar, the task of transferring the source-and-solids data from the user's geometrically-organised description to the PHOENICS grid-based one is exceptionally easy.

The IX, IY and IZ (or I,J,K) indices of the cells can then be expressed explicitly in terms of the x, y and z in which the data are expressed.

All that is necessary is for the program to break the solids and sources into sufficiently small fragments and then to "project" them into the PHOENICS grid, where they contribute to the blockage of the cells, when solids are in question, and to the sources of the appropriate PHOENICS variables.

These operations are however performed out of the user's sight.

2.2 The Q1 file

ASAP is activated by including in the Q1 file a patch called QSOLID, which extends over the whole domain of simulation, by means of the following commands:


The creation of this patch activates ASAP during the EARTH run, and causes the GEOMDA file to be read.

In the future, the simple command


will be made to suffice for all ASAP-related Q1 settings; and probably the GEOMDA data will be read from Q1 itself.

The other entries in the Q1 file are conventional. In particular, the grid which is to be used, and what variables are to be solved for, are defined there.

The value of INIADD should be set to F (ie false), whenever, as in most cases, the main function of ASAP is to provide a distribution of the variable PRPS.

ASAP is used solely to fit geometrical objects and associated sources into the grid, thereby performing tasks which would otherwise be done by Group 11 and Group 13 commands.

2.3 Getting the sources-and-solids data into EARTH

The description of the solids and sources which are to be placed in the grid must be supplied in a file called GEOMDA. This must reside in the working directory.

The GEOMDA file is the main focus of attention of the user of ASAP. It will therefore be extensively explained and exemplified below.

In order to be able to read the GEOMDA file, and to create the corresponding distributions of solids and sources within the grid, the EARTH executable must contain a special GROUND.OBJ containing the sub-routine calls mentioned above, and a special library called ASAPLB.OBJ.

This special library contains an interactive-graphical-display feature, based upon PHOTON but different from it, which enables the objects and the flow to be clearly visualized.

When ASAPLB.OBJ has done its work, if the introduction of solid objects is in question, the result is a three-dimensional array of values of the variable PRPS. That is all; and of course the same information could be conveyed to EARTH from a phi file in a restart run.

If it is sources which are to be conveyed, the result of ASAP's work is the filling of a three-dimensional array of sources of the variable in question. This is an array which does not ordinarily find a place in PHOENICS, except in the GENTRA option.

All ASAP sources are, at the present time, of the fixed-flux variety. Linearised sources could be introduced, if the need arose, as could sources of a more complex kind, for example those which depend on several local variables.

Formulae for these sources could be introduced in a PLANT-like manner; but this has not yet been done.

2.4. Creating the GEOMDA file: the ASAP language

(a) Key-words

The GEOMDA file is an ASCII file, which can be created by means of any editor or word-processor.

Two such files are shown, in sections 3.1 and 3.2 respectively. The first relates to a cylinder, and the second to a Tee-junction. They are both short, and, once a few simple rules have been recognised, easy to understand.

The language of ASAP has very few words of its own; they are, in alphabetical order:

These words are refered to as key-words. All are fully explained in Apendix 1.

(b) Other words

Not all key-words are used in every file. Thus, the file of section 3.1 uses only: COORDINATE

while that of section 3.2 uses additionally: BOX CONSTANT END END-OF-GROUP POLY-SURFACE.

However non-ASAP words, ie those introduced by the user, are also to be found. They are of three kinds, namely:-

  1. the names of constants which follow the CONSTANT keyword, for example HEIGHT in the file of section 3.2;
  2. the names of objects, or collections of objects, which follow the GROUP keyword, eg THE-CYLINDER in that of section 3.1.
  3. any words which follow // placed in the first two columns, which words are ignored by ASAP, but serve to aid the user's understanding, in the capacity of "comments" or "remarks".

(c) Conventions

ASAP is not case-sensitive; but it is useful to adopt the convention that words to which ASAP responds are upper case, while comments are lower case.

Blank lines may be inserted in GEOMDA files without having any effect.

Every line which is neither blank nor a comment must be complete in itslf; continuation from one line to the next is not permitted.

Indentation is significant to ASAP. When it occurs, as in the GEOMDA of section 3.2, the rule is always: move four spaces left or right.

Most ASAP-readable lines are of the form:

key-word, followed by a sequence of numbers

However, any number may be replaced by a previously-declared constant; and the GROUP key-word is followed by a user-chosen name.

(d) Objects

At present, eight classes of object are available. They are:

Object class

ASAP keyword

rectangular boxes, aligned with the grid BOX
circular-sectioned cylinders CYLINDER
elliptical-sectioned cones, which may be truncated CONE
ellipsoids ELLIPSOID
cylinders of arbitrary uniform cross-section AERO-FOIL
arbitrary 3D shapes SOLID
pipes (of any cross-section) with bends POLY-PIPE
point source of mass, momentum, energy, etc POINT-SOURCE

The key-word must be followed by the numbers 1 or 2, according to whether the PROPERTY value is to be applied inside or outside the surface of the object. The number is called the type of the object.

(e) Material indicators

What material is to be associated with the object, whether inside or outside its surface, is indicated by the number following the preceding PROPERTY key-word. These numbers correspnd to the values of the PHOENICS variables PRPS, to be found in the PROPS file.

Thus, in the GEOMDA files of sections 3.1 and 3.2, PROPERTY 111 signifies that the material is steel.

In the visual display, distinct colours are associated with each material. That of steel is blue. [Note: The colour-to-materials associations are currently fixed by an inaccessible data statement. This will be changed.]

The PROPERTY value governs all objects below it in the GEOMDA file, until the next PROPERTY line is reached.

(f) Constants and other GEOMDA features

It is often convenient to replace numbers by names of variables, eg HEIGHT, as in the section 3.2 GEOMDA.

The variables need to be first declared, and assigned values, by lines beginning with the keyword CONSTANT.

Thus PROPERTY 111 could be replaced by


Further details of this, and all other features of the ASAP language used in GEOMDA files, are fully described in Appendix 1. No further explanations will be provided in the body of the text.

2.5 How to attach the GEOMDA file to the Q1 file

The GEOMDA file described above can be read directly by the ASAP. However, it is strongly recommended that the GEOMDA file created is attached to the corresponding Q1 file. The advantages of this practice are twofold: a) GEOMDA files will never be mixed up with irrelevant Q1 files; b) this enables the user to create a ASAP library which contains both the PIL settings and the geometry data for each case. To attach a GEOMDA file to the corresponding Q1 file, the user should:

  1. insert cg(8)=Q1 at the bottom of the Q1 file right before the STOP statement; this causes the ASAP to read the Q1 file and to search the geometry data from it; otherwise the ASAP will read the GEOMDA file for the geometry data input;
  2. insert the flag starting from third column after the statement cg(8)=Q1;
  3. insert the flag starting from third column after the flag ;
  4. insert the entire contents of the GEOMDA file between the flag and the flag ;
  5. move in the entire contents of the geometry data statements two columns. Note that the maximum length in the Q1 file is 68.

An example of the Q1 file can be found in Appendix 1.

2.6 Interactive viewing

To enable the user to view quickly the geometry which he has created, an interactive-graphics feature has been supplied within the ASAP option.

This is activated via the graphical-monitor option (TSTSWP= -1) of PHOENICS, which offers a PHOTON button among the other interrupt options.

This allows the geometry to be inspected and velocity vectors (but not yet contours) to be drawn.

An example is shown below, in secton 3.2.

2.7 The ASAP file structure

The ASAP has been attached to PHOENICS as an option.

All the files related to EARTH attachment are in the directory D_EARTH/D_OPT/D_ASAP and the ASAP library, ASALIBDA.UDA is included in the directory D_SATELL/D_OPT/D_ASAP.

The special GROUND, GXASAP is called from GREX3 when NAMGRD is set to ASAP in the Q1 file.

2.8 How to load ASAP library cases

There are four cases in the ASAP library. They are: T-Junction case 100 Ink-Jet case 101 Soaking pit case 102 Drill bit case 103

To run a library case, the user should follow the steps described below: runsat type m to activate the top menu panel select library option from the menu panel select ASAP library select load option and enter case number select 'end' to save the Q1 file and quit the SATELLITE runear

During execution of EARTH, the user can view the geometry and velocity vectors as described in Section 2.6.

3. Some examples of the use of ASAP

3.1 The cylinder in cross-flow at Reynolds Number = 40

The GEOMDA file for this case is extremely simple because there is only one object to be introduced, namely the cylinder. It is as follows:

    COORDINATE  1.0  -0.5  0.0
    PROPERTY 111
    GROUP THE-CYLINDER  0.0 0.0 0.0  1.0 1.0 1.0
        CYLINDER 1 0.5 0.5 0.0 0.5 0.5 1.0  1.0 2 2

Computed results now follow.

Velocity vectors

Pressure distribution


Comments on the circular-cylinder results

The computed results appear to be rather satisfactory, the length of recirculation being around 2.0, whereas experimental data for this Reynolds Number may be somewhat larger.

No comprehensive study of the accuracy attainable has been made however.

3.2 The tee-junction

    A vertical pipe joins a horizontal ---------------------------
    pipe from below. Both are          |/////////////////////////|
    represented as hollow cylinders    ---------------------------
    within a rectangular steel block.  <--->
                                       -----------  ^  -----------
    The Q1 file is supplied as         |/////////|  |  |/////////|
    Appendix 2.                        ----------|     |----------

The GEOMDA file for this case is longer than that of the cylinder, because there are three objects to introduce. Note that one of them, the box, is of type 1 (ie solid is inside), while the others, namely the cylinders, are of type 2 (ie solid lies outside).

Explanatory comments are included.

   // Declaration of variables used in this file
   //        box height   horizontal  half horiz      box
   //                     pipe diam   pipe length     thickness
   //        vertical pipe  twice      y coordinate
   //        diameter     verpipdi     of horiz. pipe
   //                                  centre-line

// Note that, because ASAP language is (unlike PIL) not yet able to
// interpret arithmetic expressions, both diameter and twice-diameter // must be assigned by the user.

// x,y & z of origin of local coordinate system of following objects COORDINATE THICK 0.0 HALFHOPILN

// 111 is steel, the colour of which is blue in the visual display PROPERTY 111
// Group is a flag indicating the elements grouped to form a geometry
// Name and oordinates of bounding-box corners are:
// group name x1 y1 z1 x2 y2 z2 GROUP T-JUNCTION -THICK 0.0 -HALFHOPILN 0.0 1.5 HALFHOPILN

// Two points to define a BOX. The 1 means material set by
// PROPERTY is INside
// Coordinates of bounding-box corners are the same as for GROUP BOX 1 -THICK 0.0 -HALFHOPILN 0.0 1.5 HALFHOPILN

// 102 for brick colour is red PROPERTY 102

// Class of object is CYLINDER. Type = 2 means material is OUTside
// type x1 y1 z1 x2 y2 z2 diameter
// open ends
// vertical cylinder CYLINDER 2 0.0 0.0 0.0 0.0 YHCL 0.0 VERPIPDI 1 1

Some computed results now follow.

A picture from the interactive viewer
Velocity vectors

A picture from PHOTON
Pressure contours

3.3 The oil-well drill bit

This simulation represents a real-life industrial problem.

The GEOMDA file for this case comprised 37 objects.

The file was 650 lines long.

The data were obtained, manually, from an AUTOCAD file, because automatic data transfer has not yet been effected.

The grid was 54 * 54 * 25.

The k-epsilon turbulence model was employed.

No comparison with experimental data is available.



Velocity vectors

Velocity vectors at a cross section

3.4 The Formula-1 racing car

The GEOMDA file for this case comprised 44 objects.

The file was about 1000 lines long.

The grid size was 50 * 55 * 208

The k-epsilon turbulence model was employed.

No comparisons with experimental data have been made.




3.5 The leaking gas cooker in a room

Finally, an example in which there are sourcs of mass and momentum:

A gas cooker is supposed to be injecting unignited gas into a room.

Fortunately, it is close to a ventilator. The question is: will the gas be withdrawn with sufficient rapidity.

The study is not complete, from the engineering point of view; but the pictures will show what ASAP can do.

Approximately half a man-day was used in setting the problem up. The room, the cooker and the ventilator


A closer view

The gas flow

A closer view

The gas concentrations near the top of the cooker

4. Future developments

4.1 With staggered grids

ASAP has produced some excellent flow simulations (many more than have been shown here). CHAM thereore intends to develop it further.

Among the envisaged improvements are:

Curved solid-fluid boundaries are currently represented by ASAP in a step-wise manner, because all cells must be either fully blocked by solid or fully open to fluid. For this reason, accurate representation of the flow requires the use of rather fine grids.

It is possible to introduce into PHOENICS special solid-fluid boundary conditions, by extending the EGWF (Earth-Generated-Wall- Function) feature.

Whether or not this will be done depends on the speed with which new X-Cell algorithm of PHOENICS is developed. Probably X-Cell will advance with sufficient rapidity to rendered further adaptations of ASAP to staggered grids unnecessary.

4.2 With X-cell grids

Reference 1 describes the X-Cell feature, of which all that need be stated here is that it currently employs a cartesian grid subdivided by diagonals. Each rectangular cell therefore contains four triangular cells, in two dimensions, or six pyramidal cells in three dimensions.

This arrangement renders the acurate representation of curved solid-fluid interfaces much easier, because the fluid can lie on one side of a diagonal while the solid lies on the other.

In order to exploit X-Cell, ASAP will need to employ a somewhat different search procedure: instead of asking which rectangular cell a solid particle lies in, it must find out which CORNER of the cell it occupies.

There appears to be no difficulty of principle or practice in the way of this development.

4.3 Other possibilities

(a) Grid adaptation

As described above, ASAP placs solids and sources as well as it can in a pre-defined grid, and then immediately initiates the flow- simulation calculation.

However, it will often prove advisable to introduce a grid- adaptation and -refinement stage before the said calculation starts.

What is necessary is to compute the extent to which the solids as represented by blocked cells fail quite to conform to the objects defined by GEOMDA, and then to shift grid coordinates (while still retaining their cartesian nature) or to introduce new cells in the best possible places, so as to reduce the error. (b) Development of an object library and the link with PHOENICS-VR

A modern tendency in applied computational fluid dynamics is to keep the mechanics of the simulation process hidden from the user.

The user will take responsibility for defining the situations to be simulated, and for interpreting and assessing the results; but he will require the simulation itself to proceed automatically, economically, and with good quality control.

ASAP is wholly compatible with this tendency; but its dependence on the editing of the GEOMDA file, at the present time, imposes a requirement which not all users will meet.

Fortunately, it is also compatible with the object-oriented reality- focussed style of the PHOENICS Virtual-Reality Front End; for the latter placs objects in space; the former (ASAP) implants them in the grid.

What is therefore needed is an invisible link: the GEOMDA file must automatically result from the VR-user's specification.

5. Conclusions

ASAP has proved to be a robust and easy-to-use device for introducing complex geometrical and source data into PHOENICS.

Its great merit is that it can work which cartesian grids, and that the user is spared the task of adapting even these to the input data.

Its disadvantages are that, for a fixed number of cells, it is likely to give less accurate solutions than those obtainable from body-fitted-coordinate grids.

Two kinds of improvement are foreseen, namely:

  1. an improvement in accuracy, resulting from the adptation of ASAP to the X-Cell grid; and
  2. automatic generation of the GEOMDA file by use of the PHOENICS-VR front end.

Appendix-1 The GEOMDA File and its syntax

Geometrical information to be used by ASAP is stored in a formatted data file called GEOMDA. The data in this file are organised in terms of both format and key-words.

All key-words or data items are separated by space(s).

There is no distinction between real, integer or character variables, the type of a particular data item being determined by the format of the statement containing the data.

A typical GEOMDA file has the following format:

 // [comments-1]
 CONSTANT   name1=[value1]   name2=[value2] ...
 COORDINATE [x  y  z]
 GROUP  [group1-name] [x0 y0 z0   x1 y1 z1]

 BOX [type] [x0b y0b z0b x1b y1b z1b] 
 CYLINDER [type] [x0c y0c z0c x1c y1c z1c] [D]
 // [comments-2] 
 GROUP [group2-name] [x2 y2 z2 x3 y3 z3] 
 BOX [type] [x2b y2b z2b x3b y3b z3b] 
 POLY-SURFACES CONE [type] [x11 y11 z11] [x12 y12 z12] 
    [x13 y13 z13] [x21 y21 z21] [x22 y22 z22] [x23 y23 z23]  
 SOLID [type]
 FIRST-CHAIN [xf1 yf1 zf1] [xf2 yf2 zf2] 
 Chai1n [xcn1 ycn1 zcn1] [xcn2 ycn2 zcn2]

Items in the square brackets are values specifying the geometry.

Any line starting with double slash "//" is treated as a comment.

Comment lines can appear anywhere in the file.

No continuation line is permitted.

The rule for indentation is shifting four spaces right for each sub-object.

CONSTANT name1=[value1] name2=[value2] ...

This statement assigns numerical values to character names.

Names are character strings up to 10 characters long and value1, value2, etc are numerical constants.

Once a name has been assigned a value in a CONSTANT statement, it can be used to represent that value anywhere in the file. The basic co-ordinate system in ASAP is the co-ordinate system used in creating the mesh system. Each ASAP object can have its own co-ordinate system, which is convenient but not essential.


The three real numbers in the bracket define the origin of the local coordinate system.

Subsequent geometry elements are all defined in this local coordinate system until another coordinate statement redefines it.

The coordinate statement can appear before any geometry element or group (see later) statement but not within the definition of a geometry element.

The default coordinate system is the one used in other parts of PHOENICS.


This statement assigns the PRPS index value to all subsequent geometry elements until being redefined by another PROPERTY statement.

Like the COORDINATE statement, the PROPERTY statement can be put anywhere in the file except within the definition of a geometry element.

GROUP [group-name] [x0 y0 z0 x1 y1 z1]

All geometry elements in the GEOMDA file are grouped as the user chooses.

The group-name is a character string with no space in it.

Six numbers define a Cartesian bounding box. The first 3 indicate x, y and z of the west-south-low corner; and the last 3 indicate those of the east-north-high corner of the cube.

Any geometry element or part of it falling outside this box will be discarded by ASAP.

The group statement should always be matched by an end-of-group statement.

The default box is the entire computational domain.

BOX [type] [x0b y0b z0b x1b y1b z1b]

This statement defines a Cartesian six-sided rectangular surface.

There are two types of geometry elements:

This is true not only for BOX but for all other geometry elements.

The six numbers in the second bracket define the box by its corners, in exactly the same way as in the group statement.
ELLIPSOID [type] [xe1 ye1 ze1] [xe2 ye2 ze2]
    [xe3 ye3 ze3] [xe4 ye4 ze4]  

This statement defines an ellipsoid (of which class a sphere is a special case) having the centre at [xe1 ye1 ze1] and three axes defined by the three vectors [xe2 ye2 ze2] [xe3 ye3 ze3] and [xe4 ye4 ze4].

Both the directions and the lengths of the vectors are read by ASAP.

If the user has inadvertently specified non-orthogonal directions, ASAP will modify these by taking the first vector as correct, the second as defining only its length and the surface in which it lies, and the third as defining only its length. CONE is a truncated cone that has a top and a bottom. One of them can have effectively zero area.
CONE [type]
[x11 y11 z11] [x12 y12 z12] [x13 y13 z13]
[x21 y21 z21] [x22 y22 z22] [x23 y23 z23]  

The description of a CONE occupies three lines.

The second line defines the top plane of the cone, as follows:

In the case of circular-sectiond cone, the two vectors should have equal lengths.

The third line has exactly the same meaning as the second line but for the bottom of the cone.

CYLINDER [type] [x0c y0c z0c] [x1c y1c z1c] [D]

This object class comprises cylinders of circular cross-section, each defined by the two ends of its axis, [x0c y0c z0c] & [x1c y1c z1c], and by its diameter D.

Cylinders of more general cross-section are handled in the AERO-FOIL object class.

        AERO-FOIL  [type]  [x0c y0c z0c]  [x1c y1c z1c]
                [xf1  yf1  zf1]
                [xf2  yf2  zf2]

An AERO-FOIL is defined here as a cylinder with arbitrary cross section.

The description of an AERO-FOIL requires more than one line. The exact number of lines depends on the number of points [xfi yfi zfi] given to describe the shape.

An END statement is used to complete the data input for the aero-foil.

[x0c y0c z0c] and [x1c y1c z1c] define the ends of the axis of the aero-foil.

A poly-pipe is defined as a collection of cylinders with the same diameter and joined axes.

        POLY-PIPE  [type]  [D]
                [xf1  yf1  zf1]
                [xf2  yf2  zf2]

Here D is the diameter of the pipe and the points [xfi yfi zfi] and [xf2 yf2 zf2] describe the centre-line of the pipe.

        SOLID [type]
                        [xf1  yf1  zf1]
                        [xf2  yf2  zf2]
                        [xcn1  ycn1  zcn1]
                        [xcn2  ycn2  zcn2]

SOLID is the most general type of geometry element. In principle, any geometry can be create by using SOLID only.

However, in practice, building complex geometry with SOLID only can be very inefficient.

A SOLID is a hexahedral enclosed by 6 plane surfaces.

Each CHAIN defines a closed 3_D poly-line. All CHAINs contain the same number of points.

The rule here is that all lines linking 2 corresponding points belong to two neighbouring CHAINs are on the surface of the solid.

FIRST-CHAIN here is not different from other CHAIN statements except that the name marks the beginning of data input for SOLID geometry.

POINT-SOURCE is an object of a different kind from the others: it causes the introduction into the field of a source of momentum (in any of three cartesian directions), of mass, or of energy, at a defined point in space.

The syntax is:

POINT-SOURCE [npoints] [x y z] [uc vc wc] [m] [temp]

------------------------------------------End of Appendix-1 ------------


    Q1 file with the GEOMDA file attached
                  for Flow in a T-junction
        TALK=T;RUN( 1, 1);VDU=VGAMOUSE
        Group 1. Run Title
        TEXT(T-Junction        )
        Group 2. Transience
          * Set overall time and no. of steps
             * Modify regions
         Groups 3, 4, 5  Grid Information
          * Overall number of cells, RSET(M,NX,NY,NZ,tolerance)
           * Set overall domain extent:
           *        xulast  yvlast  zwlast    name
        XSI= 0.6;YSI= 1.5;ZSI= 3.0;RSET(D,CHAM    )
              If only a portion (half or quarter) of the geometry
              is taken as the computational domain RSG2 should be set
              accordingly otherwise set RSG2=1.
         Group 7. Variables: STOREd,SOLVEd,NAMEd
           * Solved variables list
           * Stored variables list
           * Additional solver options
         Group 8. Terms & Devices
       NEWRH1=T;   NEWENL=T
         Group 9. Properties
        RHO1    = 1.0;     ENUL    = GRND10
         Group 11.Initialise Var/Porosity Fields
       FIINIT(P1)=0.0; FIINIT(U1)=0.0
       FIINIT(V1)=0.0; FIINIT(W1)=0.0
        Group 13. Boundary & Special Sources
           After the geometry has been successfully adapted REST
           should be True to avoid repeating the geometry adaptation

PATCH(QSOLID, INIVAL, 1, NX, 1, NY, 1, NZ, 1, 1) 

PATCH(INLET, SOUTH, 1, NX, 1, 1, 1, NZ, 1, 1) 
COVAL(INLET, V1, 0.0, 1.0) 
PATCH(OUTLT1, LOW, 1, NX, 1, NY, 1, 1, 1, 1) 
PATCH(OUTLT2, HIGH, 1, NX, 1, NY, NZ, NZ, 1, 1) 
*** Group 15. Terminate Sweeps
LSWEEP = 500; SELREF = F; RESFAC = 1.000E-03
*** Group 16. Terminate Iterations 
ENDIT (P1 ) = 1.000E-03 ;ENDIT (U1 ) = 1.000E-03 
ENDIT (V1 ) = 1.000E-03 ;ENDIT(W1 ) = 1.000E-03 
*** Group 19. EARTH Calls To GROUND Station NAMGRD=ASAP
*** Group 20. Preliminary Printout 
*** Group 22.
Monitor Print-Out 
TSTSWP = -1 
// Declaration variables for used in this geometry data file constant 
Hight=1.5 Diametr=1.0 Lhalf=1.5 Thick=0.6 
// Coordinate flag is to set a reference origin 
Thick 0.0 
// Property flag only affects the geometry elements below it 
// 111 is steel colour is blue 
Property 111 
// Group is a flag indicating 3 elements grouped to form a 
// geometry in this case and it acts as 

Group T-Junction Thick 0.0 -Lhalf 0.0 1.5 Lhalf Poly-surface 
// Two points to define a
BOX and Box 1 means Blocked, if 2 
// unblocked Box 1 -Thick 0.0 -Lhalf 0.0 1.5 Lhalf 
// 102 for brick colour is red 
Property 102 
// Cylinder 2 is not blocked (2 coordinates define the length 
// of the central line, 0.8 is the diameter, both ends are open 
Cylinder 2 0.0 0.0 0.0 0.0 1.0 0.0 0.8 1 1 
Cylinder 2 0.0 1.0 -1.6 0.0 1.0 1.6 Diametr 1 1 

---------End of Appendix-2 ------------