2. Adequate vertical and horizontal discretization should be provided. This point cannot be stressed enough. This is one of the most common model usage errors because of the number of factors tied to grid discretization. Grid discretization should be based on the model application, not on available hardware. Grids that are too coarse may result in odd-looking (diamond-shaped) contours. These grid orientation effects can occur when the ratio of increments, i.e., length-to-width exceeds 10. Grids should also be graded smoothly in which the length increases by no more than a factor of 2 in any direction from one block to the next. Poor discretization also results in slow execution and/or simulation termination. This is because discretization directly effects the values that are used for dispersion and other coefficients in the model. Grid dimensions are provided on records R1-17, 18, 19.

3. The model user should include reasonable time steps recognizing the Courant number. This consideration is almost as important as grid design. Unreasonably large time steps may cause the model to perform many non-linear iterations or to "blow up". Also note that excessively small time steps may cause misleading mass balance calculations. At early time steps, there may be insufficient boundary fluxes which result in poor mass balance results. Time stepping information is entered on records R2-12. To check the values, specify IIPRT = 12 on R2-13.

4. The model user should use reasonable Peclet numbers for transport simulations. If the Peclet number (grid dimension/dispersion coefficient) is too large, the model will oscillate when using centered-in-space (R2-2). A large Peclet number will also unrealistically smear the spread of the concentration via numerical dispersion when using backward-in-space. Based on truncation analysis of one-dimensional systems, Peclet numbers greater than 4 may cause problems. However, a value of 10 or more is sometimes acceptable for multidimensional problems. The dimensions are provided in records R1-17, 18, 19. Dispersion coefficients are provided on record R1-2, R1-2.5. Check the values by specifying IIPRT = 12 on R2-13.

5. Accurate calibration should be performed. This is one of the most important aspects of model development, but continues to be overlooked by model users. Without sensitivity analyses demonstrating model results vs. observed data, predictive simulation are questionable.

6. Odd-looking results may indicate flaws in the system conceptualization, the application of model input or postprocessing. This includes stray contours, wavy-looking contours and diamond shaped contours in grids that are fairly well discretized. Make sure that all input data (especially R1-21) and grid conversions (Chapter 13) are correctly applied.

7. Wells should not be placed in zero pore volume blocks. This is a fairly harmless common error. Error codes are written to the output and are discussed in Appendix F. Zero pore volume blocks are entered in the R1-26 records. Well rates and locations are entered in the R2-6 and the R2-7 records, respectively.

8. Long term-simulations with weak regional groundwater gradients require special attention. If a long-term (5,000 - 10,000 year) simulation is performed, one may notice that, for certain geologic structures, the gradient will tend to dissipate. The gradient may not be maintained during a transient flow simulation when INAT (I-1 Record) is utilized. If this occurs, one may need to apply the regional gradient upon the modeled area by using: (1) a combination of perimeter injection and pumping wells (R2-6 & R2-7), or (2) pressure differential boundary conditions (R1-28).

9. If the model has an abnormal termination or "crashes", check the error codes written to the output file. These error codes are referenced in the Data Input Guide (Appendix F).

10. If the model application is small enough, use the direct solver. This will avoid all uncertainty associated with the iterative solver.

11. The model user should not casually use the default iteration and convergence parameters when using the indirect L2SOR solver (METHOD = "2). Convergence and mass balance should be monitored to check for correct application. Generally the solver requires a minimum of 3 or 5 iterations for variable density analysis. For steady-state water-table conditions, the number of outer iterations required is often between 10 and 20. When in doubt, print full diagnostics (KOUT = 0, IIPRT = 13, LMBAL = 1).

12. Labelling input data records in columns 71-80 should be utilized in order to improve QA, communication and transferability. Also, unused fields can also be used to enter comments and rationale for input parameters. For example, boundary conditions and perimeter wells can be identified to reduce confusion.
 

2. Provide adequate hardware for the model that you are running. It is always a good idea to have as much RAM as possible on a machine that is running simulations. The RAM requirements for each SWIFT simulation are printed by the code. If one doesn't have sufficient RAM available and have disk paging enabled, the model will run, but data will be written to the hard disk. This slows model execution considerably as the hard disk is much slower than RAM chips are. The use of a fast processor (Pentium 266, 300) is also recommended. This version of SWIFT is optimized for use on the Dual processors and runs best on it.

3. Array sizes must be realistically represented. Failure to dimension the array sizes in MAIN.FOR will result in abnormal model termination. The arrays should be dimensioned slightly larger than required by the problem.If not, the model may provide unreasonable results and eventually "bomb". The necessary array sizes are printed to the output file. Therefore, one may check the output file and edit the array sizes in MAIN.FOR accordingly. Please note that there are four primary arrays and each must be the correct size. Suggested sizes for 8, 12, 16, and 32 MB computers are included in MAIN.FOR.