Click for contents list.

What's new in PHOENICS October 2006: TR006

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.

Contents

Changes Common to VR Editor and VR Viewer

Changes to VR Editor

Changes to the Earth Solver

Changes to VR Viewer

Changes Common to VR Editor and VR Viewer

• 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.

Changes to VR Editor

• 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.

Changes to the Earth Solver

• 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.

       ---------------        ---------------        -------------
       |             |        |              |       |           |
       |             |        |              |       |           |
       -   vessel 1  ----------  vessel 2    ---------  vessel 3 ---------
       -             ----------              ---------           ---------
       |             |        |              |       |           |
       |             |        |              |       |           |
       ---------------        ---------------        -------------
          upstream  >>>>>>> direction of flow >>>>>>>>  downstream
                                                         

  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.

                        North
        |----------|---------|---------|---------|--------|--------|---
        |          |         |         |         |        |        |
        |    1     |   2     |   3     |    4    |   5    |   6    |
    West|          |         |         |         |        |        |
        |          |         |         |         |        |        |
        |----------|---------|---------|---------|--------|--------|---
        |          |         |         |         |        |        |
        |    7     |   8     |   9     |    10   |   11   |   12   |
        |          |         |         |         |        |        |
        |          |         |         |         |        |        |
        |----------|---------|---------|---------|--------|--------|---
        |          |         |         |         |        |        |
        |    13    |   14    |   15    |    16   |   17   |   18   |
        |          |         |         |         |        |        |
        |          |         |         |         |        |        |
        |----------|---------|---------|---------|--------|--------|---
                                               

  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.

• Various bug fixes have been implemented.

Changes to VR Viewer

• When PARSOL is active in Polar co-ordinates,  the contours and vectors in the cut cells are displayed correctly.

• When cyclic boundary conditions are active, an extra tab appears on the Viewer Options dialog, from which it is possible to repeat the image in X direction as many times as wanted.

• For selected objects, the surface contour values can be output to a file which can be read into Excel or Autoplot.

• For selected objects, a surface profile on the current plotting plane can be output to a file which can be read into Excel or Autoplot.

• The palette for contour plots can be reversed.

• The size of the saved image can be controlled from a macro file.

• Many internal efficiencies have been implemented to speed up the plotting of large cases.

• The vectors can be plotted in any user-selected single colour.