click here to skip extended Contents list.
Less-conventional features: physics
Less-conventional features: mathematics
Parabolic Hyperbolic Or Elliptic Numerical Integration Code Series,
wherein "parabolic", "hyperbolic" and "elliptic" are the descriptors which mathematicians use for the underlying equations.
However, the mention of equations does not imply that PHOENICS is intended for mathematicians.
Since there now exist many commercial software packages which perform some of the same functions as PHOENICS, newcomers may welcome the following indications of the respects in which PHOENICS is different, and in many cases unique.
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.2008 update
The most obvious distinguishing feature is the new relational 'pre-pre-processor', PRELUDE, which has allowed the creation of 'Gateways to PHOENICS'.
The topics discussed are:
2008 update
PLANT is still available; and is much used by its devotees. However, it has been greatly surpassed by its successor, In-Form, the use of which CHAM recommends.
2008 update
The most recent description of this can be seen by clicking
here.
What this means has been explained here.
2008 update
This unique feature has been much improved since its first introduction; and it is now, for many users, the reason for their preferring PHOENICS to other CFD codes; for it eliminates the grid-generation problem.
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.
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
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'.
Once imported, the objects can be moved, stretched, rotated, duplicated, grouped, given, attributes, hidden, deleted, etc.
elementary and advanced documentation is provided by way of POLIS, the PHOENICS information system, of which a valuable component is the PHOENICS Encyclopaedia.
By default, after the objects have been placed in the desired positions, the grid adjusts itself to fit them optimally.
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:
STREAM and X-FOIL (Japanese codes) used body-fitted coordinates for their calculations; but their agreement with the experimental data is certainly no better than that of PHOENICS with a cartesian grid and PARSOL.
Examples are:
Such simulations are very difficult, and perhaps impossible, for computer codes which try to make the grid move with the object.
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.
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.
This is illustrated in the following "multi-physics" example, wherein vectors in the fluid region represent flow velocity, whereas those in the region occupied by solid represent displacement, from which, of course, stress and strain may be deduced.
Recent improvements to the algorithm have made it especially easy to simulate bending deformations.
Information about the improvements is to be found in What's new in PHOENICS 3.5.1 .
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):
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.
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.
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.
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.
All competitive codes, it appears, used the "presumed-PDF" method. In other words, they make guesses rather than calculations.
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.
The PHOENICS Commander, which is the navigation tool recommended by CHAM to new users, therefore offers a library-search facility for precisely this purpose.
The best source of information about it is the lecture which is displayed by clicking here.
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:-
2008 update
The following text and image were provided before PRELUDE and its Gateways were conceived. Nowadays users are presented with richer possibilities, represented by the following picture
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.
It is the Q1 file with which the user has most to do, whether it is:
However it is written, the content of the Q1 file is what dictates how the flow-simulating calculation will proceed.
SATELLITE, EARTH and PHOTON can be run by issuing the appropriate commands (sat, ear or pho at the command line of DOS 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. These are:
The feature which is common to both modules is that they allow PHOENICS actions to be initiated by way of mouse clicks, thus relieving the user from remembering, and then typing, the names of the commands.
Their disadvantage is that they force the user to wait while they are starting up, and of course to navigate to the right decision-making point.
Further comments about them are:
It is the choice of necessity for Unix.
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:
Other files of importance, in alphabetical order,include:
Information about some of these will be supplied later in this document; and all of them are described in the PHOENICS Encyclopaedia.
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, except for MIGAL, which entails an additional charge.
The names of the options are:
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.
The following remarks, which are intended to facilitate the proper choice for the problem in hand, are organised under the headings:
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 Commander or Environment.
The command mode is also appropriate when the COSP constant-optimising procedure is in use; for this involves running the EARTH solver module in perpetuum mobile mode, until the sought-for goal has been attained.
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.
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:
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.
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.
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.
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.
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:
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.
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.
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 .
PHOENICS also is equipped with GENIE, its own Generic Interfacing Environment, which is capable of converting grids created by other packages into PHOENICS-usable format.
GENIE can also convert PHI files produced by PHOENICS into formats usable by third-party graphics 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.
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.
What should then appear on the screen is something like (for refinements are constantly being introduced) this:
The screen messages explain the functions which each button leads to. It is re-printed below.
The buttons along the top edge provide access to the PHOENICS Computational Fluid Dynamics Software Package. Specifically:
The buttons on the left are:
New users are strongly advised to advised to press the new-user button, whereupon they should see a screen like this.
'Quick start' is there for the impatient; 'slower start' for the more cautious, and 'tutorials' for those who are desire even more guidance.
Thereafter, judicious choice of ready-to-run cases will provide an excellent preparation for later work with PHOENICS.
If the just-described Commander route has been fully explored, the PHOENICS Virtual-Reality interface will already have been encountered and exercised.
However, an alternative and more varied approach is to 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.3 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:

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.
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.
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:
Thereafter some of the less conventional features of PHOENICS will be given more attention.
(a) Physical
Since 2006, PHOENICS has had additionally an unstructured option, namely USP (UnStructured PHOENICS). A description is to be found by clicking
here2008 update
"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:
Details of how PHOENICS performs its simulations can be discovered by on-line viewers by clicking on the above links to the PHOENICS Encyclopaedia.
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:
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
MFM is especially useful for simulating turbulent-combustion processes, about which several lectures are supplied with the PHOENICS package, for example this, and this.
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.
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:
The need for simultaneous solid-stress and fluid-flow analysis
It is frequently required to simulate fluid-flow and heat-transfer processes in and around solids which are, partly as a consequence of the flow, subject to thermal and mechanical stresses.
Often, indeed, it is the stresses which are of major concern, while the fluid and heat flows are of only secondary interest.
Engineering examples of fluid/heat/stress interactions include:
It has been customary for two computer codes to be used for the solution of such problems, one for the fluid flow and the other for the stresses
Iterative interaction between the two codes is then employed, often with considerable inconvenience.
PHOENICS, however, makes it possible for fluid flow, heat flow and solid deformation, and the interactions between them, all to be calculated at the same time.
It does so by exploiting the similarity between the equations governing velocity (in fluids) and those governing displacement (in solids).
How this is done
Thus:
ex = [d/dx]* U
ey = [d/dx]* V
ez = [d/dx]* W
sx = {YM / (1 - PR**2)} * {ex + PR*ey} and
tauxy = {YM / (1 - PR**2)} * {0.5 * (1 - PR)*gamxy}
where:
A more complete explanation is contained in a lecture which may be accessed by clicking here, if on-line.
For further information, including graphical displays, click here if on-line c.
PHOENICS can handle these so-called "hyperbolic" flows with the same economy as the parabolic ones. Some examples may be seen by, clicking here.
Since this is expensive, it should be used only when necessary. PHOENICS, uniquely, enables the user to make the choice.
The creation of fine-grid regions is particularly easy now that it can be effected by way of the virtual-reality interface.
The numerical accuracy of a flow simulation increases with the number cells in the grid; but so does the computer time; and, when the geometry of the situation is such that a very large number of cells is needed, the correspondingly large computer-time requirement may become intolerable.
The best way to reduce this requirement is to change the solution method; and, specifically, to use a "multi-grid solver", that is to say one which conducts the solution on grids of differing fineness.
PHOENICS possesses such a solver. Its name is MIGAL; and full details are supplied in the Encyclopaedia article of that name.
The increase of solution speed which MIGAL can provide is illustrated by the following figure:

This figure also shows how the memory requirements and the computer time increase with grid fineness for the well-known "driven-cavity" flow.
Evidently, the MIGAL solver is much faster than "SIMPLEST", which is the name used here for the PHOENICS default solution procedure.
However, it does use more computer storage.
What it is.
COSP is an acronym for "Constant Optimising Software Package". It started its life as a stand-alone package which "drove" PHOENICS; but it is now an integral part of PHOENICS itself.
When operating in COSP mode, PHOENICS solves what are often called "inverse" problems, i.e. those in which the task is to find what input data will lead to flow simulations which accord with some specified criteria.
Examples are:
It might reasonably be said the COSP represents the first step towards answering the designer's real CFD question, which is often not, 'What will the flow be if I choose these inflow conditions?' but rather 'What inflow conditions will give me the flow that I want?'
That being so, the future for COSP appears very bright.
It is true that narrow-sector users require to be separately treated; but that each sector should have a special program devoted to it has proved not to be economically possible; for CHAM, at least.
Nor is there any need; one can use a powerful general-purpose program for solving narrow-sector problems by creating a sector-specific 'Gateway', as has been proved for PHOENICS.
The PRELUDE pre-pre-processor makes these Gateways easy to create and maintain; for each, once the decisions have been made about what the sector-specific user need, is easily written.
"Gateways, yes; special-purpose programs, no" is CHAM's current policy.
The special-purpose PHOENICS program known as ESTER has been in use for simulating the flows in Hall-Cell reactors for many years.
This special-application area of CFD was one of those selected for attention in the EC-funded MICA project, in which one of the collaborating partners was the UK Building Research Establishment.
The lessons learned have been incorporated into the special-purpose version of PHOENICS known as FLAIR, which is widely used by HVAC (i.e. heating, ventilating and air-conditioning) engineers.
CHAM has been assisting electronics engineers with this for more than a decade, its specific offering being the special-purpose code HOTBOX.
This now uses the Virtual-Reality interface in order to facilitate both the setting up of problems and the display of results; and its use of the IMMERSOL radiation model and the LVEL turbulence model enable it to combine physical realism with computational economy.
The PHOENICS special-purpose program which simulates the development and motion of oil spills in rivers is called ROSA; and it has been extensively validated during studies made in the ex-Soviet Union, where oil spills have been prevalent.
It can also be applied to estuaries and coastal waters.
Account is taken of evaporation and dissolution, as well as of the relative motion of the oil slick and the underlying water.
CHAM created a special-purpose program for simulating the processes in such furnaces within the framework of an EC-funded project called OSIRIS. Its name is SAFIR.
This program exploits several unique-to-PHOENICS modelling features; and it is the first to be able to represent properly the four-phase nature of the process.
The TACT special-purpose version of PHOENICS enables the performance of both natural- and assisted-draft cooling towers to be predicted, as influenced by:
Parallel PHOENICS is also available on the following systems:
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:
When first devised, this was a stand-alone information-browsing program.
Now that web-browsers are available to all, the name has been retained for a particular gateway into information supplied by CHAM to the users of PHOENICS; this is now inspected by means of the local browser.
Much of the material is also accessible on CHAM's website.
This continuously growing body of information is intended to provide, in accessible form, all the information that users of PHOENICS are likely to need.
That it fails to attain this near-impossible goal, its creators freely admit; but the fact that it can be easily and instantly up-dated, without the long waits associated with the production of hard-copy documents, is the reason for CHAM's adopting it as a major communication means.
Users who do not find in it what they reasonably expected, are asked to tell CHAM about their needs, in order that gaps can be filled, for the sake of all users.
What is seen by clicking on the POliS Help link is a collection of items which can be accessed from the VR user interface.
Many results of past uses of PHOENICS have been collected together and arranged in a kind of 'museum' called the 'Applications Album'.
Some which are rather old, indeed 'museum-pieces' in another sense, have been allowed to stay in order that visitors can appreciate that CHAM and PHOENICS have been in the CFD business for a long time.
Visitors are asked therefore not to suppose that everything on view represents the current state of the PHOENICS art.
CHAM's practice is to make as much as possible of its descriptive and educational material available to its users.
The above link therefore leads not only to a series of lectures which cover the main topics of PHOENICS in a systematic manner, but also to 'occasional' lectures, i.e. those devised for particular audiences and particular times.
See also 21 years of PHOENICS, an October 2002 lecture.