It is with sadness that we report the death of Dr. Harry M. Coyle, professor of civil engineering at Texas A&M University from 1964 to 1987, back in January.  You can read the entire obituary here.

For those of us involved in deep foundations, his name is a familiar one, and his monographs have graced this site and its companion, vulcanhammer.info, for many years.  Among other things he is known for the Coyle and Castello method for estimating pile capacity in sand, the Coyle and Gibson method for determining damping for pile dynamics analysis, and the co-developer of the PX4C3 routine for axial load-settlement estimation, which we feature on this site, and which is the ancestor of many of those in use today.  He was deeply involved in the development of the TTI wave equation program, and some of his work relating to that is here.

Our continued condolences and prayers go to his family, and, as the obituary states, “Having loved his friends and family well, Harry Coyle will be missed by all until we are reunited with him in Glory. “

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.