Ingenieurbüro für angewandte Strömungsmechanik

Kontakt

PHOENICS: Features 3.5.1

Eine Vielzahl von Erneuerungen sind in die neue Version eingeflossen. Sie betreffen die folgenden Themen Bereiche:

Fluid Structure Interactions

Curved surfaces in cartesian grids, PARSOL
Moving frames of reference, MOFOR
Solid-fluid-thermal analysis, SFT

Data-input and results-display improvements

Data-input by way of formulae ,In-Form
The Virtual-Reality interface, VR

New and improved utilities

The PHOENICS Commander
FacetFix
ShapeMaker
Nu-PHOTON

Fluid Structure Interaction

Curved surfaces in catersian grids, PARSOL

The PARSOL "cut-cell" technique has been available in PHOENICS for several years; and it offers the great advantage over the use of body-fitted-coordinate grids that the mesh-creation problem, which is often an extremely burdensome part of a flow-simulation task, disappears completely.

New PARSOL features are:

Conjugate heat transfer was brought within the scope of PARSOL already in version 3.5.0; and CHAM has given much attention to ensuring that version 3.5.1 is free from the second and third deficiencies.
PARSOL is now to 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 can switch PARSOl off, if they wish to see what difference it has made.
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)
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.
The friction problem was solved by recoding the 'wall functions' with great care; for the previous implementation was not quite right in all respects.
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.

Moving frames of reference, MOFOR

The MOFOR feature of PHOENICS made its first appearance in version 3.5.0, which version could already perform calculations of describing the interaction between a moving object and the surrounding fluid.

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.

As has already been mentioned, PARSOL now can now be used for both fixed and moving bodies and the other limitations have also been removed.

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.

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 MOF files (was called BVH files) need not be used at all (although they still can be). 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.

Because of the extreme and careful attention to detail which such work entails, several desirable and undoubtedly possible features have not yet been implemented. They include:

Although the facility for doing so exists, the effects of movement of the whole frame of reference have not yet been explored, Past experience suggests that, when they are, the currently-provided coding will require some adjustment.
This feature will allow calculations of such phenomena as: The sloshing of liquids in tanks mounted on ships; mixing of fluids in a 'cocktail-shaker' 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 (see d_polis/d_enc/imbal.htm), which can already calculate the fluid-dynamic forces on bodies, will need to be extended so as to calculate moments too.

Solid-fluid-thermal analysis, SFT

SFT, the ability of PHOENICS to calculate stresses in solids and flows in fluids simultaneously, is another feature which is possessed uniquely by PHOENICS.

The solution algorithm used in all versions up to and including 3.5.0 converges rather slowly. However, it has been recognised, that there is another algorithm having better convergence properties. Now, The new algorithm has been implemented in version 3.5.1.

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!

The following four steps had to be taken:

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.
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.
Providing coding for the sources in the displacement equations for the solid-boundary cells. This required much care.
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?
The immediately-to-be-done items include:

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 moving-body-fitting-coordinate feature.

Data-input and results-display improvements

Data-input by way of formulae, In-Form

All CFD code-vendors recognise that they cannot provide all the flow-simulation features which users require. Some therefore, following CHAM's lead of 1981, permit their users to supply their own Fortran- or C-language subroutines.

CHAM's decade-old PLANT feature went further, by enabling PHOENICS itself to write error-free Fortran, on the basis of formulae provided by the user. The final stage of user-empowerment was 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 main developments in version 3.5.1 will be described.

Prescribing the motion of moving objects
Ascribing arbitrary sources to objects
The second major In-Form development has been the provision of means of ascribing arbitrarily-complex sources to VR-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.
In-Form statements created by the user, whether concerned with motion, sources, or any other of the various data-input possibilities, work by transmitting character strings to the EARTH solver module by way of SPEDAT commands.
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?

In-Form having been invented after the main structure of the VR-Editor was consolidated, its potential cannot yet be fully exploited by the Editor. There exists 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 li> 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.

The Virtual-Reality interface, VR

So many changes have been made so as to improve the appearance and functionality of the VR-Editor and -Viewer that it is practicable here merely to list them, as below:

Mouse control of view - rotate, pan & zoom
Animation of transient results, also in combination with MOFOR
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.
Improved plugins for AC3D - heal holes, orient facets, split into parts.
Extra turbulence models via Main Menu - KEMMK - Murakami, Mochida and Kondo k-e model and KEKL - Kato-Launder k-e model for flow around bluff bodies as encountered for example in wind-engineering applications.
Screen images saved with user-defined resolution.

New and improved utilities

The PHOENICS Commander

The formerly-existing PHOENICS Manager and PHOENICS Commander have been merged into a new single Commander utility, which performs all the functions of its predecessors, and many more.

It has been designed with new users of PHOENICS especially in mind, as is evidence 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.

Particularly useful is what is revealed when the input-file-library button is pressed; for this provides further buttons which activate a 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
Employing the LVEL turbulence model

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

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 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 s urface, 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.

ShapeMaker

The ShapeMaker utility has been improved and extended in the following respects:

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

Nu-PHOTON

Because the VR-Viewer is now capable of all that PHOTON could do, and more, by way of graphical display of results, the PHOTON delivered with PHOENICS 3.5.1 is unchanged from its immediate predecessor. 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.