A Journal of Applied Mechanics and Mathematics by DrD, #45
(c) DrD, 2018
It has been quite a while since I last posted anything here, but an interesting problem has come to mind that I wanted to share with you. If you really know calculus, this should be straight forward; if you don't know calculus, don't even try!
THE CHALLENGE IS NOW ENDED. I WILL NOT RESPOND TO FURTHER ANSWERS. i EXPECT TO POST A SOLUTION AND A FEW COMMENTS IN THE NEXT FEW DAYS.
Many of you have asked me various questions, so now it is my turn. Let me lay a bit of background first, and then the questions.
I have had some conversations recently with JAG (one of the other writers here at ME Forums) regarding the choice of software for 3D modeling and analysis. JAG has made some excellent suggestions, specifically a cloud based program called Onshape. Unfortunately, for reasons that are unclear, my computer cannot run Onshape; I have worked with their help people for several hours, all to no avail. JAG recommends this in part because there is a "free version for the hobbyist" and a relatively inexpensive "full version for the professional." That is pretty attractive, but since I can't run it, I'm stuck.
I gather that virtually all engineering colleges these days are teaching some sort of 3D modeling and analysis software, but that raises a few questions in my mind.
1. If your college teaches brandX 3D software, what will you do when you go to work for a small company that cannot afford anything more than 2D drafting (simple CAD), with no analysis capability at all? How will you do your job then? You probably have your own pocket calculator, but will you have your own copy of ANSYS or Pro-E?
2. What software does your school teach (every students should have an answer to this question, so I expect lots of replies on this one!)?
3. If you have used software extensively for analysis of engineering problems (beam deflections, stress analysis, fluid flow, heat transfer, etc), are you confident that you will be able to work all of those problems if there is no such software available to you on the job?
I might add, as sort of a postscript, most of you know that I am older than dirt (I just had another birthday, so the situation is even worse!), so I tend to look at things from an elderly perspective. One of my great fears as a working engineer was "What will happen when I'm ask to do something that I don't know how to do?" It happened more than once, and it usually resulted in a flurry of intense research to come up to speed on whatever topic was involved. I could usually do that because I have a pretty good library, and I knew how to use a university library as well. But in terms of software, I was always concerned that I had no FEA program, so how could I do problems that others were doing by FEA? I have come up with some interesting work-arounds, including writing my own FEA for some problems, but I never wanted to be dependent on software that I could not afford to own. So, back to my questions about: How are you going to buy your own copy of ANSYS?
A Community Built on False Values
This may well prove to be the least popular thing I ever post on this blog because what I have to say may offend many. I do not say it with the intent to offend, but because I am compelled to give a warning.
One of the most interesting things that has developed from my blog, Mechanics Corner, here on the ME Forum has been the opportunity to correspond directly with a modest number of readers. This has included both young men and young women scattered across India, Southeast Asia, the Middle East, and the rest the world. The majority of them are still students, still studying to become mechanical engineers. I have been somewhat amazed at the number of them that talk about (1) their strong intention to go on to graduate studies, and (2) their desire and intention to publish research while still in school, in some cases even below the baccalaureate level. I do not wish to discourage people from graduate study nor do I wish to dissuade them from publishing their work, but both of these strike me as somewhat inappropriate for an undergraduate engineering student. It appears to me that many are caught up in the ethos of academia which is misleading them with respect to what is really of value as preparation for an engineering career. Let me elaborate.
Let us begin by considering two words, science and engineering. Wikipedia tells us that science means knowledge, coming from the Latin root word scientia. The same source also tells us that engineering, which is derived from the Latin root ingenium, means "cleverness," and the second root word ingeniare, meaning "to contrive or devise." These definitions point to the fundamental distinction between science and engineering. The scientists, particularly the physicist, seeks to know, particularly to find new knowledge. The engineer, on the other hand, seeks to apply existing knowledge to the solution of problems of interest to society. It is evident that these two fields are very close to each other. We cannot be clever and inventive without knowing what has been known for ages. But engineering is about the application of knowledge, while science is about the search for knowledge.
Academia has lost its way. This is certainly true in the USA, in Europe, and it appears to be true in the rest of the world as well. Where the college or university once saw its role as preserving and passing along the best of human knowledge, to prepare people for a productive life, the schools have since become big businesses, focus on their influence, their endowments, and their prestige. In the past, faculty were valued for their knowledge and their ability to teach, that is, to pass along knowledge to those who studied with them. Today this has changed. Faculty are now valued for what they contribute to the image of the institution, for their reputations, for their publications which reflect favorably on the institution, and usually most of all, for the grants and other funding that they bring to the institution. (Notice that there is nothing about teaching in the present day evaluation of faculty; this is sad but it is absolutely true.)
In order for a faculty member to advance today, he must be interested in and doing those things which are seen as contributing to the image of the institution. Foremost for faculty, this means grant writing, research, and publication. It explicitly excludes professional engineering practice. Thus, the vast majority of engineering faculty today have little or no experience as practicing engineers. They have a lot of experience in obtaining funding, in writing papers, in giving presentations to prestigious audiences and other similar activities that will reflect favorably on their schools. But most have never solved an actual engineering problem from industry.
The reader may ask, "so how does this affect the students?" The answer is simple. The faculty talk about and praise their research, publications, and funding, and students are inclined to take these things as their own goals for the future. Thus if a student sees a faculty member advancing and doing well by publishing a lot of research (and no one ever evaluates the true value of most of that research), the student is inclined to assume that this should be their goal, their path to success as well. Nothing could be further from the truth for a baccalaureate or masters level engineer.
Most of us have heard the phrase "engineering research," and what these faculty members are doing is often described as "engineering research." But is this really engineering research as it is practiced in industry? Not at all. Over the years, I have worked in industrial "research organizations" of many sorts, but very, very little of the work done in those organizations is publishable for the simple reason that it is not fundamentally new. Engineering research, as practiced in industry, in most cases means going to the library to see if you can find a paper (or a book) where the problem you are currently dealing with has been previously solved, or at least a very similar problem that can serve as a model for you. If we talk about experimental engineering research, that usually implies experiments and measurements directed to answer very specific questions about the problem at hand, and almost never about fundamental physics or other "new" knowledge. Let me cite a few examples of engineering research that I have been involved with personally:
1. Many years ago, I conducted an experimental study of the flexural vibration of a sonar transducer head under a U.S. Navy contract. The transducer head is that part of the sonar device that comes in direct contact with the water in order to transmit, or receive, a sound wave. For analytical purposes, the sonar head is usually modeled as a rigid body, but it was generally understood that being a real, physical body with flexibility, there would be a degree of flexing involved as it moved rapidly back and forth. My research quantified the extent of that flexing and suggested the possible need for further stiffening of the design. There was no fundamentally new information; no new phenomenon were discovered, and there was nothing publishable other than a report to the U.S. Navy.
2. At one time, I was employed as a research engineer at the Homer Research Laboratories run by Bethlehem Steel Corporation, conducting research in cold rolling of steel strip. My particular assignment was to develop a mathematical model and a computer simulation based on that model for the multistand cold rolling mill. A significant part of my "research" was simply going to the library to search for work previously done by others about modeling the phenomenon that occur in the roll gap where the thickness reduction actually occurs. My "research" was largely the application of work done by numerous others, and it was not in the least bit publishable, although it was a valuable engineering tool for my employer.
3. I once worked for a company that assembled engine-generator packages, using both engines and generators made by others. My principal responsibility in that position was the torsional vibration analysis of these machines, essentially the forced response analysis of a rather complicated, multi-degree of freedom vibration system, done for every machine we shipped out. Even though this was after I had completed my college work, I had never studied systems quite like that before. So "engineering research" became a matter of learning about multidegree of freedom vibration analysis, becoming familiar with the modal method, learning about the Holzer calculation technique, and refreshing my memory about the application of Fourier series. Not a bit of this was new. Multidegree of freedom vibration goes back at least as far as the Lord Rayleigh in the mid-19th century if not earlier, the Holzer calculation dates from the early 20th century, and Fourier series date from the early 19th century. So, while there was nothing new in any of this, it was necessary "engineering research" in order to give me the capability to perform my assigned tasks.
4. While at the engine-generator company, I was asked to create a mathematical model and numerical dynamic simulation for a complex system consisting of a diesel engine with the governor, a generator with its exciter, and induction motor, and a pump. This system is the emergency core cooling system for a nuclear power plant. In the event of the loss of regular coolant flow to the core, the standby diesel engine is started and the speed stabilized by the governor. After this is done, the exciter is activated to apply the field to the generator windings, and power is delivered to the induction motor. This step again requires stabilizing the speed by the governor. The induction motor is rigidly coupled to the pump which provides water to cool the core. All of these steps must happen very quickly, typically in about 15 seconds, so there is a lot going on. In my own engineering education, I had learned about basic circuit theory, but I never studied much about motors and generators. Thus my "engineering research" at this point included a lot of study of motor/generator theory, all information that had been known since the early 20th century. There was nothing about the eventual simulation that was publishable research, but it was a valuable engineering tool for my company.
The point of the four little stories above is simply that, in most cases of engineering practice, "engineering research" is simply a matter of finding existing knowledge so that it may be applied to a current problem of interest to the employer. Only in the most rare circumstances is it about the search for new knowledge, knowledge previously unknown to anyone. And yet it is this last, the search for new knowledge that is the focus of most academic research. With some exceptions, academic research is rarely relevant to the actual problems of industry today.
Let me also make a few comments about graduate education. Without going into the broad topic of the degradation of education at all levels, let it suffice to say that there are, broadly speaking, two categories of engineers. Let us call the first category the Project Engineer, almost always an individual with a baccalaureate degree in engineering. The second category, which we will call the Advanced Engineer, is usually a person with a Masters or doctoral degree in engineering, although baccalaureate degree holders are not entirely excluded.
The Project Engineer has broad responsibilities for many types of projects, including design, manufacturing considerations, obtaining materials, meeting delivery schedule requirements, and resolving difficulties as they arise. He relies heavily on codes and standards in his design work, often employing "rules of thumb" instead of rigorous calculation; this is how the vast majority of engineering gets done. The Project Engineer draws on his engineering education background for understanding, but rarely makes a calculation and relies heavily on engineering intuition to do his job.
The Advanced Engineer is one who has chosen to deepen his technical expertise, and enjoys dealing with more complicated problems, particularly in terms of mathematical analysis. The Advanced Engineer may, but often does not, have broad project responsibilities, but he is expected to be more rigorous in his work and to have a greater knowledge base. He is often seen as a resource person for the Project Engineer.
Industry in every country needs large numbers of Project Engineers; this is where the jobs are for most engineering graduates. Industry in every country needs a far smaller number of Advanced Engineers because their role is largely support for the Project Engineers. At times, when there is a great industrial surge, such as the USA experienced during the space program, there is a somewhat increased need for Advanced Engineers, but there is always a greater need for Project Engineers. Even when times are good, when industry is hiring many engineers, too much education can often be a disadvantage for a job seeker. The employer, seeking a Project Engineer, will often say when considering a person with an advanced degree, "This person has more education than my position requires. This candidate is likely to become dissatisfied with the job after I invest in training him to do it. It is better to hire someone with less education who will remain with my company indefinitely." I have seen this happen, and I have been a victim of it myself. Thus I encourage all to think carefully about their goals and their potential employment prospects when considering whether to go to graduate school or not.
Let me tell one more personal experience to illustrate the difference between the Project Engineer and the Advanced Engineer.
5. Not quite 20 years ago, I was employed by a manufacturer of aerospace components. A dispute arose with the US Federal Aviation Authorities (FAA) regarding the design adequacy of a particular component in one of our products. The component was a push rod, bent into what is sometimes called a "dog-leg" configuration (a sort of Z-shape), and is operated in both tension and compression. The FAA inspector argued that the pushrod might fail by buckling, and our project engineer was unable to convince him otherwise. The problem came to me to justify our design.
Now buckling is an instability phenomenon, and I saw immediately that because of the bent configuration of the rod, there was no possibility of instability but only further bending, and hence no possibility of buckling. This argument, however, did not persuade the FAA inspector. My only option, therefore, was to calculate the deflections of the pushrod when operated in compression. This is not a simple calculation, and no one in my company knew how to do it. I turned to the classic book on elastic instability of structures by the great Ukrainian engineer Stephen Timoshenko where I found a similar, slightly simpler, problem that I could use as a model. Following Timosheno's work, I made the calculations to show that there simply was no buckling potential, and that further the very most elementary deflection calculations gave an almost identical result. The FAA inspector was unable to respond.
I mentioned this last personal experience in part to show (1) my role as the Advanced Engineer in support of the Project Engineer, (2) and also to show how, in this case, "engineering research" amounted largely to resorting to the literature for results almost 100 years old. Once again, it must be noted that this "research" produced no new results and was therefore not publishable, but it was worth a lot of money to my company.
Well, if students are being misled by academia about the nature of actual engineering, what can they do about it? The answer is simple to describe, even though it may be more difficult to put into practice. The short answer is, "Look for actual engineering experience for yourself outside of academia." How is this accomplished?
1. One of the classic ways to gain real experience has always been to look for work opportunities during the summer or other school vacation period in actual industry. Now it is obvious that working as a sacker in a grocery store will not provide much useful experience for someone who aspires to be come a machine design engineer. But work in a factory, on an assembly line, or even just distributing parts to an assembly line, will provide much useful insight into the nature of engineering work, the work environment, the demands, the expectations, and the hazards. If if you cannot get engineering work as an undergraduate, there is valuable experience to be gained simply by working around engineers.
2. In the USA, many engineering colleges provide a work/study program called Cooperative Education (Co-Op for short) in which a student, usually beginning in the second year, goes to school for one term and then goes to work in some actual industrial environment for the next term, alternating this pattern until graduation. Many students spend all their Co-Op work terms with the same company, but others will sample several different companies. If a student does well during his work experiences, this often leads to a job offer at the end of his college education. By that time, the student understands what is expected of engineers in that particular company, and the company has a understanding of the value of that student as a permanent employee. If Co-Op is available at your school I strongly urge you to take advantage of it.
3. Look for part-time work while in school with some actual, industrial firm, where you can see and perhaps participate in actual engineering work. This is an additional burden to your school work, but the opportunity to see the connection between school work and engineering practice can be invaluable. (I had a student once who worked in a battery factory while he was taking my Theory of Machines course. He was seeing, and working with on an everyday basis, many of the exact mechanisms that we were studying in class. He got an extraordinarily good education out of the combination.)
4. The SAE (the organization formerly known as the Society of Automotive Engineers but now legally simply SAE) organizes and conducts many student design competitions for engineering students. A number of these are structured around the design and construction and eventually racing various types of small race cars. Although done within the academic context, this provides students with a real engineering experience. If your school has such a competition, I strongly urge you to be a part of it. If your school does not have such, then I urge you to ask the school to get involved with the SAE student design competitions.
Let me close with one final story from my own experience, a story where I was simply an observer, not a participant at all. A company where I was employed hired two new graduate engineers, one from each of the two major engineering schools in my home state. One of the schools is known for being very practical and down to earth, while the other is known to be much more theoretical, more elegant, more research oriented. Each of these new employees was given a similar project to begin, the design of a small power transmission shaft. The graduate of the very down to earth engineering program got right to work, following steps he had learned in an undergraduate machine design class. He had an acceptable design in a matter of a few days. The graduate of the elegant, research oriented institution fumbled around for literally weeks, starting over time and again and essentially unsure how to proceed. He knew many of the things that needed to be considered, but he had no way to go about working through them systematically. It was very evident to me which one of these would make the better engineer.
I urge all students therefore to keep their eyes clearly fixed on the goal of engineering (assuming that really is their goal) and not let research, publication, and advanced studies cloud their vision.
Many years ago, when I first began to study mechanics, the "conventional wisdom," expressed by both teachers and fellow students, was this: "Statics is easy, Dynamics is hard, and Kinematics -- who bothers to actually study kinematics? Kinematic relations, when needed, simply drop from the sky like rain, but nobody seriously studies kinematics." I eventually found the truth to be a bit more subtle: Statics of structures is generally easy, while the statics of mechanisms and machines may, or may not, be easy, depending a lot on the kinematics. Further, I found that the key to most dynamics problems is having a good tool to deal with the necessary kinematics.
The purpose for this article is to present the most powerful tool I have ever found for dealing with mechanism and machine kinematics, the vector loop method. This will be demonstrated in the context of two simple problems.
Welcome to the first installment of Mechanics Corner, a feature that we hope will become a regular blog item on Mechanical Engineering Forum. The intent is that every week we will have a new article on some aspect of Applied Mechanics and Mathematics, things of broad interest to mechanical engineers. Some of these articles will be fairly elementary, while others will be considerably more advanced, but the idea is to have something for everyone. We will hope to amuse, entertain, and most importantly, to inform you with each article. We may even have a little bit of engineering humour from time to time!
Most of these articles will involve the use of pictures, diagrams, and mathematics, all things that are fairly difficult to accomplish in a blog post. For this reason, and beginning today, the bulk of the post will be in an attached PDF file. It turns out that there are fairly simple ways to have all the necessary tools available in a PDF file even though they are not available directly on the Internet. Thus I hope that each of you will click on over to the attached PDF file to read the rest of today's article.
Mechanics Corner is written by DrD, which of course raises the question, "Who is DrD?" Well, that’s me, but that doesnt tell you very much, does it? My intention is to say very little about myself in most of the articles, but since today is the day for introductions, for the blog, for myself, and a few other matters, it seems appropriate to tell you a little bit more about who I am.
I am an elderly man, a semiretired engineer and Mechanical Engineering Professor, living in Texas, USA. All of my engineering degrees are from The University of Texas at Austin, and I have professional engineering registrations in both Texas and Wisconsin (in the USA, engineers are licensed by the several states to prevent incompetents from holding themselves out as engineers and thus endangering the public safety and welfare). As I mentioned, I am old, many would say "older than dirt." I have had a long and very interesting career as an engineer working in a number of different industries, as an engineering faculty member, and as a consulting engineer (I continue to do some consulting yet today). In my engineering career, I have worked in the automotive, aerospace, naval, offshore, gas compression, steel, and electric power generation industries. I have worked on diesel and natural gas engines, steam turbines, gas turbines, large electric motors, generators and host of other machine types. If it moves, it is likely that I have worked on it; if I have not, I sure would like to work on it!
Being as old as I am, I have seen a lot of changes in my life, a few of which I wanted to touch on here. One of the most profound changes has been the shift of manufacturing industry away from the USA to India, China, Mexico, Brazil, and Southeast Asia. When I was young, the USA was arguably the greatest manufacturing power in the world, but that is no longer true today. We talk about being an "information society" (although Im not sure what that is) but we have very little to do with machinery and similar things today. But here I am, and this is one of the reasons why I feel a need to talk with many of you in the developing countries.
In October, 1957, Russia put the Sputnik satellite in orbit. It was a tiny thing, about the size of a soccer ball, but it shook the world. At that time I was in my last year in high school, preparing to go off to study engineering in college. Sputnik caused a great shake-up in American engineering education, with many warning cries that we were "behind" and had to "catch up." This meant many changes in education, but one in particular: now everything had to be done in vector notation, something that had not been done much before. In my freshman year in college, I took the introductory Mechanics course in physics, and fell in love with the subject matter. As a result, I have been studying mechanics, in one form or another, for well over half a century. Interestingly, although I initially learned everything in vector notation, I have come to the conclusion that I prefer to use scalars wherever possible. In particular this means the use of energy methods whenever they are suitable.
We all go off to college to study mechanical engineering; this is how we enter the profession. We are constantly told that we must never stop learning, but how many really believe that? Do you still hit the books every night? Are you still doing homework problems? I want to tell you a story about learning after school has ended.
About 12 years after I completed a Ph.D., I was on the faculty at Texas A&M University, one of the great engineering schools of America. I was assigned to teach Theory of Machines, and I figured that I could handle it, even though I had never had such a course in my own education. I selected a textbook that was somewhat unorthodox but I thought it looked attractive. It was a very good textbook, and it proved to be one of the greatest learning experiences in my whole life (there is nothing like trying to teach a course to be sure that you learn the course). I struggled to stay a few days ahead of the students, but that book brought me many new and powerful ideas that I had never seen previously. At the end of the semester, I asked the students what they thought of the book. They hated it! Their complaints really came down to two things: (1) the book was too big, too long, nearly 700 pages, and (2) the author had some really awkward notations. A few years later, when I set out to write my own textbook on Theory of Machines, I kept these two objections in mind and was able to produce what I think was a much better text. The point of the story is this: here I was, supposedly educated and having industrial experience, and yet I had the greatest learning experience of my life. It profoundly changed the way I work all kinds of problems to this day. The moral of the story is that we are never too old to learn, unless we think we are.
One of the great changes that I have seen, and you have seen it also, is the profound impact of the Internet. Thirty years ago there is no way that I would have been writing for you, and no possibility that you would have been reading the words of an old man in Texas. But all of that has changed now. Sadly, there is much trash on the Internet. On the good side, there is also much of a value. Among those good things, I would like to direct you to the site of a friend who has done some most excellent work in mechanism animations. When you see his animations you simply cannot help but have a better feel for how these machines work.
The URL is: http://www.mekanizmalar.com/ By all means take a look at them and see for yourself! I hope to see all of you and many more next week when we will go on to things of a more technical nature. Please check back here at Mechanical Engineering Forum for the next article.
Where Will I Find A Job??
As I read over the questions that readers post here on ME Forum and elsewhere, I sense a common theme in many of them. There seems to be a wide, dare I say almost universal, concern about where those currently in college will find employment after graduation. To a degree this is entirely understandable; we all wonder what is in our future. Even so, the level of anxiety that I sense in many of your postings strikes me as extraordinarily high. Let us consider this a bit.
Most readers of ME Forum are currently enrolled in an engineering curriculum somewhere. Some are just beginning while others are nearing the end of their undergraduate education. I would like to pose a question to all of you: Why did you go to engineering school? Why did you choose what is probably one of the most difficult curricula in any college? For the sake of this article, I'm going to presume that I have heard at least some of your answers.
It is almost universal among engineering students to be looking forward to a good job, one that will provide them a comfortable living and a substantial measure of security. This is not at all unreasonable, and is in fact entirely probable. Almost all of you can expect to be well employed and in the upper echelons of society wherever you live. You will not rank as high as the well-known politicians, nor will you be the most wealthy people in the area. But you will have stable work and a comfortable income from that work.
What does it matter where you find employment? One of the themes I see in what I read is a great many people looking for "government jobs," that is, employment with some government entity. Traditionally, "government jobs" have been very stable. As long as a government employee stays out of trouble, in most situations it is impossible to remove that employee from his government job. This feature makes government work extremely attractive to the incompetent, to those who really cannot do the job well and thus rely on the fact that they can almost never be fired. Is this why you struggle with a difficult college curriculum, so that you can be employed with those that are incompetent? Do you really want to spend your working days with people far less capable than yourself? Many of them have achieved their positions without nearly the rigorous education that you are undergoing, so I ask you, are these the ones you want to have for your close associates?
Let me tell you a personal experience. After a long career that involved both academic positions and various industrial research positions (with a few years as a solo consulting engineer), at age 59 I took a position with a research laboratory run by the U.S. Navy. It is a sad fact of life that, in the USA, most people are considered unemployable after age 60, so I was nearing the end of the time when I could look for and expect to find a new position. The job was attractive because it promised an opportunity to do some well funded work in an area I was quite interested in, the area called electro-mechanics. The position would be very stable and I would be well payed.
In my first week on the job, I was given a few documents to read but nothing really to work on. I was not too surprised and expected all that to end very soon. After about three weeks in the new position with still in no work assignment, I began to be very worried. Every place I had worked previously had plenty of work to be done and anyone not given an assignment was probably being set up to be fired. I spoke with my boss about this several times, and he very casually told me not to worry about it. That really did not relieve my concern, particularly when he was so very casual about the whole matter. I tried to find things to work on, to make myself look useful and busy. In conversation with the other engineers, a few problems were suggested, and I worked on some of those. I wrote a few technical notes, primarily just to show that I wasn't simply sitting idle at my desk. Time went by, weeks turned into months, and months turned into years. When I finally retired from that position after seven years, I estimated that I had done at most 18 months of real work. The rest of the time I simply had nothing assigned for me to work on.
Had I realized in the beginning how the game was to be played, I would have spent my days doing things that were much more productive, such as working on problems that I found interesting, writing technical papers on those problems, and probably writing a few books. In the nonproductive 5 1/2 years I had, I could have done a lot of work! But I did not realize how the game was played, and I kept expecting someone to assign to me real engineering work to do.
As I got to know the other people, I found that a few of them had ongoing projects that were of interest to them, but most had nothing to do most of the time. I am convinced that this is the pattern of government employment, the so-called "government job." There were very few people who were truly happy in their work them: most were fairly miserable in fact. But they were wedded to the paycheck and the job security that went with their "government job." They even spoke of these factors as the "golden handcuffs." Most intended to stick it out for a total of 30 years or more, so that they could retire with a good pension.
Now I ask you, the reader, is your primary goal to retire with a good pension? Is this your principal objective in life? If so, why don't you simply roll over and die now?? While it is true that no one wants to retire in poverty, most of your life is long before retirement. Retirement is the end stage of life. I have been fortunate to live almost a decade since I retired, but it is not at all uncommon for men to die within a year or two after retirement. It seems that many simply lose their purpose in life when they retire. So to live your life in preparation for retirement is foolishness of the highest order!
If preparation for retirement is not to be your principal purpose, then what should be your objective? I submit to you that your objective ought to be to find meaningful, rewarding work in the service of other people. I am not suggesting that a group of mechanical engineers become social workers, but I am saying that you should see some connection between your work and the improvement of your society, the people among whom you live. If your work does nothing to help other people, what is its lasting value? The money you bring home in your paycheck will soon be spent. The time you invested to earn that money is already spent. So what are you contributing to mankind?
Rather than looking for a secure, comfy do-nothing "government job," I suggest to you that you should be adventurous, looking for new opportunities and new ways to help others. This is urgently needed everywhere, particularly in developing countries. Look for small startup companies with new ideas for new products, things that will improve life for everyone. Many of these companies will fail, but you are young, and looking for another job after two or three years with the company that fails is no disaster. It will not reflect badly on you if the company fails; that reflects upon the management of the company rather than upon the engineering staff. Look also at very traditional companies that are doing things the way they have always been done. Many of these companies need engineering help if they are to remain competitive and to survive into the future. This may provide you an opportunity to keep an entire company functioning, providing employment for many people. There are countless other ways that we may help our fellow man, but this should always be high in our list of priorities for the work we will do. It is while you are young that you can afford to be adventurous, to take some risks and try out things that later in life will simply be too risky. Look for challenges, situations that will require it to you use everything that you have learned, and also require you to continue to learn.
There is absolutely no point to your engineering education if your goal is simply to doze the next 50 or 60 years before you die. Plan to do something with your life, something useful, something meaningful. Do not look for a place to lay your head and simply sleep away your career.
The VEProject --- Shifted Levers A Critical Assessment
The subject of this article is the VEProject Shifted Lever video, as found at the following URL:
The video shows a "Shifted Lever" mechanism, a device that appears to be perpetually off balance. It is presented as a perpetual motion mechanism, that is, a machine that will run forever without any energy input other than, perhaps, an initial push. This presentation comes from the VEProject, where VEProject stands for "Visual Education Project." An educational project can be presumed to be a presentation of truth, so should we accept that the author believes that this device is truly a perpetual motion device, or that he is attempting to deceive the viewer? As most Mechanical Engineers know, the laws of thermodynamics show that there cannot be perpetual motion. So, are the laws of thermodynamics incorrect, or are we being deceived?
Twenty One Rules for Tech Writing
One of the things that has surprised me about the readers of ME Forum is the number of folk who want to publish technical papers. When I was an undergraduate (a very, very long time ago), publishing papers was the farthest thing from my mind. I knew that publishing was a concern for some of the faculty, but it was certainly no concern of mine! To my even greater amazement, most of those desiring to write want to write in English, even though this is not their mother-tongue. I presume that this is a natural consequence of the fact that English has come to dominate the technical literature world-wide. That is a good thing for me (I only speak one language), but I would think it must be a daunting prospect for many of you. I have great respect for anyone who would undertake to write a technical paper in a foreign language; it is quite enough of a challenge in a language that I know pretty well. But perhaps it is not so much “foreign” as it is simply a “second language,” for those of you that know multiple languages. Either way, I am impressed that you would tackle this difficult undertaking at this point in your lives.
The purpose of this article is an attempt to help those of you who wish to publish, particularly technical publications. Most of what I have to say can be applied to anything you write, comments about such matters as organization, for example. Other parts of this article apply specifically to publication in technical journals, so you must use my suggestions with understand as to where they apply and where they do not.
I am organizing this article in two main parts. The first part I have labeled as Philosophy, meaning that it provides some guiding principles to be kept in mind about the way you construct your paper. The second part is labeled Mechanics and refers to details about actual construction of the paper. You will find that both of these are important. I have been reviewing papers for many years now for ASME, SAE, Journal of Mechanism and Machine Theory, and others, and I can tell you with certainty, that many papers fail on some of the most mundane items discussed here. These things matter, and if you want your paper to be accepted, you will need to pay attention to them all.
1. Have something interesting to say. There is simply no point to attempting to write a paper on an uninteresting topic, one that does not interest you, the writer, nor the reader. There are times when it is necessary to report information that is less than fascinating, but as the writer, you should seek to find what there is about this information that is interesting and/or important to the reader and point that out. You should never choose to write on a topic where you really do not know what you are talking about; it just will not work!
2. Identify your reader. In most cases, you will not know exactly who the reader is going to be, but you should have some pretty clear ideas about him nevertheless. You will be making definite assumptions about the reader (it may be helpful to go so far as to write these out), about his background and preparation for what you are going to present. Are you writing for a broad, general audience with a limited technical background, or are you writing for someone who is a specialist in the field and perhaps has even more background than you do? The assumptions you make about the reader will have a major impact on what you say and how you say it, so it is necessary to be rather definite about the capabilities of the reader.
3. Identify your publisher. When you write, you need to keep in mind who will be publishing your work. Most established publishers have very definite requirements regarding style, page layouts, footnote/endnote requirements, and a host of other matters. Many journals will publish in each issue a short section with a title like “Information for Authors,” and today this will usually lead a link for a URL where you will find pages and pages of detailed requirements. It is better by far to be aware of these requirements before you begin writing rather than having to do major re-writing simply to meet the publisher’s requirements.
4. Organize your story in a logical form. This is often not the way things came first to you, but it is necessary to make things easy for the reader. Think about the easiest possible way to explain your subject to a reader, the sequencing of information that will enable him to most easily understand the whole topic. This will help you to keep your paper concise and focused.
5. Provide any necessary background. This is often done in an Introduction where you survey related previous work so that someone not intimately acquainted with the field can still follow your work. Depending upon the nature of the publication (journal article, technical report, lab report, etc.), a bit of basic review may be appropriate in some situations.
6. Use correct terminology. Terms such as axial, radial, height, width, length, vertical, horizontal, cylindrical, conical, spherical, etc. have rather specific universal meanings. Be sure to describe carefully the orientation of dimension, and other similar matters that are often essential for a clear understanding. Consider the four words: depth, height, width, length. What directions are associated with each? Height is usually vertical, that is aligned with the local gravity vector. The length of something is usually the longest dimension, assuming that this dimension is horizontal, but what happens if it is not horizontal? The word depth is sometimes associated with a vertical distance, such as the water depth, but it is also associated with a horizontal distance measured away from the observer. The ambiguity of these words means that they must be used with great care. Often it is necessary to say something like, “The depth of the hole, measured in the horizontal plane, is ...” or “The width is 42 mm, as shown on the drawing.”
7. Use consistent terminology throughout. If you call something a brick at the beginning, then it must be called a brick throughout. If you start off talking about the engine, do not switch to talking about the motor. The exception to this occurs when you use a common place term to introduce an idea before giving the technically correct term. Consider for example, “The longest edge of a right triangle is called the hypotenuse.” The common term in this example is “longest edge,” but the technically correct term is “hypotenuse.”
8. Use figures, but use them sparingly. Figures can add a lot of interest to your publication, as well as conveying much information in a simple, easy to understand form. But remember that they are there to inform, to carry information from you to the reader, not simply to look pretty. They take up a lot of space, so they must convey a lot of information. On the other hand, they must not be too cluttered, with text too small to read. Labels with leader lines can help in many cases.
9. Always write a conclusion. The conclusion is important to solidify in the mind of the reader what it is that he has just read. When you write your final conclusion, be sure that your text supports everything that you are concluding and that you have told the whole story.
10. Don’t make you paper too long. Most journals impose a limit of 8 pages, including figures and references, so be concise. There are exceptions, journals that allow longer papers, but the best ones generally have a firm limit. If a paper becomes too long, the reader is very likely to loose interest before finishing, in which case, you have not reached the reader with your information and he has wasted his time.
11. Be precise in the use of words. Don’t describe everything as “efficient,” when you really mean “more effective,” “faster” “less expensive,” “more aesthetic,” etc. The bigger your vocabulary is, the easier this will be. Avoid “engineer–speak,” that is, the sort of slang that engineers often use on the job, such terms as “down-force,” “up-draft,” “bhp,” “mip,” “CG,” “cross-over,” etc. (Does everyone know that the CM and the CG are usually the same location, although not always? Giving the whole term makes clear which you mean.) If you think they are necessary, then you must define them in the text. In this same vein, for technical publications it is never acceptable to use the abbreviated form that have become popular with instant messaging, texting, Twitter, etc. I am speaking about such things as “u r” for “you are,” “b4” for “before,” and similar extreme contractions of words.
12. Number all figures, and provide a title. In so far as possible, all figures should be uniform in style. Think twice about the use of color. It looks pretty when well reproduced, but will it always do so? Multi-color figures on a black and white copier lose most of their information. For most purposes, black lines on a white background are the best idea.
13. Number all pages. This seems obvious, but evidently it is not so to everyone. This helps put the pages in order if they get shuffled, it helps a reviewer refer to specific items, and it helps a reader to locate information given in a citation.
14. Number all equations. Again, this seems obvious, but not so to everyone. Use conventional symbols wherever possible (Greek rho for mass density, W for weight, m for mass, v for velocity, etc.) For journal publication, do not show substitutions of numeric values into an equation. Instead, solve the equation in symbols and then show the final numeric result. There may be an exception when for a professional report (such as a stress analysis for a client), you may need to show the substitution.
15. Provide section and subsection heads. This helps to give structure to your paper, conveying the logic of your presentation. Also, it suggests to the reader where to look for particular information.
16. Start a new paragraph with each new idea. The basic purpose of a paragraph is to present one, and only one, idea. This is true even for summary paragraphs where the new idea is the interrelatedness of several ideas presented previously. Single sentence paragraphs are to be avoided.
17. Use spell-check. With all the word processing capability available today, almost all of it including a spell checking feature, there is absolutely no excuse for misspelled words. Now spell-check will not check the logic of your sentences, so the simple fact that spell-check did not flag anything does not mean that everything is correct. But if spell-check does flag a word, you must correct it.
18. Punctuate and capitalize correctly. Be sure to single space after a period at the end of every sentence. When using a hyphen to break a word, do not include a space. Punctuate consistently throughout, with the publisher’s rules as your main guide. Above all, be consistent. It looks terrible to see a space on one side of a hyphen and not on the other
19. Use consistent units throughout, usually SI. This would seem to be obvious, but it is not so to everyone. Most of your work should be formulated in such a way that it is units-free, that is, so that it may be used with any consistent system of units. But when you are reporting numerical results, you will have to use units (unless you use dimension-less ratios which are not entirely satisfactory).
20. Use abbreviations correctly. If you want to use an abbreviation, such as BWR for Boiling Water Reactor, the whole thing must be spelled out the first time, with the abbreviation immediately following in parentheses. Thus, we might say, “Westinghouse provided the Boiling Water Reactor (BWR) for the installation.” Thereafter, use BWR consistently, except at the beginning of a sentence (do not start with an abbreviation).
21. Proof-read, proof-read, proof-read! Putting the words into the computer is only the beginning of writing a paper, definitely not the end. It is necessary to proof read, looking for many different potential problems. Does every sentence make sense and say what you intended for it to say? Is your explanation complete, or are there gaps in it? Is the punctuation and capitalization all correct? Have you followed the publisher’s guidelines for format, style, equation numbering, etc.? When you have read it and re-read it many times, to the point that you think it is perfect, then get someone else to proof-read it also for you. The failure to adequately proof-read is one of the most common of failings, and it reflects very badly on the author. It says that the author did not think that this article was worth making perfect, which makes the reader wonder why he should bother with it at all?
Conclusion Following these rules does not assure that your paper will be accepted by one of the leading journals of the world, but failure to follow them virtually assures that your paper will fail. The whole idea of writing a paper is to communicate something to a reader, and these rules are largely about steps that you, the author, can take to facilitate that communication. If what you say is not interesting or is unclear, then there will be no communication. These rules are all about clarity and ease of communication.
The response here at Mechanical Engineering Forums, or should I say, the lack of response, has left me puzzled. There was a modest response (as indicated by comments) to my first post, but the number of comments has dropped to almost nothing since then. I am only aware of one person who has actually worked on one of the challenge problems that I have posed (but I hope that there are more who have). In the previous poll, there have been a good number of views, but an extremely small number of people have answered the poll. What does this all mean?
There are a lot of possible interpretations. Is the material too difficult? Is the material too simple? Are the topics boring? Are the topics too general? Is the application of these ideas not evident? Do you want to see more problems carried through to numerical answers?
Would you like to see more articles on other topics, such as (1) vibrations, (2) stress and deflection analysis, (3) gears, (4) cams, (5) electromechanics, (6) applied mathematics, (7) computer methods?
Would you like to see more articles on specific applications, with the presumption that you already know all of the necessary back ground? I’m thinking, for example, of an article I intend to write eventually about a vibration attenuation system. In order to understand that article, the reader is going to need to have a general background in multi-degree of freedom linear vibrations. Are all readers ready to simply jump into that subject?
Please answer the following poll questions, and add your comments on this topic at the bottom. I am most interested in your feedback.
The following is a verbal description of a Doonesbury cartoon of unknown date by Garry Trudeau. Doonesbury has long been one of America’s major cartoon strips, with a very dry wit and a decidedly left-of-center outlook. I found this today in going through some old files.
SCENE: A college classroom, the teacher lecturing in a rather absent minded fashion, the students silently bent over, taking notes and keeping their heads down.
TEACHER: Of course, in his deliberations on American capitalism, Hamilton could not have foreseen the awesome private fortunes that would be amassed at the expense of the common good.
TEACHER: Take the modern example of the inventor of the radar detector. In less than ten years, he made $175 million selling a device whose sole purpose is to help millions of people break the law.
TEACHER: In other words ...
STUDENT (suddenly sitting up and interjecting): Maybe the fuzz buster is a form of Libertarian civil disobedience, man. You know, like a blow for individual freedom.
TEACHER: I ... I don’t believe it!
STUDENT: Believe what, man?
TEACHER (smiling in happy elation!): A Response! I finally got a thinking response from one of you. And I thought you were all stenographers! I have a student! A student LIVES!
TEACHER (kneeling down, hand extended like one might approach a shy animal): Who are you lad? Where did you come from? Don’t be frightened ...
STUDENT: (looking around himself): What’s the deal here? Am I in trouble?
The above all appeared in print many years ago, but it is an apt description of Mechanics Corner.
1. Team building is very popular in industry these days, so here is a team building joke.
A group of mathematicians are attending a weekend seminar on team building. During the night, a fire breaks out in the room of one of the mathematicians. He quickly tears pages out of his notes and lights them on fire, one by one. He then runs down the hall, shoving burning sheets of paper under the doors of all the other mathematicians.
In the morning, after the building is burnt to the ground, the fire marshal asks how the fire spread so fast. The initiator spoke up and said, "I thought distributing the problem would lead to a quicker solution."
2. Summary of the important laws that MEs must know:
From statics, Stuff does not move on its own.
From dynamics: Stuff fights back (Newton's 3rd Law)
From mechanics of materials: Stuff stretches and breaks (Hooke's Law)
1st Law of Thermo: You can't win.
2nd Law of Thermo: You can't break even.
3rd Law of Thermo: You can't stop playing.
Addendum: Entropy isn't what it used to be.
3. An engineer, a physicist, and a statistician go hunting together. When some game is sighted, the physicist calculates his trajectory using ballistic equations, but omits air resistance. His shot falls 5 meters short. The engineer adds a fudge factor to compensate for air resistance, but his shot fall 5 meters long. The statistician shouts, "We got 'em!"
4. An engineer and a physicist are lost in a hot air balloon drifting along. The physicist is busy trying to use sextant to determine their position when the engineer spots someone on the ground. The engineer yells, "Where are we?" The man on the ground calls back, "You are in a hot air balloon, 100 ft above ground." The engineer and the physicist look at each other and one says, "That man is a mathematician. His answer was entirely correct and completely useless."
5. There is a calculus party and all the functions have been invited. ln(x) is talking with some trig functions when he see his friend e^x sulking in a corner. He says, "What's wrong, e^x?" e^x replies, "I'm lonely," to which ln(x) replies, "You should try to integrate yourself into the crowd." In despair, e^x cries out, "It won't make any difference at all!"
6. If you can just remember all these jokes, you will be a hit at the next of those parties you imagine yourself being invited to.
A Journal of Applied Mechanics and Mathematics by DrD, # 35
Machinery Dynamics Research, 2017
Good News --- Bad News
Rolling Disk in a Rolling Ring
Well, it looks like Mechanics Corner is back, at least in terms of an occasional post. It will probably be less frequent than previously, but there are just too many interesting things to talk about to remain entirely silent! The title for this post may leave you wondering what is the Good News, and what is the Bad News? Why is there both? Well, let me tell you about it ...
A Journal of Applied Mechanics and Mathematics by DrD, #43
(c) Machinery Dynamics Research, 2017
Four-Bar / Toggle Linkage Mechanism
I believe that it would be correct to say that all of the single degree of freedom mechanisms that I have discussed on ME Forums have involved only a single loop. This might lead a reader to conclude that a single degree of freedom implies only a single loop, and vice versa, that a single loop implies only a single degree of freedom. Neither of these statements is true. In this note, I want to discuss a counter example, a mechanism called the four-bar / toggle linkage; it is shown in Figure 1.
A Journal of Applied Mechanics and Mathematics by DrD, # 31
Machinery Dynamics Research, 2016
ODE Solution --- Fail!!
Digital computation has become a major tool for engineers, and it is a great benefit. It can also lead to many pitfalls for the unwary. This note is about the latter, a potential pitfall that many engineers risk on a daily basis, most of them with little awareness of the danger.
Early in the development of digital computation, every problem required that the user write a program specific to the problem at hand. If speed was a very important issue, the programs were written in machine language, so that they would execute as fast as possible. If speed was a little less critical, programs were written in so-called "high level languages." This included FORTRAN, BASIC, ALGOL, C, C++, and a host of other such names. But even with a high level language, there was the problem of generating a program for the solution of the specific problem at hand.
As things have continued to evolve, it was soon evident that a lot of the work in writing each program was the same from one problem to the next. The major mathematical operations, such things as numerical integration, matrix operations and the solution of systems of linear equations, plotting, and many other steps were re-usable from one problem to the next. It was natural that this would eventually lead to the development of general purpose programs, able to solve broad classes of problems. This group includes programs like Mathematica, Maple, MatLab, SciLab, Maxima, TKSolver, and numerous others. Most of those just mentioned have built-in capability to solve ordinary differential equations, in some cases by analytical means, and in practically all cases, by numerical means. This has taken the sting out of working with differential equations
from many engineering problems, and we must all be grateful for that.
At the same time, we must also be somewhat skeptical about any general purpose solver when applied to a particular problem. How do we know that the solution generated is correct? How do we even know if it is reasonable? Most of the time, when engineers resort to numerical solutions, it is because there is no readily available analytical solution. Thus, when faced with a problem that cannot be solved in closed form, how can we know when to trust the numerical solution? This is a very serious question, one that all must consider. It you blindly trust a numerical solution, the old excuse, "The computer said it was OK" will not get you very far. The computer cannot be fined, fired, or (in extreme cases) possibly sent to prison, but all of these things can happen to an engineer!
So, what can the engineer do when the differential equation has no known solution? Well, there are several options.
(1) He can resort to any physical principles that apply to the situation. For example, if the system is such that energy should be conserved, then he can add code to calculate the total system energy at every instant. Just verifying that energy is conserved does not "prove" that the solution is correct, but if energy is not conserved when it should be, you can be sure there is an error in the solution.
(2) He can try various approximations that may apply to see if they are in reasonable agreement with the computed solution.
(3) He can verify the solution code by applying it to a similar problem for which there is a known solution. It is this last approach that I want to talk about in this post.
You have probably heard of Engineering Econ, Engineering Management, etc., but what about Engineering Philosophy?
Most of the time, in engineering discussions we talk about “hard information,” that is, facts, ideas, and methods for doing various engineering activities. But behind all that, guiding it, there needs to be a correct philosophy, an approach to life. Late at night, when you are alone in your bed, do you ever think about, “What does it mean that I am an engineer? What does this mean about the way I approach my daily work? What does it mean about the way I think about politics? What does it mean about the way I live my life?”
A recent comment on one of my previous articles points indirectly toward these questions. I do not wish to criticize the person making the comment in the least, but rather to use his comment as a spring-board to get into my reflection on philosophy. The comment read, in part, as follows:
...but we learn in in india from our regular course, book contents are diferent from differnet author, so we have problem which one is correct. for example my project is analysisi of drum brake, the book I preferred for making the project and for formulation is wrong according to some people.
This person is pointing to a misunderstanding of engineering education. He wants an authority that is always correct, so there will be no conflict between one authority and the next. He wants to be able to say that a particular approach is correct because this author said so. What is he missing?
To try to get to that question, let us first look a bit deeper at his complaint. We have engineer W complaining that he wants to execute his project following the methods described by author X, but various others are saying that he should follow the approach given by author Y or the one set forth by author Z. What is engineer W supposed to do?
Assuming that authors X, Y, and Z each describe a different approach to his problem, how should he know which one to follow? Is it possible that each of the authors, X, Y, and Z are correct even though they are different? Well, maybe.
1. It may be the case that each of the authors describes an approach of different accuracy. Perhaps X is describing a simple, “back of the envelope” hand calculation that is only a rough approximation but requires very little effort. At the same time, Y is describing an approach incorporated into a widely accepted standard, and Z is describing a very thorough, detailed analysis (FEA, CFD, elaborate simulation, etc.). Which one is correct? Well, they all are “correct” in their own context. Then the question becomes, what does the project justify? Is it worth spending the resources (time, manpower, etc) for the very detailed approach given by Z, or is a very rough approximation sufficient for the present purposes, something like the hand calculation described by X? In this situation, the “correct choice” is the one that is appropriate to the purposes of the project.
2. Another possibility may be related to the technology involved. For example, imagine that author X is describing a graphical solution while author Y is describing a simple but effective computer solution and Z is again proposing a very involved computer solution requiring massive computing power and software resources. The graphical solution may offer a good bit of insight, but it is necessarily relatively slow and has only limited accuracy. Repeated applications of the graphical methods mean many clean sheets of paper to start again and again. The simple computer solution is likely to be much more accurate and lends itself to repeated application as needed to iterate toward a final solution. The very detailed computer solution can also be used to iterate, but often at very high costs in terms of time and resources. In this case, the simple computer solution described by author Y is likely the optimum approach.
3. There is also the unhappy possibility that the method recommended by author X may simply be in error. We may assume that he would not have published it if he thought it was incorrect, but the fact that it is in a book is no guarantee that it is correct. If this is the situation, then it is clear that the method of author X is to be avoided.
So where does this leave engineer W? The answer is really pretty simple: He should not use any tool that he does not fully understand, both in terms of how it works and what it costs. And this brings us back toward the original question, “What does it mean that I am an engineer?” An engineer is one who applies knowledge. He does not simply use tools without understanding what they do.
This last statement leads into another discussion, that regarding just how fully do you need to understand your tools. We have to recognize that no one can know everything that is known; it is simply too much. That said, it is clear also that the person who tries to drive a screw with a hammer does not understand his tool. One place where we can easily get into difficulties is with the application of commercial computer programs for FEA, CFD, etc. These are highly sophisticated programs, and the internal technical details of their workings is clearly the realm of the specialist. On the other side, the misapplication of these programs have produced some stunningly bad results, leading to catastrophic failures and false alarms. How is an engineer supposed to deal with these?
The first guiding principal is “Do Not Accept Anything Blindly Just Because the Computer Said So.” We must remember that the computer has no brain at all. It is simply a very fast way to make calculations, calculations which can be made correctly or in error. The computer is able to generate errors far faster than anything you could possibly do by hand! You must always, without exception, check computer results for reasonableness. You should also run test cases, cases for which solutions are known by other means, that incorporate as many of the features of you actual problem as possible.
Let us look at a specific case to expand upon this. Suppose that our engineer needs to design a shaft. The shaft is required to transmit certain amounts of power, it has various lateral loads, and in all likelihood has numerous steps along the length (steps are useful for locating items such as wheels, bearings, disks, blades, etc., mounted on the shaft). Our engineer may very well choose to use a finite element program or a specialty shaft design program to assist him in his design work. How will he be able to judge the correctness of the computer results?
In college, he took a course in Mechanics of Materials (sometimes called Strength of Materials) in which he studied shaft and beam deflections and stresses. The problems in that course were, without exception, based on simple geometries. The beam/shaft is usually uniform along the length, and the supports are either simple supports (knife edges) at the ends or built-in ends. The course will usually consider a variety of discrete and distributed loads. How does this relate to the design problem he faces on the job?
1. He should have learned that the boundary conditions are critical to a correct model. Changing from a simple support to a fixed (built-in) support can make a great difference.
2. He should have learned that the corners near a step along the length are essentially dead material; they do not carry much stress or strain at all because of having a free surface on two sides.
3. He should have learned how to combine the effects of different load types by superposition. This will allow him to consider one load, or one group of loads, at a time if that is useful.
4. He should have learned how to combine stresses in order to compute principal stresses and the von Mises stress at a point for failure evaluation.
5. He should have learned about stress concentration at corners, such as a step, and the means to mitigate this problem.
The list above is only a beginning, but the point is, the information from the Mechanics of Materials course is going to be fundamental in his shaft design problem on the job. He may also need to draw on information from Dynamics, Vibrations, and Material Science courses to deal with the whole problem. For this reason, it is absolutely essential that he actually learned the content of these courses. They are not there simply as hurdles to be jumped on the way to a degree; they are the basis for professional engineering work.
When I say “learn the content of these courses,” I mean just that. Really learn, understand, and make the content of these courses your own. This means learn all of the mathematics required to work through and fully understand all of the derivations. Again these are not simply hurdles to be passed; they are the foundations for your career.
Sadly, I have to admit that there are a great many people in engineering positions who have not done this. While I was still an undergraduate myself, I had an opportunity to visit with the director of the state highway department, the man ultimately responsible for the design of all the roads and bridges in the State of Texas. I asked him how much he used calculus on a day-to-day basis. He laughed at me, and told me that he never used calculus. He could not remember any of it. That puzzled me at the time, but I understand it now. This man was no longer really an engineer; he was not competent to design anything at all. He was a paper-pusher, and executive, but he was not an engineer. You can only be an engineer if you know what you are doing!
That brings me back to the comment that appeared on this blog, the complaint about different authorities in conflict. The final answer to that question is simply this: You, the engineer, must be able to correctly identify the proper approach and justify your decision. You can do this if you really know what you are doing, but you will never be able to do it if you don’t know what you are about. You, the engineer, must ultimately be your own authority!