Encyclopaedia Index

What's New in PHOENICS

Document last revised: 13.03.13

Changes made between November 2011 and January 2013

Details about new changes to the VR Editor and solver are reported here.

1. The general trends

The "New Trends" of 2011 have continued with increased concentration, momentum and practical effect.

In respect of concentration, attention is now focussed on three classes of PHOENICS user, namely:

  1. End users, who wish to have 'simulation engines' designed for their specific closely-defined applications. These are the diners in the 'PHOENICS Restaurant', who choose from the menu what suits their appetite; and who pay the bill at the end,
  2. Creative users, who provide the specialised packages which the end users employ. They are the cooks who prepare the familiar dishes; and some of them are chefs who create never--before-tasted ones.
  3. Do-it-yourself users, who are content to use the long-established VR-Editor so as to set up problems on their own.

Of the End-User class the following may be said:

For the do-it-yourself users, PHOENICS has been improved in various manners, an overview of these changes are listed in the 2012 What's New report. For example a 'sun object' has been introduced.

However, no fundamental reduction has been made in the VR-Editor's limitations. It remains as a single-instance-run launcher; and it is still unable to assist its users to exploit the full powers of the PHOENICS Input Language, PIL.

It is for the Creative-User class that the greatest new benefits have been provided, Specifically:

In summary, it would be no exaggeration to state that PHOENICS underwent a radical change in 2012; and prospective not-yet-users may find that that these changes have increased its attractiveness.

Other developments during 2012

Work in progress, 2012-2013

Changes made between September 2010 and December 2012

For more details about the following changes click here.



Earth Solver

There have been many modifications to EARTH. A full double-precision version of the EARTH solver is now available. In some cases this converges much better than the standard single-precision version. This is especially true for transient cases where the domain is huge and not much is happening. The price is doubling the memory requirement.

The normalised residuals displayed on the monitor screen have been a cause of wonder and amazement for some time. The idea – to normalise the errors by the sums of sources and fluxes – was good, but the implementation was suspect. Residual values of a thousand % were common, and the normalised error increased as the number of cells increased. PHOENICS-FLAIR users have the CONV_TABLE.CSV file which contains the errors normalised by the inflow fluxes. The problem with the internal normalisation has been fixed, so that the normalised residuals are now a much-improved reflection of the level of convergence.

The old normalisation produced: The new normalisation produces:
Whole-field residuals before solution at sweep 400
with resref values determined by EARTH & resfac=1.0E-06
Whole-field residuals before solution at sweep 400
with resref values determined by EARTH & resfac=1.0E-06
variableresref (res sum)/resref(res sum)
variableresref (res sum)/resref(res sum)

The actual residual is almost the same, but the normalised value is very small and more like that in CONV_TABLE.CSV.

There have been three modes of operation for the graphical convergence monitor:

It has always been possible to switch mode during the run, but the graph only switched at the moment of changing, so the previous values were not displayed. All monitoring values for all three modes are now held, and when the mode is changed the entire graph is redrawn in the new mode. It is possible to set a flag (Options, Solver Monitor Options) to have images of all three modes saved at the end of a run.

Some further changes and bug fixes include:-


The SUNLIGHT feature was created in 2010 in response to the demand from users for a HeatIsle module. The prototype for which is described here. This has now been updated to improve its flexibility.

The preliminary version was accessed through the WIND object dialog, and had several limitations:

An updated version is now ready for release. The main improvements made are:-
  • No longer accessed through WIND, there is a separate SUN object.
  • The required inputs can be read from a standard EPW Weather Data File. The fields read include:
  • A link to the EPW site is provided for easy download of weather data files.
  • The WIND object can take the wind speed and direction from the same weather file.
  • The transient operation has been improved.
  • The amount of incident solar radiation absorbed by each object in the scene can be set by the user.
  • BLOCKAGE and PLATE objects have an extra ‘Solar absorption’ input box which allows the absorption factor for that object to be set. For most substances the absorption will be 0.5 or greater. Bricks, weathered steel or marble can be up to 0.9. Polished metal surfaces can be 0.1 – 0.2.
  • The user no longer has to ensure that objects are facetted in order for them to be picked up by the illumination algorithm.
  • The illumination algorithm will detect PLATE objects as well as BLOCKAGEs
  • The following additional output variables can be activated directly from the SUN object dialog: These can be used to check the correct functioning of the illumination model.
  • Conditions can now be taken from a weather file and applied directly. Having created a SUN object, open its attribute dialogue to use and configure a weather data file. The default browser will open the Energy Plus site from where the weather data file can be selected and downloaded [if you do not have a weather file, clicking on 'Start browser' will enable you to download one]. Once selected, the data file can be loaded directly into the VR Editor.
  • The WIND object can also use the weather data file

    DATMAKER and CAD conversion

    The facilities for repairing and manipulating CAD data during and after import have been improved . The new DatMaker utility can:

    Often problems with geometry detection can be eased or removed by merging several touching or overlapping objects into one. The same applies to subtracting an air space from a surrounding blockage. DatMaker is now used by default when importing single or multiple CAD files, to translate the CAD to DAT format. The supported formats are, as before :-

    STL-Stereo lithography file available in many popular CAD programs as an export format.
    DXF-Drawing Exchange Format File (AutoCAD)
    3DS-Autodesk 3ds Max
    WRL-Virtual Reality Modelling Language file
    DW-Files generated by DesignWorkshop from Artifice
    AC-Files generated by AC3D from Inivis
    IV-Files generated by Open Inventor

    DatMaker can also be used to perform operations on objects already created in VR. Existing objects can be merged, split or subtracted. (1) Here there are 5 air blockages making a channel through a hidden solid; (2) then merged into one object; and (3) now subtracted from the solid leaving a channel.


    A further utility already built into PHOENICS is called AC3D from Inivis. As well as creating shapes from scratch, AC3D can import a variety of additional formats that can be exported in the native .DAT format used by PHOENICS. Alternatively, products such as Okino NuGraph can also import, repair, convert and export a variety of formats, including the 3DS format readily accepted by PHOENICS.

    AC3D from Inivis a range of output/input formats OKINO NuGraph supports:
    FormatFile ext
    3D Studio.3ds
    Obj (Wavefront).obj
    STL (ascii).stl
    VRML 1.0.wrl
    VRML 2.0.wrl
    FormatFile ext
    3D Studio.3ds
    3Ds max.max
    Alias triangle.tri
    Cinema 4d.c4d
    DXF R12
    Solid Edge.ldr
    Solid Works.dat
    PRO Engineer.mpd


    HIGHLIGHTS from the previous update

    Here follow some improvements made in the previous release which are worth mentioning again, in case they have been missed. In the VR-Editor:-

    In the EARTH solver of PHOENICS/FLAIR, the ‘Calculate link temperature’ and ‘Activation temperature’ settings for a SPRAY_HEAD object activates automatically the spray when the activation temperature is reached. In previous versions, a message was written to RESULT when the criterion was met, but the spray was not activated automatically. A table file containing the calculated link temperatures at the end of each step is also produced.

    For details of these previous updates Click here