Several concern the better simulation of fluid-structure interactions, the three main aspects of which are:

1. PARSOL, which enables bodies with curved surfaces to be smoothly represented on cartesian grids;
2. MOFOR, which allows bodies to move through such grids; and
3. SFT, which allows the stresses in solids to be computed simultaneously with the velocities and pressures in the fluids in which they are immersed.

Others concern data-input and results-display procedures, both in respect of:

1. The input of data by way of formulae (In-Form); and
2. The graphical user interface.

In addition, new utilities have been provided; and others have been improved.

1. Fluid-structure interactions
   1. Curved surfaces in cartesian grids, PARSOL
   2. Moving frames of reference, MOFOR
   3. Solid-fluid-thermal analysis, SFT

2. Data-input and results-display improvements
   1. Data-input by way of formulae
      1. Prescribing the motion of moving objects
      2. Ascribing arbitrary sources to objects
   2. The Virtual-Reality interface, VR

3. New and improved utilities
   1. The PHOENICS Commander
   2. FacetFix
   3. ShapeMaker
   4. Nu-PHOTON

4. Concluding remarks

1. Fluid-structure interactions

1.1 Curved surfaces in cartesian grids, PARSOL

Background

Nevertheless, PARSOL has not been used quite as often as its authors expected, for several reasons, namely:

• early versions were unable to handle conjugate heat transfer;
• computer times were found to increase, when PARSOL was switched on, to what was sometimes thought to be an unacceptable extent;
• PARSOL occasionally failed to represent wall friction correctly; and
• switching on PARSOL required users to make a positive step.

What has been done

So successful has this recent work been that CHAM has arranged for PARSOL to be switched on automatically, whenever objects are found in the flow field of which the surfaces cut cell-edges anywhere except at cell-corners.

Users are however allowed to switch PARSOL off, if they wish to see what difference it has made.

How it was done

• The computer-time problem was solved by making several internal improvements, including:
  • providing additional storage for quantities which were being recalculated at each sweep (with advantages for non-PARSOL simulations also); and

  • removing the formerly-built-in link between PARSOL and the equation-solver devised for fine-grid embedding, which proved to be inefficient for this purpose.

    The opportunity was also taken to improve the efficiency of the fine-grid-embedding solver for those cases for which it must be used.

• The friction problem was solved by recoding the 'wall functions' with great care; for the previous implementation was not quite right in all respects.

• At the same time, PARSOL was extended so as to be usable for both fixed-in-position and moving-through space objects, as will be explained further in the following section on MOFOR.

As a consequence, flows around rather complicated shapes can now be easily performed, as shown by the following images of air flowing through an array of louvres: velocity vectors and velocity contours.

Go to contents, #1, #2, #3, #4

1.2 Moving frames of reference, MOFOR

Background

However, there were several limitations on what MOFOR could do, including:

• PARSOL could not be used;
• the fluid had to be incompressible;
• the moving objects could not engage in heat transfer;
• motions were described by way of so-called BVH files, which had to be edited by hand.

What has been done

In respect of the last of the four, the facility has been provided for specifying the motions of the bodies by way of formulae; so BVH files (renamed now to MOF files) need not be used at all (although they still can be).

How it was done.

• In order to enable PARSOL to work, the cut-cell-detecting calculations had to be performed at the beginning of each time step.

• Removal of the incompressibility requirement required careful attention to, and appropriate modification of, the various terms in the mass-continuity equations for the cells occupied by the moving object.

• Similar care was needed for the balance equations for scalar variables such as temperature and concentration.

• The extremely-important formula-using facility was created by extending the capabilities of In-Form, which now is able to calculate and place in memory the equivalent of a MOF file. [See section 2.1 for an example]

What has not yet been done

• Although the facility for doing so exists, the effects of movement of the whole frame of reference have not yet been explored,

  This feature will allow calculations of such phenomena as:

  • the sloshing of liquids in tanks mounted on ships;
  • mixing of fluids in agitated vessels; and
  • the forces on passengers in a manouevering aircraft.

• The desirable (for some practical applications) feature of allowing the moving object to cut its way though a fixed object, has not yet been implemented.

• Although the In-Form feature allows it, the calculation of the forces exerted on the moving object by the fluid, and deduction therefrom of the accelerations, velocities and positions, has not yet been tried.

  Obviously, when it is, the range of practical applications will be greatly widened.

  To facilitate this, the so-called imbalance patch, which can already calculate the fluid-dynamic forces on bodies, will need to be extended so as to calculate moments too.

• The VR-Editor does not yet do much to facilitate input of data for moving-object problems (but the animation feature of the VR-Viewer provides an excellent means of displaying their results).

Go to contents, #1, #2 #3, #4

1.3 Solid-fluid-thermal analysis, SFT

Background

What it can do is illustrated by the following images from an earlier lecture.

• The problem
• Displacements, stresses and strains
  • velocity vectors in the airgap beteeen a radiating upper wall, and displacement vectors in the metal blocks below

  • vertical-direction stresses in the blocks
    
  • vertical-direction strains in the blocks
    
  • horizontal-direction stresses in the blocks
    
  • horizontal-direction strains in the blocks
    

• The radiation and temperature fields which caused them
  • the vertical-direction radiation flux
    
  • the horizontal-direction radiation flux
    
  • the temperature field which gave rise to the displacements
    
  • the corresponding radiation temperature
  • the thermal strains
    

• Auxiliary quantities deduced from solution of the LTLS equation.
  • the 'wall-gap' distribution used by the IMMERSOL radiation model
  • the 'wall-distance' distribution used by the LVEL turbulence model

Similar images relating to an axi-symmetrical geometry can be seen here.

Nevertheless, despite (or perhaps because?) the SFT feature is unique to PHOENICS, it has not received attention commensurate with its importance.

There are several reasons for this, including:

• There is a widespread belief that fluid-structure-interaction problems can be solved only by coupling together a fluid-dynamics code and a structural-analysis one.

• Too few examples have been provided by CHAM to show how PHOENICS can be applied to practical problems; nor has activation by way of the graphical user interface been enabled.

• The solution algorithm used in all versions up to and including 3.5.0 converges rather slowly.

In respect of the last-mentioned deficiency, however, it has been recognised for two years, that there is another algorithm having better convergence properties; and only lack of resources has prevented its exploitation.

What has been done

What it mainly involves is solving three additional equations, within the solid region, the dependent variables of which are the three components of vorticity, whereby it must be understood that these vorticities are defined in terms of displacements, not velocities.

The advantages over the formerly-used (and still available) SIMPLE-based algorithm are:

• There is no need to solve the differential equation for the 'dilatation', which, because of its appearance in the source terms of all three displacement equations, was a major cause of slow convergence.

• In many circumstances, for example when thin beams are in question, the solutions of the vorticity equations can be analytically derived, so that their influences on displacements can be expressed by way of In-Form.

• It emerges that, if only large-scale deformations in one direction are of interest, they can sometimes be accurately calculated without solving equations for the displacements in other directions at all!

An example

The relevant commands in the Q1 file are few. They represent the application of a torque at the end of the beam.

It will have been noticed that the action of the end torque was transmitted by way of two In-Form statements, one acting on the end of the beam and the other distributed along its length.

If the loading is more complex, so will be the In-Form expressions; but no matter. EARTH can handle them.

How it was done.

1. Providing for the solution of the vorticity components, and the storage of the dilatation (which is still needed, but not as a solved-for variable).

   This task was trivial; for the vorticity equations are Laplace-like, with simple load-related sources.

2. Providing a PIL variable, CONVAC (standing for convergence acceleration) which, when set TRUE in the input file, activates the new algorithm.

   This was also trivial.

3. Providing coding for the sources in the displacement equations for the solid-boundary cells.

   This required much care.

4. Ensuring that all coefficients in the displacement and velocity equations were correct in near-solid-boundary cells.

   This was even more demanding, because of the large number of ways in which near-boundary cells can adjoin.

What has not yet been done

• provision of a sufficient (for testing and exemplification) set of library examples. The number is large because of the variety of fluid-structure interactions which can arise in practice.

• provision of explanatory documentation which, because of the novelty (it is believed) of the approach, is also no light task.

• enabling users to set up stress-in-solids problems by way of the VR-Editor.

• enabling the VR-Viewer to display the results.

More distant tasks, none of which presents any difficulty of principle, include:

• Using PARSOL features to allow the deformations to be large enough to cut the cells, and so have an influence on the flow.

• Activating the transient terms on the displacement and vorticity equations.

• Additionally using MOFOR features so as to simulate large-displacement, time-dependent, two-way, fluid-structure interactions,

• As a separate line of development, extending the method to body-fitted-coordinate problems, using the long-existing and just-as-long-neglected moving-body-fitting-coordinate feature.

Go to contents, #1, #2 #3, #4

2. Data-input and results-display improvements

2.1 Data-input by way of formulae, In-Form

Background

CHAM's now-ten-years-old PLANT feature went further, by enabling PHOENICS itself to write error-free Fortran, on the basis of formulae provided by the user.

The (so far) final stage of user-empowerment has been CHAM's introduction of In-Form, which does all that PLANT could do without requiring any new coding at all.

In-Form enables (almost) arbitrary specifications of data to be supplied to CFD (or SFT) simulations by way of formulae typed into the input file (Q1).

It was first introduced with PHOENICS version 3.4; and it has increased in power with each new release.

Here the two main developments in version 3.5.1 will be described.

(a) Prescribing the motion of moving objects

The following extracts from library case 360 illustrates the capability.

First, the In-Form MOVOB command dictates how the three position and three orientation coordinates vary with time, by way of character strings.

 TEXT(MOFOR by In-Form: 2D motion of 2 objects
  Echo InForm settings for Group  7
  INFORM7BEGIN
   ** Definition of the VR moving objects by In-Form
char(vel,gravt,times)
vel=10.; gravt=9.81; times=tim
(MOVOB of SPHERE1 is POS(:times:*:vel:&:times:*:vel:-0.5*:gravt:*:t$
imes:^2&0&0&0&0))
(MOVOB of SPHERE2 is POS(-:times:*:vel:&0&0&0&0&0))

The next line says: "Don't look for a .MOF file".

  INFORM7END
 SPEDAT(SET,MOFOR,MOFFILE,C,NOTSET)

Finally the two objects, SPHERE1 and SPHERE2, in their start-of-process positions, are defined in the usual way, as follows:

> OBJ,    NAME,        SPHERE1
> OBJ,    POSITION,    0.000000E+00, 0.000000E+00, 0.000000E+00
> OBJ,    SIZE,        1.000000E+00, 1.000000E+00, 1.000000E-01
> OBJ,    CLIPART,     cylinder
> OBJ,    ROTATION24,        1
> OBJ,    GRID,              2
> OBJ,    TYPE,        BLOCKAGE
> OBJ,    MATERIAL,       -1
> OBJ,    TIME_LIMITS,   ALWAYS_ACTIVE
> OBJ,    INI_PRESS,     0.000000E+00
> OBJ,    SCAL_FIXF,     0.000000E+00

> OBJ,    NAME,        SPHERE2
> OBJ,    POSITION,    2.100000E+01, 3.000000E+00, 0.000000E+00
> OBJ,    SIZE,        1.000000E+00, 1.000000E+00, 1.000000E-01
> OBJ,    CLIPART,     cylinder
> OBJ,    ROTATION24,        1
> OBJ,    GRID,              2
> OBJ,    TYPE,        BLOCKAGE
> OBJ,    MATERIAL,       -1
> OBJ,    TIME_LIMITS,   ALWAYS_ACTIVE
> OBJ,    INI_PRESS,     0.000000E+00
> OBJ,    SCAL_FIXF,     0.000000E+00

Graphical vector plots for case 360 are shown on, for successive time instants, by the following hyperlinks:

inst 1, inst 2, inst 3, inst 4, inst 5, inst 6, inst 7, inst 8, inst 9, inst 10, inst 11, inst 12, inst 13, inst 14, inst 15, inst 16, inst 17, inst 18, inst 19

(b) Ascribing arbitrary sources to objects

• Of course, the VR editor permits sources of limited types to ascribed to objects. However, In-Form permits the nature of the sources to be varied almost without limit.

• The application of a source to a patch has been effected, from the beginning of In-Form, by statements such as this:

  (SOURCE of VAR_NAME at PATCH_NAME is FORMULA)

  where PATCH_NAME is the name appearing in the PIL PATCH command, which should precede the In-Form statement.

  This command marks, in grid-related terms, the part of the domain inside which the source calculated by the formula will be applied.

• In a similar manner, In-Form sets the sources in a VR-type object, simply replacing the PATCH name by the OBJECT name.

  The setting of a source for dependent variable VAR_NAME by In-Form is described by the next In-Form statement, in which FORMULA is a character string.

  
    INFORM13BEGIN
  (SOURCE of VAR_NAME at VR_OBJECT_NAME is FORMULA)
    INFORM13END
  

• A full description of the procedure, with examples, is provided in the PHOENICS Encylopaedia article on the subject.

How it works

These commands are written by the SATELLITE module into the EARDAT file in a form which depends on the keyword ... MOVOB, SOURCE, INITIAL, STORED, PROPERTY, etc ... which starts the In-Form statement.

The first action of the EARTH module, when it reads EARDAT, is to parse the character string, deduce therefrom what mathematical operations are to be performed, and to set the appropriate switches.

No new Fortran or C source coding is created; therefore there is no need for re-compilation.

What has not yet been done

There exists however a Tcl/Tk-based In-Form editor which is accessible from the VR-Editor; and this provides limited assistance in the writing of In-Form statements.

Work is in progress to improve this editor by providing:

• lists of formulae from which selections can be made; and
• checks on the validity of formulae which users have created for themselves.

It is intended that the In-Form editor will be extended so as to make good other shortcomings of the VR-Editor in respect of PIL features such as declarations, logic and file-handling, as well as facilitating the use of CHEMKIN.

Go to contents, #1, #2 #3, #4

2.2 The Virtual-Reality interface, VR

However, so as to connect with an earlier topic, it may be mentioned that the second feature in the list, namely animation, has proved to be especially valuable for the display of the results of calculations which use MOFOR.

• Mouse control of view – rotate, pan & zoom

• Animation of transient results

• Improved dialogs for VR-Viewer control – dynamic control of vector length, contour limits, iso-surface value, plotting volume limits

• Transparency for contours and iso-surfaces

• Option to turn contour averaging off

• Streamline width can be set in pixels.

• Streamline display can be controlled by flight time

• User-selectable colours and transparency for objects

• Bounding box of rotated objects fits limits of object geometry, allowing better control over mesh and object position

• Better Geometry creation and editing routines, including improved plugins for AC3D shape editor and the CAD file mending utility facetfix

• Extra turbulence models via Main Menu - KEMMK - Murakami, Mochida and Kondo k-ε model and KEKL - Kato-Launder k-ε model for flow around bluff bodies as encountered for example in wind-engineering applications.

• Screen images saved with user-defined resolution.

Go to contents, #1, #2 #3, #4

3. New and improved utilities

3.1 The PHOENICS Commander

Its nature and purpose

It has been designed with new users of PHOENICS especially in mind, as is evidenced by its top panel, which is also that which appears when the new-user button is pressed.

All PHOENICS modules, utilities and information sources can be activated by way of the buttons which are provided on the various panels described in the descriptive document.

The input-file-library search facility

There are many hundreds of items in the library; but hitherto finding which ones exhibit a particular combination of features has been a wearisome task.

With the new 'search-engine', a user may call for all those cases which are, for example:

• time-dependent;
• using body-fitting coordinates;
• simulating radiation by way of the IMMERSOL model; and
• employing the LVEL turbulence model.

A complete list of such cases then appears in an HTML file with links to the Q1s and Q1EARs.

How it was created

1. The power of TCL/Tk rendered it easy to construct and refine;
2. it provides the same functionality and appearance in both Windows and Unix environments; and
3. access to the underlying easily-editable ASCII files allows suitably knowledgable users to modify its functionality and appearance.

The editability can be recognised by looking at, for example, the file which organises the buttons of the run_In-Form_cases panel, namely /phoenics/d_satell/d_men/tcl/informed.tcl.

Evidently it is very easy to changes the numbers of the library cases which can be run and the words which describe them.

Go to contents, #1, #2 #3, #4

3.2 FacetFix

The aim of the new FacetFix utility is to provide a means of examining, and if necessary repairing, files which describe solid bodies by way of triangular or quadrilateral facets, such as are provided by CAD packages, for example in STL (i.e. stereo-lithography) format.

The program was created because the CAD packages used by architects do not necessarily either:

• guarantee that the facets are consistent with each other in respect of inward- and outward-looking direction; or
• define closed volumes.

PHOENICS requires that facets should have a direction sense in order that it can know on which side is the fluid and on which the solid; and of course facets which share an edge should be in agreement on the matter.

A further PHOENICS requirement is that the facets defining an object should, taken together, form a completely closed surface, such as is possessed by every real solid body.

FacetFix takes in defective STL files, enforces consistency, adds facets so as to create complete surfaces, and produces the corresponding .dat files which are needed by the PHOENICS Virtual-Reality User Interface. It can do the same for defective .dat files also.

The unrepaired and repaired files can be examined and compared in AC3D to establish that any faults have been repaired

Go to contents, #1, #2 #3, #4

3.3 ShapeMaker

• It can specify the absolute size, position and orientation of the bodies which it makes so that these can be imported directly into the Virtual-Reality GUI.

• It can create arrays of objects with user-defined spacings

• It can write and read .geo files, which are smaller and more exact than the associated .dat files containing information about the facets used for display in VR and for cut-cell determination in PARSOL.

• It can also accept, and record in the .geo file, non-geometric information such as body temperature, prps value, etc (although EARTH is not yet using this information).

• It has been provided with a `user-help' facility.

• It can be activated from the VR-environment and from the PHOENICS Commander.

Go to contents, #1, #2 #3, #4

3.4 Nu-PHOTON

Nevertheless a Nu-PHOTON package has been developed by CHAM, with the following features:

• It has an entirely new Windows-style user interface.

• Although the old commands are still accepted, well-designed dialog boxes permit all drawing functions to be more easily performed.

• It can calculate and display any derived quantities, for example: vorticity, stagnation pressure, or kinetic energy, for which the user types in the formula.

• Its macro language allows declarations of variables and posesses some primitive logical features.

• It is also being developed so as to possess the capabilities of the older PINTO and file-compression utilities.

• Additionally it will soon be able to read and display results generated by CFD packages other than PHOENICS.

4. Concluding remarks

What deserves particular emphasis, however, is the great potential offered by the new features when they are brought simultaneously into action. Thus it may be envisaged that, in the near future, PHOENICS will be enabled to simulate:

• the motion of a swimmer who springs from a flexible diving board through the air and into the water;
• the action of an explosion in rupturing a wall and sending its fragments flying; and
• the performance of positive-displacement motors and compressors of (say) the inter-meshing-helix type.

Some of these can certainly be achieved within the next twelve months. Version 3.5.1 provides for them an excellent foundation.

Finally, it should be mentioned, existing and future users can themselves accelerate the development process by:

• using systematically the main components ... PARSOL, MOFOR and In-Form ... in their present state;

• providing some of their successful results to CHAM, with permission to use them in sales publicity (for the more licences are sold the more resources can be devoted to development); and

• communicating any difficulties or failures so as to enable CHAM to improve the software and documentation.

CHAM will certainly be grateful for all such progress-promoting interaction.

Go to contents, #1, #2 #3, #4