The name PHOENICS, as an acronym for Parabolic Hyperbolic or Elliptic Numerical Integration Code Series, first appeared in a CHAM report dated around 1977; but it was not applied to a specific software package until 1980.
Prior to that time, CHAM had been developing individual flow- simulation codes which, although bearing a strong family resemblance to one another, had different authors, functions and eventual users. Codes were then supplied, in source form, to commercial and academic users, who then applied them, and even developed them further, with varying degrees of success.
With the increase in the numbers of users, and in their ambitions to perform complex flow-simulating calculations, there came an increasing incidence of disappointments: it had become impossible to maintain quality and reliability, now that so many persons could gain access to the software.
CHAM therefore decided, early in 1980, to concentrate all its development and application efforts on a single computer code, so structured as to be able to meet all then-known and -foreseeable flow-simulation needs, and to divide it into two parts, one of which would be fully accessible to the users, while the other would be closed. The accessible parts would be those concerned with data input, with output display, and with those aspects of the models which were subject to change with advancing research.
When a name for this code was sought, PHOENICS was the obvious choice; and it has been used ever since.
At first, the PHOENICS code was used by CHAM for its own in-house consultancy work; but it was soon recognised that it had become well-enough engineered to be used by persons who had played no part in its development. The decision was therefore made, in 1981, to offer it for public commercial use.
PHOENICS was therefore introduced by CHAM, as the first commercially-available general-purpose CFD code, in the third quarter of 1981.
At that time, data input had to be effected via Fortran-coding sequences; but PHOENICS otherwise already possessed the many of the major features which still distinguish it from other codes, such as:-
PHOENICS-81 enjoyed considerable success, one of its first achievements being the simulation of possible inadvertent rocket- motor ignitions within the Vehicle-Assembly Building of the US Space Shuttle, which was then being made ready for the first launch.
Many publications based upon PHOENICS-81 are listed elsewhere in POLIS (see the documentation section).
By 1984, users of PHOENICS were requesting a simpler method of data input than the use of Fortran coding, and the reading of hard-to-interpret data files. After considering and rejecting the then-fashionable menu-type input schemes, as being suitable only for less powerful software packages, CHAM converted the PHOENICS SATELLITE into an interpreter of a new high-level language.
This new language, now known as PIL (an abbreviation for PHOENICS Input language) remains a powerful and unique feature of CHAM's software package, having subsequently been developed much further.
The new PIL-reading code was at first called PHOENICS-84; but the nomenclature soon changed to PHOENICS-1.1, -1.2, -1.3, etc, as new features were added and blemishes in the first issues were removed.
PHOENICS-1.4 was issued at the end of 1986, and proved to be rather stable. It lasted indeed until mid-1989; and many users can be found who continue to rely on it. So popular was it that CHAM re-issued it as "Shareware" to celebrate the late-1993 launch of PHOENICS version 2.
A feature introduced with version PHOENICS 1.4 was the Input-File Library, which enables users to consult and make use of the flow- simulation calculations performed by others. This facility remains a unique feature of PHOENICS, which is especially well-developed in PHOENICS-2.2.
While PHOENICS-1.4 was enjoying its long period of stability, continued development at CHAM led to many improvements, which remained for a while in reserve. For example, a vectorisable solver was prepared and tested in 1987, but not immediately incorporated; and there were numerous internal economies of computer time and storage.
All these unexploited improvements, and many new ones, were collected together into PHOENICS-1.5, which was first issued in the summer of 1989. This was the first version to be equipped with a menu-type input facility, which was created in a unique way, being actually written in PIL. The advantage of this, from the user's point of view, is that the questions and answers, and the visual display, can be changed by the user if he so wishes, by simple editing of the ASCII files.
The PHOENICS Input Language was very extensively enlarged so as to make this possible, especially by inclusion of Fortran-like features such as DO loops and IF-THEN-ELSE constructs, as well as a set of graphics tools.
Because of the number of novelties, with the inevitable rough edges to be smoothed, PHOENICS-1.5 passed quickly through the stages of 1.5.1, 1.5.2, 1.5.3 and 1.5.4, the last-named being issued in the summer of 1990. The complete list of 1.5 releases is as follows:
The features introduced in PHOENICS 1.5 are listed in the next section of GUIDE. To access that information, type U to return to the previous menu.
4.2. SATELLITE features introduced with version 1.5
Note added on issue of PHOENICS-2
Descriptions of all the version-1.5 items can be found in the PHOENICS Encyclopaedia. They have therefore been removed from this document, which now merely lists their names, as follows:
4.3. EARTH features introduced with version 1.5
Contents:
4.3.1 The new solver
4.3.2 Moving body-fitted coordinates
4.3.3 Diffusion in BFC calculations
4.3.4 Turbulence-energy generation in BFC calculations
4.3.5 Interactive display and control
4.3.6 Other improvements
4.3.1 The new solver
The built-in linear-equation solver was been modified in the following ways:-
4.3.2 Moving body-fitted coordinates
It is now allowed that body-fitted-coordinate grids should move during the course of the calculation, in manners which can be controlled by the user who enters appropriate coding in GROUND.
This has been facilitated by the bringing of the cell-corner coordinates into memory. Re-calculation of their values, followed by the calling of the BGEOM subroutine from GROUND, effects the necessary changes in the grid geometry.
4.3.3 Diffusion in BFC calculations
In PHOENICS 1.4, diffusion-flux calculations were of low accuracy when the grid used in a BFC calculation was strongly non-orthogonal. This deficiency has been remedied in PHOENICS 1.5, as the running of library case 700 will make plain.
4.3.4 Turbulence-energy generation in BFC calculations
In PHOENICS 1.4, calculations of the generation rate of turbulence energy were of low accuracy when the grid used in a BFC calculation was strongly non-orthogonal. This deficiency has been remedied in PHOENICS 1.5.
4.3.5 Interactive display and control
By setting appropriate SATELLITE variables, it is now possible to cause EARTH to plot residuals from the linear-equation solver on the VDU as the iterations proceed. This enables much to be learned about what are the optimum settings for (now rather numerous) solution-control parameters, such as the over-relaxation factor.
It is also possible to cause the "spot-value" graphs to be printed to the screen.
Other SATELLITE settings cause the calculation to be paused, and then give the user a series of opportunities to reset print-out and solution-control parameters, or to terminate the run prematurely.
4.3.6 Other improvements
In addition, the internal coding of EARTH has been simplified and streamlined; and several small bugs which existed in PHOENICS 1.4 have been removed.
4 GROUND features introduced with version 1.5
Contents:
4.1 GXPRPS
4.2 The AUX function
4.3 Dimensioning
4.4 EARTH spare arrays (EASP*)
4.5 Coding style
4.1 GXPRPS
The property formulae which were alluded to above are accessed via a new subroutine called GXPRPS, which has other open-source subroutines dependent on it. They can of course be altered, amended and augmented by the user who is willing to edit, to re-compile and to relink EARTH.
4.2 The AUX function
A troublesome feature of earlier versions of PHOENICS was the necessity to refer to auxiliary variables such as density, length- scale, etc as AUX(NAME) rather than simply as NAME.
This necessity has now been removed. However, if users already have AUX( )'s distributed throughout their GROUNDs, they can be left there without harm.
4.3 Dimensioning
All the dimensioning at the top of the MAIN program is done by way of PARAMETER statements.
An extra COMMON has been added to allow users to redimension the arrays used for patch- wise variable storage.
An extra subroutine has been added to the end of GROUND, which acts as a dimensioning 'junction box' for the solver block-corrections. The number of blocks is defaulted to 10, but may be increased in this subroutine.
4.4 EARTH spare arrays (EASP*)
The number of EASPs has been increased to 20 (all reserved for GREX); and 10 new stores called GRSP1, ... GRSP10 have been introduced. These act just like EASPs but are reserved for GROUND.
4.5 Coding style
There have been minor changes to the commenting to improve clarity, and some of the IF(.NOT.) GO TOs in GROSTA have been replaced by IF() THEN ELSEs.
4.5. PHOTON features introduced with version 1.5
Contents:
4.5.1 Convenience features
4.5.2 Filling to boundaries
4.5.1 Convenience features
The PHOTON released with PHOENICS-1.5 differs from that released with PHOENICS-1.4 mainly in small but important details affecting the convenience of the user. These include:-
4.5.2 Filling to boundaries
An option added to PHOTON-1.5.2 is the ability to extend contours and colour-filled areas to the boundaries of the domain. This is effected by extrapolation across the outermost halves of the outermost cells.
This feature makes it possible to use PHOTON also for the display of the results of one-dimensional calculations.
4.6. GUIDE features introduced with version 1.5
Contents:
4.6.1 The ADD facility
4.6.2 New lecture material
4.6.1 The ADD facility
GUIDE can now be used for viewing text files other than those which are supplied with it. This is effected by entering TOP, followed by ADD. A prompt for the required file name will then appear, to which the user should respond by entering the full pathname of the file.
This is convenient for PHOENICS users who come to a new computer system, the editor commands of which are unfamiliar to them.
Movement and searching through the attached file can then be effected by use of regular GUIDE facilities, ie +n, -n, )string, (string, etc. Enter H, when viewing a file, to learn what these facilities are.
4.6.2 New lecture material
The lecture material concerned with PHOENICS and with CFD generally has been updated and extended. A lecture concerned with combustion fundamentals has been added.
4.6.3 The CHANGE facility
The user is now permitted to change, if he wishes, the number of lines printed to the screen, by entering C when the top menu is on the screen. Some preliminary "help" information is offered at the same time.
4.6.4 User's own menu
The addition of the user's own menu of items has been made easier by the provision of a skeleton menu, which the user can adapt to his purposes simply by editing the item titles and contents in the GDY1 file.
4.7. Compatibility between versions 1.4 and 1.5
Contents:
4.7.1 Q1 files
4.7.2 GROUND files
4.7.3 EARDAT files
4.7.4 PHI and PHIDA files
4.7.5 XYZ and XYZDA files
4.7.1 Q1 files
All Q1 files written for version 1.4 will be read and correctly interpreted by version 1.5, unless they infringe some of the restrictions which the advanced PHOENICS Input Language features entail (for example colons in TEXT arguments, or the use of commas rather than semi-colons as delimiters)
The reverse is not necessarily true, because Q1 files written for version 1.5 may make use of advanced PIL features.
4.7.2 GROUND files
The principles governing the construction of GROUND coding and its interaction with EARTH are the same for version 1.5 as for version 1.4.
GREX3.FTN is the version-1.5 counterpart of the GREX2.FTN issued with version 1.4. It contains everything which its predecessor had, but is somewhat richer in content, tidier in form and more economical in execution.
4.7.3 EARDAT files
All EARDAT files written for version 1.4 can be read and correctly interpreted by version 1.5.
The reverse is not necessarily true, because EARDAT files for version 1.5 may contain data settings which are without significance for version 1.4. There are however very few of these.
Version 1.5.2 (January 1990) has introduced some economies in the reading and writing of EARDAT files, which are now shorter than for PHOENICS version 1.4. If, for reasons of compatibility users wish to adhere to the 1.4 format, they should change the logical variable EAR14 from .FALSE. to .TRUE. in SATLIT.FTN, re-compile and relink.
This feature renders it especially desirable to set NPHI, in the SATELLITE, to the lowest value consistent with the number of variables which require to be stored.
4.7.4 PHI and PHIDA files
All PHI and PHIDA files written for version 1.4 can be read and correctly interpreted by version 1.5.
The reverse is also true.
4.7.5 XYZ and XYZDA files
All XYZ and XYZDA files written for version 1.4 can be read and correctly interpreted by version 1.5.
The reverse is also true.
4.8. Add-ons to version 1.5
Contents
4.8.1 Computation-speed enhancers
4.8.2 Mathematical-formulation variants
Introduction
The capabilities of PHOENICS can be extended in so many ways that it is impracticable to supply all available "add-ons" with the standard version. Instead, add-ons are being prepared for inclusion, when appropriate arrangements are made, in a separate sub-directory of the PHOENICS system.
In most cases, an add-on consists of a specific GROUND subroutine, a library of Q1 files, and some documentation.
The add-ons which are currently available, or can quickly be brought into an issuable state, are listed below.
4.8.1 Computation-speed enhancers
4.8.1.1 The "chain" solver
This add-on is a set of Fortran subroutines which can be called from GROUND, for the purpose of accelerating the solution of the pressure-correction (or other scalar) equations, when the flow domain is "labyrinth-like", ie when it consists of circuitous interconnected passages, formed by the blockage of many of the faces of most cells. It is useful because the solver built into earth, like most solvers which have no place for information about the connectedness of the domain, takes a long time to converge.
The "chain solver" has been found to converge 50 times as fast as the standard solver in some test problems.
The add-on has been used to enable PHOENICS to represent a flow domain consisting of a three-dimensional nuclear-reactor vessel, coupled to a series of pipes conveying steam and/or water to steam-generators, pressurisers and other vessels.
The solver was devised by D.B.Spalding, and implemented by M.A.Serag-Eldin, in 1987. It was further worked on by A.Palacio during 1988 and 1989. .
4.8.1.2 The cyclic-recursion TDMA replacement
This add-on is a Fortran subroutine which can be supplied to replace the built-in tri-diagonal-matrix solver. The latter employs recursive DO-loops, and so is not vectorisable.
The add-on, by contrast, is fully vectorisable.
4.8.1.3 Multi-grid solvers
PHOENICS version 1.5 has a user-adaptable multi-grid solver, which has been described above. This is more effective that conventional multi-grid solvers when blocks of high-conductivity material are arbitrarily distributed in a low-conductivity fluid.
Conventional multi-grid solvers can be supplied as an add-on, for acceleration of the convergence of equation sets of which the coefficients vary more smoothly through space.
4.8.1.4 Solvers for parallel computers
Linear-equation solvers are under development by CHAM and its associates which exploit the possibility of using several processors in parallel. They are being made available to PHOENICS users as add-ons.
4.8.2 Mathematical-formulation variants
4.8.2.1 Equation-formulation schemes
This add-on consists of a series of FORTRAN subroutines which can be called from GROUND and activated from SATELLITE. They have the effect of changing the formulation of the convection and diffusion terms in the finite-domain equations to accord with a variety of alternative prescriptions, thus replacing the default prescription, namely fully-implicit upwind.
Twelve schemes are provided, including:- fully-explicit, Crank-Nicholson, and Courant-number-dependent in respect of time; and QUICK and QUICKEST in respect of space.
*** This add-on has been incorporated in versions 1.6 (1003) onwards.
4.8.3.1 Particle-tracking schemes
This add-on handles two-phase flows by means of a variant of the particle-source-in-cell method of CT Crowe. This was first applied to PHOENICS by A Castrejon.
It allows for full coupling between the particulate and continuous phases, which exchange mass, momentum and energy.
*** This add-on has been built into PHOENICS from versions 1.5.4 onwards, with the name of GENTRA.
4.8.3.2 The scalar-equation procedure for free-surface tracking
This add-on is based upon the Imperial College PhD work of Liu Jun. It represents a simple and economical method of handling transient surface-movement phenomena in two or three dimensions.
*** This add-on has been incorporated in versions 1.6 (1003) onwards.
4.8.3.3 The Lagrangian formulation for a distorting medium
This add-on is based on the work of DB Spalding and HQ Qin. It has been applied to the distortion of a solid under impact, and in particular to that of a reactive solid, which may proceed to detonate.
4.8.3.4 The calculation of aerodynamic lift
This add-on is the work of JP Edwards. It assists the calculation of the lift and drag of an airfoil, the flow around which has been computed on a body-fitted coordinate grid.
4.9. Code configuration of version 1.5
Contents:
4.9.1 The directory structure
4.9.2 The PREFIX and "CONFIG" files
4.9.3 Installation procedures
4.9.4 Testing procedures
4.9.5 Benchmarking procedures
4.9.1 The directory structure
The PHOENICS-1.4 principle of distinguishing "public" and "private" elements of the directory structure has been retained; but the names of directories have been modified, and the pattern of distribution of files within them has been changed, so as to accommodate the present and future enlargements of the PHOENICS family of programs, and so as to facilitate delivery and installation.
The directory structure adopted for this installation can be inspected by returning to the top menu, and entering 5, followed by 1. All the directories which do not have "priv" in their names are to be regarded as being "public", which means that users have read-only access to them.
4.9.2 The PREFIX and "CONFIG" files
Each program now has its own CONFIG file, residing in its own public directory. PREFIX files are individual to users, and reside in the private directories d_priv1, d_priv2, etc.
4.9.3 Installation procedures
The detailed information on Installing PHOENICS from source code is supplied in TR108.
Installation of PHOENICS from binary code on various computer is fully described in TR110 series.
4.9.4 Testing procedures
PHOENICS has been thoroughly tested before release. However, the installer should perform the test on each program to confirm that the installation has been successful. For the version 1.5, a test directory, d_test will be created during the installation from source code. The installer should set the working directory to d_test. The testing procedure for each program is described in TR108.
For the installation from binary code, the checks are performed in the private directory, d_priv1 through running library case 523. The procedure is described in TR110.
4.9.5 Benchmarking procedures
The benchmark should be run after installation in order to establish the performance profile of PHOENICS on the computer in question. The installer should set the working directory to d_phoe15/d_test.
A Q1 file containing eleven test cases from the PHOENICS library is provided. These cases can be run from d_test by simply typing 'runben'.
5.1 Details of the data-input features
PHOENICS data-input features introduced during 1990
GSET.
This new command greatly facilitates grid generation. See the "help" entry, and also library cases 510 to 523, 527, 529 and 536.
The PROPS file
Material properties set equal to GRND10 are picked up from a file called PRPOS, residing in d_earth, in accordance with the value of the material-marker property PRPS. Library cases 459 to 467, 921 to 950, and many others illustrate its use.
Reading properties from the Q1 file
Properties may also be inserted in the Q1 file. Library case 240 illustrates this.
February 3 1991....... GREX3 reads Q1 data directly
On this date the new subroutine GXRDQ1 was introduced. It was called by GREX3 from Group 1 if LSG3 and USEGRX were set =T in SATELLITE to enable EARTH to accept new input data by reading the top of the Q1 file.
Subsequently, LSG3 was replaced by the PIL variable RDQ1; and full information about how to use the feature can now be found in the SATELLITE HELP file by entering RDQ1?.
The feature not only allows data to be supplied to EARTH without the necessity to run SATELLITE, but it also (since the extra lines supplied in Q1 are also printed on the RESULT file, provides a convenient device for annotating the latter file with descriptive text.
This feature must be used with caution, because some resettings of data may conflict with settings made in the satellite. For example, whole-field solution cannot necessarily be switched ON because necessary storage may not be provided; but it may be switched OFF (by dividing the relevant ISLN by 5).
March 4 1991........ USTEER reads top of Q1
The USTEER feature has been extended, so that, on the occasions requested by the user, EARTH re-reads the top-of-Q1 entries, which of course the user may have altered by editing since it was last read. This greatly increases the number of data items which the user can change during execution.
New SATELLITE features in version 1.6.2
PHOENICS version 1.6.2 succeeded PHOENICS 1.5.4, and was released in April 1991. This section of GUIDE summarises the main changes.
General-menu improvements
The PHOENICS general menu was enhanced in several respects:-
Grid-Generation Menu
The grid-generation and grid-handling procedures of PHOENICS underwent major re-development. The main new features were:-
Interpreting Q1 files
Library case 20 was supplied for the purpose of enabling Q1 files to be 'translated' into plain language. The 'translation' includes information on the grid; variables solved; variables stored but not solved; patches; viscosity and solver parameters. It is grouped so that different items of information for each variable are kept together.
Activation is effected by typing:
NOWIPE=T LOAD(*20)
The user will be asked whether to display the information on the screen or append it to the end of the COPYQ1 file. The latter will cause satellite to save the COPYQ1 file (not the stack) in Q1 and then terminate, hence all PIL logic will be lost (e.g. DO loops) so this should be used with caution.
If the 'translation' was displayed on the screen then the user should type LOAD(*CLEAR) to remove the PIL commands that make up library case 20 from the stack once the 'translation' has finished.
The file, which may be inspected by entering SEELIB 20 is written in PIL with much use of its logical capabilities. It is supplied as an example which users may wish to augment or replace in accordance with their preferences.
New SATELLITE features introduced with version 1.6 (1003)
All three types of grid handled by the menus
The general Menu now provides access to the GridMenu for setting up all three grid types available in PHOENICS - Cartesian, polar and BFC - and this is the recommended route for all grid specification. (The earlier procedure within the general Menu for specifying Cartesian and polar grids region-by-region is, nevertheless, still available for users who prefer that method.)
'Objects' for Cartesian and cylindrical-polar grids
The main improvements to GridMenu concern the facility for defining 'objects' in Cartesian and cylindrical-polar grids. Previously, defining an 'object' within the solution domain was merely a device for dividing the domain into regions. Now, however, this feature has been extended in two ways:
Mouse-driven grid generation in GridMenu
The VIEW facility for body-fitted coordinates has been transformed into a mouse-driven grid-generation facility, which allows the user to 'drop' points, and construct lines and frames using a mouse (or the arrow keys when a mouse is not available). Grids can be matched to frames without leaving the new system, and the 'grid check' facility (previously available only through the GRDCHK command) can be used to inspect the quality of the mesh. ('Grid check' uses a colour code to indicate the orthogonality of the grid at each point.)
Settings effected in the VIEW environment are transferred automatically to the GridMenu session, and recorded as PIL commands. The MENSAV facilities will also record and replay VIEW sessions.
Conjugate heat-transfer in the general menu
A new menu option now enables users to simulate conjugate-heat-transfer problems, solving for temperature directly instead of enthalpy. As part of this feature, a library of material properties can be accessed from the menu to assign properties to fluid and solid parts of the domain; users themselves can add materials to this library. Appropriate solution-control devices (viz the block-correction feature, solving whole-field for temperature, and harmonic averaging of conductivities) are activated automatically.
Improved specification of boundary conditions in general menu
In Cartesian and cylindrical-polar coordinates, the location of boundary features (inlets, outlets, blockages, etc) can now be linked to named 'objects' defined during the grid-generation procedure. This obviates the need to enter the coordinates twice: once when defining the grid, and again when specifying boundary conditions, as was the case in previous versions.
If an 'object' is subsequently repositioned or re-sized, then the boundary condition is also changed automatically. If an object is deleted, any associated boundary-conditions will also be deleted without further instructions from the user. If a new 'object' is created by copying an existing one, the boundary conditions are not automatically copied, but a new boundary condition may be linked to the new object. Similarly, heat sources can be attached to existing 'block' or 'plate' type boundary conditions, without re-entering their location.
Advanced-user options
Several new options have been introduced so as to make the Menu more attractive to experienced PHOENICS users, including facilities to:
Other convenience improvements
The following improvements have also been carried out:
Menu- and help-panel improvements
For all menu options, the 'hot-key' has been identified by an upper-case character in the option name. As far as possible this is the first character; where this is not possible, because two or more options on the panel share the same initial character, this first character is lower-case and whichever character is chosen as the 'hot-key' is upper-case.
The help files for the general Menu and GridMenu have been overhauled to make the information in both more easily understood, and in many cases more comprehensive.
The display panels for both GridMenu and the general Menu have been rationalised so that they all conform to a standard layout: for example, the option Return to previous panel is chosen by the same 'hot-key' on all panels.
New and modified help entries
The following entries in the SATELLITE help dictionary are new or have been modified. The entries marked * have a corresponding 'new-feature description' in this section of GUIDE.
Entry_____________Notes___________________________________________ ABORT Help absent in previous version
DELAY Help absent in previous version
FREE New entry on free-surface flows
HOL * New entry
PROPS File listing updated
REYNOLD * New entry
ROTA Errors corrected
SCHEME * New entry
SEM * New entry
TURBUL Modified entry
GSET Modified GSET (V, ...) command
VIEW * Instructions for new version of VIEW included
U1AD * Modified entry
TURMOD Modified entry
IURVAL Modified entry
SOLIDS There is no longer a need for a SOLIDS patch
TSTSWP * Entry modified to include graphical monitoring
INTRPT New entry
MENSAV Modified entry for pausing and adding to MENSAV
RSET New RSET(G,...) option
Changes to FORTRAN files
The maximum dimensions for the grid-generation arrays are now set in PARAMETER statements in the file SATLIT.
PHOENICS features introduced during 1992
Items introduced during the first three months
SATELLITE
CASE 20 of the input-file library: interpreting the Q1 file.
This library file has been supplied (in file lib6) for the purpose of enabling Q1 files to be 'translated' into plain language. The 'translation' includes information on the grid; variables solved; variables stored but not solved; patches; viscosity and solver parameters. It is grouped so that different items of information for each variable are kept together.
Activation is effected by typing:
NOWIPE=T LOAD(*20)
The user will be asked whether to display the information on the screen or append it to the end of the COPYQ1 file. The latter will cause satellite to save the COPYQ1 file (not the stack) in Q1 and then terminate, hence all PIL logic will be lost (e.g. DO loops) so this should be used with caution.
If the 'translation' was displayed on the screen then the user should type:
LOAD(*CLEAR)
to remove the PIL commands that make up library case 20 from the stack once the 'translation' has finished.
The file, which may be inspected by entering SEELIB 20 is written in PIL with much use of its logical capabilities. It is supplied as an example which users may wish to augment or replace in accordance with their preferences.
CLDA
A new GXCLDA.FTN subroutine was added. It performs the operations associated with the "conservative-low- dispersion algorithm" more efficiently than when this algorithm is implemented by way of the "neighbour-cell" technique.
CONJUGATE heat transfer
The conjugate-heat-transfer capability of PHOENICS 1.5 has been improved in several respects:- (a) An ASCII file houses now the library of materials, which can therefore be easily customised/expanded by the user. Material properties can now be constant or dependent on other properties. They can also be read from Q1 directly by EARTH. (b) Boundary conditions (including thermal links) at the fluid-solid interface are set up automatically. (c) Heat-transfer coefficients can be optionally calculated and printed out by Earth.
CONTACT resistances
The Group 12 feature allowing diffusion coefficients to be modified patchwise has been extended to allow the addition of resistances to heat transfer brought about by the inclusion of thin (sub-grid-scale) sheets of poorly-conducting material.
CORNER coordinates
The following statement in GREX3 arranges for the print-out of corner coordinates when STORE(XCEN,YCEN,ZCEN) appears in the Q1 file: PRNCEN=LBNAME('XCEN').NE.0.OR.LBNAME('YCEN').NE.0.OR. 1 LBNAME('ZCEN').NE.0
CORIOLIS forces for horizontal flows
The variable CORIOL, when set to a value other than zero, causes momentum sources per unit mass which are equal to CORIOL*V1 for U1, -CORIOL*U1 for V1, and to corresponding expressions for the second-phase velocities. This facility is useful when atmospheric and hydrospheric simulations are being performed.
An example can be found in the two-phase section of the active- demo set.
The DENPCO feature.
This new logical introduces densities into the calculation of pressure-correction coefficients in order to promote convergence when strong density variations are present.
EXPERT system
A set of 'auto-pilot' devices have been introduced which make 'in-flight' adjustments to the numerical parameters (such as relaxation factors) in order to speed up the convergence of the solution procedure.
FNxxxsubroutines
FULLY-DEVeloped flows.
It is now possible to solve for velocities without solving for pressures, or indeed activating convection terms. This is useful when it is desired to compute a fully-developed pipe-, plane-walled-channel- or Couette-flow situation, without, as was formerly necessary, simulating the flow in a long duct. either elliptically or parabolically. The solution is then one-dimensional. It is necessary to prescribe a longitudinal pressure gradient in order to create finite longitudinal velocities.
Library case (951-957) illustrates the use of this feature.
If the duct wall is neither circular nor an infinite plane, the flow will be two-dimensional. Then pressure must be solved for; and cross-duct convection must be taken into account. Otherwise the situation is as above.
An example will be found in the one-phase section of the "active-demo" series.
GROUP 12 features.
The following patch names (in which ? stands for any character) cause the terms indicated for the variable in question, in the region occupied by the patch, to be multiplied by the third (CO) argument of the corresponding COVAL:
GP12CON? all convection terms GP12SOR? all built-in sources GP12CNE? the east-face convections GP12CNN? the north-face convections GP12CNH? the high-face convections GP12DFE? the east-face diffusions GP12DFN? the north-face diffusions GP12DFH? the high-face diffusions
The fourth (VAL) argument has no significance assigned to it so far.
These facilities are especially useful when PHOENICS is to be used for fluid-flow analysis in one part of a domain and for stresses-in-solids analysis in another.
Examples can be found in the "active-demo" series under the heading "stress analysis in solids".
The INTERPHASE-mass-transfer and friction, FN98 and FN99, have been re-written and made directly accessible to users. They are to be found in file gxsor.ftn.
IPARAB=4
A new hyperbolic option (IPARAB=4) has been added for the efficient solution of wholly supersonic flows.
This feature allows the lateral pressure variations to influence also the longitudinal velocity when PARAB = T, in regions where the flow is supersonic. It can be developed for mixed supersonic and subsonic flows, and will be when specific needs arise.
Library case 156 exemplifies its use.
KINETIC-heating sources for TEM1 & TEM2.
If TERMS(TEM1,Y,.... or TERMS(TEM2,Y,...., the kinetic- heating source terms become active in the same way as for enthalpy. Warning: This may not always be desirable, for example when stress-analysis is being simulated and the velocity variables have the significance of displacements.
LINEAR links
Highly-conducting sub-grid-scale links can now be introduced by special PATCH and COVAL commands. They are useful for representing for example, thin metal plates embedded in a poorly-conducting medium.
The "LINK" feature. See: special topics - grid restructuring
LOW-REynolds-Number turbulence.
A simple low-Reynolds-number feature is provided in GXENUT. It is activated by setting PRNDTL(1) and PRT(1), which have no other significance, to non-default values. The effective-viscosity formula used is:
vist = vist_nom * amin1(1.0 , A * vist_nom / visl ) ** B)
where: vist = turbulent kinematic viscosity to be used
vist_nom = nominal (high-Reynolds-number) value of vist
visl = laminar viscosity; A = PRNDTL(1); B = PRT(1)
The term vist_nom/visl represents the "local Reynolds number of turbulence".
Suitable values for A and B may be 0.01 and 4.0
MONITORING of spot-values etc
A graphical display of spot-values and residuals has been provided for use on personal computers and work stations. It was first activated by setting TSTSWP = 12345. Later, TSTSWP = -n has been caused to elicit an updating of these values only every n sweeps.
Where the PHOENICS graphical driver allows an interruption, the EARTH run can be stopped to alter the relaxation factors or to end the run.
At the end of the EARTH run, the monitoring graphs can be plotted on any hard-copy device present in the PHOENICS graphics system.
NEIGHBOUR-patch improvement
The capabilities of the subroutine GXNEPA (n file GXMODS.FTN) have been extended, so that neighbours can be displaced in both "INDVAR-space" AND time or distance.
The use of the new features is illustrated in a Q1 file which tests the "conservative low-dispersion algorithm". It appears in the library as case number 491.
NFUSER
The user is now allowed to reserve for himself a part of the F-array. In the satellite, he must set NFUSER to the number of locations which he needs. Then, in GROUND coding, he can refer to the I'th of his reserved locations as: F(L0USER + I)
PLOTting of residuals and corrections
When a solved-for variable is given the name xxx% and the statement STORE(xxxR) appears in the Q1 file, the field of xxxR contains the values of the residuals of variable xxx% before entry to the linear-equation solver. These values can be printed in the result file, or viewed via PHOTON or AUTOPLOT, in the same was as other stored variables.
When a solved-for variable is given the name xxx% and the statement STORE(xxxC) appears in the Q1 file, the field of xxxR contains the values of the corrections to variable xxx% after exit from the linear-equation solver. These values can be printed in the result file, or viewed via PHOTON or AUTOPLOT, in the same was as other stored variables. (Note: this works at present only for nz=1).
The PROPS file
Material properties set equal to GRND10 are picked up from a file called PRPOS, residing in d_earth, in accordance with the value of the material-marker property PRPS. Library cases 459 to 467, 921 to 950, and many others illustrate its use.
P2, the second-phase pressure.
STORE(P2) has always introduced storage for and print-out of the second-phase pressure; but no use has been made of it. Now, coding within EARTH ensures that, if P2 is stored, the pressure acting on the second phase in the momentum balance is P1 + P2 (so P2 is the EXTRA pressure experienced by phase 2). It is the responsibility of the user to provide coding which ascribes values to P2; but an example has been supplied in GREX3, group 19, where P2 is set proportional to R2. This is useful for the simulation of then floating layers, for example oil slicks.
An example can be found in the two-phase section of the active- demo set.
PROPERTIES read from the Q1 file Properties may be inserted in the Q1 file. Library case 240 illustrates this.
SETBFC and MOVBFC
Setting SETBFC = T causes GREX3 to call a new subroutine, GXBFGR, which exemplifies the use of GROUND coding to create a body-fitted-coordinate grid. Setting MOVBFC = T further causes GXBFGR to be called at each time step, in order that the grid can be changed; and, if storage is provided for CONI, CONJ and CONK, GREX3 will calculate the grid-movement contributions to the convection fluxes. Library case 966 illustrates the use of this feature.
SLIP-velocity feature for two-phase flow.
Storing the variable SLPU, SLPV and/or SLPW now ensures that the differences between first- and second-phase velocities are computed and stored at the end of iterations on a slab. They can be used for the plotting of slip-velocity vectors in PHOTON.
The relevant sequence in GREX3 is: SLIPVL = .NOT.ONEPHS.AND.(LBNAME('SLPU').NE.0.OR. 1 LBNAME('SLPV').NE.0.OR.LBNAME('SLPW').NE.0)
Examples can be found in the two-phase-flow section of the "active-demo" set.
SOLIDS
It is no longer necessary to create a SOLIDS patch, in order to activate the SOLIDS feature, because EARTH test for the values of PRPs which have been set. See SATELLITE HELP
"STAR-NAME" PATCHES
If a PATCH name begins *name, where name is the four-character name of a solved or stored variable, a corresponding COVAL for variable PHI will introduce a source of PHI equal to:
-CO*PHI*NAME**VAL
where CO is the third argument of the COVAL, and NAME stands for the local value of the variable having the name which has been referred to.
Since such "power-law" patches have hitherto had to be introduced via GROUND coding, it is thought that their easy creation via the Q1 file will often be found convenient.
If the referenced variable has a 2-character name, the patch name must include the blanks, because the internal-to- EARTH test is made on the first 5 characters of the PATCH name. Thus: PATCH(*P1 A,... ) followed by COVAL(*P1 A,H1,1.E3,2.0) will create a source of first-phase enthalpy which is proportional to pressure squared; but: PATCH(*P1A,... ) followed by COVAL(*P1A,H1,1.E3,2.0) will not.
An example is:
SOLVE(VOSQ,KE);REAL(CONST1);CONST1=4.0 PATCH(*VOSQ1,1,NX,1,1,1,1,1,1) COVAL(*VOSQ1,KE,CONST1,0.5)
This provides a source equal to:
-4.0*KE*VOSQ**0.5
The feature is illustrated by library cases 413, 414 and 415.
STOPJOB
If, during execution, the user creates and saves a file called STOPJOB, execution stops after completion of final-sweep print-out. The relevant coding is in GREX3, Group 19.
This device may not work on all computer systems.
SUPPRESSing the making of pressure correction.
The PIL setting RELAX(P1,LINRLX,0.0) now prevents pressure corrections from being added to pressure, which therefore cannot change. The full velocity adjustments are still made however.
TURBULENCE-energy generation rates printed
This is now effected when a variable named GEN1 is stored, and the default print-out provisions are used.
TWO-EQUATION turbulence models augmented
Provision has been made for both the Saffman-Spalding k-W model, and the Kolmogorov model k-omega model. VIST and LEN1 formulae for these models have also been provided and also wall-function entries. Testing is in progress..
UNDER-RELAXation for pressure correction
The PIL setting RELAX(P2,LINRLX,factor), where 'factor' is a real number, multiplies the continuity errors by 'factor' before they enter the pressure-correction sequence. This may be a more effective solution-smoothing sequence than under- relaxing the pressure correction itself, because it results in reduced (for 'factor' <1.0 ) velocity adjustments. RELAX(P2,... has no influence on the P2 values themselves, when these are activated as in the note below (January 31,1991).
USTEER See SATELLITE HELP
UWATCH
See SATELLITE HELP Also, The questions which appear on the screen when UWATCH and USTEER are set = T in the Q1 file have been placed in the user- accessible Fortran file GXRDQ1. This enables a user to create his own form of interaction or interference with the execution EARTH.
A fully-VECTORisable linear-equation solver,
especially suitable for Cray and Convex machines, has replaced the previous partially- vectorisable version. Speed-up factors in excess of 2 have been obtained. The new solver produces some speed-up also for scalar machines.
Z-DEPENDENT properties
When setting a property in GROUND as anIZ-dependent function, the user no longer has to concern himself with the question of whether the current- or high-slab value is being computed.
Minor items
February 5 1991: * GRND5,6,7 for VIST in GXENUT, for the k-W (vorticity-fluctuations-squared) and k-omega (Kolmogorov's frequency) models.
March 19 1991: * Field print-out is now provided when a run is terminated because of pressures in excess of 1.E12
The following features have been made part of the standard set of PHOENICS facilities:-
It should be noted also that the PROPS file contains the properties of some additional materials. As a consequence, new materials-flag values have been assigned to some materials.
New EARTH features in version 1.6 (1003)
Alternative interpolation schemes
PHOENICS has built-in options for upwind and hybrid interpolation schemes for the convection terms of the finite-volume equations, and for implicit and explicit formulations in transient problems.
The present enhancement provides two additional convection schemes, and four time-direction formulations.
The alternative convection schemes are:
The time-direction formulations available for each of these schemes are:-
Additionally, the Crank-Nicholson and Courant-dependent formulations can be used with the built-in upwind scheme.
The implementation of the alternative differencing schemes in the present enhancement provides users with a high degree of control; thus they are able to apply different convection schemes to different variables simultaneously; moreover, they may restrict the application of the scheme to only part of the domain and to specified coordinate directions only. Users are also given the option to include or exclude the QUICK transverse terms and the near-boundary modifications.
The alternative schemes can be applied only to scalar variables in Cartesian or cylindrical-polar geometries.
Reynolds-stress turbulence-model
A new turbulence model now complements the standard built-in range, namely a Reynolds-stress turbulence-model.
The model solves differential equations for the Reynolds stresses and the turbulence kinetic-energy-dissipation rate. The RSTM is therefore able to capture the non-isotropic character of turbulence, which is present in many practical fluid-flow situations (for example, in those exhibiting large streamline curvature, swirl or strong recirculation).
As implemented in PHOENICS 1.6 (1003), the RSTM has the following capabilities and limitations:-
The RSTM is delivered in source code, as a special GROUND subroutine. Eleven examples of use are also provided in the form of a 'user' Q1 library.
Height-of-liquid method for flows with inter-fluid boundaries
Flow simulations of real processes often involve fluids that are separated by a sharp interface. Mould filling, film coating, wave formation, liquid sloshing in tanks are some examples.
The calculation of the interface is usually a computer-intensive task, and yet a necessary step in the solution procedure and often the main output from the computation. PHOENICS offers several ways of tracking such an interface, such as DONACC (in two-phase mode) or the scalar-equation method (see below).
A recent addition to PHOENICS allows the economical tracking of the interface when it is known before the computation that surface does not exhibit overturning. The method, called Height-Of-Liquid (HOL), calculates the height of the interface at each point by focussing in one of the fluids (say the lower one) and computing the height of the liquid column through a mass balance over the sides of the column.
HOL works computationally as a single-phase method, and it can be used in all three coordinate systems and for transient and steady-state problems.
HOL is attached to PHOENICS as a GROUND station and delivered in source code. The activation of the HOL features is from PIL. Twelve examples are provided.
Scalar-equation method for flows with inter-fluid boundaries
When the inter-fluid surface separating two fluids exhibits overturning, the HOL method outlined in the previous section is not applicable. For these cases, PHOENICS has been equipped with a Scalar-Equation Method (SEM).
In this method, a scalar property is used to distinguish between the fluids. The transport equation is integrated using special interpolation techniques (namely, the Van Leer scheme) to prevent numerical diffusion; and physical diffusion is switched off.
SEM is attached to PHOENICS as a GROUND station, and provided in source code. SEM is activated via PIL commands.
Changes to GROUND
Two new sections have been added to group 19 of GROUND:
Changes to GREX and GX subroutines
GREX3 and many GX subroutines have been upgraded. Interested users are advised to check the actual listing in the directory d_earth, rather than in TR200.
New EARTH features in version 1.6.6
Improvement of iteration cutoff-criterion
RESREF (the variables that control the magnitude of the residuals which will cause the iteration to finish for each variable) can be set automatically by EARTH during the computation.
Algebraic-Slip Model
An algebraic-slip model for multi-phase flows has been added to the range of multi-phase models available in PHOENICS.
Two-phase interphase models for IPSA
New interphase-transport laws have been added for droplet drag, mass-transfer and heat transfer, and for turbulence modulation.
New laws for ENUL
Two new laminar-viscosity laws have been added to the range of existing ones: ENUL=GRND3, which relates ENUL to temperature, and ENUL=GRND4, which relates ENUL to the strain rate.
External heat-transfer laws
New PATCH and COVAL commands have been added to facilitate inclusion of external heat loss by way of radiation (a*(Ts**4-Test**4)) and free convection (a*(Ts-Test)**n).
Radiation and free-convection boundary conditions
The star-name-patch feature has been extended for use with the variable TEM1 (first-phase temperature). The syntax is as follows: PATCH(*TEM1abc,north/south/etc,,,,,,,) COVAL(*TEM1abc,TEM1,coeff,exponent)
When exponent = 3.0, the source per unit area is: coeff * (TEMP0**4 - TEM1**4) , actually calculated in the linearised form: coeff * (TEMP0 - TEM1) * (TEMP0**3 + TEMP0**2*TEM1 + TEMP0*TEM1**2 + TEM1**3)
When exponent = any other value, eg 0.25 as is suitable for laminar free convection, the source per unit area is: coeff * (TEMP0 - TEM1)**(1 + exponent) .
TEMP0 is a satellite variable, representing the surroundings temperature.
Non-orthogonal grid solution improvement
This is a new solver that allows linear equations to be solved without repeated sweeps, so saving computer time.
PATGEO: Automatic output of geometry for PHOTON
A GROUND add-on has been prepared that writes the geometrical information of all the PATCHes as PHOTON GRID OUTline commands in a PHOTON USE file. The file can then be executed from PHOTON to draw automatically the geometrical features of the problem by means of the command USE PATGEO, entered after the loading the PHI file.
5.3 New PHOTON features in version 1.6.2
Streamline plotting
PHOTON 1.6 has now been provided with a much demanded feature: the ability to plot streamlines (in two-dimensional flows) and tracks of mass-less particles (in two- or three-dimensional flows).
Command-session recording
A 'macro-making' facility is now available by means of a new command that records the interactive command-session in a file. The file can subsequently be read as a USE file to reproduce automatically the command sequence.
DUMP;
selection of variables to be plotted Selected dumping was designed to produce additional data files for plotting. These data files are similar to PHI file except that they contain field values of only selected variables. More than one file can be produced for a single run at selected slabs, sweeps or time steps. Variables are selected by using OUTPUT commands with the third answering parameter (Y or N) set to Y.
TIME as a plotting direction
Subroutine GXPARA is used for transient cases to save data for each time step so that the problems can be viewed with time as one coordinate and some variable as another, if:- (a) NZ=1; (b) the value of ISG16 is greater than 0 and ISG17 is greater than ISG16; and (c) ISG20 is greater than 0.
Here ISG16 (equivalenced to IDFPAR in GRDLOC for use in EARTH0 indicates the first time step at which dependent variable fields are to be dumped; ISG17 (equivalenced to IDLPAR in GRDLOC for use in EARTH0 indicates the last time step at which dependent variable fields are to be dumped; and ISG20 (equivalenced to IZTDPF in GRDLOC for use in EARTH0 indicates the time-step frequency of dumping.
In addition, subroutine GXTIM can be used to provide various transient options for sources, for example, battlement, saw-tooth or sine-wave variation.
Both PHOTON and AUTOPLOT now start by reading automatically a USE file with a name U, if such a file exists in the user's private directory. This device can be used to execute routine command sequences, which are often needed when exploratory or parametric runs are performed.
Of course, if a U file is left in the directory from a previous PHOTON session which is not appropriate to the new session, PHOTON will read some commands which do not fit the current data. It is therefore a wise practice to delete U, or save it with a different name, after use.
The main new functions added are:-
The Gentra menu and manual TR 211 were modified accordingly; and a special library of input files contains 62 test cases.
The D_ACTDEM sub-directory - Active demonstrations
A suite of "active demonstrations" now forms part of the PHOENICS package delivered for most systems. The word "active" is used to register the fact that at least three PHOENICS modules are activated by them, typically SATELLITE, EARTH and PHOTON (or AUTOPLOT); and their users also have the opportunity for activity of their own (typically by influencing input data) during the course of the demonstrations. "Passive" demonstrations, by contrast, typically involve the only the display of the results of previously-executed computations.
To access the catalogue of available demonstrations, select Demo in the Commander menu-bar, or enter rundem at the operating-system prompt from a PHOENICS private-directory.
There are 84 examples provided currently (on 25 March 1992) in the active demonstration package, which is supplied with standard PHOENICS. These examples are grouped as follows:-
a One-phase
b Flames
c Two-phase, including particle combustion
d Input-menu demonstrations
e Free surfaces, by HOL and scalar-equation methods
f Grid generation
g Grid-restructuring
h Reynolds-stress model
i Two-fluid turbulence model
j Special-purpose programs (if supplied)
k GENTRA (if supplied)
l Stress analysis in solids
m One-equation examples
q CLDA and QUICK schemes
r Radiation
To run an "active demonstration", the user should enter a working directory such as D_PRIV1 (NOT the directory d_actdem), and then type: RUNDEMO The contents list, with some information on each example, will appear on the screen as the demonstration proceeds.
An interesting feature of these demonstrations is that the PHOTON or AUTOPLOT "use" files are included at the top of the Q1 files.
On PC386/486 and UNIX the demonstrations may be run by way of the interactive " PHOENICS commander" environment program.
Changes to active demonstrations in version 1.6.6
The existing active demonstrations have been grouped into more rational sections, and new demos have been added.
End GUIDE and type rundem to access the demonstration system.
D_TUTOR
A grid-generation tutorial program is supplied with the standard PHOENICS. It is to be found in sub-directory D_TUTOR.