The 'engine' is CHAM's PHOENICS software package; and this is an embodiment of the science of Computational Fluid Dynamics. SimScene users however need no knowledge of these.
A SimScene can be thought of, by analogy with the 'apps' which abound for smart-phones and tablet computers, as an 'App for PHOENICS'. The following slide from a recent lecture illustrates the concept:
A SimScene consists a package of unique-to-it text and graphics files, together with the needed-by-it members of the general PHOENICS family. There is no need for the ordinary SimScene user to know anything about these; but the more-inquisitive few will find a brief description here.
1.2 A preliminary list of Simscenes Currently-available SimScenes include those which may be seen by clcking on the following hyperlnks:
Activating the file start.bat in the main folder of the SimScene launches a SimScene run, which brings to the screen an image such as (for the Labyrinth SimScene) the following:
The content of the central part of this 'top page' of Labyrinth, is the start of a descriptive document which is specific to it. The buttons and tabs along the top of the page, however are present in all SimScenes; and is their functions which will be explained in this 'how-to-run' document.
A mouse-click on the second tab, 'Inspect or modify input data', evokes the following image:
This is the first of several menus, by means of which the user enters, in the white boxes, the parameters which he selects.The entries may be numbers, character strings or algebraic expressions; and in some cases, indicated by the presence of the downward-pointing arrow, they may chosen from a displayed pull-down list.
The menu shown is that named 'geometry'; and others may be activated by clicking on the other names in the list on the left. The contents of the white boxes are the defaults of the Labyrinth SimScene.
However, so extensive have become its powers that 'learning-to-use-PHOENICS' has become a dauntingly complex and time-consuming task. In respect of PHOENICS as it was until recent years, the task can be begun by clicking here.; but there is much more now.
These have simple menu-type interfaces, which address the user in terms which he or she can reasonably be expected to understand. Pre-chosen default answers are diplayed; so the user has only to make changes where he or she wishes, as in the following example:
The menus are placed on the screen by the so-called 'PHOENICS-Direct' package, which translates the user's menu entries into instructions to PHOENICS in language which the latter understands. They define the calculations to be performed and how their output is to be presented to the user.
The VR-Editor provides, for users who have learned its rules, access to a wide (but still partial) range of PHOENICS capabilities; by contrast PHOENICS-Direct, with its associated SimScenes, leads directly to just the capabilites that its current users require.
Moreover, PHOENICS-Direct menus can accept, as the VR-Editor can not, data entries in 'relational' form, as illustrated below.
Evidently, in this 'boundary-condition' menu, the inlet velocity is to be deduced from the Reynolds Number, and from property and geometry data which have been set elsewhere; and the inlet temperature is also specified indirectly by reference to the separately-set external temperature.
This relational-data-input (RDI) feature of PHOENICS-Direct is a very useful time-saver indeed..
At this point it is appropriate to argue that SimScenes will interest CFD practitioners of two distinct kinds.
Such persons will be pleased to learn that PHOENICS-Direct enables them to achieve their ends with much greater ease, and so may wish themselves to become SimScene creators. Among them will be:
Such would-be SimScene creators need neither profound knowledge of CFD nor the skills of the VR-Editor connoisseur. They do require some acquaintance with the PHOENICS Input Language; and they also need to know something about the behind-the-scenes workings of PHOENICS-Direct.
The latter is what section 7 is about.
5. A typical SimScene
6. How to acquire a SimScene
SimScenes are not integral parts of PHOENICS, to be supplied to its licensees whenever a new version is issued, They are best thought of as being akin to 'apps', to be obtained via whatever means, and on whatever terms, are offered by their creators.
At the time of writing, all SimScenes have been created by CHAM UK, to which a request should be addressed by anyone who wishes to acquire one. Those who already possess PHOENICS licences may obtain them, at the present time, free of charge. However they may be supplied to others, as stand-alone limited-capability PHOENICS versions, at finite charges which are nevertheless much lower than those of the standard full-capability PHOENICS.
The PHOENICS-Direct executable which is needed for all SimScenes, and the PQ1 Editor which is needed by all SimScene creators, are themselves such apps. They are obtainable from CHAM, but not necessarily free of charge.
The ultimate reason for creating such a SimScene would be to assist heat-exchanger designers to choose tube-bank configurations and dimensions which would provide the required heat-transfer performance, without demanding excessive fluid-pumping power.
In addition to numerical output, graphical displays by way of graphs, contour diagrams and streamline displays, possibly animated, convey valuable information about the simulated equipment or process. For example, pictures of the following kind provide an insight into the internal workings of a heat exchanger that tables of numbers cannot convey.
The TubeFlow SimScene can serve as a model. Its descriptive document explains that the items to be included in menus can be conveniently presented in ten groups, as listed here:
TubeFlow itself however has only nine groups, 'initial conditions' being absent because only steady-flow situations are considered.
Whereas uniformity of format facilitates human understanding, variations for the alleviation of boredom are permissible. Greater strictness is desirable however when it is the understanding of computers which is in question, as is true of one important aspect of PHOENICS-Direct. This concerns the way in which new PIL vriables are declared and set in the underlying parameterised Q1 file which has to be identical in content to the scene.xml file (to be described below) which embodies the menus.
This compatibility can be ensured if the human editor of both files exerts extreme care. But, if the PQ1 is written in accordance with certain precisely-defined rules, its compatible scene.xml can be produced automatically by the computer. Boredom is a small price to pay for such relief.
In the TubeFlow folder resides the batch file, start.bat, which activates this particular SimScene; and if Russian , Japanese, Chinese, etc are suported, of which PHOENICS-Direct is capable, the corresponding batch files start_ru.bat, start_ja.bat, start_ch.bat etc. are also present.
The file descr.htm resides in \tubeflow\docs, together with the images which it displays. This is the file of which the contents were made accessible in sub-section 2.1 above. This file is written by the SimScene creator in order to explain to its users what are the features of the current SimScene which distinguish it from others.
The sub-directories \working\ and \multirun\ are where the results of single and multiruns,respectively are to be found; and the user may find it useful to create to copy their contents to additional folders with similar names for the storage of results obtained at different times.
Favorite is of course the place where favoured settings are to be stored.
Finally the folder \input\ is the home of two important scenario-defining files. These will now be discussed
7.4 The parameterised Q1 file
At first this comprised a list of assignments of values to pre-defined variables, for example:
but later it was enabled to declare new variables and assign values to them too, for example:
Soon followed logical structures (IF_THEN_ELSE_ENDIF ; DO_ENDDO ; etc), graphics-display features and further utilities enabling complex fluid-flow-simulating calculations to be initiated.Year-by-year new features have been added, making present-day PIL an invaluable aid to the CFD specilist
Its nature is fully described in the relevant PHOENICS Encyclopaedia article, the main content of which will be supposed known to readers who wish to progress beyond this point.
In particular it will be supposed understood that PIL has a relational character which allows one item of input to be expressed in terms of, and so to depend on, another (as for example WIDTH depended on LENGTH above).
It is to emphasise this capability that the Q1s used by PHOENICS-Direct are called parameterised Q1s (PQ1s from now on). These too are the subject of lengthy Encyclopaedia articles
That GUI however, despite it many merits, is unable to exploit the full richness of the PQ1 possibiliities; which is why PHOENICS-Direct (PD from now on), which can do so, has been introduced.
The introduction of PD has influenced the way in which PQ1s are written; for it has necessitated a stricter adherence to formal modes of expression in order to allow the menu-related scene.xml files to be generated automatically.
A modern PQ1 contains three parts, namely:
The reading of the default and menu-set parameters is effected by a single line at the bottom of Part 1 of the PQ1, namely:
INCL(frommenu.htm)It is Part 1 which requires the strictest formalism; for it is this which is read by the PQ1 Editor (see below) in order to generate the second important scenario-defining file: scene.xml, which dictates what the user sees on the menu screen
As has been seen in sub-section 7.2, input parameters are conveniently organised in groups of more-or-less similar items. The entries in Part 1 of PQ1 must therefore be grouped in this way; and the grouping is then reflected in scene.xml.
In order to illustrate this, corresponding parts to the two files will be shown. First an extract from the PQ1 of the TubeFlow SimScene:
XML-Group Geometry real(xang) ! circumferential extent, radians xang=3.14159 real(diam) ! tube inner diameter, m diam=0.05 real(thck) ! wall thickness, m thck=0.002Next the corresponding part of scene.xml:
The similarity of their contents is obvious, Their differences of form reflect the differing practices of the PHOENICS Satellite and PQ1 editor, which read the first, and of PD, which reads the second.
<name>Geometry</name> <param> <name>circumferential extent, radians</name> <variable>xang</variable> <variable_type>real</variable_type> <declared>yes</declared> <value>3.14159</value> </param> <param> <name>tube inner diameter, m</name> <variable>diam</variable> <variable_type>real</variable_type> <declared>yes</declared> <value>0.05</value> </param> <param> <name>wall thickness, m</name> <variable>thck</variable> <variable_type>real</variable_type> <declared>yes</declared> <value>0.002</value> </param>
This file can, like the PQ1, be created by means of any text editor; and indeed the very first such files were created in this manner, However such great care is required to ensure that the necessary relationships between the two files are precisely established that a special editor for both has been created. Describing this is the task of the next section.
It is only when the help button is pressed that its much more powerful character starts to manifest itself, thus:
The whole content of the extensive help files can be explored by clicking here. Therefore it suffices to draw attention only to the fact that the macro and code-completion features make use of customisable files.
Specifically, although the relevant files, pq1ed.dci and pq1ed.htc, flies already contain most of the items needed by conventional SimScenes, they can be added to without limit by any SimScene creator with unusual needs.
A PDF document describing the PQ1 Editor extensively can be viewed by clicking here.
7.8 Other aspects of SimScene creation
The above description of the SimScene creator's tasks is far from exhaustive; but it suffices as a starting point. Those who desire more information can best gather it for themselves by inspecting in detail the TubeFlow example referred to in section 5.