Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Computing in Mechanical Engineering?

  1. Jun 16, 2008 #1
    I ask all Mechanical Engineers, if you do use a computer programming language to aid in your problem solving and work, which one do you use?
    I use Visual Basic For Applications (VBA) which is integrated with Microsoft Excel 97 and onwards, but my university recommends a proper computing course which uses C as a programming language.
    (I'm a first year by the way.)

    Personally, I think we have moved on from the days of slide rules to now electronic calculators so I find C less interesting and much more difficult to grasp and I find using software such as Microsoft Excel (along with VBA) much better to use due to its popularity, graphical user interface and capabilities.

    Spreadsheets aren't just used for financial purposes!
  2. jcsd
  3. Jun 16, 2008 #2
    Of the general-purpose programming languages, I use C/C++ (managed to avoid Fortran most of the time). Of the scripting languages, nowdays Python (formerly Perl). I somehow rarely get into pressing need for specialized mathematics stuff, but here and there it was Matlab (or Octave) and Maple.

    I consider spreadsheets horrible hellspawn that has befallen unwary engineers, an improvement on hand-held calculators in the same way in which a diesel-powered titanium-built difference engine would improve on a slide rule.

    I assert that teaching spreadsheets to engineering students cripples their computational abilities, and should be treated as professional offense.

    Yes, I'm having unusually strong opinion here.

    (I make no such claim for spreadsheets in other fields, for which I've no knowledge of their particular needs.)

    Chusslove Illich (Часлав Илић)
  4. Jun 16, 2008 #3


    User Avatar
    Science Advisor
    Homework Helper
    Gold Member

    I've been an engineer for 20 years. Used Fortran, C++, Basic, home-grown programs, Excel and have some limited Mathcad experience. Of these, Excel is my favored program for basic stress analysis (ex: on flat plates, beams, springs, etc...), fluid flow (ex: through pipe, valves, other restrictions), thermodynamic processes (ex: determining fluid conditions in cryogenic systems, steam systems, heat exchangers, other process equipment), heat transfer and even some fairly complex dynamics analysis (ex: I've used for compressor and pump valve dynamics). Also, there are add-ons for Excel that can broaden it's capability (ex: NIST REFPROP).

    Engineering in industry is very focused on cost, and spreadsheets make it very easy to do almost any repetitive type analysis quickly while also providing a means of documenting information. There are things it can't do that specialized programs are needed for such as FEA, piping networks (both stress and flow), CFD, etc... but those programs are often so complex that companies have only a handful of engineers who specialize in using only one of them such as CFD.

    Perhaps the best reason to use Excel is because (almost always) you have to write the program yourself, and if you don't understand how to do the analysis, you have to figure it out! The same can't be said for canned programs where all the programing has already been done.
  5. Jun 16, 2008 #4


    User Avatar
    Science Advisor
    Gold Member

    For solving all of my engineering-related analytical problems (that don't involve FEA), I use MathCAD. It's an excellent program in my opinion, and the Mechanical Engineering plugin package for it is invaluable. From calculating stresses to calculating heat flow to estimating electrical skin depth, even symbolically deriving beam equations, I've done a bit of everything in there and it has proven to be a very powerful calculation documentation tool for collaborating with co-workers.

    In the end whatever you use is just a tool, and sufficient proficiency with any tool will usually mean you can solve the problem; but in my opinion Excel is a poor choice for engineering caulculations due to its nature- its basically a numerical financial program. Sure, its POSSIBLE to do pretty much anything in there; but having used unit-aware calculations, symbolic manipulation, and data anlysis in MathCAD, I won't ever try to solve an engineering problem in Excel.

    Knowing programming languages like C++ or Java can be a stong skill for engineers from a problem-solving standpoint, and can be useful in understanding more about numerical methods of programs you might use. But, using C++ to solve an mechanical engineering problem is kind of re-inventing the wheel because you have to write the program, and then use it. Why not just use a program that already has the groundwork laid out, and you just write the equation and have it solved?
    Last edited: Jun 16, 2008
  6. Jun 16, 2008 #5


    User Avatar
    Science Advisor

    Curious. I'm not saying right or wrong. I must say that you are the only person I have ever seen with a bad opinion of spreadsheets. Granted, you put in the caveat that your field negates their purpose. I guess I'm interested in why you feel this way especially since a spreadsheet is simply a calculator. Having a bad opinion of spreadsheets is akin to not liking electronic calculators. If you have problems that can be broken down into finite differences without having too much of an affect on the outcome, what's the issue?

    Personally, I agree with Q and Mech. Not only do they make the repetetive stuff easier, but they aid in documentation. I use MathCad but there are a few things that I just do not like about it. If my company had a license of Mathematica, I would use that. I haven't touched Fortran since college (other engineers at my company do use it though) and I occasionally dabble in VBA, especially for Excel. Then there are the specialized programs that I use daily.
  7. Jun 16, 2008 #6
    This is because I've followed somewhat of an unusual educational path for a mechanical engineer. Other people in my position usually went into fields where spreadsheets are unheard of, as using them would be totally out of question -- so they can't have a strong opinion on something that's nowhere near their reach.

    Quite correct deduction.

    The only reason I don't have bad opinion of hand-held calculators as such, is that their introduction considerably predated capable enough personal computers. They were a revolutionary replacement to slide rules, and so have their place in history. Today, however, the only thing that makes my hair more pointy than seeing a calculator next to a computer monitor, is seeing a spreadsheet on the monitor.

    This has the following background. During my high school days, the only place where we needed to crunch any numbers were Physics exams, and there, the calculator; however, at the same time, we had quite a hefty programming syllabus. It was in second year of university, circa 1998., that I first got into a situation where one would, if devoid of computer, need to make a tabulated computation on paper with a calculator. But, by then I had enough programming self-confidence to feel that just carrying such a computation onto computer (i.e. spreadsheet) is a gross underuse of general-purpose computing machines. So, I continued using calculator exclusively on exams, and accordingly kept spreadsheets at bay.

    Some time ago, I tried to point out some crucial deficiencies of spreadsheets by posing a few higher level questions, not to go into gritty details.

    Chusslove Illich (Часлав Илић)
  8. Jun 16, 2008 #7
    One big downside to VBA is it puts you at the mercy of Microsoft. I have experienced the pain first-hand. I created a relatively complex application in VBA several years ago, automating a tedious and error-prone process. Then the company "upgraded" to the latest Microsoft Office... and my app broke. No heads-up from MS that they were changing the API, no "backwards compatibility", just "CRASH".
  9. Jun 18, 2008 #8
    To All:

    I have been practicing engineering for a while. Also, I have been dealing with programming for a number of years.

    Way back, programming started with Fortan and BASIC.

    In my opinion, if one knows one programming language very well, there is no need to fear any new/other language.

    I do like MS Office very much. Before, in old days, plotting was very difficult. Today, that is no more the case.

    I do like Ms Excel and its connection to BASIC and VBA. This is a great way to make spreadsheet calculations powerful and reduce potential error when working with spreadsheets.

    My suggestion is as follows: be open and try to expand your knowledge base when possible ...

    Today, sky is the limit when it comes to resources and their capabilities and presenting and sharing your work with others over the Internet ...

    Good luck!


  10. Jun 18, 2008 #9
    Just out of curiosity, does Excel have some type of mathematical library?

    As an example, how would you use Excel to solve differential equations? I guess one could setup something simple like a fixed step Euler, or Runge-Kutta method... but crap, I can't imagine a multistep method with Excel.
  11. Jun 18, 2008 #10

    Actually, it is possible to use MS Excel for Euler integration etc.

    It get clumsy, but it is possible.

    One neds to use BASIC or VBA by creating functions/subroutines. Such routines are connected to cells in a sheet.

    By playing with cells and routines, solution is possible when dealing with integration -- plots are easy to get setup displaying the input and output data ...


  12. Jun 19, 2008 #11
    Given that -- I suppose -- VBA too can be shown to be Turing complete, you can of course do anything with it (albeit not in practical sense, cf. the questions in my linked message). However, once one has moved to VBA for any decent computation, then he had unwittingly 1) demonstrated that spreadsheet is actually crap, 2) chosen probably the poorest of the proper-like replacements for it (VBA as compared to... any other scripting language).

    Chusslove Illich (Часлав Илић)
  13. Jun 19, 2008 #12
    Hi there:

    Yes, you are right.

    But here is the catch.

    With MS Office, either BASIC or VBA come for free. MS Excel provides easy environment to work with and files are very small. Today, everybody has a copy of MS Excel on his/her computer. Therfore, files can be exchanged quickly.

    Having created BASIC or VBA routines in MS Excel, one can migrate to VBA.

    VBA is not totally free and it needs to be installed as a standalone application. Sharing original VBA files is no longer easy, because people need to have a copy of it installed on their computer. Also, it is possible to provide fully operational VBA applications with a VBA engine, but now the things get complicated.

    Actually, there are two Worlds -- MS Office and VBA. There are +s and -s.

    In my opinion, please respect MS Office and MS Excel and take advantage of what they bring to the users. They are not perfect from the programming point of view, but knowing the good benefits, go ahead and work with them.

    Actually, work with both Worlds -- it is to your advantage ...


  14. Jun 19, 2008 #13
    So how crazy of computations does one actually do with Excel?

    • I mean FORTRAN kills for speed and cluster computing.
    • MATLAB is quick and dirty.

    I've heard C is used often... I guess it really depends on what is being calculated. But could someone give me an example of what would be done with Excel?
  15. Jun 19, 2008 #14


    User Avatar
    Science Advisor
    Gold Member

    It can help to look at the problem from an efficiency standpoint. Are you getting paid to solve the problem, or are you getting paid to write a piece of software that solves the problem? In the academic world this might get a little fuzzier, but in private industry it's all about finding the right tool (or person) for the job.

    In most cases, it is cheaper for you and your company if you purchase software designed for your application. If you're spending your time writing algorithms to solve ODE's in Excel, or writing your own set of functions you use to solve complex non-linear system of equations in FORTRAN, you're re-inventing the wheel. Most mathematic calculation software (MatLab, Methematica, MathCad, etc.) can solve pretty much any complex problem with relatively few commands. Therefore you spend less time solving the problem and more time doing what you need to.

    Sure, you can solve anything in a base-level programming language if you know what you're doing and given enough time. But, it probably isn't a good way to do it...
  16. Jun 19, 2008 #15
    Mech Engineer:

    You should be encouraging people to do some work on their own instead of saying there is a black box and lets go with the black box -- that is not a good engineering approach ...

    In my opinion, people should try something on their own no matter what the problem scope is. For sure use an off the shelf piece of software to help you out and be more efficient. I am not saying, lets reinvent the wheel, but lets make sure that the wheel is spinning in the right direction and there is a sanity test that was completed ...

    In a long run, it is always good to have a set of tools developed on your own -- in general, off the shelf software ends up having some kind of a limitation ...


  17. Jun 19, 2008 #16


    User Avatar
    Science Advisor
    Gold Member

    Your opinion is contrary to efficient engineering practices used in industry. Engineering managers would rather purchase a properly supported mathematic suite (or other software package) as a tool for their engineers than have the engineers spend lots of expensive engineering time writing their own software to solve the problem. Period.

    Maybe that's ok for students learning the applications of numerical methods in college, but later on this is not an efficient use of engineering time. No matter what the scope is??? Do you really expect people to try and write their own FEA or CFD software rather than purchasing COMSOL or ANSYS? What about a fully parametric solver for PDE's? Software to solve systems of equations in the hundreds? Sounds like a lot of time wasted to me... Unless your company is in the business of developing these algorithms, that's money down the drain.

    There's a huge difference between understanding an application and the intricacies involved, rather than writing your own software suite to understand it.
  18. Jun 19, 2008 #17
    Mech Engineer:

    I do appreciate your reply and rational.


  19. Jun 19, 2008 #18
    Let's just not confuse counterparts here. From mechanical engineer's viewpoint, MathCAD is to be used in exactly the same capacity as spreadsheet (Excel). There is no reason to use both of them, one "for this" the other "for that".

    Meaning, of course, that MathCAD is vastly superior to Excel. It's like a "graphical" Matlab ; one can also write algorithmic functions in it, loops 'n all, which perfectly interact with "ordinary" stuff. Having physical units from the ground-up is really nice too. I myself used it for a lot of university stuff, had to dump it near graduation only because it became too limiting -- too slow, bound to wrong platform, not tractable enough -- for my purposes (that was some 6 years ago, perhaps stuff changed since...) But otherwise, it was a good tool for single-person, non-intensive engineering computations.

    MS Excel (as one particular spreadsheet app) is less available than the workhorses I use or recommend, being two-platforms only. And not everyone has MS Office on his/her computer; I even witnessed an employee (probably a higher-ranked one) of a certain airframe manufacturer, bouncing a file sent to him by a colleague of mine, with note "no MS Office, provide in another format".

    Then, as far as I've seen, in the view of heavy spreadsheet users, a spreadsheet app either has to be Excel, or it's useless. Spreadsheets = Excel. This is quite understandable, since due to poor basic concept of spreadsheets, one has to tie himself to a lot of "extra features" (i.e. patches to conceptual defects) provided by one particular heavyweight app. This further reduces practical availability of spreadsheets in general.

    However, compared to other problems, availability of spreadsheets is of negligible importance, so I normally don't pull it out of the hat for bashing purposes :) But, you mention here something else in conjuction with availability -- exchange, i.e. collaborative work. This is where spreadsheets are disastrous.

    I've yet to see a spreadsheet in wilderness that was developed by more than one person, and modifiable and maintainable by anyone else. At best, people other then the creator used it as a canned solution -- input numbers here, see results there, complain when it spews obvious nonsense. There is no practical way to develop a spreadsheet computation modularly and accountably by several people; no way to track history of changes, of who did what, when, and why. As opposed, this is normal and established practice with any proper programming material (Matlab's .m files amenable too), and can be performed with free and fully cross-platform tools.

    Even the creator himself should think twice when modifying a few-month old spreadsheet. There are either no tools, or only very specific and very costly ones (i.e. extremely poorly available) for asserting spreadsheet's sanity over time. E.g. there is no provision for regression tests, in environment where introducing errors is extremely easy. Several reports on that:


    Chusslove Illich (Часлав Илић)
  20. Jun 19, 2008 #19

    I do appreciate your reply and rational.


  21. Jun 19, 2008 #20
    To All:

    Apparently, being engineers and practicing engineering for many, many years, there are different views and opinions on the same subject matter.

    Therefore, please do it as it suits your preferences and ways of doing business.


    Last edited: Jun 19, 2008
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?

Similar Discussions: Computing in Mechanical Engineering?
  1. Mechanical Engineering (Replies: 13)

  2. Mechanical engineer (Replies: 2)

  3. Mechanical engineering (Replies: 5)

  4. Engineering mechanics (Replies: 1)

  5. Mechanical Engineering (Replies: 6)