by Robert Pyke, Consulting Engineer, Lafayette CA

It is widely acknowledged that good geotechnical engineering requires a combination of scientific knowledge and the art of applying engineering judgement which one gains primarily from experience based on meaningful case histories. However, the balance between the art and the science of geotechnical engineering has been upset in the last twenty years by the appearance of computerized analytical methods which often give the appearance of being scientifically correct when in fact they are not! I will get back to this point in a moment, but first let us examine some of the reasons that geotechnical engineers run computerized analyses.

There are good reasons and bad reasons for conducting formal analyses of geotechnical engineering problems. The bad reasons include:

1. To make work for consultants;
2. To satisfy regulatory authorities.

These reasons are often interlinked. Regulatory staff ask that certain analyses be performed, not because they are really needed but because the staff like to be seen doing something, and then the consultant, rather than questioning the regulators, use their demands as an excuse to get more work out of the client.

Good reasons for conducting formal analyses include the following:

1. To explore the sensitivity of proposed solutions to changes in geometry and material properties. This is particularly useful if there is some way of calibrating the analysis by checking it against the known performance of a similar problem. The best calibration of all is obtained when one starts with a failure on the site in question, but it is not suggested that you deliberately cause failures in order to calibrate your analyses!

2. To make full use of the observational method in geotechnical engineering design and construction. For example, the TAGAsoft program TCON can be used to estimate the significant increases in the rates of settlement of compressible clays layers that can result from installation of sand or wick drains, but the results of the calculation and the actual performance in the field are sensitive to the horizontal hydraulic conductivity, the thickness of the smear zone and the hydraulic conductivity of the smear zone which are difficult to predict in advance. Thus, more precise estimates of the rates of settlement and in-service dates can be made if the analytical results are calibrated by constructing test fills and/or carefully monitoring the initial response to the production program. If the initial response for wick drains at a given spacing is carefully monitored, the TCON analyses can be adjusted as necessary to provide a good fit to the observed results and then used to either amend the predicted in-service data, or if that is fixed by other considerations, to adjust the wick spacing to obtain the desired performance.

3. To extend our understanding of likely behavior when construction in new regions or on a new scale goes beyond our base of experience. This is particularly applicable in frontier areas such as arctic or deep-water construction, but may also be applicable where new materials, such as geotextiles, are used, or even in more routine earthworks construction when grading results in higher cuts and fills than have been customary in a particular area. Again, however, a cautionary note - even if a particular method of analysis or computer program has apparently given good results for problems in shallow water depths, or for smaller pile diameters, or at moderate confining pressures, the same method of analysis and computer program will not necessarily yield equally good results at great depths, for large diameter piles, or at high confining pressures.

The good reasons for conducting analyses are all consistent with the old adage that, at least in geotechnical engineering, the purpose of analysis is not to obtain precise numerical answers but is to obtain insight into the problem that is under consideration.

Our insight might be limited by the assumptions built in to particular methods of analysis and computer programs. It is one of those self-evident but often ignored truths that the user of any computer program should understand the limitations of the program and the method of analysis that is embodied in it before using it on real problems. However, it is evident from the author's consulting practice and from 15 years of supporting TAGAsoft programs that this is frequently not the case. Why is this so? At least three reasons can be suggested:

1. The basic documentation of geotechnical programs is often inadequate. Not only are the methods of analysis employed, and their inherent limitations, not adequately spelt out, but insufficient example problems are given to illustrate the sensitivity of common problems to key input assumptions. TAGAsoft has been as guilty as anyone-else on this score! When many of our programs were first released in the early eighties the Users' Manuals were quite good but the example problems were chosen more to show what the programs could do, rather than to show what they couldn't do. As a particular example, TCON includes so many options for sequences of loading and material properties that while it worked fine for all the combinations that we tested, it turned out that it didn't work for many other combinations. As our programs have evolved we have found it difficult to update the paper documentation to report bugs, illustrate work-arounds for bugs and other limitations, and to advise all users of updates. We are now implementing procedures for updating all our programs and their documentation through the Internet so that past problems should be minimized in the future.

2. Even with access to good documentation, many users appear to work under such tight time and monetary constraints that they neither check the available documentation nor make the time to run their own test problems. This is one of the results of the excessive competition that has developed in geotechnical engineering consulting. It can be combatted partly by vendors, such as ourselves, doing a better job on documentation but it also requires continuing education of both geotechnical engineers and their clients so that they better understand that using computer programs without understanding them is a notable example of false economy. This can lead to overly conservative and expensive designs on the one hand, and failures on the other.

3. Even with good documentation and sufficient time, verification of the suitability of a given computer program for a particular problem is not a particularly easy thing to do! Why? Because ideally this requires a thorough understanding of the method of analysis involved, knowledge of how that method is actually programmed, and the running of numerous test problems, both against known solutions and to check the behavior of the program as you move it away from known solutions.

The level of detail that is necessary to fully understand the methods of analysis that are employed in computer programs for even common problems such as limit equilibrium and consolidation is commonly not taught in Masters degree programs and in general is only acquired by Ph.D candidates working in one of these fields. That is not to say that practicing engineers cannot learn these details but this takes special effort.

The inability of most users to check the source code of the better geotechnical programs is difficult, if not impossible, to overcome since most of these are now proprietary, it being impractical to develop programs which have both sophisticated technical features and ease-of-use features in the public domain. Why is this even an issue? Because it is easy to check that a word processing program or a spread sheet does what the manual says it does, but it is not so easy to check that a finite element program does what the manual says it does.

As an example, FEADAM, a well-known public domain static finite element program, includes a procedure for reducing the angle of friction as a function of increasing confining pressure. This may be important in studying stress-redistribution in high zoned embankment dams because, in areas of stress concentrations, the stress levels may get high enough that strength impact the stiffness at working loads - and if the stiffness is impacted, the stress-redistribution changes and so on. However, most users will not check that this procedure is working as intended and it turns out that if the user specifies any non-zero value for the cohesion term in defining the strength, the reduction in the angle of friction is suppressed. This can be readily seen by reading the source code but not by reading the users' manual.

So, how can users overcome this kind of problem? Principally by running test problems that check the program being used against known solutions for simple problems and then testing each of the features of the program in turn by progressively running test problems that, for example, go to higher and higher confining pressures, in order to check that the pattern of behavior is reasonable. In TAGAsoft programs we also try to provide the user options to examine intermediate results. This can result in voluminous output files so users will not normally want to exercise these options on production runs, but they are available when the users wants to check a program out in advance or when unexpected results are obtained and the user wishes to follow the calculations in more detail. As an example, FEADAM only allows two iterations on properties for each load increment and it is not possible to follow the moduli that are actually used in the calculation. TELSTA not only allows the user control over the number of iterations on properties but also allows the user the option of tracking the moduli that are actually used from one iteration to another. TAGAsoft also assists companies and organizations that wish to acquire multi-site licences to perform their own QA and QC checks by making our source code available for inspection.

However, even if a computer program has no bugs and does exactly what it is supposed to do, there is a more fundamental limitation of which users should be aware. Most, if not all, geotechnical analyses are simplified in some way in order to make it easier to solve the problem in question. For example, limit equilibrium slope stability analyses involve several key assumptions that date from the days of hand calculations. These limitations are well understood by academic experts on slope stability analysis but appear to be not well understood by many practicing engineers. Two of the more obvious limitations of this class of analysis are: (1) notwithstanding the division of the potential sliding mass into slices for computational purposes, the potential sliding mass is treated as a rigid body; (2) because of the way the factor of safety is defined, the mobilised shear strength, or local factor of safety at the base of each slice, is assumed to be the same. These limitations between them mean that the stress distribution around the potential failure surface is most unlikely to be correct! So, even though we make a point of printing and plotting the base as well as the interslice forces in TSLOPE, and tout TSLOPE as providing a capability to run two-stage rapid drawdown analyses, in which the undrained strength used in the second stage is based on the stresses computed in the first stage, it should be understood that these stresses are in some sense artificial.