DIAGNOSING COMPUTATIONAL PROBLEMS IN FEQ

- 1. Errors in Processing Model Input
- 1.1 Conversion Errors
- 1.1.1 No visible format error
- 1.1.2 End-of-file reached or wrong line read
- 1.2 Table Type and Range Errors
- 1.2.1 Invalid table type
- 1.2.2 Argument below range in time-series table
- 2. Checking Warning Messages
- 3. Failure During Steady-Flow Computations
- 3.1 Missing depth
- 3.2 Maximum iterations exceeded
- 3.3 Initial conditions for tidal boundaries
- 3.4 Table below range
- 4. Failure During Unsteady-Flow Computations
- 4.1 Frozen-time failures
- 4.2 Zero pivots
- 4.3 Table overflows
- 4.4 Table below range
- 5. Computational-Problem Diagnostic Chart

Plate 1. Diagnostic flow chart for resolving computational difficulties with FEQ

The unsteady-flow simulation of every new flood wave has the potential to encounter problems with hydraulic features that were not apparent with earlier flood waves. A model that has successfully computed 25 different flood waves may fail to complete the computations for the 26th flood wave. The reason may be that no two flood waves are exactly alike and, therefore, each new flood wave has the potential of making use of some function in a new argument range. Also the pattern of flows for the new flood wave may differ across the hydraulic system, which may introduce computational difficulties not experienced in previous flow simulations. These effects can be minimized by attempting to reduce the frequency of abrupt changes in values in any function involved in the computations. The more abrupt the change, the more likely are computational problems at that change; therefore, unnecessary abrupt changes should not be introduced.

A stepwise development of the unsteady-flow model representation of the simulated stream is assumed. This means that the complete model input has not been prepared before making test runs with a simplified version. This greatly reduces the probability of encountering so many problems in the initial runs that the causes cannot be determined. The model should start out simple even though it is not fully representative of the problem being considered. Once the simple model is debugged, a series of refinements is begun, with one or more test runs made for each refinement to determine the problems. This makes it easier to find the source or sources of the problems.

A step-by-step process is presented here to help find and solve the problem. These are guidelines only, and there is no guarantee that the solution will be found immediately. It is rare for a model to run to completion on the first try. Unsteady-flow computations are highly complex, and not tolerant of even minor errors in the model representation. Small and simple models sometimes do run to completion after the input-processing errors are fixed, but it is normal to make several runs before the desired computations are completed. Even after much user experience in unsteady-flow applications, there will still be computational problems that present a challenge. However, there is always a solution for every problem: not always as elegant or exact a solution as wanted, but one that will be acceptable given the design constraints.

[Begin] [Table of Contents] [Back to FEQ Web Resources]