(common types and avoidance of)
(See PHENC entry of this name)
(See PHENC entry of this name)
(See PHENC entry of this name)
Probably the most common mistake of all is to expect too much too soon. Thus you may build up an extensive GROUND structure, for a flow process involving many simultaneous and complex non-linear processes; and you may then suppose that PHOENICS will derive from it plausible flow predictions at the first attempt.
Experience has shown that few such PHOENICS users achieve more than occasional and accidental advantage from their boldness; for they over-estimate their own ability to write extensive tracts of error-free fluid-dynamic coding; and they neglect the fact that non-linear equation systems can be solved only in a few well-defined ways.
You are therefore recommended to introduce the special features of their models step-by-step, testing as they advance. The more numerous are the component processes involved, the more prolonged should be the first and second stages of the three-stage approach.
Users sometimes forget that computers can handle only a limited number of significant figures, and that attempts at excessive precision may be self-defeating.
For example, you might wish to enforce the condition that the pressure in the vicinity of an outlet had a definite value; and, to this end, you could reasonably set the relevant 'coefficient' to FIXVAL, which has the pre-set value of 1.0E10, and the corresponding 'value' to the desired pressure.
However, a large coefficient would require very small pressure differences to be computed; and these might well be below the level at which round-off errors become appreciable.
Thus, it could be that tiny but fluctuating pressure differences, being multiplied by large coefficients, would cause finite continuity errors to be reported constantly. It is for this reason that the quantity FIXP has been made available in the SATELLITE; its value is 1.0, which is sometimes more suitable for setting pressures. Generally speaking however, you have to take responsibility for specifying your pressure boundary conditions; for only you know just what situation you are trying to simulate.
Similar consequences may follow from the employment, in transient-flow problems, of excessively small time steps. The motive may be to gain accuracy, regardless of computer- time cost; but the result is a loss of accuracy because the transient terms in the finite-domain equation, having the same time interval in the denominator, are so large as to 'swamp' the other terms.
For PHOENICS therefore, as for many other situations, the wisest choice is to avoid extremes.
Although the final solution is usually independent of the initial guesses supplied (via FIINIT or PATCH and INIT) by you, these guesses can influence both the time taken to attain the solution, and indeed whether the solution is reached at all, as has been mentioned in sub-Section 5.8 above.
It is therefore a good rule to seek always to supply initial guesses which are as close as possible to the values to be expected in the final solution. Thus, they should have the right sign, and be of the correct order of magnitude; and the velocity fields should satisfy continuity.
If this is not done, PHOENICS will normally attain the correct solution, but at a greater cost in computer time than is necessary; and sometimes the initial guess can be so far from the solution that divergence occurs.
Computers work to only a limited number of significant figures. It is therefore advisable to avoid producing calculated results of the following kinds:
These can be avoided by use of suitable datum levels for the enthalpy or pressure (see PRESS0) respectively, or by non- dimensionalisation.
It is hard to know in advance precisely what print-out will be required. Some users therefore call for much more than they are sure to need, just in case it will be found to be useful; but, in doing so, they create needless difficulties, burdening themselves with more paper or longer output files than they can possibly inspect.
Because of the ability easily to 'restart' a PHOENICS computation, it is best to call for only a small amount of output at first, concentrating perhaps on the 'residuals', and how they diminish with number of sweeps; and this should be viewed at the VDU, without recourse to the line printer. If the results of the computation are saved, by way of the SAVE=T setting in Group 24 (this is the default), it will always be possible to elicit desired output by making one more sweep with the appropriate settings in Groups 21, 22 and 23 (see AUTOPS).
Thus, a series of minimum-output runs may be made, by a succession of restarts, until it is judged that the solution is sufficiently converged to be interesting. Then a succession of single-sweep runs can be made, with various output options, until tables and plots containing the desired combination of information items, suitably displayed, have been elicited. Only at the end of this is it appropriate to cause the output actually to be printed.
When divergence occurs at the start of a run, printing out and inspecting the field values for the first two or three sweeps will often permit the cause to be discerned. For example, it may reveal that some variables have totally unrealistic values even at the start, possibly because of errors in coding introduced into GROUND; or the occurrence of low pressures near what is ostensibly an outflow boundary may reveal that inflow is occurring there, with the consequences which have been referred to above.
It is rarely desirable that complete tables of field values are required to be printed; therefore, when fine-grid runs are being performed, a user who neglects the numerous print- out-control features of PHOENICS can impose a needless burden on himself.
Attention is therefore drawn to the "output-thinning" variables NXPRIN, NYPRIN, NZPRIN, NTPRIN and NPRINT, the functions of which are described in TR 200. In this connexion, it may be convenient to make settings such as NXPRIN=NX/5 in the SATELLITE; for these will keep the amount of print-out approximately the same, even when the values of NX, NY etc are changed.
The sizes of the output tables can also be limited by setting IXPRF, IYPRF, IZPRF, ISTPRF and ISWPRF to values in excess of 1, and those of IXPRL, IYPRL, IZPRL, ISTPRL, ISWPRL to values below NX, NY, NZ, LSTEP and LSWEEP respectively. Once again, TR 200 should be consulted for more complete information.
Finally, the use of PROFIL- and CONTUR-type patches, especially when the associated field values are printed out as numerical tables (see ITABL) can often provide all the numerical information which is needed. Then the regular field output can be dispensed with, by setting: OUTPUT(variable,N,,,,,).
Oversights sometimes occur in respect of the formulation of mass inflow conditions at IZ=NZ. For example, a user might make the following settings for an inflow of mass of 2.0 kilogram per metre-squared per second over one half of the slab at NZ:
PATCH (INLET,HIGH,1,1,1,NY/2,NZ,NZ,1,1)
COVAL (INLET,P1,FIXFLU,2.0)
COVAL (INLET,V1,ONLYMS,0.0)
COVAL (INLET,W1,ONLYMS,0.0)
Although the correct ascriptions are made for P1 and V1, that for W1 will have no effect whatsoever, because the w velocities at NZ are not solved for. In order to account for the effect of the inflow of w momentum, it is necessary to define an additional PATCH exclusively for the specification of the inflow of w momentum on the w's at NZ-1, namely:
PATCH (WIN,HIGH,1,1,1,NY/2,NZ-1,NZ-1,1,1)
COVAL (WIN,W1,2.0,-2.0/RH01)
The coefficient of 2.0 represents the mass inflow and as such is postive. The value of -2.0/RH01 represents the w momentum convected into the cell by this mass flow rate; it is negative because the w is directed from high z to low z.
It is only for w-velocities at IZ=NZ that you need to take this action; for all other circumstances EARTH makes the necessary adjustments internally.
wbs