It’s happened again: the paper “Vibratory and Impact-Vibration Pile Driving Equipment” has been cited by Mohammed Al-Amrani and M Ikhsan Setiawan in their paper “Prefabricated and Prestressed Bio-Concrete Piles: Case Study in North Jakarta.” The abstract of their paper is here: In this research, we will talk about Prefabricated and Prestressed Concrete piles in general and […]
The Paper “Vibratory and Impact-Vibration Pile Driving Equipment” Cited — vulcanhammer.info
It comes around every year, but this time it’s very special: today is the twenty-fifth anniversary of the start of this site. I wrote pieces of this for the tenth anniversary and the twentieth anniversary and one in the wake of COVID, which did as much as anything to move it in a more educational direction and not just a document download site.
You’d think that a site this old would have run its course, but it hasn’t: it continues to grow in traffic and popularity. The shift to a more educational emphasis has paid off, especially in traffic from outside of the U.S.. This is the fulfillment of a dream.
Want to support the site? Buy the books listed in the sidebar (or at the bottom, for those of you on mobile devices.) That’s all we ask. Again, as with my class videos, thanks for visiting and God bless.
In our last post on the subject we discussed the concept of resultants as replacements for simplicity of calculations. We’ll expand on the topic here by discussing two examples: surcharge retaining loads and loads on shallow foundations.
I discuss the topic of surcharge loads behind a retaining wall in my post The Difference Between Flamant’s and Terzaghi’s Solution for Line Loads Behind Retaining Walls. I show that the loads can either be applied to the wall as a non-uniform, distributed load or a single resultant, as is shown below.
Obviously condensing that kind of distributed load into a resultant requires more serious integration that you have for a uniform or triangular load. In the past using a resultant was common in hand solutions of sheet pile problems; with software, if it has the option for something other than uniform surcharge (SPW2006 for example does not) it generally reproduces the distributed load.
One other use of a resultant concerns strip vs. line loads. You’ll notice that the information for line loads is more extensive than strip loads. One reason is that engineers commonly convert a strip (distributed) load into a line (resultant) load by multiplying the width of the load by its pressure and placing the load in the middle of the strip (assuming, of course, the distributed load is uniform.)
Shallow foundations offer an interesting situation because in some ways we reverse the process, starting with a resultant and end up with a distributed load. We’ll restrict the discussion to the simplest case, a continous foundation, in this case under a gravity retaining wall. Other cases are discussed in more detail here.
You may recall that, for a uniform pressure distribution, the load is in the middle of the distribution. If a shallow foundation is loaded concentrically, the load is through the centroid, and this is the case. That is designated by the centreline. If the load is concentric, the eccentricity e = 0 and the two pressures q’min and q’max are both the same, as we see in the equations above, namely the load divided by the width of the foundation.
If the load is eccentric, e is nonzero. As e increases, q’max increases and q’min decreases. When we reach the point where e = B/6, q’min = 0. Beyond that point we get liftoff from one end of the foundation, which is generally not an acceptable result, especially since foundations cannot transmit tension between the soil and the foundation. As long as -B/6 < e < B/6, both q’min and q’max are positive and at least this criterion is met. This region is referred to as the “middle third” and is crucual to the success of shallow foundations. (Food for thought: how does that related to the “triangle rule” that we use with retaining walls?)
Eccentricity in loads is not strictly the result of off-centroid loads. It can also be due to a moment on the foundation, in which case e = M/N’ (without any other factors to make the load eccentric.)
As mentioned earlier, this is the simplest case. Things get complicated when we actually implement this concept, and these are discussed in Foundation Design and Analysis: Shallow Foundations, Bearing Capacity II.
My students in Soil Mechanics and Foundations get introduced to some strange concepts. One of those is what I call the “old coot” method of statics, which I discuss here. Related to that is the concept of the “resultant.” Introduction of these concepts leads to puzzlement, which students generally hide in class, as many engineering students would make great professional poker players. But homework and tests do not lie…
Most all loads in geotechnical engineering are distributed loads, because they are the results of earth pressures, either horizontal (lateral) or vertical. Although most of these are either constant or ramped linear, the math with these gets complicated fast. In the past this was a major problem for geotechnical engineers armed with slide rules. The resultant is one way of simplifying the computations, and at the same time it offers better understanding of how earth pressures either load a structure or support it.
Let’s start with a definition: for most geotechnical problems, a resultant is a point load which is used to represent a distributed load. In general statics, the definition is broader, but this is what we’re going to discuss here. To accomplish this such a resultant must meet two criteria:
The example we’ll use here is from a previous post on braced cut analysis, a subject that has buffaloed many of my students over the years. The software layout of the wall, earth pressure loads, shears and moments is shown below.
Let’s start with the easy section: the portion of the wall between 17′ and 28′ below the top of the wall. The beam has a uniform of 1485 psf, or for our purposes 1485 lb/ft/ft of wall (vertical.) With a distributed load the shear and moment looks like this, taken from the CFRAME program:
The way Terzaghi and Peck set this method forth, the beams at the top and bottom of the wall would be considered to be cantilever beams and the rest simply supported beams. This turns the whole problem into a statically determinate one, necessary to simplify the calculations. The diagram above shows a reaction of 8168 lbs. at each end, a maximum moment of 269,500 in-lb at the centre, and zero moment at the supports (due to the simply supported assumption.)
We could obtain this result by hand calculations. First, the reactions at the supports are given by the formula
which is the same as above. The maximum moment is given by the equation
which is also the same as above.
Note: one of my students got very put out with me because I had the bad taste to say that these formulas were in the "steel book," the AISC Steel Construction Manual. While I realise that it's hard to find anything in the steel book, they are there, and have been since the days I first used it at the Special Products Division.
Now let’s replace the distributed load by a resultant point load. Since the load is uniformly distributed, the centroid is at the centre of the beam. The resultant is
The reactions are computed as follows:
and the maximum moment is
The reactions at the braces are the same. Thus, for the design of the braces, the methods give the same result. The maximum moment from the resultant, however, is twice the moment from a point load resultant. In practice one could deal with this problem by a) assuming the uncertainty in the earth loads justifies the conservatism of the resultant, b) scaling down the anticipated moment by noting the differences between the two (which are in turn the result of the statics of simply supported beams) or c) a combination of the two. In any case the need to use a resultant here isn’t great because of the uniform load.
Things get more complicated when we consider the second segment from the top, from 5′ to 17′. This 12′ long segment has the following pressure distribution:
Although it’s possible to get resultants from ramped load, it’s easier to divide a ramped load into a constant portion (minimum pressure) and a triangle load from zero to the difference between the minimum and maximum pressures. That being the case, the three regions are as follows, with their resultants:
The location of these resultants is as follows:
The reactions for a point load at any point in the beam are given by the equation
The variable k is the ratio of the distance from the top end of the resultant to the total beam length. We can add the contribution from each resultant to obtain total reactions.
| Resultant | Fres, lb/ft | Location from top, ft | k | R1 | R2 |
| 1 | 4125 | 3.125 | 0.26 | 3053 | 1073 |
| 2 | 2578 | 4.17 | 0.35 | 1676 | 902 |
| 3 | 8539 | 9.125 | 0.76 | 2046 | 6493 |
| Total | 15,242 | 6775 | 8468 |
It can be shown that the sum of the reactions is the same as the sum of the resultants within rounding error, as should be the case.
The maximum moment is a little more complicated. For any point load on a simply supported beam, the moment begins at zero at the support, linearly rises to a maximum of 
Now let’s compare this with the CFRAME results, which took into consideration distributed loads. Hand calculations for distributed loads are fairly involved.
We’ll start with the moment. The maximum moment from CFRAME (273,900 in-lb/ft) is a little smaller that that which is predicted by the resultants. This is expected; the more resultants the load is divided into, the closer to the distributed load result the moment will become.
With the reactions, the sum of the reactions shown in CFRAME is identical to those from the resultant method; however, the reactions themselves are different. That’s because it is not possible to accurately reproduce a simply supported beam for Segment 2 and have a cantilever beam for Segment 1. In CFRAME we are forced to use a continuous beam from the top to the second brace (17′) and simply support them at both points. Note carefully that the moment at the left (top) end of the beam is nonzero, which is not the case with a simply supported beam. This illustrates that, from a structural standpoint, the method of Terzaghi and Peck for braced cuts is artificial, although it is possible to combine Segments 1 and 2 and do hand calculations for these with resultants.
It’s worth noting that the brace loads using SPW911 at 17′ and 28′ are 16,340 lb/ft of wall. If we use the resultant method, the brace loads (the structure is symmetric) should be 8468 + 8168 = 16,636 lb/ft and using CFRAME 8233 + 8168 = 16,401, neither of which are identical to SPW 911. This is a good illustration of the care you need to take when evaluating computer generated results.
Nevertheless, I think the use of resultants is adequately illustrated by this example. Perhaps in the future more examples of resultants can be given.
My last degree is in Computational Engineering. To start out on acquiring such a credential at an age when most people are either thinking about their last job or retirement isn’t easy. That’s one reason why I never intended the STADYN program–the most important outcome of that effort from a research standpoint–to be the last word as much as a conversation starter to move pile dynamics forward. It wasn’t easy writing a three-dimensional wave equation program–forward and inverse–from the ground up, and I doubt that the ultimate outcome–wherever it comes from–will do it that way.
In the process I got caught in the “language wars” which dominate high speed computing. Which is better, Fortran or C? Or Python? Or something else? This can result in heated debate without enlightened discussion, as is the case with many more conventional topics in geotechnical engineering. There are passionate partisans on all sides.
The whole discussion was put in perspective by my PhD advisor and professor of the two finite element courses I took, Dr. James C. Newman III. One day in class he gave us one of his memorable monologues on the subject. His observation was simple: looked at in the long view, when it comes to programming languages, it’s always something different.
FORTRAN was the first scientific high-level programming language developed, and pretty much “ruled the roost” for many years. I think that the lack of change in the language (FORTRAN 77, for example, dominated with its fixed arrays from the late 1970’s to the early 1990’s) invited competition, and both C and its later version of C++ filled the void (sorry!) Fortran caught up somewhat with Fortran 90 and its later versions, but C++ was predominant in the program I was involved with. The C based languages were never intended for intensive high speed computation but improved compilers gave them an edge. Now we have Python and other languages competing for programmers attention.
Newman’s point, however, was simple: the language of choice changes over the years. By the time a new generation of programmers starts their education, there will be another one to take the place of the language(s) we’re arguing about today. The key is that the language or method being used gets the task done. But as for languages and computer methods, it’s always something different. So today’s desperate fight for superiority will be tomorrow’s quaint tempest in a teapot.
In reality, that’s the way it is with all technology. The technology–operating systems, applications, networking, all of it–we have now is “the latest and the greatest” but soon will be considered “legacy.” In spite of this obvious fact, some employers expect engineering schools to train their students in their pet application, and make a big deal out of that when given the chance. So what happens when that application gets left behind by something different? The now-practitioner either needs to learn something entirely new, get left behind, or perhaps be in a position where their legacy skills are still needed to maintain whatever installed base their employer needs to be kept up.
But that’s going to happen sooner or later to everyone, right? It has always been my idea that engineering schools need first and foremost to teach people how to think, which includes an understand of the basic physics of their field and how it is applied. Our calculation abilities and methods will change and the specific skills required will also change, but the core remains.
My first exposure to computers in engineering was FORTRAN programming. Programming of some kind was de rigeur for engineers and computer users alike for many years until packaged applications took the helm (which themselves were the product of programming.) Programming, from an educational standpoint, is a useful skill in that the student a) is forced to learn to think logically and think problems out and b) comes to realize how easy it is for computers to make mistakes, which is one of the chief lessons my PhD program strove to inculcate in its students.
That leads to the one application that virtually any engineer encounters: spreadsheets. I’ve used a wide variety of them over the years: Visi-Calc, Works, Excel, Quattro Pro, Star Office, Open Office, Libre Office, and Google Sheets. The problem with spreadsheets is that they’re really a better business tool than an engineering one. The strength of them is that they enable the user to program a wide variety of tasks and to present the results in a reasonable manner. But I never cease to be appalled at the lack of spreadsheet skills some of my students demonstrate, which is why I’ve made spreadsheet use central to my Fluid Mechanics Laboratory course.
For engineering education–or any education–to be successful, it needs to identify its basic goal and then pursue that goal in a focused manner. Putting too much emphasis on learning one software package or another will not accomplish that. Learning to properly use software applications is a skill students must acquire to survive (and one that the advent of the smart phone has unfortunately dulled.) But acquire they must, because for student, engineer and employer alike, sooner rather than later it will always be something different.
vulcanhammer.net 