This post originally appeared in 2013 on my companion site.

Recently I had a round of correspondence with a county official in Washington state re pile drivability studies and their place in the contract process.  (If you’re looking for some explanation of this, you can find it here).  His question was as follows:

During the bidding process, is the contractor’s sole basis for anticipating the size of the hammer needed the WEAP analysis? Does a contractor rely solely on design pile capacities or does the contractor combine geotechnical boring logs and cross-sections with his expertise? Who will be ultimately responsible that a large enough hammer is considered in the bid and brought to the site, the contractor or the preparer of the design package?

My response was as follows:

First, at this time the WEAP analysis is the best way for contractor and owner alike to determine the size of a hammer (both to make sure it isn’t too small with premature refusal, or too large and excessive pile stresses) necessary to install a certain pile into a certain soil.

It is a common specification requirement for a contractor to furnish a wave equation analysis showing that a given hammer can drive a pile into a given soil profile.  As far as what soil profile is used, that’s a sticky issue in drivability studies.  Personally I always attempt to estimate the ultimate axial pile capacity in preparation of a wave equation analysis.  There are two important issues here.

The first is whether the piles are to be driven to a “tip elevation” specification vs. a blow count specification.  For the former, an independent pile capacity determination is an absolute must.  For the latter, one might be able to use the pile capacities if and only if he or she can successfully “back them out” from the allowable capacities, because the design factors/factors of safety will vary from one job and owner to the next.  Some job specs make that easy, most don’t.

Even if this can be accomplished, there is the second problem: the ultimate capacity of interest to the designer and the one of interest to the pile driver are two different things.  Consider this: the designer wants to know the pile with the lowest capacity/greatest settlement for a given load.  The pile driver wants to know the pile with the highest capacity.  If you use the design values, you may find yourself unable to drive many of the piles on a job or only with great difficulty.  I’m seeing a disturbing trend towards using the ultimate capacity for design and running into drivability problems.

As far as responsibility is concerned, that of course depends upon the structure of the contract documents.  I’ve discussed the contractor’s role; I would like to think that any driven pile design would include some consideration of the drivability of the piles.

Some of the FHWA publications I offer both in print and online (including the Driven Pile Manual) have sample specifications which you may find helpful.

Hope this long diatribe is of assistance.

After this, there’s another way of looking at this problem from an LRFD (load and resistance factor design) standpoint that might further illuminate the problem.  The standard LRFD equation looks like this:

This is fine for design.   With drivability, however, the situation is different; what you want to do is to induce failure and move the pile relative to the soil with each blow.  So perhaps for drivability the equation should be written as follows:

It’s worthy of note that, for AASHTO LRFD (Bridge Design Specifications, 5th Edition)  can run from 0.9 to 1.15, which would in turn force the load applied by the pile hammer upward more than it would if typical design factors are used.  Given the complexity of the loading induced by a hammer during driving, the LRFD equation is generally not employed directly for drivability studies, and the fact that hovers around unity makes the procedure in LRFD very similar to previous practice.

The problem I posed re the hardest pile to drive vs. the lowest capacity pile on the job is still valid, especially with non-transportation type of projects where many piles are driven to support a structure.  When establishing a “standard” pile for capacity, it is still the propensity of the designer to select the lowest expected pile capacity of all the pile/soil profile combinations as opposed to the highest expect pile resistance of all the pile/soil profile combinations necessary for drivability studies.

Put another way, the designer will tend to push the centre of the probability curve lower while the pile driver will tend to push the centre of the probability curve higher.  This is a design process issue not entirely addressed by LRFD, although LRFD can be used to help explain the process.

This is the first installment of a new series on the development of the STADYN wave equation program for analyzing impact driven foundation piles. This program was the subject of this study and what you’ll see on this site is the sequel to that study.

The first in the series, however, isn’t really about technical aspects of the program and application, but something more mundane: formatting the output in a way that one can easily read the output. Although STADYN is written in FOTRAN 77 (with extensions) the techniques shown here are useful elsewhere and in other languages. In fact, techniques similar to these were used in the development of this routine, which is in PHP.

Engineers have done tabular output in regimented text format for many years. While it gets the job done, it’s not very pretty or easy to read, and requires some very regimented formatting to keep the columns straight. The simplest way to illustrate this is to use a worked example. Although ultimately the idea is to apply this to STADYN, the program used is a revision of the BENT1 program which is available on this site and goes back to the 1970’s.

BENT1 is a program designed to analyze pile groups for axial and lateral response to loading, and is in fact the ancestor of programs such as the COM624 series (it’s the first of those,) LPILE and APILE. It starts off with output that looks like this:

EX 1  COPANO BAY CAUSEWAY, ARKANSAS COUNTY TEXAS, US HIGHWAY 35    


          LIST OF INPUT DATA ---


          PV              PH             TM           TOL    KNPL KOSC
     0.8440E+06     0.3640E+05     0.1682E+08     0.1000E-02  4    0


        CONTROL DATA FOR PILES AT EACH LOCATION 

     PILE NO    DISTA        DISTB      BATTER         POTT       KS   KA
         1    -0.1260E+03  0.0000E+00 -0.2440E+00  0.1000E+01    1   1
         2    -0.9000E+02  0.0000E+00  0.0000E+00  0.2000E+01    1   1
         3     0.9000E+02  0.0000E+00  0.0000E+00  0.2000E+01    1   1
         4     0.1260E+03  0.0000E+00  0.2440E+00  0.1000E+01    1   1



  PILE NO.  NN         HH            DPS      NDEI   CONNECTION FDBET
     1     31    0.36000E+02    0.12000E+03    1      FIX    0.0000E+00
     2     31    0.36000E+02    0.12000E+03    1      FIX    0.0000E+00
     3     31    0.36000E+02    0.12000E+03    1      FIX    0.0000E+00
     4     31    0.36000E+02    0.12000E+03    1      FIX    0.0000E+00

Note the text is all caps (typical for the era) and formatted in a fixed-pitch format. The programmer had to exercise some care to get the columns and headers lined up properly, which in FORTRAN 77 could be a job.

HTML documents—which are still, in their various forms, what you see most often when you browse the web—are basically ASCII text documents with formatting markup. This is also true of XML documents as well. Just about any language can readily generate ASCII files, and FORTRAN 77 is no exception. One of the biggest changes in the Internet, however, is that, in the early days, HTML documents were generated by hand (including the markup) and were uploaded to a server as static web pages. Today virtually all pages are generated « dynamically » to varying degrees. (The major downside to dynamic generation is that many security flaws in web pages come from holes in the code, but that’s another post.) In a sense we’re going to make FORTRAN 77 become a dynamic page generator.

Getting back to the output above, the first line was generated by the following code:

 1111 FORMAT(20A4)
  100 READ(3,111,END=800) ANUM
      CALL UPPER(ANUM,72)
  111 FORMAT(72A1)
      READ(3,1111)IBUF
      CALL UPPER(IBUF,80)
...
  132 WRITE(4,111)(ANUM(IK),IK=KII,72)

Here the title is read one character at a time into a character array, converted to upper case using the « UPPER » routine, and then output to the file using the same format statement it was read with.

Turning to how to do this in HTML—and the HTML you’re going to see here is very old and basic—we start by generating the header for the page with this code:

 write(4,*)'<head><title>BENT2 Run for Case ',casenm,
&'</title></head><body>
<div align="center">' 

Just about all HTML pages have a header, and here we use the case name variable to « personalise » the title, which appears at the top of the page. Note also that, when we transition to the body portion of the page, we use a div tag to center all of the content. That’s a matter of personal preference. It’s also possible to put CSS in the head as well, which opens up possibilities to liven up the page. Whether you do that depends upon how deep into HTML you want to get. With twenty years of experience doing this, I could have done more, but what you’ll see will be an improvement.

From here we change the last line of the original code shown above to generate the title as follows:

 90 WRITE (4,*) '
<h2>',(anum(ik),ik=kii,72),'</h2>
'

The header tags (Level 2, I think Level 1 generally makes it too large) are placed at the start and end of line and the title is in the middle. We could have gotten rid of the all-caps business, but for starters we did not.

Now to the tabular data. The title and table immediately below the original code was generated using this:

     WRITE(4, 150)
 150 FORMAT ( // , 5X, ' LIST OF INPUT DATA ---'
    & /// 4X, ' PV PH '
    & , ' TM TOL KNPL KOSC')
     WRITE(4, 160) PV, PH, TM, TOL, KNPL, KOSC
 160 FORMAT (4E15.4, I3, I5)

This is a simple one-row table with a header above it. Doing this in HTML using HTML tables (which, I know, are hopelessly obsolete but in this case handy) results in the following:

 WRITE (4,110)
110 FORMAT ('
<table border="2" cellspacing="2" cellpadding="3">',
&'<caption>List of Input Data</caption>',
&'
<tr>
<td>Vertical Load on Foundation, kips</td>
',
&'
<td align="center">Horizontal Load on Foundation, kips</td>
',
&'
<td align="center">Moment on Foundation, in-kips',
&'</td>
<td align="center">Iteration Tolerance, in.',
&'</td>
<td align="center">Number of Pile Locations',
&'</td>
<td align="center">Solution Oscillation Control</td>
</tr>
')
WRITE (4,120) 0.001*pv,0.001*ph,0.001*tm,tol,knpl,kosc
120 FORMAT ('
<tr>
<td>',4(g15.4,'</td>
<td align="center">'),
&i3,'</td>
<td align="center">',i5,
&'</td>
</tr>
</table>
')

The last table shown earlier is only slightly harder to write. The original code (which includes the read statement) is as follows:

      WRITE(4, 170)
  170 FORMAT ( // , 5X, '   CONTROL DATA FOR PILES'
     &     , ' AT EACH LOCATION ' // 4X, ' PILE NO   '
     &     , ' DISTA        DISTB      BATTER         '
     &     , 'POTT       KS   KA')
      DO 200 K = 1, KNPL
      READ(3,*) LINNO, DISTA(K), DISTB(K), THETA(K),
     &      POTT(K), KS(K), KA(K)
      WRITE(4, 190)   K, DISTA(K), DISTB(K),
     &      THETA(K), POTT(K), KS(K), KA(K)
  180 FORMAT (4E10.4, 2I5)
  190 FORMAT (5X, I5, 1E15.4, 3E12.4, I5, I4)
  200 CONTINUE

The new table generation code looks like this:

 130 format ('
<table border="2" cellspacing="2" cellpadding="3">',
&'<caption>Control Data for Piles at Each Location</caption>',
&'
<tr>
<td>Pile Number',
&'</td>
<td align="center">Horizontal Coordinate of Pile Top, in.',
&'</td>
<td align="center">Vertical Coordinate of Pile Top, in.',
&'</td>
<td align="center">Batter, Degrees',
&'</td>
<td align="center">Number of Piles at Location',
&'</td>
<td align="center">p-y Curve Identifier',
&'</td>
<td align="center">t-z Curve Idenfifier',
&'</td>
<td align="center">Number of Pile Increments',
&'</td>
<td align="center">Increment Length, in.',
&'</td>
<td align="center">',
&'Distance from Pile Head to Soil Surface, in.',
&'</td>
<td align="center">Number of Flexural Stiffness Values',
&'</td>
<td align="center">Head Connection of Pile',
&'</td>
<td align="center">Rotational Restraint Value',
&'</td>
</tr>
')
DO 150 k=1,knpl
READ (3,*) linno,dista(k),distb(k),theta(k),
&pott(k),ks(k),ka(k)
150 CONTINUE
DO 180 i=1,knpl
READ (3,40) ibuf
CALL upper (ibuf, 80)
ieod=0
istrt=1
CALL iget (linno)
CALL iget (nn(i))
CALL fget (hh(i))
CALL fget (dps(i))
CALL iget (ndei(i))
CALL strget (tc(i), 3)
CALL fget (fdbet(i))
CALL fget (e(i))
WRITE (4,170) i,dista(i),distb(i),57.295779513*theta(i),
&pott(i),ks(i),ka(i),
&nn(i),hh(i),dps(i),ndei(i),tc(i),fdbet(i)
170 FORMAT ('
<tr>
<td>',i5,
&1('</td>
<td align="center">',g15.4),
&3('</td>
<td align="center">',g12.4),
&2('</td>
<td align="center">',i5),
&1('</td>
<td align="center">',i7),
&2('</td>
<td align="center">',g15.5),
&1('</td>
<td align="center">',i5),
&1('</td>
<td align="center">',a3),
&1('</td>
<td align="center">',g14.4),
&'</td>
</tr>
')
ndst=ndei(i)
DO 180 j=1,ndst
READ (3,*) linno,rri(i,j),xx1(i,j),xx2(i,j)
180 CONTINUE
write(4,*)'</table>
'

The biggest difference is the need to write multiple table rows. On the other hand, we were able to combine two tables into one, which makes for easier reading.

Note: WordPress (which powers this site) may power a quarter of the web, but it’s a very “vertical” format and doesn’t always “do horizontal” very well.  With non-mobile devices, the wider tables will bleed off to the right, but you can see them.  With mobile devices, it just cuts them off because these don’t have a left-right scroll.  Also, it doesn’t always reproduce FORTRAN 77 code very gracefully, we apologize for the inconvenience.

The final result of all of this coding looks like this:

EX 1 COPANO BAY CAUSEWAY, ARKANSAS COUNTY TEXAS, US HIGHWAY 35

List of Input Data

Vertical Load on Foundation, kips	Horizontal Load on Foundation, kips	Moment on Foundation, in-kips	Iteration Tolerance, in.	Number of Pile Locations	Solution Oscillation Control
844.0	36.40	0.1682E+05	0.1000E-02	4	0

Control Data for Piles at Each Location

Pile Number	Horizontal Coordinate of Pile Top, in.	Vertical Coordinate of Pile Top, in.	Batter, Degrees	Number of Piles at Location	p-y Curve Identifier	t-z Curve Idenfifier	Number of Pile Increments	Increment Length, in.	Distance from Pile Head to Soil Surface, in.	Number of Flexural Stiffness Values	Head Connection of Pile	Rotational Restraint Value
1	-126.0	0.0000	-13.98	1.000	1	1	31	36.000	120.00	1	FIX	0.0000
2	-90.00	0.0000	0.0000	2.000	1	1	31	36.000	120.00	1	FIX	0.0000
3	90.00	0.0000	0.0000	2.000	1	1	31	36.000	120.00	1	FIX	0.0000
4	126.0	0.0000	13.98	1.000	1	1	31	36.000	120.00	1	FIX	0.0000

So how does this look when implemented in STADYN? We’ll start with the case which compares STADYN’s output with Finno (1989,) and the output (after complete conversion to HTML) looks like this:

At the end, the page needs to be closed with a statement like this:

 write(4,*)'</div>
</body></html>'

In addition to the changes to the output, extensive changes were made to the input. The original code was a research type of code and the input was strictly from a file. Moving forward, the program was made more interactive to allow the program itself to generate the text file necessary for the input. Because of compiler limitations, for STADYN the dialogue is of a text type. It’s also possible to use dialog boxes and entry, depending upon the compiler and language you’re coding in. Many of the program’s options were « hard coded » into the program, as some preferences are fixed. Newer ones will be introduced, and discussed in later installments.

Although all of what’s discussed here is fairly primitive, the result is considerably easier to read and understand. It can also be copied into either word processing or spreadsheet software with little difficulty.

As noted earlier, later installments of this series will get into more technical aspects of the program, but improving the output will make these discussions easier for this or any program.

References

All references for this series are in the original study, unless otherwise noted.

This week we feature two programs for the analysis of deep foundations: BENT1 and PX4C3.  Although these names may not be familiar, if you’re in the deep foundation engineering field you’ll probably recognise some of their successors.

Let’s start with BENT1, the program description is as follows:

BENT1 is a program designed to analyse two dimensional problems involving pile supported foundations subjected to inclined & eccentric loadings. It consists of an interactive solution for the three equilibrium equations. The purpose of the iterative procedure is to find deflected position of the structure so that equilibrium and compatibility are satisfied. The pile cap is assumed to be rigid in the analysis. Subroutines MAKE and COM62 are used in this program. A complete description of the program can be found in the document “Background Theory and Documentation of Five University of Texas Soil-Structure Interaction Computer Programs,” Miscellaneous Paper K-75-2, by N. Radhakrishnan and F. Parker.

COM62 is the ancestor of all of the programs with that in the name, and ultimately programs such as LPILE.

Then we consider PX4C3:

PX4C3 is a finite difference program used to compute load settlement characteristics on an axially loaded pile of constant outside diameter. A set of load transfer curves along the pile (i.e., skin friction developed on the side of the pile relative to the absolute axial displacement of the pile section) & four point resistance curve at the pile tip (i.e., relationship between the total axial soil resistance on the base of the pile tip & the pile tip movement) are used in program to obtain non-linear soil-pile relationships. Finite difference equations are used to achieve compatibility between pile displacement & load transfer along the pile & between soil resistance & load transfer along the tip of the pile. A complete description of the program can be found in the document “Background Theory and Documentation of Five University of Texas Soil-Structure Interaction Computer Programs,” Miscellaneous Paper K-75-2, by N. Radhakrishnan and F. Parker.

This is the ancestor of programs such as APILE.

Complete documentation for both programs is included, and can also be found here.

Download BENT1 and PX4C3

It’s official: the construction management textbook Soils in Construction, Fifth Edition by W.L. Schroeder, S.E. Dickenson and D.C. Warrington is now at Waveland Press.  As someone who has dealt with contractors for his entire working career, I know that an understanding of the essentials of soil mechanics and foundations is crucial for successful–and profitable–completion of just about any civil engineering project.  Most soil mechanics and foundations textbooks are aimed at design professionals or engineering students; Soils in Construction, Fifth Edition is aimed at the contractor and the construction management student. It presents soil mechanics concepts in an easy to understand fashion. It includes many worked examples and illustrations to make understanding of the basic concepts simple.

And the really good news is that, with Waveland as publisher, the price has been reduced considerably.

Chapters in the book are as follows:

1. Physical Character of Soil Constituents
2. Natural Soil Deposits
3. Soil Index Properties
4. Soil Classification
5. Stress Analysis and Engineering Properties
6. The Contract and Contract Documents
7. Interpretation of Soils Reports
8. Embankment and Construction Control
9. Dewatering
10. Excavations and Excavation Supports
11. Foundation Construction
12. Construction Access and Haul Roads

The book also has two appendices:

• Laboratory Testing Exercises
• Pile Hammer Specifications

You can order a copy of the book by clicking on the graphic above or here.  Academics who would like more information or order a desk copy can do that here.

Last week we posted an update to the program VDISPL, which estimates vertical displacements/settlement for shallow foundations.  Now we feature another program from our Bearing Capacity of Soils volume, namely AXILTR.

Program AXILTR, AXIal Load-TRansfeR, consists of a main routine and two subroutines. The main routine feeds in the input data, calculates the effective overburden stress, and determines whether the load is axial down-directed, pullout, or if uplift/downdrag forces develop from swelling or consolidating soil. The main routine also prints out the computations. Subroutine BASEL calculates the displacement at the base for given applied down-directed loads at the base. Subroutine SHAFL evaluates the load transferred to and from the shaft for relative displacements between the shaft and soil. An iteration scheme is used to cause the calculated applied loads at the top (butt) to converge within 10 percent of the input load applied at the top of the shaft.

The program is designed to run exactly as shown in Bearing Capacity of Soils, and you can find complete documentation there, as well as the source code for the program.

As was the case with VDISPL, the program was written by Lawrence D. Johnson at the Waterways Experiment Station.

Download AXILTR