Problem Solving in Engineering (eBook)
1304 Seiten
Wiley (Verlag)
978-1-394-18000-4 (ISBN)
Bring mathematical principles to bear on engineering problems with this updated text
The evolution of industrial processes has resulted in greater emphasis upon analytical and numerical problem solving. Process improvement through experimentation is impractical and consequently engineers must rely upon computational and technical analysis. Furthermore, the ease with which time-series data can be collected and processed has made harmonic signal interpretation routine. Thus, the ability of engineers to analyze, model, compute, and interpret process phenomena is crucial to professional practice.
Problem Solving in Engineering meets these needs with a foundational introduction to mathematical techniques in applied sciences and engineering. Incorporating examples from a range of scientific fields, it communicates principles that can be adapted to many hardware-software combinations. Now fully updated to reflect the latest research and applications, it remains an essential tool for engineers and applied scientists everywhere.
Readers of the second edition will also find:
- Extensive time devoted to problem formulation
- Detailed discussion of integro-differential equations and the processing and analysis of time-series data
- The use of vorticity transport for the solution of momentum, heat, and mass transfer problems in two dimensions
- Examples and problems drawn from aviation, telegraphy, structural failures, railroad operation, chemical processes, automatic process control, seismology, neutron diffusion, gravitation, and quantum theory
- Many additional narrative-type exercises written to appeal to students who find problems in context better suited to their learning style
- Solutions manual available for qualified instructors
Problem Solving in Engineering is ideal for advanced undergraduate, graduate students, and technical professionals in the physical sciences, specifically chemical, civil, biochemical, electrical, and mechanical engineering, as well as physics, chemistry, and biology.
Larry A. Glasgow began his teaching career at Kansas State University in 1978 and taught nearly all of the classes the department of chemical engineering offers, earning numerous teaching awards throughout his 38-year long career before retiring in 2016. Glasgow's research areas of focus concern the interaction of turbulence with fluid-borne entities in multi-phase processes, including flocculation, aggregate breakage and aggregate deformation. In addition, he has investigated bubble formation, coalescence and breakage in aerated reactors, the effects of energetic interfacial phenomena upon cells in culture, and the impulsive distribution of small particles in air-filled chambers. Glasgow has also authored multiple publications, as well as two books: Transport Phenomena: An Introduction to Advanced Topics (2010), and Applied Mathematics for Science and Engineering (2014).
1
Problem Formulation, Models, and Solution Strategies
1.1 Introduction
Many engineering textbooks describe the steps one should follow when solving engineering problems, and the list given by Eide et al. (2008) is appropriate for our purposes:
- Recognize the problem and develop a physical understanding of it
- Accumulate pertinent data if they are available
- Select an appropriate principle or theory as the basis for the model
- Apply the simplifications necessary to make the model tractable
- Solve the problem with the best available tools
- Verify the results using experience and physical insight.
Most of our work here will be focused upon 4), 5), and 6) since the models we will be working with—for the most part—have already been formulated for us and the data needed are provided in the problem statements. However, we should remember a physical understanding of a particular problem, 1), is a key element of a successful process; we cannot evaluate the results of our solution or our computational procedure without it. We should also observe that there is one aspect of the philosophy of engineering problem solving that does not appear in this list: Always begin with the simplest possible model and the most direct solution procedure. You are less likely to make a mistake, and additional complexity can always be added should you find it necessary. An inelegant solution procedure that provides the required result is always better than an elegant one that fails.
In this context, we note that many of the numerical methods described in this text were developed with PBCC™ (the Power BASIC Console Compiler). This has not been done with the expectation that students of this material will learn to write their own programs. A few may be so inclined, but for most it is more practical to utilize readily available commercial software. Nevertheless, there are important reasons for providing these examples: i) BASIC codes are pretty transparent—the logic is clear even to students with no background in high-level languages, ii) the author has found that PBCC generates very fast executables; although this is of little consequence for, say, root finding with Newton–Raphson, it may be critically important if one is trying to solve partial differential equations, and iii) both the structure and the intent of these example programs are obvious, so the solution strategies can be adapted to many different hardware/software combinations.
This touches on an old debate in engineering education: Should engineering students be taught computer programming? Proponents of this idea argue that programming in a high-level language fosters a systematic approach to problem solving. In the era of centralized computing prior to 1980 (in centralized computing users submitted their programs on punched cards to a mainframe computer and then waited for the printed output to be returned) this meant learning FORTRAN, a high-level language designed specifically for scientific computations. Software available for technical calculations included IBM's Scientific Subroutine Package (SSP) and, after 1971, SAS (the Statistical Analysis System). The former had capabilities for common operations like solving algebraic equations, performing numerical quadrature, and solving sets of ordinary differential equations. The SSP routines had to be “called” by a main program written by the user; furthermore, an engineer with an atypical computational problem would need to write their own code from scratch. This situation persisted into the beginning of the personal computing revolution when IBM introduced the PC based upon Intel's 8088 processor. Technical professionals immediately discovered the benefits of accessible computing power; unfortunately, software available for personal computers was limited to the disk operating system (DOS), a BASIC interpreter, and rudimentary spreadsheets. By necessity, engineers developed BASIC programs for many technical computations despite the speed limitations of the line-by-line interpreter. This changed rapidly, though, with the availability of the 8087 numeric coprocessor and Microsoft's publication of high-level language compilers for both FORTRAN and BASIC. By 1990 the computing power of PCs had evolved to the point where engineers could solve important problems without ever leaving their desk. It is no exaggeration to say that the decentralization of computing power greatly facilitated progress in the technical professions.
It is possible—even likely—that at some point in the near future an AI (artificial intelligence) system for engineering problem solving will exist. We can assume that it will make calculations for routine engineering problems autonomously with a near-zero probability of error. However, this does not mean that skilled engineering problem solvers will disappear. What the incorporation of automation in industrial settings has demonstrated is that when some job functions are eliminated, others are created. We should anticipate a future where highly capable engineering professionals will work in concert with AI to produce solutions that are practical, efficient, and economically optimal.
Exactly what are we trying to accomplish in this course?
- We want to model a system, process, or phenomenon so that future behavior can be predicted.
- We want to select an appropriate solution procedure so the model can be used as a tool for process design, improvement, or control. In the case of the latter, we are particularly concerned with problems that may result from transient operations or process excursions. In these instances the fidelity of the model and the accuracy of the solution procedure may have significant implications for safety.
- We want to interpret data that have already been collected; i.e., we need to develop a framework that allows us to understand what has transpired and confidently apply that to analogous situations.
To accomplish these objectives we will review some mathematical techniques that can be used to solve important problems in engineering and the applied sciences. We will focus upon problem types that are crucial to the analysis and simulation of real, physical phenomena. As noted previously, sometimes our objective will be to predict future behavior of a system and sometimes it will be to interpret behavior that has already occurred. We want to stress that the author and the readers are collaborators in this effort, and whether this text is being used in a formal setting, or for self-study, the ultimate goal is the same: We want to be able deal with problems that arise in the applied sciences and do so efficiently. And—this is important—we do not want to rely upon calculation software unless we know something about the method(s) being employed. Too often real problems can have alternative solutions, so it is essential that the analyst be able to exercise some judgment based upon understanding of the problem and of the algorithm that has been selected.
We will redirect our discussion momentarily to underscore a common difficulty faced by engineers engaged in problem solving—and one not described above. Before you commit the time required to solve a particular problem you should ask the following question: Do I have enough information to formulate a model and to find an appropriate solution? Though the answer is usually obvious in instructional examples, it is less likely to be so in real-world problems. All engineers (and managers) want to make efficient use of the time spent solving problems, so allocating effort to determine whether a particular problem as posed is solvable prior to commencing the actual work is always justified. Let us illustrate this with two examples beginning with an elementary DC circuit illustrated in Figure 1.1.
Assume a voltage is applied and the resulting current flow in the circuit is measured. The resistors are parallel–series–parallel, so we write the appropriate equations beginning with Ohm's law:
Figure 1.1 A DC circuit with five resistors.
Figure 1.2 A desalination process consisting of an evaporator and a crystallizer.
Now, suppose the following information is available: V = 75 V, I = 2.19 amps, R1 = 8 Ω, R2 = 15 Ω, and R3 = 10 Ω. Can we determine R4 and R5? We cannot since we have two unknowns:
or
So what we can calculate is the sum of the inverses—we must know something about one of these resistors if we are to go farther. For example, if we know R4 = R5, one can then show that R4 = 38 Ω. In this simple problem the lack of information necessary for solution was apparent. But that will not always be the case, more complex problems may be missing subtle elements that render solution impossible; e.g., many engineering students have experienced this in the analysis of forces in trusses or solving material balances for chemical processes with recycle streams. Let's look at an example of the latter.
Material balance problems for chemical processes produce sets of algebraic equations, and it is often unclear whether or not a solution can be obtained with the information provided. For example, consider a desalination process in which a salt solution is fed...
| Erscheint lt. Verlag | 4.3.2025 |
|---|---|
| Sprache | englisch |
| Themenwelt | Naturwissenschaften ► Chemie |
| Technik | |
| Schlagworte | algebraic equations • algorithm • Data Interpretation • Finite Difference Method • integro-differential equations • model development • ordinary and partial differential equations • quadrature • time series data |
| ISBN-10 | 1-394-18000-4 / 1394180004 |
| ISBN-13 | 978-1-394-18000-4 / 9781394180004 |
| Informationen gemäß Produktsicherheitsverordnung (GPSR) | |
| Haben Sie eine Frage zum Produkt? |
Kopierschutz: Adobe-DRM
Adobe-DRM ist ein Kopierschutz, der das eBook vor Mißbrauch schützen soll. Dabei wird das eBook bereits beim Download auf Ihre persönliche Adobe-ID autorisiert. Lesen können Sie das eBook dann nur auf den Geräten, welche ebenfalls auf Ihre Adobe-ID registriert sind.
Details zum Adobe-DRM
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen eine
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen eine
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich