Posted in Academic Issues, Civil Engineering

With Technology, It’s Always Something Different

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.

Posted in Academic Issues, Civil Engineering, Geotechnical Engineering

My Review for the FE Exam Civil/Geotechnical Section

Over the years, my department has asked me to give a review session for my students before they take the FE exam. In this time of COVID, I’ve committed all my other lectures to video, and this one is now no exception:

I mention a few of things in the intro I’d like to elaborate on:

  • About ten years ago, it was brought to my attention that my students weren’t doing well on the FE Exam geotechnical section. My response to that was simple: “I’ll fix that problem.” I did that by aligning what I taught in class with what was in the FE “cheat sheet” (I’m sure NCEES loves that designation.) I don’t subscribe to the idea that we should only be “teaching to the test” but the FE exam’s geotechnical requirements are pretty basic, so that wasn’t much of a conflict. What has been tricky is that they’ve shifted around what they require over the years. But my students’ performance on the test has improved.
  • Since COVID I’ve put my lectures online. If you need to investigate some topics in detail, I’ve got them either at my Soil Mechanics or Foundations pages.
  • Once you’ve digested what’s presented in the video, you can and should solve sample problems. I just don’t recommend that you start your preparation doing that.
Posted in Academic Issues, Soil Mechanics

The “Line of Optimums” Approach for Compaction

There are some things in geotechnical engineering that don’t get really good (if any) coverage in many textbooks, which means that those who go on into that part of civil engineering are blindsided by their appearance. One of these is the “line of optimums” approach for compaction evaluation. The only formal textbook I know of that covers it is Soils in Construction, for which I must credit my co-author, Lee Schroeder. It also appears in the Soils and Foundations Reference Manual.

The line of optimums approach seeks to answer a key question in compaction: how much compactive energy is necessary to effect a given compaction? We have the Standard Proctor and the Modified Proctor test, but when we’re trying to determine a specific compactive effort for a particular soil and project, we need more flexibility.

I discuss this in my class video for Soil Mechanics: Compaction and Soil Improvement, but let’s consider an example, in this case from Rebrik (1966).

Compaction Chart with Multiple Compactive Energies and Line of Optimums, from Rebrik (1966)

Lines 1, 2, 3 and 4 represent compaction curves for a soil, but with a different number of blows (25, 50, 100 and 150, as shown in the chart.) The energy variation is explained in my video. In any case with the increase in compactive energy is a closer packing of the soil particles. The peak dry density/unit weight also increases with compactive energy, although the water content decreases (which makes sense as the void ratio decreases with greater compaction.) Line 6 through the peaks in the compaction curve is referred to as the “line of optimums.” Once we establish this line we can make a determination of the compactive effort we will need based on the result we are looking for, taking into consideration the degree of relative compaction we are prepared to allow for.

Line 5 is the zero air voids curve.

The line of optimums method is a good one for compaction evaluation, and we hope that this little presentation helps you to understand it.

Reference

  • Rebrik, B.M (1966) Vibrotekhnika v burenii (Vibro-technology for Drilling.) Moscow, Russia: Nedra.
Posted in Academic Issues, Civil Engineering

Yes, Civil Engineers, Things Move — vulcanhammer.info

A salutary reminder from Y. Ryabov’s An Elementary Survey of Celestial Mechanics: There is of course no sense in asking why the planets rotate or why they have motion in general. Everything in the universe, from the smallest dust particle to colossal cosmic bodies, is in constant motion. There is no such thing as matter […]

Yes, Civil Engineers, Things Move — vulcanhammer.info
Posted in Academic Issues, Geotechnical Engineering

Ohio DOT’s Rendition of the AASHTO Classification System

With the Unified soil classification system, there are many ways of diagramming it. One of those was presented in the last post. With the AASHTO system, there’s generally only one, as shown in the Soils and Foundations Reference Manual. For classification this is pretty much it, but it’s not very informative when it comes to getting a “feel” for what these classifications mean.

Below is a chart from the Ohio Department of Transportation (about the only DOT I know of which uses the AASHTO system for just about everything they do) which describes each AASHTO classification in words and attempts to describe the type of soil for each type in the system.

AASHTO Soil Classification System as Described by the Ohio Department of Transportation