Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Value of learning FEM theory vs mastering engineering 3

Status
Not open for further replies.

ninjaneer777

Mechanical
Jun 22, 2010
25
0
0
Given that each engineer only has a finite amount of time, how would you rate the value of learning the FEM theory vs mastering engineering principles?

I could see the answer varying depending on what your job is, Designer, Analyst, Researcher, but I think it would be interesting to get a variety of perspectives on this.

Essentially, what is going to give you the most return on your time?

I read a lot of threads about people really getting into the intricacies of FEM theory and I wonder how much of an impact that will actually have on results. Don't get me wrong, I enjoy learning everything I can about FEM theory but I often find myself realizing that my engineering mechanics studies prove 100 times more practical.
 
Replies continue below

Recommended for you

Not an easy question to answer, that is for sure.

It will depend on the industry. For example, FEM seems to be more useful in space applications where there are fewer classical solutions. FEM is less useful on commercial aircraft programs where classical solutions have been developed and refined over the decades.

Without a doubt though, FEM is overused. It is easy to spend a long time on a FEM that could have been solved via classical solution (if you better understood the problem). I speak from personal experience. That will be wasted effort and the net result is reduced skill level in the long run.

Aside from overuse, there is abuse. The curb appeal of FEM for young engineers is strong and companies like to advertise it because of the pretty pictures and appearance of being state of the art. Managers without understanding seem to get excited over FEM. In turn, young engineers see this as an easy to develop an advanced skill. A lot easier and more fun than digging into those books right? Again, speaking from personal experience.

Anyway, only the individual can determine how much time should be spent with FEM. If one is asking the question, they are probably in good shape, since they realize the limitations. A bad scenario would be if you keep building models, then more and more advanced models (nonlinear, etc.), but you are not writing equations and cracking the books open (or company manuals, etc.)



Brian
 
ESPcomposites,

I'm sorry I should have been clearer in my opening post. My question was towards people who routinely use FEA and wish to improve themselves through studying/learning more.

If you do use FEA routinely and want to improve yourself as an analyst which is more practical to spend time studying, the theory behind FEM or engineering principles?

Your point is interesting though and is the topic of the next thread I was going to post, hand calcs vs FEA.
 
I would say improving yourself would be becoming comfortable with hand calculations, and how they correlate with your FEA. I believe the best FE analysts are those who grasp how truly "approximate" FEA can be, and who understand the limitations of the assumptions used.

i.e. the best way to be a valued FE analyst is to do less of it!

Also, learning about buckling (all types) and design code equations for stability, in my opinion, separates the FE black box operators from the true engineers.

tg
 
Ninjaneer777,

I reread your question and better understand now (I think). I spent a good amount of time familiarizing myself with FEM theory and the numerical methods to solve them. I think sometimes it comes in handy, but not nearly as much value as using the principles (not sure if you mean general engineering principles or specific FEM principles).

The basic theory is probably good to understand (perhaps a requirement), but I don't think one needs to get carried away if they are a practicing engineer.

I have a few advanced theory books on FEM. I cracked them open a few times, but never found them practical. Some of the researchers and professors I know get more use out of them though.

One caveat is that sometimes by better understanding the theory, you force yourself to better understand the mechanics. Though, vice-versa works to some degree as well.

Brian
 
IMHO the preferred answer to your question is "c) both". you can't make a reliable model unless you understand both how structures work ("real engeineering") and how to model them "FEM theory" (including how the particular code (eg NASTRAN) works, how different elements work in different situations, when you can get away with fully rigid constraints, etc).
 
I took quite a bit of theory courses, and as we had no commercial solver at uni, many grad students had projects to add bits of code to an in-house solver. I spent some time doing the same, quickly realizing that while the theory and equations could be quite elegant, reduction to practice (writing bug-free, input- and error-trapped code) was the big time consuming part. Agree with Rb, answer is c. You need some background in FEA just to know when to trust/distrust the black box; you need some background in real world structures to do the same, and to know when you need to crack open the FEA manual.

FWIW, knowing FE theory helped me solve some problems for companies over the years, in that I could write some fairly simple statments in a spreadsheet or Mathcad solver, and generate fairly complex results that wouldn't have been possible for the big commercial codes (at least at the time). Other times, I could go to the lab, and hang calibrated weights off various bits of structure and measure deflections that wouldn't agree with the PhD'd analyst's FE model predictions...and then we would argue...and then we'd figure out why the differences existed. Most often, there were simplifying assumptions in the FE model, as Greg notes, typically in the boundary conditions and/or mechanics assumed vs. the real world structures.
 
clearly the answer to your query involves guaging the financial return on the amount invested.

In that case don't worry about it, get your business degree and avoid engineering all together.

on the otherhand if engineering is in your heart and soul, then learn as much as you can, not all at once because the computational field is too vast, but focus on the current needs of your employ or prospective employ.

FEA is here to stay and some problems simply are beyond intuitive solution, ultimately if you are dealing with real world solutions you need to have access to serious computing resources and management that is capable of comprehending the work and its direction and committed to the long term.



 
"It'd be interesting to estimate how many hours are wasted due to mechanisms, boundary conditions, chasing little patches of red, rigid links and dubious load applications, compared with these more theoretical issues."

Probably the same amount of time spent figuring out where you got your negative sign wrong, miss-wrote a number, what you over idealized, looking up stress concentration factors, organizing your equations, figuring out where you substituted an equation incorrectly, which Excel cell you incorrectly used, figuring out what part of your many pages of calculations went wrong, etc.

I don't understand where all this hatred of FEA comes from. It's a tool just like hand calcs. You think hand calcs use less assumptions or result in less erroneous conlusions? It depends on who is using them.

Of course there is a ton of terrible FEA work being done, but you really think the same engineer who is fine with using a tool he doesn't understand would have ended up with a better result if he had just worked it out classically?? Probably not.

It seems most examples of why FEA is bad are about engineers having little idea about what they are doing and who don't understand the limitations of the tool they are using compared to someone else who is extremely competent at traditional methods. That is not a very fair comparison. Either compare engineers who are both bad at what they do or engineers who are both good at what they do.

Don't get me wrong, I am not for overhyping the value of FEA, but I am also not for neglecting a tool that has valuable uses.
 
GregLocock,

I just wanted to add that my previous post was not just about your specific comment and more about that comment reminding me of a sentiment that I see a lot on eng-tips posts. I very much appreciate the posts that put up and you taking the time to participate in the thread I started. :)
 
From my observations, some engineers dislike FEM for the following reasons:

- Too easy for "anyone" to generate a fringe plot. Therefore, people not qualified are playing the role they should not be.
- Easy for engineers to use it as a crutch, instead of learning how to be real engineers.
- Abuse and misuse somewhat ruins it for those who really do understand it.

The obvious advantages are there, provided the above pitfalls are avoided. The challenge is to remove the "bad" parts while retaining the "good". So while personally, I like to get the benefit of the good portions, I also try to discourage the bad usage. This may be what you are seeing by others as well.

Brian
 
ESPcomposites,

Thanks for your answer. I absolutely agree with what you listed as some of the downsides to FEA.

What I maintain is that people who use it as a crutch or have overconfidence in their results are probably bad engineers, FEA or no FEA.

I see a lot of throwing the baby out with the bathwater, in regards to the downsides to FEA, with some of the posts on eng-tips. Everything in engineering has it's trade offs and downsides, which means that you have to educate yourself and use your brain and read a lot of posts on eng-tips.

It probably just depends on what you have personally experienced at work. I could see that if you have experienced years of engineers/management abusing FEA you could eventually develop a personal frustration with the downsides. I probably just haven't been around long enough.
 
I see your point about good versus bad engineers.

Another difficulty is that it is hard to check a FEM, just by looking at it. Compared to classical solutions, this presents a challenge. Also, people who normally would shy away from classical stress analysis may entertain the idea of doing "FEM", which is backwards logic.

Another frustrating area is that management seems like FEM a lot, regardless of the user. It is even standard for first year engineers to learn Patran/Nastran, which I have a distaste for. This is partially based on my misguided usage early on in my career.

All that being said, I am pretty good with FEM and use it regularly. I have even developed some software that is FEM based.


As far as eng-tips goes, I think time and again people are asking basic mechanics questions that they think are FEM questions. This demonstrates lack of basic knowledge and the pitfalls have not been avoided. If, on the other hand, better questions were being asked, perhaps there might be a different viewpoint?


Brian
 
Again, good points. Those scenarios are indeed frustrating.

You make the same argument against eng-tips though. Lot's of people us it as a crutch instead of trying something out for themselves first. Or they see someone state something and take that as the answer without fully understanding/checking it, just like bad engineers do with FEA (and sometimes me). I wouldn't bag on eng-tips for that though because there are plenty of amazingly good uses for eng-tips. It is a great way to pick up on a broad array of experiences. That is my favorite thing about the site.
 
a major problem with FE is that it gives you an answer, no matter how you state your problem ... i spend a lot of time "adjusting" models to get the behaviour i expect to see. we've all seen nonsensical results being put forward as the answer, because someone hasn't looked at the results and asked "would this happen ?". I'm still trying to get the Helpdesk to tell me why the combined stresses on a simple angle section aren't "right".

another problem with FE is that it won't give you an answer no matter how you state the problem ... 'cause there's some little percularity with this particular code/element.

of course, the same can be said about hand calcs, but i like the manual stimulation ...
 
"a major problem with FE is that it gives you an answer, no matter how you state your problem

another problem with FE is that it won't give you an answer no matter how you state the problem"


haha. Very True.
 
In engineering, as elsewhere, the ability to think things through is what distinguishes the superstars. And for better or worse the toolset will, from here on out, consist mostly of commercial FEA software.

One problem I see in discussions of the value of FEA is that the term "FEA" means such wildly different things to different generations. If you're talking about using a commercial package like Ansys to analyse stresses on your 3D CAD model of a complicated investment casting and wondering if hand calcs might serve you better, I'd personally say you're nuts for asking the question. Have you ever tried doing the equivalent with nothing but a copy of Roark's and a scientific calculator? I have once, and I'm not ashamed to say that I gave up after two wasted hours of flipping from table to table to lookup all the coefficients, all the while struggling to remember what in the hell I had set out to calculate in the first place. There are obviously exceptions to this, e.g. pressure vessel design á la ASME Sec VIII Div 1, or design-to-code in any sphere.

Multiphysics FEA is not being exploited to the extent it should be. Much work still needs to be done to make code-coupling accessible to normal users of commercial codes like ANSYS Workbench. But this is the domain of specialists -- mostly software developers writing a lot of glue code -- and not even they seem to touch the underlying solver code anymore, except to parallelize it to run on GPUs. All the necessary element formulations are there, and have been for some time. FE theory, as distinguished from the use of commercial simulation software, is fast becoming an arcane curiosity akin to basic computer theory and CPU architecture.
 
Status
Not open for further replies.
Back
Top