Can we really integrate simulation in the design process?

Today’s blog post will be a bit special.

One of my readers sent me his ideas about the integration of simulation into the design process… a lot of idea!

This got me thinking that he probably isn’t the only one in this situation, and that it would be beneficial to share his thoughts on the blog so that everyone can read, think and comment about it.

(No need to say that I got his approval to share all this, of course)

To give you some taste, it talks about:

• Why CAD Designers can’t do FEA simulation
• Why FEA is often not taken seriously in some companies
• The real world obstacles to building a team of real FEA simulation professionals
• etc…

Here it is:

---

As a team leader for a team of dedicated R&D and simulation engineers, I can say that integrating FEA into the Design process early does have a lot of importance to me.  The message about incorporating simulation into the design process is a very strong one and one that I have really been trying hard to “champion” in my organization.  In my experience, when simulation is  used early in the design process, I have found that it has the greatest positive impact on engineering designs and provides the best “return on investment.”  However, there is one point that perhaps I slightly disagree on or that I’m not understanding, and that mainly is on who is performing the simulation work at this early design stage.

In a perfect world, the design engineer would also have the capabilities to run simulations and that would allow for very fast work flow and very good engineering. 

This seems to be what you are trying to encourage.  However, time and again this has been a major problem in our organization  for a number of reasons.  University education seems to be evolving in the US.  This largely depends on which universities we recruit engineers from, but an unfortunate reality that we are facing is that a lot of engineering education in the US appears to be “dumbed down”.  This is also certainly related to the way an individual treats their engineering education and the level of Design Engineers that an organization hires (are they passionate and focused on retaining engineering knowledge or are they just trying to get a degree land a high-paying job). 

In my current organization, unfortunately, a lot of Design Engineers behave as glorified CAD modelers.  There is more emphasis on drawing things in 3D modeling software and less emphasis on thinking about the fundamental engineering concepts behind these drawings.  Frequently, we see that Design Engineers are lacking certain background fundamentals needed to set up a proper, meaningful simulation

We have had part failures and field issues that were directly related to design engineers thinking that they “know what they’re doing” with simulation and making bad decisions.  I’ve had to retroactively look into these failures and it results in a headache for me as I slowly uncover all the bad boundary conditions and modeling practices that caused the miscalculations.  Worst of all it results in hindsight FEA which is good sometimes to validate modeling practices but doesn’t ultimately fix a problem.

So the first problem I guess which sounds terrible but it is my honest finding is: engineering incompetence

With the first problem, the question is:

Can we teach Design Engineers to use this tool more responsibly? 

Based on my experience in the context of my organization, the answer is unfortunately no for the following reasons:

(1)    Design engineers don’t have time (they are swamped with constant requests and design projects).  They are constantly being asked to do engineering drawings and sales drawings (and frequently making changes to these drawings), create 3D models, part setups, etc…

(2)    Related to (1), Design Engineers don’t want to take the time to learn.  They don’t see forming a good fundamental basis and foundation (stresses, strain, stiffness, boundary conditions, etc…) as “useful” “practical” engineering and they don’t understand why these things are important for simulation (it’s just a software tool with buttons for them). 

This is not totally their fault as they are constantly under pressure from Product Managers/Sales to produce engineering drawings and set up Bills of Materials along with many other things that distract them. 

The Design Engineers are mainly “production” level engineers that routinely recycle very old/conservative designs and make slight adjustments/modifications to meet a customer’s needs.  They place more emphasis on things related to the manufacturing process and supply chain, and thus don’t have time to consider the fundamental stress/strain and load bearing aspects of their design. 

Because of this situation, they don’t see the core fundamentals of engineering theory and simulation as important or useful to them.  They don’t have the time to “think” and make the connections to how it relates to what they’re doing, therefore they just see it as “theory:” some milestone they had to get through in college to get their paper degree. 

In the event we get a good Design Engineer, even if we take the time to train that Design Engineer properly in FEA, they often don’t have the time to do a model properly and look into things like mesh convergence, cell aspect ratios, boundary condition behaviors and sensitivity, energy norm errors, etc…  All these things as you know affect the engineering conclusion and subsequent design decisions one makes about a simulation.  Sometimes they start off using the simulation well but as time progresses and they get more “rushed” by other things.  The knowledge and practice seems to deteriorate over time.

(3)    Simulation software companies who want to sell 200 licenses for use by Design Engineers hold their own software specific trainings that show engineers how to click fancy buttons in their programs and make nice colored pictures, but they don’t teach engineers the fundamentals and real purpose of FEA. 

This is a problem because Design Engineers come out of these courses with a fake certificate thinking that they have FEA capabilities, then they go and produce absolute nonsense, show pictures of it and spread misleading ideas.  Sooner or later things break, we run into field issues and I have to do retroactive FEA to convince people that simulation is not garbage in its entirety

We have the same issue with CFD calculations.  We actually have some arrogant engineering managers in our company who think that a universal “template” should be set up for FEA and CFD simulations so that his engineers can simply click the “run” button, get an answer, and make a decision.  He claims that he got this information from a simulation software training session.

(4)    We have a lot of Design Engineers in our organization.  To purchase an FEA software license for each Design Engineer (or adequate floating licenses to support all of them), then send them to meaningless software training so they learn to click buttons gets very expensive.  Software companies love this because they make a lot of money from us.

So based on the above and some other issues, I have tried to set up a team of dedicated “Development and Simulation” engineers who really focus on the core engineering of a design.  These are the people who took their engineering education seriously, are interested in and take the time to learn proper FEA/engineering theory and strive to unite theory with practice.  These engineers are set up to offer support for Design engineers with good quality FEA/CFD calculations, R&D related tasks, and laboratory testing if necessary.  We try to encourage good collaboration between Design and Development Engineers and we’ve tried to make the system as “seamless” as possible.  However, this does not come without its own problems and shortcomings.  I have found that when done properly, this works better in terms of the quality of the simulations and the subsequent quality of engineering designs.  However, I admit it’s not “full proof.”  Some issues I’ve had with this approach are:

(1)    Under high volumes of work load, the Development engineers can’t support the Design Engineers fast enough (perhaps more Development engineers are required). 

(2)    It is the Design Engineer’s/Product Manager’s choice as to whether or not they want to involve a Development Engineer.  We’ve seen some Design Engineers and Product Managers develop a sort of “proud” and “egotistical” attitude.  Therefore, they don’t want to listen to Development engineers or anyone for that matter.  They want to constantly argue and tell others what to do, or they just want to do things themselves and don’t want to work with a team.  Therefore they sometimes choose not to involve Development engineers in projects/decisions where they should be involved.  These people frequently make their own decisions based on their knowledge of everything  and not on real sound engineering…   These same individuals are some of the ones who are impossible to train in FEA as talked about above.  They don’t want to listen, they don’t want to learn, and they don’t want to revisit fundamentals as it is beneath them.  They just want the FEA software because they already “know everything.”  However, when given the software, the results seem suggest otherwise…

(3)    Development engineers are really intended to support Design Engineers.  However, Product Managers and Sales Specialists want to use Development Engineers for their own purposes. 

The problem with FEA is that it produces pictures with a lot of nice colors.  When Product Managers/Sales see a picture with nice colors, it excites them.  They want ownership of the picture and they want to sell it to the customer. 

They see at as an opportunity to make their numbers go up.  They want to go to the customers, show them the pictures, and get praise because they can “wow” the customer with some fancy pictures and convince the customer that they know what they’re talking about (even if they don’t)… 

This raises other, deeper questions about the role of Sales and proliferation of Product Management in organizations, but I won’t get into that, that’s not the goal of this discussion. 

The point is: as much as I want simulation to be used in my organization for the right reasons, it is frequently seen as a “sales” tool.  This reliance on FEA (and CFD especially) as a way for Product Management/Sales to get customer praise or create the illusion of competency is unfortunately deeply engrained in the culture of many organizations.  So we do our best to focus hard on the “right” applications of FEA, but mixed in we inevitably have to take the good with the bad and do some “sales” FEA/CFD to make pretty pictures.

(4)    Development engineers aren’t perfect.  We make mistakes too.  We spend time trying to make things “perfect” or “useful” for engineering.  However, there are times we make errors for various reasons (we thought we understood something we didn’t, we didn’t do proper validation, we couldn’t get the information we needed to do an accurate calculation, etc…).  However, we have the time to look into these errors carefully and make a serious effort towards fixing these errors.  Our goal is to reduce expensive build-and-test iterations with simulation, but not eliminate testing completely. 

Simulation should never replace validation testing.  However, as companies move more and more towards cutting costs, they try to find ways to make simulations replace testing.  Not only is this a liability, but it results in poorly developed engineers and bad simulation practice even by the ones who focus on it. 

Development engineers can become “detached” from reality if they focus too much on simulation and don’t also bring in knowledge of reality and testing.  However, this knowledge requires investing in testing and lab equipment, and actually taking the time to do productive validation testing.  This is seen as a major cost unfortunately so we are not able to do as much validation testing as we would like, especially for things like material properties and high-cycle fatigue data validation.

Here are the things that come to mind and the questions that are raised. 

I would like to get your input on this and maybe suggestions/experience. 

• Do you think I’m handling simulation correctly in my organization?  
• Do you agree/disagree with certain aspects or suggest different ways of going about this? 

I value your input and if there is any good advice you can offer I would like to learn from you on this.

---

My Simple Answer … for now

I think I could probably write 3 times the same amount as an answer to finally say one simple thing:

I agree 100% with all of this… the world is not simple and many companies are using simulation as a sales method to get colorful results in front of excited customers instead of seeing it as the real scientific tool that it is.

What I experienced as well is that more the company using simulation has a business critical to human lives, more simulation is taken seriously… And use Open-Source Codes (But that’s another story…)

But until when? As education is decaying a lot in this area and software company only teach the click on this button mindset…

There is also a very important thing that I should often more often on this blog:

Scientific Proficiency, Engineering and Meaningful Learning are all based on Humility.

Never be too proud of your achievements of “what you know”. Always question your assumptions, accept and internalize external feedback and learn from your mistakes.

Those who fall into the trap of the “I know it because I am an engineer” are lost. In fact, you should never say that phrase. Because there is always a risk that you don’t know what you think you know.

This is all for my answer as I said I would keep it short…

Now it’s your time to share your own experience!

So if you just need to vent because the same kind of s*** is happening in your company…Or if you have been in this situation and you found some solutions…

Write your answer in the comments and let the world know.

Cyprien “All the truth about FEA” Rusu