Encyclopaedia Index

Contents list

Space and Time Grids

Spatial Grids

Switching Co-ordinate Systems

Cartesian and Cylindrical-Polar Co-ordinates

Displaying the Grid
The Default Grid - Auto Meshing
Modifying the Grid

Changing the Auto-mesh Rules
Manually Changing the Grid by Region

Advice on Grid Settings

Body-Fitted Co-ordinates

Displaying the BFC Grid
Moving the Probe
Modifying the BFC Grid

Creating a Grid with the PHOENICS Grid Generator
Importing a Grid Created by an External Grid Generator
Creating a Grid with PIL
Modifying the Grid for an Existing Case

Time Grids

Switching Between Steady and Transient
Setting the Time-Step Distribution
Saving Intermediate Results
Restarting Transient Cases


Spatial Grids

There are three kinds of spatial grids:


Switching Co-ordinate Systems

To switch between the co-ordinate systems, click on Menu / Geometry, then on Co-ordinate system. The Cartesian grid is the default.


IMAGE: Grid Mesh Settings Dialog

The change between Cartesian and Cylindrical-polar can be made in either direction.

Note that whilst it is (often) possible to convert existing cases to BFC, it is not possible to reverse the procedure.

Cartesian/Polar cases which cannot be converted are those which use geometries other than cuboids.


Cartesian and Cylindrical-Polar Co-ordinates

Displaying the Grid

Turning the mesh toggle on the hand-set ON by clicking on the Grid mesh button causes the current grid to be displayed on the graphics image:


Image: GRID

The grid is displayed on a plane at the probe location. By default the plane is normal to the co-ordinate axis nearest the view direction. For example, if the view direction is along, or close to, +Z, the X-Y plane will be displayed. As the probe is moved or view directions are changed, the grid display will also change to follow.

To manually select the displayed plane, click the pull-down arrow next to the mesh toggle

and choose the required plane. This plane will now be displayed regardless how the view direction is changed, until another direction or 'Auto' is chosen. The position of the plane is still controlled by the probe location.


The Default Grid - Auto Meshing

The grid-creation actions which the VR-Editor takes by default relate to the three aspects the Cartesian or polar grid, namely:
  1. locating the boundaries of the regions;
  2. determining the numbers of intervals in each region; and
  3. choosing the type and numerical exponent of interval non-uniformity.

The orange lines shown in the above image are region boundaries. These are automatically created to match the edges of the object bounding boxes (see VR-Editor Object Dialogs - Object Size, Object Positioning), as a consequence of the default ticking of each of the x, y and z options in the 'object affects grid' menu shown below.

If the user removes the ticks, no region is created; nor, of course, are the intervals within them.

This is sometimes desirable; for the user may know that the objects in question, although truly present, can have negligible influence on phenomena of interest. If so, it is time-wasting to allow the grid to be refined around such objects. See Advice on Grid Settings below.

As objects are introduced, removed and re sized, the region lines will adapt to match the object layout.

The blue lines are 'ordinary' grid lines. By default, these are distributed by the auto-mesher according to the current set of rules. These are:

  1. The maximum cell size is not allowed to exceed a set fraction (0.05 by default) of the domain size.
  2. The ratios between the sizes of the first cell in the current region and the last cell in the previous region, and the last cell in the current region and the first cell in the next region, are not allowed to exceed a set limit (1.5 by default).
  3. If the ratios are exceeded, the number of cells in that region is increased, and the spacing is set according to a geometrical or power-law progression using a set expansion ratio (geometrical 1.2 by default), until either the ratio criterion is satisfied at both ends of the region, or the cells at both ends are below a set minimum fraction (0.005 by default) of the domain size.

Note that if there are no region boundaries in a direction, the auto-meshing will usually assume that only one cell is required in that direction. This is appropriate for 2D cases in which all objects cover the whole domain in the third direction.

If there is an INLET, FAN, OUTLET or PLATE object on the edge of the domain, the auto-meshing will assume that grid is required in that direction, even if there is only one region.

Users should always inspect the grid visually to satisfy themselves that it is appropriate to their purposes. The default auto-mesh settings may sometimes be found to have created a rather coarse grid, suitable for first-exploration runs but not for realistic simulations. It is equally possible that they have created too fine a grid; or one that is fine in the wrong places. 'Object affects grid?' is too important a question for users to disregard.

In most cases auto-set grids will require adjustment, either by changing the auto-grid rules or by manual adjustment before the final runs are made.


Modifying the Grid

Clicking anywhere in the image whilst the grid mesh display is on will show the Grid Mesh Settings Dialog. By default, the auto-meshing feature is turned on, as shown in the image below:


Image: GRID Mesh SETTINGS - Auto

The grayed-out values cannot be changed from this dialog unless the auto-mesh is turned off for any direction, as shown here:


Image: GRID Mesh SETTINGS - Manual

Settings on this dialog which are common to auto-mesh on or off are:

Changing the Auto-mesh Rules

To change the auto-mesh settings for any direction, click 'Edit all regions in' on the Grid Mesh Settings dialog for the direction in question. The following dialog will appear:


Image: X Direction Auto-mesh Settings

The grayed-out values cannot be changed manually unless the auto-meshing is turned off. They reflect the settings generated by the current auto-mesh control parameters.

The following settings influence the auto-meshing:

Manually Changing the Grid by Region

When the auto-meshing for a direction is turned off, the number of cells in any region, and the distribution within any region, can be set by clicking on the region to be modified. The initial region settings will be those created by the auto-mesher. Clicking on X region 3 and Y region 1 of the example shown previously, for example, brings up the dialog box shown below:


Image: GRID Mesh SETTINGS - manual

The diagram below shows a simple three-part grid. Region 1 has 10 cells with a power of -1.5. Region 2 has 10 cells with a symmetric power of 1.5, and region 3 has 10 cells with a power of +1.5.


Image: DIAGRAM 1

The next diagram shows the same grid, but with geometrical expansions in all three regions:


Image: DIAGRAM 2

Advice on Grid Settings

The two most important pieces of advice to the user who has allowed the grid to be created by the automesher are:

  1. Look at the grid which has been created; and
  2. Consider critically whether the automesher has placed the finer-grid regions in places which are of most importance to the user.
The answer to the last question will most often be negative; for how can the satellite know what it has not been told?

An example is shown by the following picture which shows the automeshed grid for the simulation of what happens when a car catches fire in a car park. The car, one might suppose, is of greatest interest, and so should have the finest grid. However automesher has paid attention to the numerous small ventilation apertures in the car-park wall; and, precisely because of their smallness, has created a grid which fits them.

   

Having recognised that automeshing has created a grid which, because it is very fine, will require large computer times but ignores his needs, what should the user do? The answer depends upon his expertise level.

Many would do best to seek from CHAM, or from their in-house experts, a Q1 file which corresponds better to reality and to their desires. Do-it-yourselfers however, who wish be their own in-house experts, should proceed as follows:

  1. Clarify precisely what is the purpose of the simulation.
  2. Use their general knowledge of physics (or that of their advisers) to determine what geometrical aspects of the scenario are most likely to influence the simulation outcomes which bear on that purpose.
  3. Judiciously switch off the 'Object affects grid' attributes of selected objects to prevent the creation of regions where they are not needed.
  4. Judiciously add NULL objects to create extra regions where they appear to be needed but have not been created by any current object.
  5. Edit into the Q1 file such grid-defining PIL statements as most effectively reflect those aspects, bearing in mind that the finer the grid the less easy it will be to investigate the influence of other important scenario parameters.
  6. In respect of those elements of the scenario as are likely to have significant influence on the interesting outcomes but are too small to be handled by Detailed-Geometry CFD, edit into the Q1 files such PIL statements as express their Space-Averaged CFD equivalents.

The last two are not actions for which the VR-Editor is able, or can be expected, to provide assistance; but the more-recently developed Parameterised-Q1 Editor is being supplied with an increasing number of macros to facilitate items 5 and 6.

The actions will now be discussed in more detail.

Distinct purposes might be:

  1. To simulate the car-burning process, i.e. to calculate its rate of progress, taking account of the rate of mass transfer of oxygen to its fuel-bearing parts.etc.
  2. Having instead specified the rate of burning to establish whether the rate of air and smoke extraction through ventilation apertures is sufficient to draw away all that is produced, or alternatively will allow smoke to accumulate if the garage space or perhaps even to spread, and cause further conflagrations, elsewhere.
  3. To establish how low should be the external pressure applied to the ventilation apertures so as to ensure that all the smoke produced will be extracted.

Whichever is the purpose, the grid which automesher created is totally unsuitable.

Let us suppose that inquiry shows that whoever commissioned the simulation had purpose (b) in mind, and that the scenario specification consisted of:

If that is the case, it must be admitted that a CFD simulation is not truly needed at all; for a back-of-envelope sum will indicate the ratio of the rates of smoke production and extraction.

However, if CFD is to be used, a 20-by-20-by-20 grid will suffice to demonstrate that the back-of-envelope sum was not far wrong.

How would the extractor devices be represented in such a model? Fixed-mass-flux patches at the walls would be quite good enough.


Body-Fitted Co-ordinates

All BFC library cases, and all user-generated BFC cases can be loaded into PHOENICS-VR.

The possible methods of grid generation are:


Displaying the Grid

Turning the mesh toggle on the hand-set ON by clicking on the Grid mesh button causes the current grid to be displayed on the graphics image:


Image: BFC Grid

The grid is displayed on a plane at the probe location. The plane is normal to the co-ordinate axis nearest the view direction. For example, if the view direction is along, or close to, +Z, the X-Y plane will be displayed. As the probe is moved or view directions are changed, the grid display will also change to follow.

In a multi-block grid, the grid will be displayed in the block containing the probe.


Moving the Probe

In BFC, the probe can only be moved from cell-centre to cell-centre. The probe location is always in IX, IY, IZ.

In a multi-block case, these are shown in 'big' grid co-ordinates, not in local block co-ordinates. Any cell can be moved to directly by typing the cell IX,IY,IZ values into the hand-set.

Note the colouring of the block containing the probe:

In a complex multi-block case, this will help in identifying which way to move the probe.

To move the probe from one block to the next, move up to a linked face, and then step through it by continuing to move in that direction.

The axis colouring will jump to the next block. If the Move probe button is kept pressed, and the IJK orientation of the next block is different, the probe may take off in an unexpected direction - it may even jump back to the previous block if the axes are reversed!


Modifying the Grid

Creating a Grid with the PHOENICS Grid Generator

To enter the Grid Generator, turn the grid display ON by clicking on the Grid mesh button. Click on the grid anywhere in the domain. The BFC Menu will appear.


IMAGE: BFC Menu

The main functions on the BFC Menu are:

For those users not familiar with the BFC grid generator, several tutorials are available, reached from POLIS / Learn / BFC tutorials. There is also a lecture, reached from POLIS / Learn /Lectures describing... / Body-fitted co-ordinates; introduction describing the fundamentals of BFC Grid generation.

The images above show the geometry created by the BFC tutorials.


Importing a Grid Created by an External Grid Generator

Whichever external grid generator is used, the outcome will be a skeleton Q1, and at least one grid file. If the case is a multi-block case, there will be one grid file for each block.

The skeleton Q1 file will contain a READCO command to read the grid file(s), and instructions for linking the blocks.

An example skeleton file for a single-block grid stored in the grid file grid1 must contain at the very least:

TALK=T; RUN(1,1)
BFC=T
READCO(grid1)
STOP

It may also contain (M)PATCH statements locating boundary conditions, and also COVAL commands setting inlet values.

In GeoGrid (Note: this software is no longer available, but the images are shown for illustrative purposes) the name of the Q1 will be project.Q1, where project is the name of the GeoGrid project.

To import this into PHOENICS-VR, click on File - Open existing case from the top bar of the main VR-Editor/Viewer graphics window. Double-click on project.Q1 to open it in PHOENICS-VR.

The first image shows a very simple 3-block example in GeoGrid.

 

One inlet (purple, on the left) and one outlet (blue, on the right) have been designated.

 

The second image shows the same case imported into PHOENICS-VR.

Note: The grid files must be in the current working directory, OR the READCO(filename+) command must be modified to include the path to where they are.

If a grid generator other than GeoGrid is used, please ensure that the skeleton Q1 is copied to the working directory as case.Q1, together with all the necessary grid files. Use File - Open existing case to open case.Q1.


Creating a Grid with PIL

If the user is familiar with the PIL GSET suite of commands, the Q1 can be edited to create the grid in any convenient way. PHOENICS-VR will recognise and retain all GSET commands.

It does not recognise the older SETPT, DOMAIN, SETLIN or MAGIC commands. If the grid is built with these, or some of these commands are used to smooth parts of the grid, use the DUMPC(name) command to write out a grid file, and supply PHOENICS-VR with a  Q1 that just contains:

TALK=T;RUN(1,1)
BFC=T
READCO(name)
STOP

The final result should be a file called case.Q1, which either contains the required GSET commands, or a READCO to read an existing grid file (or files).


Modifying the Grid for an Existing Case

Often, once a case has been set up and run, it becomes obvious that the original grid is inadequate. It may be generally too coarse, or grid may be concentrated in the wrong places.

If the grid was generated in the PHOENICS Grid Generator, this can be used to modify the grid as required. On exit from the Grid Generator, most of the objects will have to be re-located and re-sized , as they will still be in their original IJK positions.

If the grid was generated externally, in many cases this can be avoided. Re-enter the grid generator, say GeoGrid, and modify the grid as required. Save the PHOENICS output file with a different name to that used for the original grid.

In VR-Editor, click on Main Menu - Geometry - Read new geometry from file. This will bring up a file browsing window, which will allow the selection of the new Q1 written by the grid generator. The new grid will be read in, and boundary condition locations will be remapped to the new grid when Open is clicked. Note that only boundary conditions common to both grids will be remapped.


Time Grids

To simulate transient behaviour, time is discretised in a similar way to the space dimensions. The Earth solver produces a solution for each step in time before advancing to the next step. An extra term is automatically added to the equations solved, which expresses the influence of the previous time-step.

The default equation formulation is implicit, so there are no extra stability criteria to satisfy when setting the size of the time-steps. If the steps are too large, the details of the transient behaviour will not be picked up.

In Transient mode, objects representing sources will have additional dialogs allowing start and end times to be set.

Switching Between Steady and Transient

To switch from Steady to Transient, click on the Steady button on the   Grid Mesh Settings dialog,

or in BFC,

 

on the BFC menu dialog. A new button labeled Time Steps will appear.

The Steady button will now be labeled Transient. To switch back to Steady, click on Transient.


Setting the Time-Step Distribution

Clicking on the Time Steps button displays the Time Step Settings dialog.


IMAGE: Time Step Settings dialog

Time can be divided into regions by the Split Regions button. Within each time region, the number of time steps can be set, together with a geometrical or power-law size distribution.


Saving Intermediate Results

To save intermediate results for plotting in the VR-Viewer or any other post-processor, click on 'Main menu', 'Output', 'Field dumping'. The following dialog will appear:


IMAGE: Transient Field dumping dialog

Set the first and last time steps to be dumped, and the step frequency for dumping. If the first and last steps are left as zero, the program will assume the first and last steps for the current run. Set a start letter for the intermediate output files. A start letter of A, and a dump frequency of 1 will result in files called A1, A2, A3 etc being dumped at the end of each time step.

The letter Q should not be used, as the file dumped on step 1 will overwrite the Q1 input file!

The size of the intermediate files can be reduced by choosing not to dump each variable to the file. Changing the Y to an N in the OUTPUT 3 DUMP line will prevent that variable from being written to the intermediate file. If the property-marked variable, PRPS, is so excluded, Viewer will not be able to determine which cells are blocked. Depending on which variables are excluded, it may not be possible to restart the calculation from the intermediate files. All variables are written to the final solution files (PHIDA or PHI and PBCL.DAT) regardless of the dump settings.

If the case is 2D in X and Y, the start letter can be left blank. In this case, a special output file called PARADA or PARPHI is written, in which the results of each time step are saved as a Z plane. In the viewer, sweeping through Z in effect sweeps through time.

To print flow fields to the RESULT file every time step, go to 'Main menu', 'Output', 'Field printout', and set NTPRIN to 1. Note that NTPRIN may be displayed on the next page of the menu. Click 'Page down' to display settings on the next page.

Note that the intermediate output files are optionally saved by 'File', 'Save as a Case', and restored by 'File', 'Open existing case'. The output files can be big and numerous, so it may be better to either ZIP them up, or copy them to a CD for safe-keeping.

The intermediate files can be selected for plotting in the Viewer by choosing 'Use intermediate step files - Yes' on the 'File names' dialog displayed when the Viewer starts.


Restarting Transient Cases

There are two main possibilities:

  1. Restarting to continue with more time steps
  2. Restart from some intermediate point and re-calculate some steps.

To restart and continue the run, bring up the Time step setting dialog. In the 'Time at end of last step' box, enter the new extended end time of the run. Leave 'Time at start of step 1' at zero. In the 'Last step number' box, enter the new total number of steps. In the 'First step number' box, enter the previous last step+1. A dialog will appear asking if a restart is to be activated. Click 'Yes'. The restart will be activated, and the names of the restart files will be deduced from the start letter chosen for saving the intermediate fields.

Please check that the names are correct. To force a restart from the final solution files which are guaranteed to contain all the solved and stored variables, set the 'Solution file' to phida (or phi) and the 'Cut-cell file' to pbcl.dat.

For example, the original run did 100 steps from time 0.0s to 10.0s ( thus giving time steps of 0.1s each). It is now desired to do the next 10.0s with the same time step size. Set 'Time at end of last step' to 20.0, 'Last step number' to 200, and 'First step number' to 101. To activate the restart, click on 'Yes' when asked about activating the restart.

To restart from an intermediate step, say step 50, just set 'First step number' to 51. A dialog will appear asking if a restart is to be activated. Click 'Yes'. The restart will be activated, and the names of the restart files will be deduced from the start letter chosen for saving the intermediate fields.


IMAGE: Time Step Settings dialog for restart

The names of the restart files are also displayed on (and can be set from) the 'Main Menu', 'Initialisation' panel. An active restart is shown by all the initial values (FIINIT) being shown as READFI.


Contents list