Encyclopaedia Index

The CHAM LOGO

PHOENICS Overview

CHAM Technical Report: TR 001

Contents
  1. What PHOENICS is
  2. How PHOENICS differs from other CFD packages
  3. The components of PHOENICS
  4. Modes of operation
  5. Getting started
  6. Physical and mathematical content of PHOENICS
  7. Special-purpose versions of PHOENICS
  8. Sources of further information

click here to skip extended Contents list.

Extended Contents

  1. What PHOENICS is
  2. How PHOENICS differs from other CFD packages
  3. The components of PHOENICS
    1. The main modules
    2. The inter-communication files
    3. Auxiliary modules
    4. Additional files
    5. The options
  4. Modes of operation
    1. Distinguishing the modes
    2. Command
    3. Q1-editing
    4. Text-interactive
    5. Menu-interactive
    6. PLANT-using
    7. Own-Fortran-using
    8. Input from CAD
    9. Input from grid-generation packages
    10. Output to graphics-display packages
  5. Getting started by way of:
    1. the VR-Editor
    2. the command mode
  6. Physical and mathematical content of PHOENICS
    1. Conventional features
      Less-conventional features: physics
    2. Multi-phase flows
    3. Turbulence
    4. Radiation
    5. Chemical reaction
      Less-conventional features: mathematics
    6. "Parabolic, Hyperbolic Or Elliptic"
    7. Body-fitting
    8. Fine-grid embedding
    9. Parallel processing
  7. Special-purpose versions of PHOENICS
    1. Introduction
    2. Chemical-vapour-deposition reactors
    3. Electrolytic smelters
    4. Heat, air and smoke flow in buildings
    5. Cooling of electronics
  8. Sources of further information

1. What PHOENICS is

2. Distinguishing PHOENICS from other CFD and solid-stress codes

Since there now exist many commercial software packages which perform some of the functions as PHOENICS, newcomers may welcome the following indications of the respects in which PHOENICS is different, and in many cases unique. The topics discussed are:

  1. Relational Data Input
  2. Multiply-shared space: MUSES
  3. The automatic new-FORTRAN writer: PLANT
  4. Input of data via formulae: In-Form
  5. Input of data via the Virtual-Reality Editor
  6. PARSOL; fitting curved surfaces into cartesian grids
  7. MOFOR: moving objects through cartesian grids
  8. The parabolic option
  9. Fine-grid embedding
  10. Wall-distance and -gap calculation
  11. Radiative heat transfer
  12. Turbulence; the LVEL model
  13. Turbulence; the MFM model
  14. How many phases
  15. Chemical reaction
  16. The Input-File library

2.1 Relational Data Input

Whereas other packages, and PHOENICS itself until 2007, allow the setting up of single-instance flow-simulation scenarios, the user of the new PHOENICS can set up classes of scenarios, of which sub-sets are selected by way of user-chosen parameters.

These, which are designed for particular classes of would-be flow simulators, are designed to provide their users with just what they need and no more, thereby enabling persons without specific CFD expertise to benefit from CFD.

2.2 Multiply-Shared space

Unique to PHOENICS is the MUSES (Multiply-SharEd Space), technique which allows many fluids to flow within the same space, as for example in the heat exchanger shown below, in which the solid stresses may also be computed simultaneously.

figure

The input file is library Case z604. Click here in order to inspect it.

MUSES has been employed for the construction of the PHOENICS-special-purpose version, SAFIR, for blast- and other shaft furnaces.

2.3 User-supplied coding

Whereas many codes now enable users to supply their own sub-routines (a facility pioneered by PHOENICS in 1981), only PHOENICS has an automatic new-Fortran-writing facility (i.e. PLANT) which makes it unnecessary for the user even to understand Fortran.

2008 update

It should be remarked that, although PLANT is still available; and is much used by its devotees, it has been greatly surpassed by its successor, In-Form, the use of which CHAM recommends.

The following example shows a small fraction of the PLANT-generated Fortran coding for the just-mentioned heat-exchanger simulation.


C      Property name: PRPT05
      IF(ISTEP.GE.1       .AND.ISTEP.LE.LSTEP   ) THEN
       IF(IZ.GE.1       .AND.IZ.LE.NZ      ) THEN
       LFMARK=L0F(INAME('MARK'))
       LFVISL =L0F(AUX(VISL  ))
       LFU1  =L0F(U1    )
       LFV1  =L0F(V1    )
       LFWDIS=L0F(INAME('WDIS  '))
       DO 90605 IX=IXF     ,IXL
        IADD=NY*(IX-1)
       DO 90605 IY=IYF     ,IYL
        I=IY+IADD
       L0VISL=LFVISL+I
       L0MARK=LFMARK+I
        INMARK=NINT(F(L0MARK))
         IF(INMARK.EQ.1  ) THEN
       L0U1  =LFU1  +I
       L0V1  =LFV1  +I
       L0WDIS=LFWDIS+I
       F(L0VISL  )=1.*SQRT(F(L0U1)**2+F(L0V1)**2)*F(L0WDIS)
         ENDIF
 90605  CONTINUE
       ENDIF
      ENDIF

2.4 Input of data via formulae

Also unique to PHOENICS is the In-Form facility, which is even more powerful than PLANT, yet requires no new coding at all.

Here for example is what the user enters into the input-data file when he or she wishes to set linearised momentum sources which depend on: 


PATCH(I,CELL,1,NX,1,NY,1,NZ,1,LSTEP)
(SOURCE of U1 at I is 1.E5*(VEL*(YIC-YG)-U1) with IMAT>=90!LINE)
(SOURCE of V1 at I is 1.E5*(VEL*(XG-XIC)-V1) with IMAT>=90!LINE)
The formulae following the "is" can have almost unlimited complexity.

'with IMAT>=90' means: 'for materials having identifying indices greater than or equal to 90'.

'!LINE' means: 'linearise the source so as to accelerate convergence'.

An extensive power-point description of In-Form can be seen by clicking here.

2.5 Input of data via the Virtual-Reality Editor

The Graphical User Interface of PHOENICS facilitates the import of objects from:

Once imported, the objects can be moved, stretched, rotated, duplicated, grouped, given, attributes, hidden, deleted, etc. By default, after the objects have been placed in the desired positions, the grid adjusts itself to fit them optimally.

2.6 PARSOL: fitting curved surfaces into cartesian grids

Of course, if bodies with curved surfaces are to be fitted into cartesian or polar grids, something special must be done to the equations for the obliquely-cut cells in order to procure smooth flow around the object.

This 'something special' is PARSOL, which does away with the 'staircase-like' appearance and behaviour sometimes exhibited by other codes.

An example of flow though an array of louvres is shown here:

velocity contours.

Are the results from cartesian grids with PARSOL as accurate as those from body-fitted grids?

The following simulations of laminar flow around an airfoil suggest that they are:

2.7 MOFOR: moving objects through cartesian grids

Another capability of PHOENICS is its ability to simulate the influence on the flow of the motion of single, many, or articulated bodies through fluids.

Examples are:

Such simulations are very difficult, and perhaps impossible, for computer codes which try to make the grid move with the object.

2.8 The parabolic option

Whereas all of the competing codes are constrained to use full three-dimensional grids and storage for all (3D) simulations, the unique parabolic option of PHOENICS enables many practically important flows (eg in pipes, smoke plumes, and boundary layers on aircraft wings) to be handled much more economically, and therefore accurately.

The following simulation of smoke movement in a long tunnel, with a million-node grid, for example, was performed in this way, long ago, on a 386 lap-top computer.

figure

It was recently used for the simulation of the plume of oil-polluted water rising above the wrecked PRESTIGE oil tanker on the floor of the Atlantic.

2.9 Fine-grid embedding

Although PHOENICS has a fully-unstructured-grid capability, local grid refinement is possible when a structured grid is in use, by way of "fine-grid embedding",.

The following picture illustrates the use of this feature for simulating the flow around an automobile displayed in the Virtual-Reality interface (also a unique feature of PHOENICS):

figure

2.10 Wall-distance and -gap calculation

The influence of solid walls on the flowing fluids which they surround is of such importance that flow-simulation codes need to be able to calculate, for each point within the fluid;

For example, if flow between parallel plates is in question, and the Nikuradze formula for effective viscosity is to be used, the former is the distance from the nearer wall, and the second is the distance of one plate from the other.

Other turbulence models, e.g. Lam-Bremhorst, require at least the first of these; and the IMMERSOL radiation model requires the second.

PHOENICS possesses a unique (unless recently copied) method for calculating the two quantities in an economical manner; it involves solution of the LTLS equation.

2.11 Radiative heat transfer

Thermal radiation is so important a mode of heat transfer that most codes have some means of simulating it. Only PHOENICS however possesses the economical and realistic IMMERSOL model, which calculates the radiative transfer between arbitrarily-shaped solids immersed in fluids which may or may not themselves emit and absorb radiation.

This, like the LVEL model described below, makes use of the also-unique LTLS method of calculating distances from and between walls.

Below is a contour plot of the vertical-direction radiation flux, computed by way of IMMERSOL, for the same case as was mentioned above in respect of solid stress.

2.12 Turbulence: the LVEL model

Whereas some codes are confined to a single turbulence model, PHOENICS has a very large number, including several which are unique.

The already-mentioned LVEL model is one; and it is perhaps the only model which provides a satisfactory compromise between physical realism and computational economy for flows in spaces 'cluttered' with solid objects, when the Reynolds number is not abnormally high.

2.13 Turbulence: the MFM model

Another of the unique-to-PHOENICS, the "multi-fluid model" may prove to be of most long-term importance; for it allows the hitherto-intractable turbulence-chemistry-interaction problem to be resolved economically for the first time.

It computes "probability-density functions" (PDFs) such as that reproduced on the left-hand side of the diagram below.

figure

All competitive codes, it appears, used the "presumed-PDF" method. In other words, they make guesses rather than calculations.

2.14 How many phases

Whereas some codes are confined to single-phase flows (eg air or water alone, but not a mixture of the two), PHOENICS can handle multi-phase flow as well, as indicated by the following example:

figure

2.15 Chemical reaction

Whereas some codes are confined to chemically-inert flows, PHOENICS can handle those which react chemically as well, as is shown by the following simulation of an oil-platform-explosion:

figure

2.16 The input-file library

Because PHOENICS has been in continuous use for more than 20 years, tens of thousands (more probably millions) of calculations have been performed with its aid.

The data-input files corresponding to a tiny fraction (but still several thousand) of these have been included with each delivered PHOENICS package, in the form of an input-file library.

One of the methods which can be adopted by users faced with a new simulation problem is therefore to search through the library for files which solve problems akin to their own, one of which can be adopted as the starting point for the new study.

Concluding remarks

The above list of unique or especially strong features of PHOENICS is far from being exhaustive. Some others will be mentioned in the present document. Others are described in the PHOENICS on-line-information system, POLIS.

3. The components of PHOENICS

3.1 The main modules, for input, data-processing and output

PHOENICS performs three main functions:
  1. problem definition (i.e. pre-processing), in which the user prescribes the situation to be simulated and the questions which are to be answered;

  2. simulation (i.e. data-processing), by means of computation, of what the laws of science imply in the prescribed circumstances;

  3. presentation (i.e. post-processing) of the results of the computation, by way of graphical displays, tables of numbers, and other means.

PHOENICS therefore, like many but not all CFD codes, has a distinct software module, or set of modules, for each of the above three functions.

This sub-division allows functions (1) and (3), say, to be performed on the user's home computer, while the power-hungry function (2) is carried out remotely.

The three (sets of ) modules of PHOENICS are called:-

  1. SATELLITE (which incorporates also the Virtual-Reality Editor and Viewer)
  2. EARTH (the solver module); and,
  3. PHOTON (which incorporates the graph-plotter, AUTO-PLOT).

Their interrelationships are shown below, albeit with the VR-Viewer displayed on the post-processing side, even though it is part of the SATELLITE module.

figure

3.2 The inter-communication files

The four names in white rectangular boxes in the above diagram refer to files which are used for communication between modules, as follows:

It is the Q1 file with which the user has most to do, whether it is:

  1. taken from the extensive Input-File library which forms part of the PHOENICS installation; or
  2. created by way of a text editor, perhaps as a modification of a library file; or
  3. created as part of an interactive SATELLITE session in which the user enters PIL statements at the keyboard, and is assisted to do so correctly by acceptance and non-acceptance responses; or
  4. created without the user's needing knowledge of PIL, by way of the VR-Editor, with its associated menu system.

However it is written, the content of the Q1 file is what dictates how the flow-simulating calculation will proceed.

3.3 Auxiliary modules

SATELLITE, EARTH and PHOTON can be run by issuing the appropriate commands (sat, ear or pho at the command line of Windows or Unix, or by double-clicking on the appropriate line of the Windows desktop.
CHAM has however also provided, for the convenience of users, other means of activating the programs, either individually or in sequence.

It is in fact an enhanced SATELLITE module working in VR-Editor mode.

There are other modules which, in this overview document, it is appropriate to mention only in passing. They are:

3.4 Additional files

Other files of importance, in alphabetical order,include:

  1. CHAM.INI, into which users can insert decisions about modes of operation which they wish only seldom to modify;
  2. CONFIG, which contains the crucial 'unlocking string';
  3. FACETDAT, which is created by SATELLITE, and which contains the geometrical information about the those objects which are described by way of facets;
  4. GROUND.HTM, a Fortran file which is accessible to users, and contains slots for the introduction of the user's own coding sequences;
  5. PHOLOG, which records the key-strokes made during a PHOTON session, in case they need to be repeated;
  6. PBCL.DAT, which is created by EARTH and which is used for recording information, useful for displaying results, about partially-blocked cells,
  7. Q1EAR, which is created at the end of a SATELLITE run and which records, in standardised format, all the implications of the Q1 file for a particular run.
  8. Q2, which, being read by SATELLITE after Q1 and, if it takes place, the interactive session, can contain the user's after-thoughts;
  9. U, from which PHOTON can read display-eliciting commands;
  10. XYZ, which contains the co-ordinates of all cell corners of a 'body-fitted-coordinate' grid.
  11. direct-access forms of the sequential files PHI and XYZ, namely PHIDA and XYZDA.

Information about some of these will be supplied later in this document; and all of them are described in the PHOENICS Encyclopaedia.

3.5 The options

For reasons which are now mainly historical, the coding and the input-file libraries of the EARTH (i.e. solver) module of PHOENICS are arranged in segments called "options".

Newcomers to PHOENICS are bound to encounter some mention of the options, and may suppose their existence to be more important than it is. Therefore the following account is provided.

The original purpose of options was to enable purchasers of PHOENICS licences to reduce their expenditure by taking the "core"; but none, or few, of the options.
Nowadays all options are supplied always.
The names of the options are:

  1. advanced-multiphase
  2. body-fitted-coordinate
  3. advanced-chemistry
  4. GENTRA (particle tracking)
  5. multi-block and fine-grid-embedding
  6. multi-fluid
  7. advanced-algorithms
  8. PLANT fortranizer
  9. advanced-radiation
  10. simultaneous-solid-stress
  11. advanced-turbulence
  12. two-phase
wherein the word 'advanced' is used when the core already includes some capabilities of the kind indicated.
Correspondingly:
As far as the coding is concerned, these names do indicate where the relevant Fortran files are to be found.
However the correspondence between the option names and the contents of the input files is much less direct, for the simple reason that practically-interesting flow simulations often involve several "optional" features, for example two-phase flow and combustion and body-fitted coordinates.

4. Modes of operation

4.1 Distinguishing the modes

PHOENICS modules can be operated in various manners, the choice of which depends on the user's personal preference, experience, and current needs and circumstances.

The following remarks, which are intended to facilitate the proper choice for the problem in hand, are organised under the headings:

  1. command
  2. Q1-editing
  3. text-interactive
  4. menu-interactive
  5. PLANT-using
  6. own-Fortran-using
  7. input from CAD
  8. input from grid-generation packages
  9. output to third-party graphics packages
  10. mixed

4.2 The command mode

By command mode is meant the entering of commands at the DOS or UNIX prompt by way of the keyboard, no other response being expected but that of execution.

The command mode is appropriate for what might be called "production runs", i.e. those flow-simulating calculations for which:

This mode is preferred by users who, perhaps having spent some day-time hours preparing a series of Q1s, wish to have the runs executed overnight, possibly by way of the PHOENICS "multi-run" facility.

CHAM's quality-control procedures, for example, entail the performance of many hundreds of such "test-battery runs" each night, followed by comparison of the results with those which are expected, so as to detect whether any change made to the software has had an inadvertent consequence.

However, newcomers to PHOENICS may also wish to use the command mode at the start, confining themselves to executing ready-to-run cases, or 'active demos' via the Environment.

The commands supplied with the PHOENICS installation are described in the scripts entry of the PHOENICS Encyclopaedia; but the user is of course free to embody these into others which he or she prefers.

4.3 The Q1-editing mode

What happens in a flow-simulating calculation made by PHOENICS is, as has been already stated, entirely controlled by the contents of the Q1 file, expressed via the PHOENICS Input Language, PIL.

Many users, especially those having months or years of experience, therefore prefer to take full control of the calculation by writing the Q1 for themselves.

However, even new or infrequent users, who are likely to prefer one of the interactive modes of operation, may like to know that these modes are there only to make Q1-writing easy.

The merits of the Q1-editing mode of operation are:

  1. speed, especially if the required Q1 can be created by making minor changes to one which has been used successfully before, for example one of the many hundreds in the PHOENICS Input-File libraries supplied with the installation;

  2. certainty that no well-meant but inappropriate settings made by the writers of the menus can have over-written what the user intended;

  3. freedom for the user to employ his or her personal style and to include helpful annotations;

  4. the ability to exploit the numerous features of PIL which cannot be introduced interactively; for example:
    1. DO loops
    2. IF ..... THEN .... ELSE constructs
    3. file-handling statements such as INCL and INTRPT
    4. DISPLAY ....ENDDIS
    5. PHOTON USE ...ENDUSE
    6. GOTO .... LABEL
    7. READVDU
    8. MESG(
    9. The wide range of commands which are associated with In-Form, the powerful new Input-of-FORMula feature.
    and many others.

The disadvantage, of course, is that knowledge of PIL is needed; and this can be only gradually acquired.

However, those who intend to become serious long-term users of PHOENICS, and to exploit more than the most superficial of its flow-simulating capabilities, should recognise that they may need to master at least the rudiments of PIL; for the VR Editor can not do everything for them.

Full information about PIL can be found in the PHOENICS Encyclopaedia.

There also exist some PIL tutorials.

It may be remarked that the Q1-editing mode can also control the subsequent running of PHOTON; for this is so programmed that, if there exists in the local directory a file called "u" or "U", it will take instructions from it.

Then, if that file contains simply the line: "USE Q1", PHOTON will look in the Q1 file for, and obey, instructions between the lines:
PHOTON USE
and
ENDUSE.

Many input-library Q1s contain such PHOTON-instruction sequences.

The VR-Viewer can also use such Q1 files as macros to display a similar sequence of images.

4.4 The text-interactive mode

The PHOENICS SATELLITE module can be caused to run in such a mode that, once the existing Q1 has been interpreted, the program awaits the entry of further PIL statements by way of the keyboard.

The relevant commands are txt.

The new statements, if they contain no errors, are then accepted as augmenting or replacing the existing statements; and they are added to the end of the Q1 file.

If the new statements infringe the rules of PIL in some way, they are rejected; then an explanation of the reason for rejection appears on the screen.

The text-mode SATELLITE also permits the introduction, modification or deletion of lines which are not immediately interpreted; for it has its own built-in Q1-editor.

[Therefore what has been said above about the inability of the interactive mode to introduce DO loops and other features is somewhat too strong; for they can be introduced via the built-in editor, in text-interactive mode.

However most users nowadays prefer to use a stand-alone text editor for creating all but the simplest Q1s.]

It should be remarked that PHOTON can also be run in text-interactive mode, which is indeed the default. Commands typed at the keyboard, so long as they are among those recognised by PHOTON, are responded to immediately.

A list of such commands is provided by the PHOTON HELP file.

PHOTON also has the facility to record the user's actions in a pholog file, which can be later hand-edited and re-named as a u macro. Similarly, the VR-Viewer can save a macro file which can then be used to re-create the same image from another data set.

These facilities are valuable because of their person-time-saving potential. Interacting with a graphical-display package is often enjoyable; but, since humans cost more than computers, it can be the most expensive part of a CFD-using operation.

4.5 The menu-interactive mode

The second method of interactive problem specification is via the SATELLITE menu, which is usually, but not necessarily, associated with the use of the VR-Editor; the latter represents visually what the already-accepted data are.

This mode can be entered:

The advantage of using this mode is that some settings are made by simple mouse-clicks, and others by typing numbers into boxes; so it can be used by those who have no knowledge of the nature or meaning of PIL variables or the syntax of the statements which set their values.

The disadvantage is, as already mentioned, that only a sub-set of the desirable PIL settings can be made in this way; and moreover:

The use of this mode of problem specification is described in TR 324, for beginners and in TR 326, for more advanced users.

PHOTON also can be operated in menu mode, as well as text mode. This is convenient for users who do not remember, or have never learned, what are the commands which PHOTON otherwise needs.

The VR-Viewer, which is the alternative results-display module, and which has the merit of giving the flow domain an appearance which is wholly compatible with that presented by the VR-Editor, can be operated in menu mode, or it can read commands from a macro file.

4.6 The PLANT-using mode

For those users (a diminishing proportion, it may be remarked) who find the already-described methods of problem-specification insufficient, the next recourse is to introduce PLANT formulae into the Q1 files, and so allow the SATELLITE to:

Thereafter the file is compiled, the new EARTH executable built, and the run executed, without further user intervention. The PLANT lines can be introduced into the Q1 file in either of two ways, namely:

  1. direct editing, which requires some acquaintance with PLANT-formula terminology and syntax, and
  2. interaction with the PLANT-menu utility, which does not.

4.7 The own-Fortran-using mode

There do exist PHOENICS users who would rather introduce their own Fortran coding than find out whether, or how, what they want can be provided by PLANT.

Such users need to learn how GROUND coding interacts with EARTH; but this is not difficult, because the extensive open-source components of PHOENICS provide many examples which users can follow.

Further, PHOENICS is equipped with numerous 'service' subroutines, calls to which can be incorporated into the user's coding.

The relevant entry in the PHOENICS Encyclopaedia provides further explanations and examples.

4.8 Input from CAD

Very often, CFD analysis is required for a situation which has been already defined geometrically by way of a Computer-Aided-Drawing (CAD) package.

The definition is then usually expressed by way of one or more STL or DXF files, which it is necessary to import into PHOENICS.

This task is made extremely easy for the user, because The PHOENICS SATELLITE is itself able to read STL and DXF files, and to convert them into the format which it employs for display in its Virtual-Reality Editor and Viewer.

The details of how this is done are explained in the PHOENICS-VR Reference Guide, TR 326.

Below is shown an example of residential buildings displayed in the VR-Editor. The CAD file was created by way of the well-known AUTOCAD package. This CAD file in STL format was polished by PHOENICS, and then imported into PHOENICS-VR in a few seconds, rotated, and somewhat re-sized.

figure

4.9 Input from grid-generation packages

The PHOENICS SATELLITE has its own several ways of creating body-fitted-coordinate grids; and such grids can be created also via PLANT or by means of user-created Fortran coding attached to EARTH.

However some users prefer to use a third-party grid-generation package .

4.10 Output to graphics-display packages

Typical of the third-party graphics packages with which PHOENICS can interact is TECPLOT,

The following picture shows streamlines in a duct into which flow two streams from transverse ducts. The computational grid was created with the aid of GeoGrid; PHOENICS was used in multi-block mode; and the graphics display was prepared by means of TECPLOT.

figure

4.11 The mixed mode

There is no "mixed mode" as such. This section is therefore provided simply as a place for stating that experienced users of PHOENICS rarely use one mode only; and that they are certainly not forced to do so by PHOENICS.

Indeed, users of PHOENICS are more likely to complain about the over-large range of different ways which PHOENICS offers for doing essentially the same thing.

It is for this reason that section 4 of the document has been provided.

5. Getting started

By way of:

  1. the VR-Editor
  2. the command mode

Preliminary note

After installation of PHOENICS, four icons should be present on the desk-top, entitled:
  1. PHOENICS-VR
  2. PHOENICS Command Prompt
  3. POLIS
The first two correspond to the next two sub-section of this document; the third leads to the main on-line information source about PHOENICS, of which the Encyclopaedia is the most-often used.

5.1 Getting started via the VR-Editor

Proceed by studying the document TR 324, "Starting with PHOENICS-VR", which is accessible by way of the POLIS button and the 'documentation' and 'hard-copy documentation' links to which it leads.

Those proceeding by this route are advised either to follow the instructions printed in the hard-copy version of the document, if they have one, or to do so by keeping its electronic copy open in a separate window.

A warning should be expressed at this juncture: despite the many things that the VR-Editor can do, it cannot unleash the full potential of PHOENICS.

Since newcomers to PHOENICS often have the desire to embark immediately on some very ambitious flow-simulation tasks, they are sometimes disappointed to discover that these cannot be launched from the VR-Editor.

They will then need to dig a little deeper into the documentation, helped if they so request by CHAM's user-support team, in order to learn how the PHOENICS Input Language, and especially its In-Form and PLANT features, will enable them to achieve their objectives.

They can however rest assured that there are few known flow-simulation problems which PHOENICS can not solve.

5.2 Getting started via the command mode

Those users who prefer always to be in complete control of what they are doing may prefer to start at the command prompt, and issue simple commands only, until their confidence has grown sufficiently to allow more complex ones.

The DOS command prompt can be brought to the screen by double-clicking the 'windf' icon, the name of which stands (rather inappropriately) for Windows Digital Fortran.

The working directory should then be found to be:
\phoenics\d_priv1.

Users whose practice it is to employ such auxiliary programs as The Norton Commander, or FAR, may find it convenient to activate one of them at this point. But this is not essential.

If the installation has been fully successful, the 'path' associated with the Window should include:
\phoenics\d_utils and
\phoenics\d_utils\d_windf

However, if it does not, the full-path-name alternatives to the commands mentioned below should be employed.

(a) A do-nothing run

In order to start the VR Editor in command mode, the command to issue is: modq1, which places a 'model' Q1 file in the local directory.

The DOS DIR command will reveal whether it is present. [If it is not, try typing the full path-name of the command which is:
\phoenics\d_utils\modq1 ]

The command edit q1 will show the content of this file, exhibiting the standardised data-group structure of PHOENICS, but making no non-default data settings whatsoever.

A suitable command to issue next is txt [full path-name: \phoenics\d_utils\d_windf\txt], which activates the SATELLITE module in text-interactive mode. The resulting screen image is as follows:

figure

This gives the user an opportunity to enter data; but, if the opportunity is not taken, and the session is immediately terminated, it will be found that:

If then the command ear is issued, the solver module, EARTH, will run; but it will terminate very quickly, producing a RESULT file of which the small content indicates that no simulation has actually been performed.

(b) Exploring the text-interactive SATELLITE

If the process is repeated, but this time the opportunity to insert data interactively is taken, the methodical explorer will probably proceed in small steps, for example as follows:-

This is not the place for a comprehensive presentation of the PHOENICS Input Language, PIL. However, enough has perhaps been written to indicate its general character, and the way in which the PHOENICS SATELLITE responds to it.

(c) Exploring the menu-interactive SATELLITE

If the command m2 is entered at the command prompt, the SATELLITE is activated in "menu-2" mode.

What then appears on the screen is as shown below. It is the top panel of the menu which is associated with, but is distinct from, the VR editor.

figure

The exploration-minded user will wish to click on the buttons at the top of the panel so as to access deeper levels, at which settings can be made by mouse clicks or the typing in of numbers.

Then, having returned to click on OK, he or she will quit the program, and thereafter examine the Q1 and Q1EAR files which have been created.

It will be observed from the above image that this menu does allow a library case to be loaded, if its number is known. Then the settings made by it are displayed in the appropriate boxes of the menu, and can be altered by the user.

ear thereafter launches an EARTH run as before.

Then pho launches a PHOTON run; and vrv activates the VR-Viewer.

6. Physical and mathematical content of PHOENICS

6.1 Conventional features

PHOENICS has all the features which are common to commercial CFD codes; indeed it pioneered them. Since the present document is an overview rather than a text-book, it has been judged sufficient here simply to list the conventional features, under two headings, namely:

  1. physical, and
  2. mathematical.

Thereafter some of the less conventional features of PHOENICS will be given more attention.

(a) Physical

(b) Mathematical

Click here for a more extended treatment.

6.2 Simulation of multi-phase flow in PHOENICS

"Multi-phase flows" are those involving, to name but a few examples:-

PHOENICS was the first general-purpose computer code to be able to simulate multi-phase flows; and it is still capable of doing so more effectively, and in a greater variety of ways, than most of its competitors.

Multi-phase-flow phenomena can be simulated by PHOENICS in four distinct ways. These are:

  1. as two inter-penetrating continua, each having at every point in the space-time domain under consideration, its own:
    velocity components, temperature, composition, density, viscosity, volume fraction, etc;
  2. as multiple inter-penetrating continua having the same range of properties;
  3. as two non-interpenetrating continua, separated by a free surface;
    (If on-line click here to see an example) or
  4. as a particulate phase for which the particle trajectories are computed as they move through a continuous fluid.

Details of how PHOENICS performs its simulations can be discovered by on-line viewers by clicking on the above links to the PHOENICS Encyclopaedia.

6.3 Turbulence models in PHOENICS

Why turbulence models are used

The flows which PHOENICS is called upon to simulate are, more often than not, turbulent, by which is meant that they exhibit near-random fluctuations, the time-scale of which is very small compared with the time-scale of the mean-flow, and of which the distance scale is small compared with the dimensions of the domain under study.

Since the beginning of the practice of computational fluid dynamics, in the 1960's, the impracticability (or, more precisely, the prohibitive expense) of predicting these fluctuations has resulted in the invention of "turbulence models" which represent, to some extent, their results.

The subject is too large to deal with in this Overview; but the lectures and other documentation provided with the PHOENICS package contain much information. Typical is the lecture entitled Turbulence models for CFD in the 21st Century.

Satisfactoriness

A broad-brush summary of the satisfactoriness of the most-widely-used turbulence models is:

Turbulence models in PHOENICS

PHOENICS is particularly rich in turbulence models, as can be seen from the relevant Encyclopaedia Entry.

Two of these are of special interest, because they are unique to PHOENICS, namely:

  1. The LVEL model is most useful in circumstances in which many solids are immersed in the fluid, making conventional "two-equation" models impractical.

    It handles the complete range of Reynolds number smoothly; and it contains its own unique and simple method for calculating the distances to and between walls. If on-line click here to see an example

  2. The "Multi-Fluid Model" (MFM) possesses more radical novelty; for it provides a direct means of computing the quantities of practical importance, so supplanting the conventional indirect means.

    MFM is especially useful for simulating turbulent-combustion processes, about which several lectures are supplied with the PHOENICS package, for example this, and this.

6.4 Radiative-heat-transfer models in PHOENICS

PHOENICS is supplied with several means of computing thermal radiation, all of which are described in the PHOENICS Encyclopaedia Entry

A method which is unique to PHOENICS, and is especially convenient when radiating surfaces are so numerous, and variously arranged, that the use of the view-factor-type model is impractically expensive, is IMMERSOL. If on-line click here to see an example

This method is:

examples of its use may be seen by clicking here.

IMMERSOL is particularly useful for electronics-cooling problems, and is an important feature of HOTBOX.

6.5 Chemical-reaction processes in PHOENICS

From its beginning in 1981, PHOENICS has been used for simulating processes involving chemical-reaction processes, and especially those involving combustion.

It continues to be heavily used for these purposes, both by CHAM and others, e.g. ESA.

PHOENICS can handle the combustion of gaseous, liquid (e.g. oil-spray) and solid (eg pulverized-coal) fuels.

Chemical reactions are simulated by PHOENICS in several ways, including:

6.6 "Parabolic, Hyperbolic Or Elliptic"

  1. The above words appear in the expansion of the acronym, PHOENICS; and for good reasons, having practical significance.

  2. "Parabolic" flows are those, such as steady jets, boundary layers and wakes, from which reverse flow is absent. If the Reynolds number is not too low, all influences flow from upstream to downstream; so the calculation can proceed in the same way. If on-line click here to see an example

  3. PHOENICS, perhaps still alone among the general-purpose computer codes, exploits this opportunity; the result is a great reduction in computer time and memory requirements. In effect, two-dimensional storage suffices for a three-dimensional problem.

    For further information, including graphical displays, click here if on-line c.

  4. Where the velocity is subsonic, use of the parabolic option involves neglect (usually justifiable) of the cross-stream pressure variations. However, where the velocity is supersonic, this is no longer necessary. If on-line click here to see an example

    PHOENICS can handle these so-called "hyperbolic" flows with the same economy as the parabolic ones. Some examples may be seen by, clicking here.

  5. Flows which are neither parabolic nor hyperbolic, i.e. all the others, are called "elliptic"; for them, allowance has to be made for influences to travel in all directions; so three-dimensional storage must be used.

    Since this is expensive, it should be used only when necessary. PHOENICS, uniquely, enables the user to make the choice.

6.7 Body-fitting in PHOENICS

  1. PHOENICS can use any one of three types of coordinate system for describing the space in which it performs its computations, namely:

  2. PHOENICS was the first general-purpose CFD code to be enabled to compute flows around such bodies by using "body-fitted-coordinate (i.e. BFC) grids"; and it still possesses perhaps the widest range of means of doing so.

  3. PHOENICS possesses its own built-in means of generating such grids; but it can also accept grids created by specialist packages.

  4. Not all CFD codes have a BFC capability; and of those which do not, some employ other means of permitting flows around arbitrarily-curved surfaces to be accurately computed. PHOENICS too has such a capability, called PARSOL.

  5. PARSOL allows flows around curved bodies to be computed on cartesian grids; and the solutions are often just as accurate as those computed on body-fitted grids. The following figure exemplifies the use of PARSOL for "body-fitting" rather literally:

    figure


  6. The user of PHOENICS therefore can choose for him or her self which method to use, according to requirements for accuracy, personal preference and limitations of time.

6.8 Fine-grid embedding

  1. The first embodiment in PHOENICS of fine-grid embedding (FGEM) was made in connexion with the CCM (collocated covariant method), which employed body-fitted coordinates.

  2. Subsequently, the FGEM method was generalised so that it could work with any coordinate system, of which the cartesian grid, being most commonly used, and computationally efficient, is perhaps the most important. If on-line click here to see an example The creation of fine-grid regions is particularly easy now that it can be effected by way of the virtual-reality interface.

  3. The use of FGEM for the calculation of flow around an automobile is illustrated here.

  4. Especially when combined with the PARSOL (ie partial-solid) technique, it makes the use of body-fitted coordinates less-often needed, as the following, which shows an application to a three-part airfoil, powerfully suggests:
    figure

6.9 Parallel PHOENICS

  1. The architecture of PHOENICS has proved to be especially well-suited to parallelisation, because of the "slab-wise" arrangement of its data-structure. This was adopted in the 1980s, as a means of economising computer memory, which was necessary at the time.

  2. Although that need has disappeared, the slab-wise arrangement made "domain-decomposition", the parallelization strategy chosen by CHAM, especially easy to implement.

  3. Its most usual implementation involves "z-direction splitting", in which the whole three-dimensional grid is broken into as many sub-grids as there are processors available for use; however splitting in other directions is also allowed.

  4. Transfer of information from one sub-grid to its neighbours is carried out within the innermost iteration loops of the solution algorithm.

  5. To ensure the efficiency of this transfer, a conjugate-gradient solver is used.

  6. Information on performance can be obtained by clicking here if on-line.

7. Special-purpose versions of PHOENICS

7.1 Introduction

8. Sources of further information

References have been made at many points in this overview to sources of further information. Here therefore it should suffice to make only a few summarising remarks, as follows:

End of TR 001