If the program fails to run at all, then this is usually a sign that some of the formatted input data is not correct (no empty lines where these were expected, or an empty line where data was expected, or similar formatting problems). The screen monitor information then says that the file has broken down in a particular input subroutine; this provides a clue for identifying which file has an incorrect format. Most straightforward errors caused by new users or new cases are related to the data input files, which are fairly rigid with regards to the lines of data and which do not accept an empty line where a line of data should be. No built-in con-sistency checks of the input data are made, so errors of this nature can easily occur, especially at the beginning of a completely new calculation. To help avoid this type of error, you can copy lines from similar existing input files.
The program might report the name of the input file that contains an error. Should such errors happen, you should examine the .hst file where the input data is recorded. From this, you can determine which file has not been correctly read or might have errors, and also which part of that file has been successfully read.
If the program reads all the input files, starts successfully but then fails before the iterations begin, then this is often a problem related to the specified flow and speed conditions in the input data or the geometry specification, and these should be checked. These errors are usually related to errors in the units of the specified data (flow conditions, boundary conditions, geometry, empirical data, and so on). A typical user error of this type is that the diameter is needed as a reference value for the size in the flow information (.aer), but the user specifies a radius because the coordinates in the geometry file (.geo) are radius values.
Another common error with users is to specify the geometry in inches rather than meters. Another typical user error of this type is that the pressure is specified in bars whereas it is expected to be in N/m2. Other errors may be related to the fact that the specified flow conditions imply choked flow or reverse flow. A useful consistency check of the flow data is made where the following information is printed:
Vista TF: Axial compressor calculation
---Estimated mean flow coefficient cm/u at first rotor inlet = 0.4567 Estimated mean Mach number cm/a at first rotor inlet = 0.4426
These values may be used to identify if the mass flow, speed and other data have been specified sensibly, as typical values of these parameters for each type of machine will be known.
If the program runs, but breaks down after only a few iterations, then this can often be a sign that some of the input data is still not correct because the program is generally very reliable. Here the strategy is to reduce the value of the maximum number of iterations to a lower value than that at which the flow breaks down
Appendices
the results in the .hst and .out files. The errors are usually related to mistakes in the specified data (such as flow conditions, boundary conditions, geometry, and empirical data) rather than mistakes in the numer-ical method, and these data problems can then often be identified from un-converged results or values provided in the .hst,.txt and .out files. It can also be useful at this stage to examine the plot files of the initial geometry set up by the program, which is named test_prefix.txt or test_prefix.csv. This can often identify aspects of the geometry or flow data that are inconsistent.
If the program runs, but the results are extremely unexpected, such that a pump impeller or a compressor stator blade row has been interpreted by the program as a turbine row, then the blade angle definition should be checked. The program attempts to identify the type of blade row from the geometry specified, but in some cases the rules that have been programmed may fail. For example, a compressor stator is identified as a stator blade row which turns the absolute flow towards the meridional direction, that is the blade angle decreases from the leading edge to the trailing edge through the blade row. In some special cases, such as an axial compressor stator with a degree of reaction above 100% or rotor blades with extensive local leading edge recamber, the blade may have other blade forms. In these cases it is possible to specify additional data in the geometry file (see parameter i_row below) to overwrite the program’s own attempts at blade type identification. Geometry produced by BladeEditor contains blade type information provided that, in the blade feature within BladeEditor, a blade type (rotor or stator) is specified.
Convergence
The program has several different internal convergence checks, but a converged solution can be achieved only if all of the internal loops also converge, so only one convergence criterion really needs to be checked, which is the convergence of the meridional velocity.
The most important convergence check is the maximum error of the local meridional velocity anywhere in the flow field, expressed as a percentage of the local meridional velocity and denoted as error_cm (%) on the screen and in the output files. During the iteration process, the maximum value of the change in the meridional velocity in the whole flowfield between one iteration and the next (delta_cm %) and the loc-ation of the maximum error is printed onto the screen every 10 iterloc-ations and into the history file for each iteration. The local value of this error is also printed in the output file and into the .csv and .txt plot files. To achieve convergence near machine accuracy, use a maximum value of 0.01% as a convergence cri-terion. Note that this corresponds to a maximum residual error in CFD terminology of 0.0001, that is 1E-04, which is a much more stringent criterion than the RMS residual error often used in CFD programs of 1E-04.
The value of the local error is output for examination with plot software and, for cases that have not con-verged, it is worthwhile to examine the location of the maximum as this may identify the location of the problem.
It is important to remember, however, that numerical methods have many sources of error. In a throughflow calculation, the so-called model errors, related to the fact that the equations we are solving do not really describe the real flow particularly adequately (in this case we solve for inviscid, circumferentially-averaged mean values on widely spaced grid lines) probably outweigh all other sources of error. A solution that is converged to a maximum error in meridional velocity of 0.5% is likely no worse in terms of its agreement with reality than a solution that converges to 0.01% or lower. So calculations that converge to 0.5% can also be considered to be converged for practical engineering purposes.
The second convergence check occurs in the innermost mass-flow iteration loop where the program monitors the number of loops required to solve the continuity and radial equilibrium equations on each calculating station. The maximum value of the number of mass flow iterations and the location of the quasi-orthogonal where this occurred is also printed onto the screen and into the .hst file. You can specify the maximum number of loops for the internal mass-flow iteration loop with the max_it_mass parameter in the control file. The recommended value for this parameter is 10. Early in the run, the program usually stops the internal loops when the value of max_it_mass is reached. Later, as convergence is approached, less then 10 internal
loops are generally required. A typical converged solution may require only 1 or 2 internal loops. The error in the mass flow should be tighter than that for the meridional velocity; a value of 0.001% is currently re-commended.
The third convergence check occurs in an iteration to a specified pressure ratio and is related to the conver-gence of the inlet mass flow to a final value and the converconver-gence of the specified target pressures at the trailing edges to a fixed value. These are written onto the output file as error_p and error_mass respect-ively. The same limit for the mass flow convergence is used as given above and the target pressure conver-gence is set internally within the program to be tighter than this. Experience shows that it is important in simulations to a specified pressure ratio to ensure that tight tolerances on these parameters are given, oth-erwise the program modifies the target pressures on the basis of inadequately converged data and divergence may result.
In some cases with closely spaced calculating stations (high aspect ratio grid) it has been identified that, although the simulation converges to a relatively low level of the maximum error in the meridional velocity of 0.1% relatively quickly, it does not always continue to converge below this level of error. In these cases you have several options. Firstly, it might be sensible to accept this level of convergence and continue to optimize the geometry of the machine. In some cases, the simulation that is not perfectly converged may indicate the existence of an unwanted flow feature as a cause of the poor convergence. Such features include:
anything that creates a tendency for the flow to reverse direction; an extremely high curvature in the meri-dional channel; a poor grid. A second approach is to make use of other models that are built-in for the damping factors within the program, by reducing the value of the streamline curvature damping factor damp_sc and the velocity level damping factor damp_vl. In some cases it may be helpful to reduce both the value of damp_sc and damp_vl to smaller values than the standard values of 0.25 and 0.40.
The most common failure for the program to converge is related to difficulties in the streamline curvature calculation causing divergence of the maximum error in the meridional velocity distribution. If the program identifies a trend for the results to start to diverge then it automatically decreases the damping factors to avoid divergence by causing more damping of the solution. If the errors continue to increase, then further reduction of the relaxation factors tends to freeze the unconverged iteration at the state where the problem was identified so that there is at least no unexpected exit from the program even if the simulation does not converge. Because of this feature it is not advisable simply to increase the number of iterations in the hope that the simulation will converge. A better strategy is to calculate with a large number, say 2000 iterations, and if the simulation does not converge, restart the calculation from the restart file to reset the damping factors to sensible values. This strategy often works in difficult cases.
The numerical fix of reducing the damping factors when the error diverges is reported on the screen and in the history file. If this fix does not work, then the calculation of the streamline curvatures may ultimately fail, although this only occurs in simulations that have otherwise started to have serious numerical problems.
The ultimate failure here tends to be an error in the subroutine pero, called from subroutine curvature, or in subroutine parabola, called from subroutine streamlines. Both are, in themselves, generally robust.
Subroutine pero is a modified interpolation routine along the lines of the so-called AKIMA splines. The breakdown is related to the numerical difficulty of calculating curvatures in a flow when the streamlines are no longer smooth and the spacing of the calculating planes is small. Subroutine "parabola" attempts to fit a parabola through internal data in the program and is also robust until serious problems occur. These errors have mostly been trapped such that an error message is printed and the program exits the calculation without breaking down.
In cases where such problems occur, it is often worthwhile simply to run the simulation again from the restart file generated from an earlier unconverged simulation or with a different initial estimate of the flowfield (which is controlled through the initial value of cm_start in the control file), because starting from better initial conditions may clear the problem found in the initial calculation. In choked flows it is generally better
Appendices
useful strategy is to reduce the value of the maximum number of iterations to a lower value, say 200 (para-meter max_it_main in file .con), and recalculate and examine the unconverged results. It may also help to run the simulation repeatedly with a low limit on the maximum number of iterations because each suc-cessive run tends to get to a lower value of the maximum error. If this fails, it is useful to examine the .hst and .out files and plots of the unconverged results. These files and plots can be used to identify aspects of the design that, when improved, allow convergence to be achieved.
The program also writes the values of the local error and the local choke ratio into the .txt file so it is possible to examine this and quickly locate the location where the problems are occurring. A value of unity for the choke ratio implies that the flow is choked and a value above unity indicates that the local mass flow is above the choking mass flow of the streamtube. It may be necessary to have some fundamental understanding of how the turbomachine operates in order to identify how to remove these problems. Further comments on choking are given in Choking (p. 142).
The program prints an error message if it reaches a state where the maximum change in meridional velocity from one iteration to the next is more than 400% and then it closes down the calculation. Should this occur it is then recommended that you repeat the calculation with the maximum number of iterations set at a value lower than that where the program stopped (see the history of iterations in the output file) and then examine the results for this unconverged point. This can help you to identify the problem.