- A historical introduction
- Definition
- Mathematical aspects
- Finite-volume equations
- Integration procedure;
- Storage implications

- Implementation in PHOENICS
- Graphical display
- Library examples

When computational fluid dynamics first engaged the attention of engineers, during the 1960s, parabolic flows were a natural focus, because of their relatively small demands on computing power. For example, the first Patankar-Spalding program of 1967, which was later developed into GENMIX, concerned two-dimensional parabolic flows, such as boundary layers, jets and wakes.

The second Patankar-Spalding contribution to CFD, of 1973, namely the SIMPLE algorithm, was also first applied to three-dimensional parabolic flows in the first instance.

It is therefore not surprising that PHOENICS is equipped with a "parabolic option". The only surprise is that, after so many years, it has not yet been copied by CHAM's competitors.

The GENMIX code can be obtained as a free down-load, by application to CHAM.

- steady (ie independent of time),
- predominantly in one direction, defined as that in which the velocity vector nowhere has a negative component; and
- without recirculation or diffusion effects in that direction.

These conditions often prevail in boundary layers, shear layers, jets, wakes, pipes and other conduits, when the Reynolds and Peclet numbers, based upon the cross-stream dimension, are large.

Smoke plumes, flows in not-too-winding rivers, and jet-engine exhausts are practical examples.

Such flows are called parabolic because mathematicians have applied that adjective to the differential equations which describe them, contrasting them with the related but different "elliptic" and "hyperbolic" ones.

The main reason for distinquishing parabolic flows from elliptic ones is that their special features may be exploited so as to reduce greatly the time and expense of the calculations.

This exploitation is effected, in PHOENICS, by setting PARAB = T in the Q1 file. The same applies, incidentally, to hyperbolic flows, which also allow differences to flow downstream only.

**Hyperbolic** flows are those in which the velocity in the
main direction of flow is supersonic, which circumstance prevents
the upstream transmission of information in a steady flow. Then the
same economies as are associated with parabolic flows, namely
unlimited grid-refinement in the z-direction, can be enjoyed.

It is sometimes then said that the "parabolized Navier-Stokes equations are being solved".

Whatever it is called, PHOENICS provides for it.

Click here for the "mathematics of PHOENICS lecture"

The finite-volume equations for parabolic problems differ from the general ones in three respects.

The **first** is that the terms in the finite-domain equations involving
the coefficient aH are omitted. In parabolic calculations, the terms
expressing variations with time are also absent; so the general
equation reduces to the following form when PARAB=T:

phiP = aE.phiE + aW.phiW + aN.phiN + aS.phiS + aL.phiL + S ---------------------------------------------------- aE + aW + aN + aS + aL + aP

The **second** difference is the omission of the diffusive component
from the coefficient aL that connects the current z step to the
preceding one; so this term carries the convective contribution
only.

The **third** difference concerns the representation of the pressure
force on the z-directed velocity resolute w. The z-wise variations
of pressure level, p, are **decoupled** from the lateral (ie x and y)
variation of the pressures (which continue to be determined by
reference to cell-wise continuity).

The force on the w velocities is taken as -Dp/Dz. In confined flows, EARTH determines p by reference to slab-wise mass continuity at each z; in unconfined flows, p has to be defined in some other way (see IPARAB and pbar).

Because of the absence of the AH term, a single sweep through the integration domain suffices. However, in order that the non- linearity and inter-connectedness of the equations can be adequately represented, sufficient iteration must be conducted at each slab, in order that imbalances in the equations have been adequately reduced; for single-sweep parabolic calculations allow no 'second chance'.

Therefore, instead of the LSWEEP = 50 (say) which is set for an elliptic-flow problem, the corresponding setting in a parabolic-flow calcultion would be LITHYD = 50 .

To make one forward step in the integration sweep, it is necessary to hold in computer memory the variables relating to only two slabs: the local one, and its immediately-upstream neighbour.

This means
that an **unlimited** number of slabs can be employed without any any
increase of computer storage.

This means that a very-fine-grid solution can be obtained; because all available storage can be used for the cross-stream directions.

In PHOENICS, the predominant direction of a parabolic flow is always the z-direction. Storage is therefore provided only for the current and low slabs.

Attempts in GROUND coding to access "high" values will therefore fail.

To instruct PHOENICS to simulate a flow in the parabolic manner, it is necessary to set PARAB = T in the Q1 file.

LITHYD should be set to a sufficiently high value to ensure convergence. LSWEEP, which is used for this purpose in elliptic problems, has no significance.

The integer IPARAB also needs to be set in order to indicate how the downstream pressure is to be computed. This differs as between confined and unconfined flows; and it also allows certain hyperbolic flows to be simulated economically (See PHENC entry: IPARAB).

It is often desirable that the lateral dimensions of the domain, ie x and y, increase with downstream distance so as to permit the lateral growth of the mixing zone. The parameters AZXU and AZYV may be set to effect a variation of XULAST and YVLAST with z.

The parameter AZDZ similarly controls the growth of the forward-step size. When AZDZ=0.0, which is the default, the forward step is decided by the ZFRAC settings.

See also the PHENC entries: AZXU, AZYV, AZDZ.

Since, by definition, downstream events can have no upstream influence in a parabolic situation, no downstream boundary conditions are needed. Moreover, attempts to provide them may have undesirable effects, because PHOENICS will attempt to apply them at the last slab that it knows about, which is the current one.

Consequently, simply to set PARAB = T, at the end of a Q1 file that had been earlier set up for an elliptic-mode solution, would give an undesired result. For example, the IZ=NZ boundary condition corresponding to a fixed-pressure outlet would prevent any pressure variation at all.

Users who have hitherto used only elliptic-mode (ie PARAB=F) settings, are therefore advised to study the parabolic examples in the Input File Libraries.

If PARAB is T, EARTH storage is only provided for the current z-slab and the one preceding it (ie the lower slab); as a result, the data file used for PHOTON and EARTH restarts (PHI or PHIDA) contains only data from the last slab.

It can therefore be used for restarts but is not very useful for viewing results with PHOTON. However, a GX... subroutine, GXPARA, has been provided for the creation of PHOTON- readable output files for the graphical representation of the results of parabolic runs. GXPARA is called only when the following setting are made in the Q1 file:

PARAB = T and IDISPA = 1 or greater.

Setting IDISPA to a value greater than one will cause GXPARA to group the slabs in groups of IDISPA, and dumping only the values at the central slab of each group to the output file, thus allowing for economy of space and processing time for problems with a large number of slabs.

Users can also set IDISPB and IDISPC to the first and last slabs, respectively, for which results are to be dumped. The defaults are: IDISPB=1; IDISPC=NZ.

Formatted or direct-access files are created by GXPARA according to whether PHIDA=T or F in has been set in the PREFIX file by the user. Formatted files are named PARPHI, direct-access files PARADA.

If either XULAST or YVLAST is a function of IZ, then a geometry file PARXYZ (formatted) or PARZDA (direct-access) file is also written. PHOTON treats these files as it would the files generated by EARTH for a body-fitted-coordinate problem.

If there are any variables of which the values are not required to be written to PARPHI, the variable name should be set to a 4-character string, the last 2 characters of which are '**'; eg. NAME(R2)=R2**

(NOTE that only PHIDA or PHI should be used for restart runs, NOT PARADA or PARPHI)

The PHOENICS-core Input-File Library contains a special section in which all examples are parabolic.