ADVICE on the use of PHOENICS

Contents

1. What PHOENICS can do: prediction and optimisation
2. How PHOENICS (guided by its user) does it
3. Desirable background knowledge
4. Why caution is needed

1. What PHOENICS can do: prediction and optimisation

PHOENICS is a CFD oracle: it answers what-will-happen-if questions.

Or rather what may, even perhaps probably will, happen, in the light of current physical knowledge.

In these two sentences, much is implied, including:

• that the questioner must define his or her question; as for example:
  • What will be the effectiveness of the heat exchanger?
  • What will be the maximum temperature in the computer room?
  • What will be the lift and drag forces on the airfoil?
• that the questioner must also define the 'if' condition, thus:
  • if the number and diameter of the tubes etc. are such and such;
  • if the computers and the cooling units are arranged in the following manner;
  • if the airfoil shape, its 'angle of attack' and the Reynolds number are ...

To discharge these responsibilities, the user needs no specialist CFD knowledge; but the more he possesses the background understanding outlined in sections 3 and 4 below, the less likely he is expect more of PHOENICS, and indeed of CFD, than is reasonable.

For its part, when the PHOENICS oracle delivers its answer to the 'What' question, it ought, in order to give a balanced picture (and to maintain its credibility), to emphasise that the answer is based on a more extensive set of other if's than the questioner may have had in mind. The reason is that, in addition to the physical and geometrical parameters of the scenario in question, there are numerical parameters which may have an equally significant effect on the answer. If the user does not set them, PHOENICS uses its defaults, which cannot possibly be optimal for all circumstances.

These other if's fall into two classes, namely:

1. those which inevitably affect the reliability of the prediction, such as:
   • if the material properties, and their dependences on temperature, are accurately represented by the formulae which PHOENICS has been instructed to use;
   • if the turbulence model selected by the user is reliable in the circumstances; and
   • if the only significant influences on the phenomena in question are those of which the simulation has been informed; and
2. those which need not affect reliability, if computer resources suffice, such as:
   • if the user-chosen space-time grid is sufficiently fine to reflect the significant geometrical and temporal variations;
   • if the iterative solution process is continued until all errors in the equations are reduced to insignificant levels.

It is limitations in scientific knowledge which affect class a ; while those of class b are affected by limitations of financial resources; for computer time increases in proportion to the number of iterations; and to the number of computational cells much more steeply.

(b) Optimisation

Cost takes on especial importance when this second mode of PHOENICS use is concerned. For its question is not "what will happen if?" It is rather: "of the range of possible 'if's, which will provide the most desirable 'what'?"

To answer this question requires the exploration of very many 'if' scenarios; so the cost per scenario must be kept to a minimum.

The words used for distinguishing the two modes differ in different communities. For example, heat-exchanger specialists call prediction 'rating', and optimisation 'design'. Others refer to the former as the 'direct' and the latter as the 'inverse' problem.

From the point of view PHOENICS, demoted now from 'Oracle to 'Simulation Slave', the only difference is that it has to work harder, in the second mode, before it is allowed to rest. One run more? one run less? PHOENICS does what it is told.

2. How PHOENICS (guided by its user) does it

The first thing to emphasise is that the 'how' depends tremendously on the 'it'. To explain this essential idea, three extremely different prediction tasks will be discussed. The first is the calculation of the lift and drag forces sustained by an airplane in steady flight. The second is the determination of the adequacy of the ventilation of a car park. The third is the simulation of the flow of air, heat and pollution over a large urban landscape

2.1 The forces on an aircraft

The 'it' in this case is perfectly clear; but PHOENICS allows several possible answers to 'how?'. The question is: which of these best corresponds to its user's needs and capabilities?

(1) A user acquainted only with non-aeronautical applications of PHOENICS might suppose that it suffices to represent the airplane's shape by means of an stl file, its flight speed by upstream and downstream inlet and outlet objects, and its engine intakes and exhausts similarly; and then to choose a very fine Cartesian grid, into which the highly-non-Cartesian airplane would be fitted automatically by the easy-to-activate PARSOL technique. Then parallel-computing mode could be adopted so as to reduce the time needed to arrive at a converged solution. The following image shows an airplane in such a grid.

It is not a bad approach; and, if a very, very fine grid can be afforded, it ought to arrive at grid-independent values of the lift and drag. But its expense is very great; and even the finest affordable grid commonly fails to resolve adequately the all-important processes which take place in the thin boundary layer close to the airplane surface.

(2) Users of PHOENICS from before the years in which Virtual Reality became popular will remember that body-fitted-co-ordinate grids (BFCs), although more troublesome to create, can resolve the thin boundary layers very well.

Today's users need therefore to be positively advised that BFCs may be more cost-effective than PARSOL; and they should be provided with more assistance to create such grids to fit facet-described objects.

(3) Both Cartesian and BFC grids, in PHOENICS, are structured, with each grid node connected to six neighbours in the north, south, east, west high and low directions. This has its advantages in respect of ease of coding, and speed of computation; but its disadvantage is that it often causes too many cells to be placed where they are not needed. This is wasteful.

For this reason PHOENICS has been provided with an unstructured-grid option. This is of the 'sub-divided-Cartesian' character which, to judge by modern trends, is agreed to be more cost-effective than the 'arbitrary-polygon' kind which was fashionable in earlier years. It is commonly used in the aircraft industry.

(4) Lastly, an unusually knowledgable user might remind himself of the time before modern CFD existed, The aircraft designers recognised that, outside the boundary layer, the flow was inviscid and could be calculated by potential-flow theory; and that the effect of the boundary layer was to add to the airplane's volume a calculable 'displacement thickness'.

Why should he not use then, in combination, the PHOENICS potential-flow option for the main part of the flow and the also-in-PHOENICS 3D-boundary-layer option? How to do so is outlined in a power-point slide shown here.

(5) In summary, PHOENICS has many capabilities; but it does not yet:

• interrogate the user,
• extract from him an unmistakeable statement of what he or she wishes to know, and of much he/she is wiling to pay for it;
• and then say: "Of the many ways in which I can help you solve your problem, this is the one that I recommend".

In the future, perhaps; but not right now.

     It must therefore be emphasised that simply to open the VR-Editor and choose from its menus seldom leads to the best way of using PHOENICS. Formulating precisely what it is to be used for and then seeking expert advice, is a better practice.

2.2 The ventilation of a car park

1. The geometry (i.e. shape of car-park) is far from streamlined.
2. The scenario-setting conditions, e.g. the possible presence of a burning car, are suppositions about what might trigger the event.
3. The questions to be answered by the CFD simulation are only semi-quantitative, for example: Will the provided air-extraction system keep the smoke concentration below a regulation-defined permissible maximum? The wise user will multiply the predicted concentration by 2 or more anyway, for safety's sake.
4. Very often, the information about the geometry which has been provided in a drawing or CAD file contains vastly more detail than is relevant to the question to be answered or to PHOENICS which is to answer it.

Items (b) and (c) render it unnecessary to strive for high numerical accuracy. The heat-production rate of the fire can be no more than a rough guess; turbulence models for buoyant flows are notoriously unreliable; and external atmospheric conditions, although probably influential, have also to be fixed arbitrarily.

It is therefore wise to use a coarse computational grid, so that computer times are short; for then many runs with varying boundary conditions can explore the significance of their uncertainty.

It is item d. which makes the problem in one respect more challenging to the user than the aircraft-drag one: he/she has always to extract from the information supplied to him/her the few items which are relevant to the question to be answered. This will have been done in the simulation shown below, which concerns the computed fire spread in a spirally-shaped car part in Annecy, France. Had it not been, the computations would have been immensely more expensive: but provided no better insight.

Among the benefits of restricting computer-run times to minutes rather than hours or days is that it allows exploration of influences otherwise ignored. For example, the strength and direction of the external wind must surely affect the movement of the smoke; both ought therefore always to be included in the list of variants investigated.

How to make the extraction? It depends on how the information is supplied.

• If it is by way of drawings or files which PHOENICS cannot read itself, the task is easy. The rule is: take first only what is certain to be influential, and perform exploratory runs with that. Possibly influential ones can be tried later.
• If PHOENICS can read them, it may be easiest to inspect the geometric input by way of the VR-Editor, in order to make a preliminary assessment of what has been provided. Two extremes are: (1) the CAD file presents everything as a single named object; and (2) it presents many individual objects, each with its own list of facets.
• The latter is the easier to deal with, because it allows the objects to be considered, accepted, or removed, one after another. Therefore it is sometimes desirable to use DatMaker to convert the input data from form (1) to form (2); for this can be used for merging or subtracting objects.
• As to what to merge or subtract. it is useful to observe, but often not acccept, the default settings of PHOENICS, particularly the object-affects-grid ones. When they are accepted, the presence of an array of small objects, such as air-extraction apertures, inevitably entails use of a very fine grid; with all its computer-expense consequences. Yet an equally-realistic flow simulation can be achieved, with a much coarser grid, by representing the array of objects by a single patch having the same overall effect.
• Such simplification can be taken, by those who employ the VR-Editor for all their data-input actions, simply by removing the ticks on the screen below; or, better still, deleting the sub-grid-scale objects. Thereafter a single large inlet~outlet object can be introduced which will have the same overall effect.

• Users who have learned enough of the PHOENICS Input Language (PIL) to employ parameterised Q1 files can make such changes more directly.

Current development work at CHAM is directed towards making this coarse-grid representation a switch-on option. Meanwhile, users uncertain about how to make the change should ask CHAM's User Support.

2.3 The urban landscape

PHOENICS is often used for making simulations such as that below, with a streamline animation followed by a plan view of the grid.  

It has to be said however that, although many hours of computer time may be spent, the reliability, and therefore usefulness, of the calculation often leave much to be desired.

There are several reasons for this, namely:

• Such scenarios always involve the presence in the domain of many buildings, and other possibly-significant items; and, if the user unreflectingly supposes (as experienced CFD users do not) that what exists in reality must also be included in the CFD model, only a very fine grid will do so. Computer times will be correspondingly large.

• Large computer times mean few runs; therefore some possibly-significant influences may not be explored at all; for example those of:
  • temperature stratification in the surrounding atmosphere,
  • rainfall,
  • time of day, and
  • any of the "other if"s referred to above.

• Often the purpose of the simulation has not been explicitly expressed beforehand, perhaps because whoever commissioned it had been led to suppose that CFD stands for Complete Full Disclosure. "Tell me all" they have , by implication, commanded PHOENICS. "Then I will decide which items interest me".
  Such persons get something approximately, and nothing reliably.
  Only those who express their needs explicitly may get what they want.

• Sometimes the purpose of the simulation is to find out what will be the wind velocity, at pedestrian level in the neighbourhood of a particular building, but the size of computational cell in its vicinity is not the small fraction that it needs to be of the distance between buildings to ensure even order-of-magnitude correctness. This is because, when a structured grid is employed, small cells there entail small cells elsewhere as well; for which the available computer capacity may not suffice.
      What then is needed is a 'successive-focus' strategy, which involves a succession of PHOENICS runs in which each takes in the results of its predecessor and focusses its attention on a smaller volume surrounding the location of special interest,
      PHOENICS does possess a utlity which embodies such a strategy. The module which needs so be activated is SPINTO. It has existed for several years, but little used, chiefly because it could not be activated from the VR-Editor which, for many users, has been their only means of telling PHOENICS what to do.

• It should be noted however that SPINTO has two distinct aspects, nowadays distinguished as SPINTO-TS (for time-saving and SPINTO-MA (for maximising accuracy) which is involved in the 'successive-focus' procedure.

• Often the purpose is to compute the spread of pollutant from a upstream source into its surroundings; and often it is required to do so for several different wind directions.
      In this case the PHOENICS-Direct SimScene, arranges that the grid is rotated relative to the geographical co-ordinate system so that one set of the horizontal grid lines is aligned exactly with the wind; for otherwise the well-known phenomenon of numerical (i.e. false, non-physical) diffusion is likely to predict far too great a rate of spread.

      The following two diagrams illustrate the problem and one of its possible ameliorators. The one on the left shows how, in the absence of any physical difusion whatever, the default 'upwind difference scheme' of PHOENICS causes the 'pollutant plume' to spread. The second shows the reduced but still finite rate of spread when one of the many 'higher-order schemes' built into PHOENICS is activated.
  

  

      The true result would be a thin band of contour lines, of constant concentration and unchanging width, stretching diagonally across the domain. Only one of the schemes can achieve this, the unique-to-PHOENICS CLDA scheme; and this is not accessible from the VR-Editor menus. None of them are switched on automatically; and few are ever used.

      Aligning the grid with the wind-direction is also an alternative near-perfect solution; but only the Urban-Virtual-Wind Tunnel SimScene provides this automatically.

• A final reason, it is sometimes said, is that town-planning licensing authorities, lay down regulations as to what minimum cell size should be adopted for the resulting calculations to be acceptable. If it is so, those authorities should be reminded that to specify a minimum cell size everywhere leads to reduced reliability of the desired outcomes; and that, as explained above, it diminishes the extent to which other significant variants are explored.
      What knowledge town-planning authorities have of numerical diffusion is also questionable. Only, it seems probable, that which their CFD specialists have imparted.

3. Desirable background knowledge

PHOENICS can be used successfully by persons of varied experience and background; however, the probability of success is greatest if they are already familiar with the general features of computer simulation of flowing continua; in particular, they should be aware of the following:

• that the continua of Nature must be represented in a digital computer by 'discontinua', i.e. by sets of discrete volumes of space retaining their properties for discrete intervals of time;
• that the predicted behaviour of the hypothetical discontinua will be close to the actual behaviour of Nature's continua only if the volumes and intervals are numerous enough to reflect the steepness of variation in space and time of the characterising properties (e.g. temperature, or velocity);
• that, because of the non-linearity of the physical phenomena which are being simulated (in most cases), or because of the large numbers of equations requiring simultaneous solution (in other cases), iterative procedures of solution must ordinarily be employed;
• that iterative procedures do not invariably converge (i.e. arrive in the end at the solution), and may require user-intervention before they do so;
• that, either because of the round-off limits of the computer, or because the iteration process is prematurely terminated, the solution yielded by a computer program will differ somewhat from the true solution of the equations governing the discontinua;
• that to compute solutions to the discontinua equations which are very close to the solutions of the continuum equations therefore entails greater costs than providing approximate solutions, because both accuracy and cost increase with the number of volumes, with the number of time intervals and with the number of iterations;
• that providing computed solutions which are close to those for the continuum equations is still not the same as simulating physical reality, the success of which depends additionally on: the validity (i.e. truth to Nature) of the continuum equations themselves; the appropriateness of the information concerning material properties; and the correctness of the formulation of the initial and boundary conditions;
• that, as a consequence, the use of computer codes for the simulation of flow processes is an art as well as a science; for it concerns the creation of significant abstracts from reality, which have most merit when they can economically and rationally persuade experienced persons to base their decisions and actions upon them;
• and finally that credibility, economy and relevance to important practical concerns are all qualities that the simulation specialist values highly.

4. Why caution is needed

The ideal user of PHOENICS has been identified in this way in order that, should less experienced persons use it, they should have received due warning that computer simulations of fluid flow differ appreciably from calculations of the kind which are customary in, say, structural engineering or in rigid-body dynamics.

In the those fields, non-linearities are often of secondary importance, if indeed they are present at all; the computer code can therefore be left to produce the solution automatically.

Fluid-flow phenomena, by contrast, are essentially non-linear; so the user of a flow-simulating code must reconcile himself to having, on occasion, to help the code along, using his intuition and experience in the selection of the 'switches' and 'tuning knobs' of the solving procedure.

The final solution itself, i.e. the result of the solving procedure, of course must not depend upon the settings so chosen, any more than the scenery at the port of destination can depend upon the course which the ship's navigator selected.

It is WHETHER the solution is arrived at, and HOW SWIFTLY, that these steering adjustments may beneficially influence.

PHOENICS does already possess a primitive EXPERT system for making optimal adjustments of the numerical parameters as the calculation proceeds; and this auto-pilot feature is being further developed by CHAM. However what has been stated above remains true: the user of PHOENICS, or of any other CFD code, should never trust their predictions blindly, or expect them to proceed efficiently regardless of how injudicious are the user's settings.