STADYN Wave Equation Program 2: Effective Stress, At-Rest Lateral Earth Pressures and Poisson’s Ratio

Posted on 8 June 201726 May 2025 by Don Warrington

With the output improved, we can turn to the first topic of interest. Before we do that, we need to discuss our test cases.

Test Cases

The original study featured several test cases. For this and subsequent installments, we will concentrate on three of those:

FINNO2, which features the actual static load test output from Finno (1989).
SEASIA, which is a GRLWEAP comparison from a notional offshore pile case in Southeast Asia.
MANDK3, which features the inverse solution of an instrumented pile in the New Orleans area. The original GRL report for this is Mondello and Killingsworth (2014). Several soil profiles were analyzed using both standard and annealed polytope methods of analysis. For this study the four-layer annealed polytope case will be featured, as its results a) seemed to be the most reasonable and b) matched the standard results very closely.

Details of the original results are shown in the original study.

Effective Stresses, Vertical and Horizontal

The concept of effective stress is a foundational one in geotechnical engineering, and is discussed in textbooks such as Fellenius (2015) and Verruijt and van Bars (2007). As is the case with “classical” methods of analysis, it is necessary to compute these for successful geotechnical finite element analysis. However, there are two important considerations that come up with finite element analysis that can usually be ignored with simpler methods.

The first is that it is necessary to apply gravity forces at the start of the run to the elements to simulate the impact of effective stresses on the soil finite elements. This is one of those important steps in analysis that most manuals and discussions of commercial codes mention in passing but do not detail how they are done. It is one of those phenomena that has “gone dark” in the literature. The original study presented an outline on the procedure for computing the effective stresses and applying them to the elements.

The second is that the computation of effective stresses concentrate on the vertical stresses and generally ignore the horizontal ones until retaining walls come into play. Nevertheless, for any three-dimensional continuum such as the semi-infinite soil mass we assume in geotechnical analysis, horizontal stresses are guaranteed to exist, if nothing else via the theory of elasticity. If we use the theory of elasticity, which is valid in an elastic-purely plastic model such as is used in STADYN until the yield point is exceeded, the relationship between the horizontal and vertical stresses is given by the equation (Verruijt and van Bars (2007))

$\frac{\sigma_{x}}{\sigma_{z}}=\frac{\nu}{1-\nu}\$ (1)

where $\nu$ is Poisson’s Ratio, $\sigma_z$ is the vertical stress, and $\sigma_x$ is the horizontal stress. We normally define the left hand side thus:

$K = \frac{\sigma_{x}}{\sigma_{z}}$ (2)

For our case, the lateral earth pressure coefficient $K$ is the at-rest lateral earth pressure coefficient, generally expressed as $K_o$ . This is reasonable for this case because, since we have a semi-infinite soil mass, the soil literally has nowhere to go, thus all of the horizontal strains are zero. This is a key assumption for Equation 1. We can thus combine Equations 1 and 2 to yield

$K_o = \frac{\nu}{1-\nu}\$ (3)

In theory, we could compute the lateral earth pressure coefficient using Equation 3 and “reasonable” values of Poisson’s Ratio.

Turning back to STADYN itself, soil properties in most cases (and especially for inverse problems) are defined using the “ξ – η” system, which in turn uses typical values of various soil properties to reduce computing same for a given typical soil state to two dimensionless variables. Using this system, Poisson’s Ratio is a function of ξ and η, and is thus varied as these dimensionless parameters are varied. The variation of ν with ξ and η is shown in the original study. As a practical matter, even if Poisson’s Ratio is measured for each project and soil profile (an unlikely situation at best,) the problematic nature of soil elasticity makes accuracy of the parameter equally problematic. Another approach is to begin by considering the following empirical relationship

$K_o = 1 - sin(\phi)$ (4)

This is Jaky’s Equation. It has been shown to be reasonable for normally consolidated soils, although there are other relations in use for both normally and overconsolidated soils. Values of the at-rest lateral earth pressure coefficients are limited to $0\leq K_{o}\leq1$ , the upper limit achieved for a purely cohesive soil where $\phi = 0$ . As the original study noted, Equation 4 is a common expression to compute horizontal stresses from vertical effective stresses in finite element codes, and is used to compute the horizontal effective stresses in STADYN.

Unfortunately this leaves an inconsistency between the way horizontal stresse sare computed between the effective stress computation and subsequent computations. To remedy this problem, we can combine Equations 3 and 4 and solve for Poisson’s Ratio to yield

$latex \nu=\frac{sin\phi-1}{sin\phi-2}\ $ (5)

Poisson’s Ratio is varied here as $0\leq\nu\leq0.5$ , where once again the upper limit is for purely cohesive soils. This indicates that these soils act as a fluid, which is nearly true for very soft clays. The main problem with this result is that, when ν = 0.5, the consitutive matrix experiences singularities. The simplest way to deal with this problem is to limit Poisson’s Ratio to a value below this one. In STADYN this value is 0.45.

Comparison With Previously Generated Values and Forward Test Cases

Having defined a new way of generating values of Poisson’s Ratio, we can compare these values both with the original values and with the two forward test cases. We will leave the inverse test cases for a later post.First, the original “ξ – η” relationship to generate Poisson’s Ratio values is shown in Figure 1.

Poissons Ratio

Figure 1: Poisson’s Ratio “ξ – η” Relationship, Original Configuration

We can see that Poisson’s Ratio is independent of η in this configuration,and
$0.25\leq\nu\leq0.45$ for $-1\leq\xi\leq1$ . Computing Poisson’s Ratio based on Equation 5 yields the result shown in Figure 2.

Poissons Ratio Revised

Figure 2 Poisson’s Ratio “ξ – η” Relationship, Jaky’s Equation

There are several differences to note, as follows:

The maximum value is ν = 0.5 for the revised relationship. To prevent singularities in the constitutive matrix, in actual application Poisson’s Ratio is limited as described earlier, a similar concept to the “corner cutting” for Mohr-Coulomb failure.
For purely cohesive soils, ν is invariant in both cases. As ξ is reduced and internal friction is increased, ν varies with η. In other words, Poisson’s Ratio tends to decrease in cohesionless soils as the relative density of the soil increases.
The range of possible values for Poisson’s Ratio in both cases is very much the same; it is simply distributed differently in the continuum.

As far as the forward test cases (the first two) are concerned, SEASIA is the same in both cases because the soil is assumed to be purely cohesive, thus Poisson’s Ratio is the same in both cases.

For FINNO2, the simplest way to compare the two is to compare the hammer blow counts and the Davisson static load test result. That comparison is as follows:

Original Poisson’s Ratio Computation: Blow count 17.7 blows/300 mm, Davisson failure load 976 kN.
Revised Poisson’s Ratio Computation: Blow count 17.8 blows/300 mm, Davisson failure load 980 kN.

The differences for this case are not that substantial. The differences which emerge in the inverse case will be discussed in a subsequent post.

One other change that was made in the program was the stopping point for the static load test. The program is capable of interpreting the static load test for several criteria; however, how long the static load test is conducted (in the computer or in the field) depends upon the criteria being used to interpret it. The program now stops the test depending upon when the selected criterion is reached; Davisson’s criterion is the default. It is also interesting to note that, since the Jacobian is fixed, Davisson’s criterion, which generally stops before the others, is probably more suitable for STADYN’s current algorithm.

References are given in the original study.

Uncategorized

Tribute to Harry M. Coyle

Posted on 3 June 201726 May 2025 by Don Warrington

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. “

Uncategorized

My Perspective on Driven Pile Drivability Studies

Posted on 24 May 2017 by Don Warrington

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:

$\sum _{i=1}^{n}{\it \gamma}_{{i}}Q_{{i}} \leq \phi\,R_{{n}}$

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:

$\sum _{i=1}^{n}{\it \gamma}_{{i}}Q_{{i}} \geq \phi\,R_{{n}}$

It’s worthy of note that, for AASHTO LRFD (Bridge Design Specifications, 5th Edition) $\phi$ 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 $\phi$ 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.

Uncategorized

STADYN Wave Equation Program 1: HTML Formatted Output

Posted on 24 May 201726 May 2025 by Don Warrington

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,*)'&lt;head&gt;&lt;title&gt;BENT2 Run for Case ',casenm,
&amp;'&lt;/title&gt;&lt;/head&gt;&lt;body&gt;
&lt;div align=&quot;center&quot;&gt;'

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,*) '
&lt;h2&gt;',(anum(ik),ik=kii,72),'&lt;/h2&gt;
'

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

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 ('
&lt;table border=&quot;2&quot; cellspacing=&quot;2&quot; cellpadding=&quot;3&quot;&gt;',
&amp;'&lt;caption&gt;Control Data for Piles at Each Location&lt;/caption&gt;',
&amp;'
&lt;tr&gt;
&lt;td&gt;Pile Number',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Horizontal Coordinate of Pile Top, in.',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Vertical Coordinate of Pile Top, in.',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Batter, Degrees',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Number of Piles at Location',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;p-y Curve Identifier',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;t-z Curve Idenfifier',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Number of Pile Increments',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Increment Length, in.',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',
&amp;'Distance from Pile Head to Soil Surface, in.',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Number of Flexural Stiffness Values',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Head Connection of Pile',
&amp;'&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;Rotational Restraint Value',
&amp;'&lt;/td&gt;
&lt;/tr&gt;
')
DO 150 k=1,knpl
READ (3,*) linno,dista(k),distb(k),theta(k),
&amp;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),
&amp;pott(i),ks(i),ka(i),
&amp;nn(i),hh(i),dps(i),ndei(i),tc(i),fdbet(i)
170 FORMAT ('
&lt;tr&gt;
&lt;td&gt;',i5,
&amp;1('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',g15.4),
&amp;3('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',g12.4),
&amp;2('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',i5),
&amp;1('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',i7),
&amp;2('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',g15.5),
&amp;1('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',i5),
&amp;1('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',a3),
&amp;1('&lt;/td&gt;
&lt;td align=&quot;center&quot;&gt;',g14.4),
&amp;'&lt;/td&gt;
&lt;/tr&gt;
')
ndst=ndei(i)
DO 180 j=1,ndst
READ (3,*) linno,rri(i,j),xx1(i,j),xx2(i,j)
180 CONTINUE
write(4,*)'&lt;/table&gt;
'

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:

Output for STADYN Wave Equation Program

Case finno2, 7: 5:41:78 9 May 2017

Hammer Properties
Ram Mass, kg	0.295E+04
Hammer Equivalent Stroke, mm	914.
Hammer Efficiency, Percent	67.0
Ram Velocity at Impact, m/sec	3.46
Ram O.D., mm	286.
Ram I.D., mm	0.000
Cross-Sectional Area of Ram, mm**2	0.642E+05
Ram Length, mm	0.583E+04

Cap Properties
Mass of Cap, kg	465.
Cap O.D., mm	483.
Cap I.D., mm	0.000
Cap Body Thickness, mm	323.
Cushion Thickness, mm	127.
Cushion Material	Micarta & Aluminium
Cushion Area Same as Ram

Pile Properties
Pile Length, m	15.5
Pile Length Immersed in Soil, m	15.2
Head Cross-Sectional Area, mm**2	0.134E+05
Head Impedance, kN-sec/m	541.
omega2 (c/L), 1/sec	330.
2L/c,msec	6.07
Number of Complete Cycles for Pile Stress Wave, L/c	8
Ratio of Actual to Ideal Interface Stiffness	4.00
Minimum Distance from Pile for Model Side, m	15.0
Width of Soil Box (x), m	15.2
Depth of Soil Box (y), m	30.5

Material Properties for Hammer and Pile Materials
Material Type	Material Code	Modulus of Elasticity, MP	Poissons Ratio	Density, kg/m^3	Cohesion, MPa	Yield Strength MPa	Phi Degrees	Psi Degrees	Acoustic speed, m/sec
Steel	1	0.207E+06	0.300	0.788E+04	0.131E+04	0.262E+04	0.000	0.000	0.512E+04
Concrete	2	0.275E+05	0.300	0.241E+04	50.0	100.	0.000	0.000	0.338E+04
Wood	3	0.965E+04	0.300	800.	75.0	150.	0.000	0.000	0.347E+04
Aluminium	4	0.690E+05	0.300	0.271E+04	0.100E+04	0.200E+04	0.000	0.000	0.504E+04
Micarta & Aluminium	5	0.241E+04	0.300	0.183E+04	100.	200.	0.000	0.000	0.115E+04

Data for Region 1 (Pile )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 219.1, y = -304.8), mm	10	3(x= 228.6, y= -304.8), mm
100	Corner Locations Nodes and Connectivity	100
1(x = 219.1, y = 0.0), mm	2	4(x = 228.6, y = 0.0), mm

Data for Region 2 (Pile )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	16
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 219.1, y = 0.0), mm	1	3(x= 228.6, y= 0.0), mm
100	Corner Locations Nodes and Connectivity	5
1(x = 219.1, y = 15211.4), mm	3	4(x = 228.6, y = 15211.4), mm

Data for Region 3 (Pile )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 219.1, y = 15211.4), mm	2	3(x= 228.6, y= 15211.4), mm
100	Corner Locations Nodes and Connectivity	6
1(x = 0.0, y = 15220.9), mm	4	4(x = 228.6, y = 15220.9), mm

Data for Region 4 (Pile )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 0.0, y = 15220.9), mm	3	3(x= 228.6, y= 15220.9), mm
100	Corner Locations Nodes and Connectivity	7
1(x = 0.0, y = 15240.0), mm	8	4(x = 228.6, y = 15240.0), mm

Data for Region 5 (Soil )
Number of Nodes in a Regional Row	21
Number of Full Element Columns	20
Geometric Squeeze in x-direction	3
Number of Nodes in a Regional Column	16
Number of Full Element Rows	3
Geometric Squeeze in y-direction	1
2(x = 228.6, y = 0.0), mm	100	3(x= 15240.0, y= 0.0), mm
2	Corner Locations Nodes and Connectivity	101
1(x = 228.6, y = 15211.4), mm	6	4(x = 15240.0, y = 15211.4), mm

Data for Region 6 (Soil )
Number of Nodes in a Regional Row	21
Number of Full Element Columns	20
Geometric Squeeze in x-direction	3
Number of Nodes in a Regional Column	2
Number of Full Element Rows	3
Geometric Squeeze in y-direction	1
2(x = 228.6, y = 15211.4), mm	5	3(x= 15240.0, y= 15211.4), mm
3	Corner Locations Nodes and Connectivity	101
1(x = 228.6, y = 15220.9), mm	7	4(x = 15240.0, y = 15220.9), mm

Data for Region 7 (Soil )
Number of Nodes in a Regional Row	21
Number of Full Element Columns	20
Geometric Squeeze in x-direction	3
Number of Nodes in a Regional Column	2
Number of Full Element Rows	3
Geometric Squeeze in y-direction	1
2(x = 228.6, y = 15220.9), mm	6	3(x= 15240.0, y= 15220.9), mm
4	Corner Locations Nodes and Connectivity	101
1(x = 228.6, y = 15240.0), mm	9	4(x = 15240.0, y = 15240.0), mm

Data for Region 8 (Soil )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	21
Number of Full Element Rows	1
Geometric Squeeze in y-direction	3
2(x = 0.0, y = 15240.0), mm	4	3(x= 228.6, y= 15240.0), mm
100	Corner Locations Nodes and Connectivity	9
1(x = 0.0, y = 30480.0), mm	101	4(x = 228.6, y = 30480.0), mm

Data for Region 9 (Soil )
Number of Nodes in a Regional Row	21
Number of Full Element Columns	20
Geometric Squeeze in x-direction	3
Number of Nodes in a Regional Column	21
Number of Full Element Rows	3
Geometric Squeeze in y-direction	3
2(x = 228.6, y = 15240.0), mm	7	3(x= 15240.0, y= 15240.0), mm
8	Corner Locations Nodes and Connectivity	101
1(x = 228.6, y = 30480.0), mm	101	4(x = 15240.0, y = 30480.0), mm

Data for Region 10 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 219.1, y = -304.8), mm	11	3(x= 228.6, y= -304.8), mm
100	Corner Locations Nodes and Connectivity	100
1(x = 219.1, y = -304.8), mm	1	4(x = 228.6, y = -304.8), mm

Data for Region 11 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 14.3, y = -627.3), mm	14	3(x= 142.9, y= -627.3), mm
13	Corner Locations Nodes and Connectivity	12
1(x = 219.1, y = -304.8), mm	10	4(x = 228.6, y = -304.8), mm

Data for Region 12 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 142.9, y = -627.3), mm	100	3(x= 241.3, y= -627.3), mm
11	Corner Locations Nodes and Connectivity	100
1(x = 228.6, y = -304.8), mm	100	4(x = 241.3, y = -304.8), mm

Data for Region 13 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 0.0, y = -627.3), mm	100	3(x= 14.3, y= -627.3), mm
100	Corner Locations Nodes and Connectivity	11
1(x = 0.0, y = -304.8), mm	100	4(x = 219.1, y = -304.8), mm

Data for Region 14 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	2
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Micarta & Aluminium
2(x = 0.0, y = -627.3), mm	15	3(x= 142.9, y= -627.3), mm
100	Corner Locations Nodes and Connectivity	100
1(x = 14.3, y = -627.3), mm	11	4(x = 142.9, y = -627.3), mm

Data for Region 15 (Hammer )
Number of Nodes in a Regional Row	2
Number of Full Element Columns	1
Geometric Squeeze in x-direction	1
Number of Nodes in a Regional Column	7
Number of Full Element Rows	1
Geometric Squeeze in y-direction	1
Region Material	Steel
2(x = 0.0, y = -6458.1), mm	100	3(x= 142.9, y= -6458.1), mm
100	Corner Locations Nodes and Connectivity	100
1(x = 0.0, y = -627.3), mm	14	4(x = 142.9, y = -627.3), mm

General Properties of Run
Total Number of Nodes	860
Maximum Number of Nodes Allowed	10000
Percent of Available Nodes Used	8.60
Number of Elements Used	789
Maximum Number of Elements Allowed	7500
Percent of Available Elements Used	10.5
Total Number of Degrees of Freedom	1660
Total Degrees of Freedom Available	20000
Percent of Available Used	8.30
Number of Stiffness Matrix Entries	88208
Total Stiffness Matrix Entries Available	2000000
Percent of Available Entries Used	4.41
Node at Pile Head	3
Node at Pile Middle	19
Node at Pile Toe	37
Element at Pile Toe	18
Node at Ram Point	847
Element at Soil Corner	759
Level of Water Table from Soil Surface, m	5.18
Estimated Time Steps Used in Dynamic vtk output	143

Parameters for Explicit Dynamic Analysis:
Number of Time Steps	38239
Time Step, msec	0.635E-03
Element for Minimum Time Step	779
Newmark Constants:
Beta	0.000
Gamma	0.500
c₁	0.202E-12
c₂	0.317E-06
c₃	0.317E-06
c₄	0.000
c₅	0.635E-06

Results of Dynamic Run
Actual Time Steps for vtk Run	143
Pile Set, mm	16.9
Blowcount, blows/300 mm	17.7

Layer Data For Static Load Test
Layer	Bottom y-coordinate, m	xi	eta	E, kPa	Poissons Ratio	Unit Mass, kg/m**3	c, kPa	Yield Strength, kPa	Friction Angle, Deg.	Dilitancy Angle, Deg.	Acoustic Speed, m/sec	G_s	Total Stress, kPa	u, kPa	Effective Stress kPa	xi Optimisation Index	eta Optimisation Index
1	5.18	-1.00	-0.560	0.188E+05	0.250	0.161E+04	0.000	0.000	30.5	0.000	108.	2.65	81.8	0.000	81.8	1	2
2	7.32	-1.00	-0.560	0.188E+05	0.250	0.200E+04	0.000	0.000	30.5	0.000	108.	2.65	124.	20.9	103.	1	2
3	15.2	0.000	-0.600	0.180E+05	0.350	0.193E+04	28.0	56.0	15.1	0.000	111.	2.71	273.	98.6	175.	3	4
4	30.5	0.000	-0.600	0.180E+05	0.350	0.193E+04	28.0	56.0	15.1	0.000	111.	2.71	561.	248.	313.	5	6

Davisson and Randolph-Wroth Coefficients
Davisson Inverse Slope, N/m	0.179E+09
Davisson Offset, mm	7.81
Randolph & Wroth Inverse Slope, N/m	0.197E+09

Static Load Data
Meyerhof Maximum Pile Capacity, kN	0.153E+05
Number of Static Load Steps	1000
Load Increment per Step, kN	15.3
Maximum Number of Newton Steps	25000
Davisson Load, kN	976.
Brinch-Hansen 80% Load, kN	0.104E+04
Brinch-Hansen 90% Load, kN	996.
Maximum Curvature Load, kN	0.101E+04
Slope-Tangent Load, kN	946.

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

 write(4,*)'&lt;/div&gt;
&lt;/body&gt;&lt;/html&gt;'

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.

Pile Driving Equipment

What Splash Lubrication Looks Like in Vibratory Hammers

Posted on 12 May 201712 May 2017 by Don Warrington

Vibratory pile driving equipment has been used for many years for the construction of sheet pile and soldier walls and, in some cases, bearing foundations. Most vibratory hammers built in the U.S. use a “splash” form of lubrication, where the rotation of the gears basically throws the oil around the inside of the case, reaching (hopefully) the bearings as well as the gears.

The XFlow CFD package recently rendered this depiction of both the flow and heat transfer of oil inside the case, which gives you an idea of what this really looks like:

Many American vibratory hammers used larger teeth than shown here, but Vulcan developed a vibratory using smaller teeth and a one-piece gear-eccentric design, and the teeth are comparable in side to what’s shown here.

HT Pointwise.