What's new in PHOENICS October 2006

Summary

This document describes changes made between PHOENICS version 3.6.1 and 2006. The much
greater changes between PHOENICS 3.5 and 3.6.0 and 3.6.1 are described in an earlier
version of this document, here.

The location of the PHOENICS installation is now held in an environment variable. This
makes it possible to install PHOENICS into any convenient location, not just the root of a
drive. It also makes network installations neater, as only the environment variable and a
working directory need be present on client machines.

The handset buttons are now repeated on the tool bar. Either or both handsets can be
closed retaining full control. The open/closed status of the handsets is held in
phoenics.cfg between sessions. There is also more detailed control over which icons appear
on the toolbar.

Text can be added to annotate the image.

The domain axes can be positioned anywhere. Previously, they were always drawn at the
domain origin. This location could be off-screen, or obscured by objects within the
domain. The axes can now be located at any position on the screen.

A larger font size is used for dialogs to make them more legible.

It is possible to turn the hardware acceleration of the graphics card off with a switch
in the CHAM.INI file. On some systems, with some graphics cards/driver versions, the
hardware acceleration can cause corruption of the image. Typical examples are failure to
refresh the part of the image exposed when a dialog box is moved, or failure to draw the
title and contour scales properly.

An auto meshing feature has been added. For most cases the Editor will generate a
reasonable grid with little or no user input. The grid distribution is based on a maximum
cell size (as a fraction of the domain size), and a maximum change in cell size across
region boundaries. The default grid can then be easily refined as shown below:

New ANGLED-IN and ANGLED-OUT object types have been created. These allow inlets and
outlets to be placed on the outer surface of any arbitrarily-shaped blockage. The active
Inlet/outlet area is the area of intersection of the ANGLED-IN/OUT object with any
blockage object. In the image below a cylindrical ANGLED-IN object is intersecting a
quarter-cylinder blockage.

The inflow can be specified as Cartesian velocity components (as above), velocity
normal to the blockage surface (as below), or as volume or mass flow rate.

The treatment of Polar geometries has been significantly updated. In polar co-ordinates,
X is q, the angle, Y is r, the radius and Z is z, the axial
distance. For objects using the default 'polcu' geometries, the size is set in (dq,dr,dz) and position in (q,r,z) as
before. For non-'polcu' geometries, including STL imports, size is in (dx,dy,dz), but
position is still in (q,r,z). As the Cartesian size is used,
the shape and size of the object are preserved with no distortion, as shown below.

The treatment of INLET objects in Polar co-ordinates has been improved. The inflow can
now be specified as:

Cartesian velocity components

Polar (grid-directed) velocity components

Volumetric flow rate

Mass flow rate

The 'Slide velocity' can be set for blockages as well as for plates. By setting the
surface velocity, a range of cases involving steady movement can be treated as
steady-state. In Cartesian co-ordinates, there is a 'Spin' option which sets the surface
velocity as if the object were rotating about its axis.

In Polar, the slide velocity can be in m/s or rad/s. The following image shows a bar
being pulled at constant speed through a Polar domain:

The input for multiple STL import is now taken from a multiple-file-selection dialog not
from a list-file as previously.

For MOFOR, the MOF files controlling the motion can be created and edited directly from
the Sources page of the Main menu.

The Editor can output the entire geometry in TECPLOT format. Each object is shown in
TECPLOT as a 'zone'. A TECPLOT macro is also written which sets common flags and performs
common data manipulation, such as calculating absolute velocity, and performing Cartesian
- polar transformations. In total, 3 files are involved. TECGEOM.DAT (containing the
geometry) and PHOENICS.MCR (the macro) are written by the Editor. TECDATA.DAT (containing
the solution) is written by the Earth solver. The image below shows the geometry for an
offshore platform (approximately 120 objects) exported to TECPLOT 10.

When PARSOL is active, the cut cells are calculated properly for polar geometries.

For buoyancy-driven flows, the effect of buoyancy on turbulence can be significant. In
stably-stratified flows, such as smoke layers, turbulence can be damped. Conversely, in
the vicinity of plumes, the turbulence can be enhanced. These effects are implemented in
the K-e models via an additional source term. The choice
between stable or unstable stratification was previously made by setting a constant to 0.0
or 1.0, and so could never be universally correct.

An 'auto' function has been
introduced which switches between the stable and unstable forms depending on the local
flow direction. This should produce better results for cases with zones of both stable and
unstable stratification.

The 'auto' option is now the default for new cases set via the Editor, but constant
values can still be set from the Main Menu - Sources panel.

The solution can be output in TECPLOT format. An output file, TECDATA.DAT, containing
two TECPLOT zones for each PHOENICS domain is written. One zone is contains data at the
cell centres (adjusted for PARSOL cut cells), and one contains data at the cell corners.
The first is better for plotting vectors, the second for plotting contours and
iso-surfaces. The image below shows the geometry and solution from Library case V146
displayed in TECPLOT 10.

Domain partitioning via Transfer objects.

The domain-partitioning technique is useful
for computer simulation of flow phenomena characterised by a predominant direction of
flow, as for example when several chemical-plant vessels are connected in series, as
sketched below, the flow being always from left to right.

It is of course possible, with sufficient computer memory, to simulate all three
vessels, and the pipes and spaces between them, at the same time; but it is seldom either
necessary or cost-effective to do so; for there is usually no significant influence of
happenings in downstream vessels on those in upstream ones.

A similar situation arises when it is necessary to simulate the flow over an extensive
tract of terrain, for example a complete city or a wide forest. Partitioning is then
possible because usually the direction of wind varies little from place to place.

Thus, if the wind blows predominantly from the north west over the area of
land indicated below, the sub-areas marked 1, 2, 3, etc below can be simulated separately
but in sequence, if the output from an earlier calculation is stored for use as input to a
later one.

When it is desired to take account in the simulation of the shapes of individual
buildings in the city, or of fire-breaks traversing the forest, the computer-memory
requirements could not be met by commonly-available machines if the whole region were to
be simulated at once.

The domain-partitioning technique however does permit the simulation to be performed by
computers of modest size, by splitting the whole terrain into parts which are sufficiently
small to be handled by the available computer; and it then causes the parts to be
simulated one after the other, the upwind ones being considered first.

At the end of each calculation, data describing the flow conditions on the downstream
boundaries are placed into files which serve as 'transfer objects'; for the data can then
be imported as upstream-boundary data for the later-to-be simulated next-downstream part.

The first image shows the smoke distribution in a room with a fire. The open windows
are treated as 'export' objects.

The next image shows the flow around the outside of the building the room is in. The
building itself is a blockage. The flow from the windows, saved in the first run, is now
used as the inlet condition via 'import' objects. Around the corner from the first room is
a second room with open windows, set as outlets. The flow through them is saved via
'export' objects.

The final image shows the flow in the second room, which uses the saved window
mass-flows from the second run.

It has this been possible to calculate the three parts separately with grids suitable
for each part whilst maintaining the linkage between them.