Computing in Mechanical Engineering?

  • Thread starter CGUE
  • Start date
  • #26
354
0
suggestions

Does anyone have any online sources where one could begin to learn different tools? Like tutorials or sample code to get me started. I used Matlab back in varsity, but now it seems apparent that not everyone agrees on what is best. Also, I don't have access to "specialised" programs like Fluent for CFD or even Matlab for that matter. VBA is readily available though as it comes with excel, for example, anyway. I was interested to see it can be used for engineering applications. How? Where can I learn? I feel like a kid that just found out his old dog (excel, in this case) can do new tricks (VBA) and I want to learn how to make him do the tricks I want him to do. I have some basic programming knowledge, like all engineers do, I guess. I did some courses in Turbo Pascal, Java, Matlab and experimented with Assembler for microchips. Looking forward to getting my teeth in :wink:

To be more specific, right now I am trying to model fluid flow in a pipe system, and at the moment I just have huge tables with variables and equations floating around and charts to graph the results (really basic and messy stuff). My company doesn't have CFD tools and is not about to buy me a licence for one short term project, but they do want some sort of results. I would love to be able to show them visual results, but graphs and numbers would be great too. How can I learn to use my humble Excel spreadsheet optimally.

I'm open to sugesstions, thanks in advance. :smile:
 
  • #27
131
0
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?

I use Excel for everything except for matrices and diff. eqs. Then I use MATLAB. Though it is possible to do diff eqs in excel, I don't bother. What no one has mentioned is the SOLVER in Excel kicks ASS. Let's say you need to choose a bolt size based on assorted loads and fall within a factor of safety. Make the spreadsheet, then backsolve for the bolt size. 10 minutes in Excel. With Matlab it would take an hour because you'd have to work the problem backwards on paper first. Excel imports text files well too. The craziest thing I've seen excel do was solve a linear equation with 5 variables using a prony scheme. Sometimes it would take up to 20 minutes. Some guys even do FFTs in excel. But like I said, Matlab is tops for diff. eqs. and laplace stuff in my book. MATLAB is C based.
 
  • #28
62
2
redargon:

Here is an MS Excel sample case dealing with combustion.

If you have any questions, please let me know.

Thanks,

Gordan
 

Attachments

  • Combustion-PF.xls
    99.5 KB · Views: 142
Last edited:
  • #29
stewartcs
Science Advisor
2,177
3
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 ...

Thanks,

Gordan

In order to actually use most of the software on the market, you have to know what is going on inside the software (to a certain extent). This where ones engineering education comes into play. Actual engineers already know the concepts behind what the program is doing. The program is just making the process faster and less error prone. It is pointless for an engineer to have to write a program to get an answer for a problem when there are countless "off-the-shelf" ones out there that work just fine that will certainly have more man-hours put into the development of it than any one person would writing their own.

CS
 
  • #30
86
0
MATLAB is incredible. It is, in my opinion the definitive computational programming tool. Not as powerful as a raw programming language on the base levels, but far more solution-oriented.

Just my $.02
 
  • #31
131
0
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.

I agree, everybody has their own style when it comes to spreadsheets. Excel does have a "track changes" feature which will keep track of who changed something and when. People rarely use this feature, but it is there. Even in my own spreadsheets, I can't always remember why I did something a couple months ago. So I've gotten into the habit of inserting comments into important cells.
 
  • #32
Jupiter6 said:
[...] What no one has mentioned is the SOLVER in Excel kicks ASS. [...]

Har, har. Just waited for a mention of that one :)

Excel's solver is good, I'll even say "world class", in a certain sense. But there are two crucial problems with it. (Also, make no mistake, CAS tool like Matlab, MathCAD, etc. will contain such solvers without exception. And there are free libraries of such methods too, for use in custom codes.)

Firstly, while it uses an algorithm which is one of the several well-proven for general optimization, all algorithms of that kind (gradient-based) suffer one theoretical boundary. A boundary which, unfortunatelly, frequently gets lost to a practicing engineer. This boundary is the following: gradient-based methods can find only a local optimum of the goal, i.e. such which is optimal to any near-designs (those obtained by slight variations in design parameters), but without any guarantee to global optimality. Think of an x-y function plot where there are two "valleys" (or "humps"); gradient descent (or ascent) will give you one of them, depending on the starting point, without clue to the existance of the other, which may be better. Excel Solver's users see this effect when it gives different results with different initial cell values. Furthermore, if the goal to optimize is non-smooth (think of that x-y plot with a break in it, e.g. x-segment of undefined y-value), gradient descent methods guarantee exactly nothing for the final value they provide.

Secondly, while Excel's solver can be applied to anything that provides a value to a cell, like some complicated external add-on, thusfar I've seen in the wild, it was always used on the custom-made computations made in basic Excel itself; the number of design parameters ("by changing cells...") was usually single-digit at any one case. This all amounts to an unusual observation: in the time Excel's Solver will take to crunch the problem, if it were written in e.g. Fortran instead, one could brute force it, do a complete parameter sweep -- the only optimizing "method" guaranteed to give global best solution. (Back to x-y plot, brute force means: subdivide x-axis into problem-significant division -- e.g. airplane wing span into ~10 cm segments -- compute for each x, pick best. Don't think now "But I can do that in Excel too!" as I'm speaking of, say, 5-parameter combinations, each varied for every other, and a worksheet that will take a second or so to evaluate for one combination.)

In my masters thesis I was faced with exactly the problem described above: multi-parameter, multi-optima goal function, and non-smooth at many segments (and aircraft conceptual design computation, on basis of Raymer, Roskam, etc.) I was to thoroughly test a specialized optimizer, having 5-figures/year (or was it 6 for companies?) licence fee, on this simple, but conceptually significant problem (the real one would have CFD/CSM simulations in the background, for high-fidelity results, but still displaying same general behavior).

And then I wondered: can I actually know what the best solutions were beforehand, so that I have a hard point to benchmark against? The answer, if I used Excel (or, frankly even Matlab or another CAS in this case) would be plain and simple -- no way. However, I estimated that I could write the basic computation (one set of params in, result out) in C for the same or less time it would take me with anything else (after all, there was just one way to handle these packs of formulas); and that afterwards I can brute force the problem in several hours using 8-16 CPUs (of which there were plenty to harness around the university labs). Using a scripting language (Perl at that time, today I'd use Python), it took me a week to patch a script which will read XML setup of the computation -- with freely exchangable subproblems (e.g. different powerplant, drag models), physical units, nested parameter variations, consistency guards -- and use it to build out of the basic C code both the evaluation model for the 5-figure optimizer, and an MPI-parallel brute force sweeper for getting to the benchmark hardline.

In short, in less time than it would take me to wade through columns just to set up a spaghetti-like computation in Excel, I had a safe-guarded, readable, modular, and maintainable computation, and unlimited-CPU brute force sweeper guaranteeing global optima. In the end, it left me with spare time and means to play around with what-if scenarios, like "how about if a/c was hydrogen-fueled?" :) (I should also note that the call of the Dark Side for the user of the 5-figure heavyweight was not small -- it had a "charming" feature to happily accept an Excel spreadsheet as an evaluation model...)

--
Chusslove Illich (Часлав Илић)
 
  • #33
FredGarvin
Science Advisor
5,066
9
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.

I definitely see that you are very well versed in the pluses and minuses of the various methods for computing. I definitely respect your opinions on this and other matters. However, I still don't see anything that supports such a strong assertion as what you said previously.

I see this as a perfect example as you being a smart user and understanding what tools work best for your situation and needs. You have proven that spreadsheets definitely do not suit you for a few good reasons, however you don't really present anything to refute the usefulness of them to the rest of the engineering community.
 
  • #34
FredGarvin said:
[...] you don't really present anything to refute the usefulness of them to the rest of the engineering community.

There are degrees of usefulness. Given that spreadsheets are heavily used by engineering community, how could I, or anyone else, present an argument that refutes their utility in total? Is a slide-rule useless, is a hand-held calculator useless? This was not my intention; more specifically, I never try to convince current hardcore spreadsheet users to stop using them. My intention is a subversive one: steer people, young people, waxing and waning in their choice of tools, away from spreedsheats. E.g. in the case of OP, if after reading mine (and others') arguments he becomes more favorable towards taking a "proper computing course", and later tries to apply the knowledge obtained there to tasks in other, programming-unrelated courses, I will have achieved my goal.

On the other hand, if we base conclusions on widespread of use, one could make a similar "utility" claim for Cobol, the programming language once favored in a certain field. One key point in its design was to make it user-friendly, such that it paralleled how people would do things "intuitively". A lot of Cobol code was written in its heyday, and a huge pile of dark-matter Cobol code is still pushing numbers today. And the field is -- yep, finance. How could one then make too a strong claim of Cobol's ill-effects on programmer's abilities? Yet, http://www.tech-faq.com/cobol.shtml [Broken] (my statement on spreadsheets is a toned-down, inelegant paraphrase of Dijkstra's words); such statements made newcomers think twice before reaching for Cobol, gradually phasing it out of use.

--
Chusslove Illich (Часлав Илић)
 
Last edited by a moderator:
  • #35
131
0
On the other hand, if we base conclusions on widespread of use, one could make a similar "utility" claim for Cobol, the programming language once favored in a certain field.
--
Chusslove Illich (Часлав Илић)

LOL. I took classes in turbo pascal, fortran and C but I don't think I've ever met anyone who used Cobol. I understand your disdain for spreadsheets but I think a lot of that resulted from your graduate work. Excel can be a wonderful thing depending on whos using it and I have seen some wonderful things.
 
  • #36
30
0
My undergrad was in Mechanical Engineering, we where mostly taught FORTRAN and Matlab, as for CFD we used I-DEAS NX10, and solidworks & AutoCAD, and yes spreadsheets where used too :D (only time we used it was an actual sample from a European Satelite system).

Since then I've learnt C++, C#, Java, Python, and a ton of other scripting languages (and Z80 machine language, plugging binary values straight into memory on a simulator)

But no-one seems to be mentioning the Floating Point Errors of Excel, this is something that can not be avioded, during our Systems failure studies one of the case study was regarding a financial organisation that lost literally millions becuse they assumed the results from the spreadsheet where accurate!

Anways I say learn them all, they are just tools, and like I always say

"If your toolbox just consists of a hammer; consider getting a new one"

Anhar
 
  • #37
30
0
Oops I forgot to mention, one of the best use was to see Excel used to create a real 3d engine!, each cell was used as a "pixel" ! :)
 
  • #38
Excel is good for making your results presentable, but for solving computational math problems its not very good.

I most frequently use MATLAB, which is great because it has built-in solvers that can be used with user-defined functions. MATLAB stands for "MATrix LABoratory" and is named that because its operator syntax accomodates the laws of linear algebra. It can numerically integrate user-defined functions and discrete data sets using the most effective methods availiable. It's the best software availiable for numerically solving ODES. It also has excellent plotting capabilities. Its 3-D plotting functionality far exceeds Excel's.


I have a hard time getting it to solve PDE's. It has a toolbox for this but I can't use it yet.
I am also trying to figure out a way to put REFPROP functions into MATLAB however. It has excellent tools for solving non-linear systems, but I need that to solve heat exchanger problems which require thermodynamic property functions that MATLAB seems to lack.

I use C# because I work in a software group that develops windows applications for heat exchanger simulation.

Look into matlab.
 
  • #39
6
0
Hello everyone!
I'm not an engineer at all, I just surfed on in because I'm you can say a Linux advocate and I'm just basically going around telling everyone about it. It's almost unbelievable luck that a thread like this happened to be going on here. Linux is a free open source OS, you can download it and use it, and there are tons of places around the net with resources and information on how to get started and get on with your work and your life.
Now the thing is I don't know what software you all use , I read some of the discussion - there is OpenOffice.org which comes with just about all distributions which has a spreadsheet. Windows software can be run under Linux with Wine, a sort of "emulation layer", and there are numerous solutions to even run Windows under Linux (you must have enough RAM and space, needless to say). So - the OS, a ton of software and help and hand holding are all free - can we ask that once you use it, you give away some of your plane designs as well? :)

I will follow this thread, and answer any questions you have, and try searching on the net for free software equivalents of whatever it is you use - just throw them at me :)

Just to add -wikipedia just told me about gnu octave and freemat as something like Matlab, and there is BRL-CAD for CADing. What does Solidworks do?
 
Last edited:
  • #40
28
0
Hello everyone!
Windows software can be run under Linux with Wine, a sort of "emulation layer", and there are numerous solutions to even run Windows under Linux (you must have enough RAM and space, needless to say).

I am running Ubuntu 7.10 under the OpenGEU platform name and have set up Virtual Box, which allows me to run XP within Linux. I only do this when I absolutely have to, as i despise Winblows. I have 1 GB of ram with a 2.0 GHz processor and both systems run almost natively. Linux is the way to go. Onto the thread topic:


I must agree with caslav.ilic. Spreadsheets are the spawn of hell.

From what I have observed, many engineers have replaced the program form of an engineering tool with formula-based spreadsheets. Not only is this messy if you want to share the tool with others, (Formulas may be erased, its not easy to copy outputs, can't follow thought process. etc...) but you are reliant upon Microsoft and their shoddy programing.

The other problem is speed. Most programs that I create end up taking 10-20 sec of computation time, if not more. I could speed this up by tossing my calculations out to a .dll, but such things get messy quickly. Your better off bypassing the spreadsheet and using a faster language from the start.

Basicly what I am saying is there is no need to be tethered to one company, one operating system or program. Spreadsheets can be useful for basic, quick and dirty calculations, or making pretty graphs for management, but anything beyond that and I believe that something like matlab or maple or mathmatica will better serve your purpose. If your looking for a tool that will do a lot of calculations and fast, then you need to use the right tool. Odds are VBA and excel are not the right one.

As a side note, matlab is capable of interfacing with excel files. Pulling info in or passing it out is a matter of a few commands. on the downside, it is not nearly as fast as c++.
 
  • #41
FredGarvin
Science Advisor
5,066
9
If you're working on something in a spreadsheet that requires 10-20 sec of CPU time then you are missing the point of this argument completely.
 
  • #42
(One) point of my arguments was that any computation -- something which has input parameters, number of formulas to process them, and output results -- should be trivially usable at a later point as a part of something that will take 10-20 sec, to hours and days, to compute. And if the computation could, in principle, operate on variable number of input parameters, and do two or more iterations somewhere inside (which I've seen people implement as several worksheets, each named "iteration-x"), that's from the onset a total loss with spreadsheets.

Stating that one should "think ahead" and "choose the right tool for the right job" overly simplistically assumes that this is a one-way process, neglecting the feedback that the tools have on breadth and scope of our ideas. Engineers are especially susceptible to this feedback, as they tend to think problems over constructively, in specific procedures that could lead to the solution. That's why they, of all people, should avoid constraining tools.

--
Chusslove Illich (Часлав Илић)
 
  • #43
28
0
If you're working on something in a spreadsheet that requires 10-20 sec of CPU time then you are missing the point of this argument completely.

Not at all. I have seen Solver processes easily go for that long on newer computers.
 
  • #44
Mech_Engineer
Science Advisor
Gold Member
2,572
172
Not at all. I have seen Solver processes easily go for that long on newer computers.

I think Fred's point is that 10-20 seconds of computing time is nothing, and you can use any program to solve it. The argument for faster and more efficient solvers comes into play when your computer is running for hours or days. A 50% difference in solve time for a problem that runs for 40 hours is a big deal, where as with a 10 second algorithm you won't even notice the difference.
 
  • #45
nvn
Science Advisor
Homework Helper
2,128
32
Matlab is currently US$1900 per license, whereas the same thing, Octave, is free. Secondly, http://curveexpert.webhop.biz/ [Broken] is excellent.
 
Last edited by a moderator:
  • #46
stewartcs
Science Advisor
2,177
3
Matlab is currently US$1900 per license, whereas the same thing, Octave, is free. Secondly, http://curveexpert.webhop.biz/ [Broken] is excellent.

MathCAD is only around $1,000.00 last time I checked anyway.

CS
 
Last edited by a moderator:
  • #47
FredGarvin
Science Advisor
5,066
9
I think Fred's point is that 10-20 seconds of computing time is nothing, and you can use any program to solve it. The argument for faster and more efficient solvers comes into play when your computer is running for hours or days. A 50% difference in solve time for a problem that runs for 40 hours is a big deal, where as with a 10 second algorithm you won't even notice the difference.
That's pretty much what I was attempting to get at. For something that takes such a short period of time, where is the time benefit of coding something yourself? Perhaps I am stubborn, but with all of the things mentioned here, only the comment about floating point errors has been mentioned to show that spreadsheets are not a legitimate engineering tool.
 
  • #48
Mech_Engineer
Science Advisor
Gold Member
2,572
172
Perhaps I am stubborn, but with all of the things mentioned here, only the comment about floating point errors has been mentioned to show that spreadsheets are not a legitimate engineering tool.

Spreadsheets aren't unit-aware either, that's a big minus in my book. And they don't have symbolic/exact manipulation capabilities; everything must be solved in dicrete pieces no matter how infantesimally small.
 
  • #49
FredGarvin
Science Advisor
5,066
9
ANSYS isn't unit aware either.

Symbolic manipulation is a shortfall, but that is outside the original scope of their development. It sure would be nice if they had it, especially since it is not an unheard of thing in a piece of software.
 
  • #50
Mech_Engineer
Science Advisor
Gold Member
2,572
172
ANSYS isn't unit aware either.

ANSYS Workbench is :approve:

I'm not sure I consider ANSYS a calculation tool as much as a simulation tool. The line between the two is a bit of a gray area, but ANSYS is very good at what it is designed to do- generate and solve huge linear algebra problems using geometry and boundary condition inputs from the user. In a way, it's a very specialized engineering math tool; I shudder at the thought of trying to find the inverse of a 300,000 x 300,000 matrix using MathCAD...
 

Related Threads on Computing in Mechanical Engineering?

Replies
4
Views
10K
  • Last Post
Replies
2
Views
4K
  • Last Post
Replies
3
Views
664
  • Last Post
Replies
6
Views
5K
  • Last Post
Replies
5
Views
3K
  • Last Post
Replies
13
Views
6K
Replies
1
Views
935
Replies
5
Views
1K
Replies
3
Views
6K
Replies
2
Views
1K
Top