z-logo
open-access-imgOpen Access
Computational Paradigms In Undergraduate Mechanical Engineering Education
Author(s) -
W. Glenn Steele,
B. K. Hodge
Publication year - 2020
Publication title -
papers on engineering education repository (american society for engineering education)
Language(s) - English
Resource type - Conference proceedings
DOI - 10.18260/1-2--9020
Subject(s) - fortran , curriculum , computer science , session (web analytics) , mathematics education , programming language , matlab , software engineering , computer programming , point (geometry) , engineering education , computational thinking , engineering management , mathematics , artificial intelligence , pedagogy , engineering , world wide web , psychology , geometry
Undergraduate mechanical engineering (ME) programs in the United States were surveyed to determine the usage of programming languages (such as C or FORTRAN) versus the use of arithmetic systems (such as Matlab or Mathcad). A survey form was e-mailed to all ME programs. The survey form was used to determine the following: (1) programming courses required, (2) use of programming in ME curricula, (3) use of arithmetic systems in ME curricula, (4) junior-level analysis courses required, and (5) computer ownership requirements. Seventythree responses, representing a good cross section of ME programs were received. The survey showed that about threefourths required at least one course in structured programming but that only one third of the programs requiring a formal programming course used programming in two or more required courses. More than three-fourths of all programs used arithmetic systems such as Matlab or Mathcad, and about the same number required a junior-level analysis course. Thirteen of the seventy-three ME programs that responded to the survey required students to own computes. Background At some point in any engineering endeavor, calculations must be made and “numbers” generated. The manner of doing calculations in the engineering workplace and in engineering education has continuously evolved, especially since World War II. Prior to that time, engineering calculations were accomplished in a manual fashion using what were then state-ofthe-art techniques. In the eighteenth century, addition, subtraction, multiplication, division, and log tables were laboriously used. The situation was greatly improved by the slide rule [the first useful one was introduced about 1850 (1)] and the mechanical calculator, but generating numbers was, until after World War II, still a labor-intensive undertaking. Feynman’s (2) anecdotal account of neutron diffusion calculations at Los Alamos in the 1940’s is a good example of the drudgery and tediousness of extended pre-computer calculations. The digital computer fundamentally altered the use of “manual” calculations and replaced it with machinebased computations. Initial efforts were hard-wired (literally) with patch boards, but by the early 1950’s higher-level programming languages evolved. For engineering computations, FORTRAN became the dominant programming language. However, as these advances were taking place, both the engineering workplace and engineering education struggled to effectively utilize the promise of the “computer” and to define the relationship between the computer and engineering. Indeed, one could argue that these struggles are ongoing. The situation is much clearer today than a decade ago, and much progress has been made in effective utilization and in the computer/engineering symbiosis. Hodge (3) identified four P ge 681.1 Proceedings of the 2001 American Society for Engineering Education Annual Conference & Exposition Copyright 2001, American Society for Engineering Education computational modes in the long-term evolution of Energy Systems Design (ESD), a specific mechanical engineering course at Mississippi State University. The course started out as handheld calculator based (1981-1984) but quickly evolved into a course requiring extensive FORTRAN or BASIC programming to solve problems. During the late 1980’s and early 1990’s, the assignments moved from programming based to software application/modification based. However, by the mid-1990’s, arithmetic systems such as Mathcad, Matlab, and Mathematica had been developed to levels that were very congruent with problem formulation and offered significant computational and visualization enhancements. Hodge’s experiences with integrating Mathcad as the arithmetic engine in the ESD course are described in Hodge and Taylor (4). The use of Mathcad permitted much more realistic problems to be assigned and allowed the students to focus on problem formulation and solution (engineering tasks), rather than on programming issues. To some extent these four different modes of accomplishing arithmetic parallel the evolution of computational paradigms in engineering and engineering education. Certainly, two dominant influences in the engineering workplace and in engineering education in the latter part of the twentieth century were the ever-increasing capability of digital computers and the ever-increasing utility of software. Indeed, engineering education has struggled to integrate and accommodate the evolving hardware and software into curriculums. The preEC2000 ABET accreditation criteria for a number of years specifically addressed the integration of computers into engineering curricula. Until the advent of arithmetic systems, such integration meant devoting time and effort to structured programming in higher-level languages (FORTRAN for example). Now the use of arithmetic systems such as Mathcad represents a more fruitful path that seems to portend the future. Indeed, as Baker et al. (5) point out, “...the days of amateur programming are over.” That is to say, except for highly-skilled engineering specialists with post-BS degree education, engineers are not likely to do much structured programming in their careers. This does not imply that engineers won’t use computers, only that applications, not programming, will be the engineering tasks. All of the above raises questions about what is happening in mechanical engineering education in terms of computational paradigms used in undergraduate programs. Based on discussions at the last few ASEE Annual Meetings and Exhibitions, the topic of programming versus arithmetic systems is of great interest to the ME educational community. One way to find out what is happening is to survey the ME programs in the United States. This paper reports the results of such a survey. Survey A survey form was developed and transmitted via e-mail to all ME programs in the United States. The e-mail contained a letter explaining the survey form and the survey form. Issues of interested include: 1. Programming courses (FORTRAN, C++, ....) required. 2. Indications of programming language usage in required ME courses. 3. Arithmetic systems (Matlab, Mathcad, EES, Mathematica, ....) used. 4. Indications of arithmetic software usage in required ME courses. 5. Junior-level ME engineering analysis course required. 6. Computer ownership requirements. P ge 681.2 Proceedings of the 2001 American Society for Engineering Education Annual Conference & Exposition Copyright 2001, American Society for Engineering Education The survey form is reproduced in Figure 1. The survey contains nine questions. Question 1 asked if a programming course is required in the undergraduate ME curriculum. If the answer is “yes,” then questions 2, 3, and 4 as well as questions 8 and 9 are answered. If the answer to question 1 in “no,” then questions 5, 6, 7, 8, and 9 are answered. This survey format was selected to ensure a clear distinction between programming usage and arithmetic system usage. Even so, interpretation differences were found in some survey comments. Several institutions, for example, considered Matlab to be a programming language. In the survey, the original intent was that Matlab usage was not structured programming. In compiling the survey results this ambiguity was noted. Question 2 requested the programming language (or languages used) in the required course. Question 3 asked if two or more required courses used programming, and question 4 asked if two or more courses used arithmetic systems. Both questions 3 and 4 relate only to programs that require a programming language course. Questions 5, 6, and 7 are answered only if a programming language course is not required. Question 5 requested the system used if a programming language was not required. Question 6 asked if arithmetic systems were used in two or more required courses in the curriculum, and question 7 enquired if a special course was used to make sure all students were proficient in the arithmetic system used. Question 8 was included in order to determine if a sophomore/junior-level engineering analysis course was required in the ME curriculum of the institution. Such a course would likely be taught by an ME faculty member and would emphasize algorithm applications (either in a structured programming language or an arithmetic system) of ME-oriented problems. Question 9 asked if computer ownership was required by students in ME at the school. Mr. Thomas Perry, Engineering Education Director of ASME International, graciously agreed to e-mail the letter and survey form to all ME department heads via his ASME e-mail list for ME department heads. Additionally, he volunteered to pass out a hard copy of the survey form at an ASME department heads meeting in November. A total of 73 responses were received. The respondents included a good cross section of ME programs that were geographically well distributed. Based on the number of responding institutions requesting the results, considerable interest is present for this subject. Survey Results and Interpretation The response for each question in the survey will be examined and interpreted. Question 1: Are all undergraduate mechanical engineering students required to take a programming course?

The content you want is available to Zendy users.

Already have an account? Click here to sign in.
Having issues? You can contact us here
Accelerating Research

Address

John Eccles House
Robert Robinson Avenue,
Oxford Science Park, Oxford
OX4 4GP, United Kingdom