Encyclopaedia Index


Click for contents list.

What's new in PHOENICS-3.5.1: TR005


Many changes have been made in PHOENICS since the release of version 3.5.0 .

Several concern the better simulation of fluid-structure interactions, the three main aspects of which are:

  1. PARSOL, which enables bodies with curved surfaces to be smoothly represented on cartesian grids;
  2. MOFOR, which allows bodies to move through such grids; and
  3. SFT, which allows the stresses in solids to be computed simultaneously with the velocities and pressures in the fluids in which they are immersed.

Others concern data-input and results-display procedures, both in respect of:

  1. The input of data by way of formulae (In-Form); and
  2. The graphical user interface.

In addition, new utilities have been provided; and others have been improved.

  1. Fluid-structure interactions
    1. Curved surfaces in cartesian grids, PARSOL
    2. Moving frames of reference, MOFOR
    3. Solid-fluid-thermal analysis, SFT

  2. Data-input and results-display improvements
    1. Data-input by way of formulae
      1. Prescribing the motion of moving objects
      2. Ascribing arbitrary sources to objects
    2. The Virtual-Reality interface, VR

  3. New and improved utilities
    1. The PHOENICS Commander
    2. FacetFix
    3. ShapeMaker
    4. Nu-PHOTON

  4. Concluding remarks

1. Fluid-structure interactions

1.1 Curved surfaces in cartesian grids, PARSOL


The PARSOL "cut-cell" technique has been available in PHOENICS for several years; and it offers the great advantage over the use of body-fitted-coordinate grids that the mesh-creation problem, which is often an extremely burdensome part of a flow-simulation task, disappears completely.

Nevertheless, PARSOL has not been used quite as often as its authors expected, for several reasons, namely:

What has been done

Conjugate heat transfer was brought within the scope of PARSOL already in version 3.5.0; and CHAM has given much attention to ensuring that version 3.5.1 is free from the second and third deficiencies.

So successful has this recent work been that CHAM has arranged for PARSOL to be switched on automatically, whenever objects are found in the flow field of which the surfaces cut cell-edges anywhere except at cell-corners.

Users are however allowed to switch PARSOL off, if they wish to see what difference it has made.

How it was done

As a consequence, flows around rather complicated shapes can now be easily performed, as shown by the following images of air flowing through an array of louvres: velocity vectors and velocity contours.

Go to contents, #1, #2, #3, #4

1.2 Moving frames of reference, MOFOR


The MOFOR feature of PHOENICS made its first appearance in version 3.5.0, which version could aleady perform calculations of the kind illustrated here for a ski-jumper, and here for an under-water missile launch.

However, there were several limitations on what MOFOR could do, including:

What has been done

As has already been mentioned, PARSOL now can now be used for both fixed and moving bodies; and the other limitations have also been removed.

In respect of the last of the four, the facility has been provided for specifying the motions of the bodies by way of formulae; so BVH files (renamed now to MOF files) need not be used at all (although they still can be).

How it was done.

The main components of the work were:

What has not yet been done

Because of the extreme and careful attention to detail which such work entails, several desirable and undoubtedly possible features have not yet been implemented. They include:

Go to contents, #1, #2 #3, #4

1.3 Solid-fluid-thermal analysis, SFT


SFT, the ability of PHOENICS to calculate stresses in solids and flows in fluids simultaneously has been available for many years.

What it can do is illustrated by the following images from an earlier lecture.

Similar images relating to an axi-symmetrical geometry can be seen here.

Nevertheless, despite (or perhaps because?) the SFT feature is unique to PHOENICS, it has not received attention commensurate with its importance.

There are several reasons for this, including:

In respect of the last-mentioned deficiency, however, it has been recognised for two years, that there is another algorithm having better convergence properties; and only lack of resources has prevented its exploitation.

What has been done

The new algorithm has however been implemented in version 3.5.1 .

What it mainly involves is solving three additional equations, within the solid region, the dependent variables of which are the three components of vorticity, whereby it must be understood that these vorticities are defined in terms of displacements, not velocities.

The advantages over the formerly-used (and still available) SIMPLE-based algorithm are:

An example

That bending phenomena can now be handled satisfactorily is shown by the displacement and velocity vectors shown here.

The relevant commands in the Q1 file are few. They represent the application of a torque at the end of the beam.

It will have been noticed that the action of the end torque was transmitted by way of two In-Form statements, one acting on the end of the beam and the other distributed along its length.

If the loading is more complex, so will be the In-Form expressions; but no matter. EARTH can handle them.

How it was done.

The following four steps had to be taken:
  1. Providing for the solution of the vorticity components, and the storage of the dilatation (which is still needed, but not as a solved-for variable).

    This task was trivial; for the vorticity equations are Laplace-like, with simple load-related sources.

  2. Providing a PIL variable, CONVAC (standing for convergence acceleration) which, when set TRUE in the input file, activates the new algorithm.

    This was also trivial.

  3. Providing coding for the sources in the displacement equations for the solid-boundary cells.

    This required much care.

  4. Ensuring that all coefficients in the displacement and velocity equations were correct in near-solid-boundary cells.

    This was even more demanding, because of the large number of ways in which near-boundary cells can adjoin.

What has not yet been done

The immediately-to-be-done items include:

More distant tasks, none of which presents any difficulty of principle, include:

Go to contents, #1, #2 #3, #4

2. Data-input and results-display improvements

2.1 Data-input by way of formulae, In-Form


All CFD code-vendors recognise that they cannot provide all the flow-simulation features which some users will require. Some therefore, following CHAM's lead of 1981, most vendors now permit their users to supply their own Fortran- or C-language subroutines.

CHAM's now-ten-years-old PLANT feature went further, by enabling PHOENICS itself to write error-free Fortran, on the basis of formulae provided by the user.

The (so far) final stage of user-empowerment has been CHAM's introduction of In-Form, which does all that PLANT could do without requiring any new coding at all.

In-Form enables (almost) arbitrary specifications of data to be supplied to CFD (or SFT) simulations by way of formulae typed into the input file (Q1).

It was first introduced with PHOENICS version 3.4; and it has increased in power with each new release.

Here the two main developments in version 3.5.1 will be described.

(a) Prescribing the motion of moving objects

Of the two main new developments, one has already been described: In-Form allows the motion of an arbitrary number of 'objects' to be described.

The following extracts from library case 360 illustrates the capability.

First, the In-Form MOVOB command dictates how the three position and three orientation coordinates vary with time, by way of character strings.

 TEXT(MOFOR by In-Form: 2D motion of 2 objects
  Echo InForm settings for Group  7
   ** Definition of the VR moving objects by In-Form
vel=10.; gravt=9.81; times=tim
(MOVOB of SPHERE1 is POS(:times:*:vel:&:times:*:vel:-0.5*:gravt:*:t$
(MOVOB of SPHERE2 is POS(-:times:*:vel:&0&0&0&0&0))

The next line says: "Don't look for a .MOF file".


Finally the two objects, SPHERE1 and SPHERE2, in their start-of-process positions, are defined in the usual way, as follows:

> OBJ,    NAME,        SPHERE1
> OBJ,    POSITION,    0.000000E+00, 0.000000E+00, 0.000000E+00
> OBJ,    SIZE,        1.000000E+00, 1.000000E+00, 1.000000E-01
> OBJ,    CLIPART,     cylinder
> OBJ,    ROTATION24,        1
> OBJ,    GRID,              2
> OBJ,    TYPE,        BLOCKAGE
> OBJ,    MATERIAL,       -1
> OBJ,    INI_PRESS,     0.000000E+00
> OBJ,    SCAL_FIXF,     0.000000E+00

> OBJ,    NAME,        SPHERE2
> OBJ,    POSITION,    2.100000E+01, 3.000000E+00, 0.000000E+00
> OBJ,    SIZE,        1.000000E+00, 1.000000E+00, 1.000000E-01
> OBJ,    CLIPART,     cylinder
> OBJ,    ROTATION24,        1
> OBJ,    GRID,              2
> OBJ,    TYPE,        BLOCKAGE
> OBJ,    MATERIAL,       -1
> OBJ,    INI_PRESS,     0.000000E+00
> OBJ,    SCAL_FIXF,     0.000000E+00

Graphical vector plots for case 360 are shown on, for successive time instants, by the following hyperlinks:

inst 1, inst 2, inst 3, inst 4, inst 5, inst 6, inst 7, inst 8, inst 9, inst 10, inst 11, inst 12, inst 13, inst 14, inst 15, inst 16, inst 17, inst 18, inst 19

(b) Ascribing arbitrary sources to objects

The second major In-Form development has been the provision of means of ascribing arbitrarily-complex sources to VR-objects.

How it works

In-Form statements created by the user, whether concerned with motion, sources, or any other of the various data-input possibilities, work by transmitting character strings to the EARTH solver module by way of SPEDAT commands.

These commands are written by the SATELLITE module into the EARDAT file in a form which depends on the keyword ... MOVOB, SOURCE, INITIAL, STORED, PROPERTY, etc ... which starts the In-Form statement.

The first action of the EARTH module, when it reads EARDAT, is to parse the character string, deduce therefrom what mathematical operations are to be performed, and to set the appropriate switches.

No new Fortran or C source coding is created; therefore there is no need for re-compilation.

What has not yet been done

In-Form having been invented after the main structure of the VR-Editor was consolidated, its potential cannot yet be fully exploited by the dialogue boxes of the Editor.

There exists however a Tcl/Tk-based In-Form editor which is accessible from the VR-Editor; and this provides limited assistance in the writing of In-Form statements.

Work is in progress to improve this editor by providing:

It is intended that the In-Form editor will be extended so as to make good other shortcomings of the VR-Editor in respect of PIL features such as declarations, logic and file-handling, as well as facilitating the use of CHEMKIN.

Go to contents, #1, #2 #3, #4

2.2 The Virtual-Reality interface, VR

So many changes have been made so as to improve the appearance and functionality of the VR-Editor and -Viewer that it is practicable here merely to list them, as below.

However, so as to connect with an earlier topic, it may be mentioned that the second feature in the list, namely animation, has proved to be especially valuable for the display of the results of calculations which use MOFOR.

Go to contents, #1, #2 #3, #4

3. New and improved utilities

3.1 The PHOENICS Commander

Its nature and purpose

The formerly-existing PHOENICS Manager and PHOENICS Commander have been merged into a new single Commander utility, which performs all the functions of its predecessors, and many more.

It has been designed with new users of PHOENICS especially in mind, as is evidenced by its top panel, which is also that which appears when the new-user button is pressed.

All PHOENICS modules, utilities and information sources can be activated by way of the buttons which are provided on the various panels described in the descriptive document.

The input-file-library search facility

Particularly useful is what is revealed when the input-file-library button is pressed; for this provides further buttons which activate a library-search facility.

There are many hundreds of items in the library; but hitherto finding which ones exhibit a particular combination of features has been a wearisome task.

With the new 'search-engine', a user may call for all those cases which are, for example:

A complete list of such cases then appears in an HTML file with links to the Q1s and Q1EARs.

How it was created

The Commander has been created with the aid of the Tcl/Tk language, for three main reasons, namely:
  1. The power of TCL/Tk rendered it easy to construct and refine;
  2. it provides the same functionality and appearance in both Windows and Unix environments; and
  3. access to the underlying easily-editable ASCII files allows suitably knowledgable users to modify its functionality and appearance.

The editability can be recognised by looking at, for example, the file which organises the buttons of the run_In-Form_cases panel, namely /phoenics/d_satell/d_men/tcl/informed.tcl.

Evidently it is very easy to changes the numbers of the library cases which can be run and the words which describe them.

Go to contents, #1, #2 #3, #4

3.2 FacetFix

The aim of the new FacetFix utility is to provide a means of examining, and if necessary repairing, files which describe solid bodies by way of triangular or quadrilateral facets, such as are provided by CAD packages, for example in STL (i.e. stereo-lithography) format.

The program was created because the CAD packages used by architects do not necessarily either:

PHOENICS requires that facets should have a direction sense in order that it can know on which side is the fluid and on which the solid; and of course facets which share an edge should be in agreement on the matter.

A further PHOENICS requirement is that the facets defining an object should, taken together, form a completely closed surface, such as is possessed by every real solid body.

FacetFix takes in defective STL files, enforces consistency, adds facets so as to create complete surfaces, and produces the corresponding .dat files which are needed by the PHOENICS Virtual-Reality User Interface. It can do the same for defective .dat files also.

The unrepaired and repaired files can be examined and compared in AC3D to establish that any faults have been repaired

Go to contents, #1, #2 #3, #4

3.3 ShapeMaker

The ShapeMaker utility has been improved and extended in the following respects:

Go to contents, #1, #2 #3, #4


Because the VR-Viewer is now capable of all (or nearly all ; it cannot show displacements in solids) that PHOTON could do, and more, by way of graphical display of results, the PHOTON delivered with PHOENICS 3.5.1 is unchanged from its immediate predecessor.

Nevertheless a Nu-PHOTON package has been developed by CHAM, with the following features:

4. Concluding remarks

It will be apparent that version 3.5.1 is significantly superior to all previous versions of PHOENICS in several important respects.

What deserves particular emphasis, however, is the great potential offered by the new features when they are brought simultaneously into action. Thus it may be envisaged that, in the near future, PHOENICS will be enabled to simulate:

Some of these can certainly be achieved within the next twelve months. Version 3.5.1 provides for them an excellent foundation.

Finally, it should be mentioned, existing and future users can themselves accelerate the development process by:

CHAM will certainly be grateful for all such progress-promoting interaction.

Go to contents, #1, #2 #3, #4