Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Use of computer programs to predict settlement - there are several bad programs out there 3

Status
Not open for further replies.

eg1776

Geotechnical
Mar 14, 2008
8
0
0
US
Has anyone checked ILLICON 2016 against exact solutions? I am writing a user's manual for my finite element consol program that I wrote several years ago, and was verifying my current version with Hamilton Gray's 1945 solution for 3 cases. However, I was also trying to verify that I understood how to use ILLICON 2016 and developed three data files to check its use before I recommended the program to Parsons. ILLICON gives very wrong results when checked against classical Terzaghi and two layer (Gray, 1945) solutions.

The first figure attached here shows how ILLICON fails the simple check against the Terzaghi classical solution:

I have attached another figure that compares the degree of consolidation with time from Gray 1945, from my finite element program, and from ILLICON. the 3 cases use the following properties:

Hamilton Gray 1945 Check for a two layer system of 10 feet thick each.

Case 1 A has both top and bottom draining.
Case 1B has top draining and bottom impervious,
and Case 1C has the top impervious and the bottom draining.

The ILLICON results are in solid line colors of blue CASE 1a and Red CASE 1c. CASE 1b looks to plot over CASE 1c with an orange curve even though I used a different BC condition.

Third, I compared ILLICON and the D-Settle code (developed by the Dutch) for a live field test conducted in the Texcoco clay of Mexico City and the results from my Finite Element code TEXCOCON and measured field settlements with time. Both ILLICON and D-Settle give spurious solutions and apparently would predict infinite settlement at infinite times. See the attached comparison plot.

My conclusion is that ILLICON should not be used as it fails the most basic verification problems. I talked to Dr. Mesri in three different emails and conversations about this 6 months ago to alert him of this problem. As far as I know no fixes have been made to the code to correct these fatal errors. Furthermore, both D-Settle and ILLICON give wrong predictions of settlement at Mexico City's Texcoco test site. By contrast the FE code I wrote many years ago matched the measured data on the first interpretation of the soil layering and properties. No iteration or adjustment of properties or boundary conditions was conducted.
 
 http://files.engineering.com/getfile.aspx?folder=ff3c0a58-fdad-4e99-9063-76999cb34c43&file=Settlement_PRedicted_versus_Postena_field_test.png
Replies continue below

Recommended for you

This is another example of why you can't believe results of every programmers work. Doing it the lazy way, hoping the programmer caught all the possible variations, can get you in trouble. Start out by doing the the first "try" by hand calculations, even approximately to see what ball park you are in..

Why not set up your own spreadsheet to run through the calcs for you? That way are in charge.
 
Wow... I just read a paper from Dr. Mesri about the settlement of the Japan's Kansai International Airport which he used ILLICON for the analysis...

eg1776, this case can also be a good one for checking your program.
 
yes it could be, but my experience is there is rarely enough information provided by the paper to credibly repeat the case history unless you have unlimited aCcess and time and money equal to the original work. Illicon’s example of that case history illustrates the total and complete worthlessness of using field data for so called verification. It is just too damn easy to adjust your parameter to match observed data. It might be interesting to run the case history using illicon independently and with one set of independently derived geometry and properties to avoid using contrived data and inputs. But given that Illicon is fatally flawed already, there is nothing to gain in comparing to a problem with more unknown than knowns!.
 
eg1776: I'm interested to know how you implemented your FEA consolidation code. What was it based on? Are the inputs identical to the other programs, including seemingly unimportant things - such as time steps, element size, etc. - which often have a big role in the calculations for many programs?
 
Status
Not open for further replies.
Back
Top