Analyzing Design

Notes from the NAFEMS North American Summit

The NAFEMS North American Summit meeting was held in Hampton, VA a week or so ago (10/29-31 to be exact).  Unfortunately, based on informal polling at many user groups and customer events, I'm sure that many of you are asking, "Who is NAFEMS and why do they need a summit?"  NAFEMS (www.nafems.org) is a non-profit organization focused on FEA quality and education.  They provide an unbiased and unaligned resource for users at all levels and of all tools to learn and network on simulation related topics. 

Uptake in North America has been slower than we'd like.  I have a couple theories on that but won't delve into them right now.  Suffice it to say that there is no other organization like NAFEMS in the world for those of us who believe simulation is a critical part of the design process.  If there is a short-coming, it is that being volunteer/member driven, the content and activity tends to reflect the interests of the volunteer members. Currently, these tend to be more involved specialists. Consequently, the activities are geared more (not exclusively) but more for specialists, thus drawing in more specialists and creating a cycle that has been hard to break.  I've been in communications with the NAFEMS leadership on how to change this and would be open to suggestions from the design analysis community.

OK... here is a quick summary of my key take-aways from the conference, which was focused on the future of the technology...  Where will simulation be in 2020?

1. Increased ‘realism’ will provide the biggest payoff in the next several years.  This means both assy vs. part and multi-physics and nonlinear as the default.  More realism = less interpretation required. 
2. As has been said for the last 20 years, the technology has to be scaled for the needs of the design engineer.  Vendors differed on how to get there.  SolidWorks' position (& Simulia’s) calling for a paradigm change stood out from the rest who seemed to say “same thing but easier and faster.” (I think we are on the right track here.)
3. Optimization (presented in several flavors) will be a bigger component of simulation in the next 10 years.  (I still have my doubts as to whether design-level users will embrace structured optimization.  Interested in feedback on this!!!)
4. Computing speed will increase and vendors need to capitalize on it.  The market will demand it.  (The projections for increased power at reduced costs are staggering!)
5. Executive buy-in of simulation as a strategic tool will be required to move it to the next level.  (I’ve been saying this for years.  Education targeted at managers would pay off if the experts at this conference are to be believed.)

More detailed comments to follow...

Wisconsin/Illinois COSMOS User Group

Attended the Fall meeting of the Wisconsin/Illinois COSMOS UG today... Great turnout and discussions!  Two points warrant sharing...

First, after an excellent, albeit uber technical, presentation on nonlinear from one of the local VAR AEs, the discussion turned to keeping analysis skills sharp when these tools are only used part-time and often on a specific project when the next project might be months off.  My response tied in some things I observed at last week's NAFEMS North American Summit meeting in Hampton, VA. (More on this in a later post.)  I was happy to see that most of the major simulation tool suppliers embraced the need for a change in the way software is developed for design engineers and part-timers.  SolidWorks (Me) and Simulia were notable in saying that the paradigm must change. Easier to use but same, the way it has been going for 20 years, isn't enough.  Additionally, it was generally acknowledged in side conversations that as we re-tool simulation software to be what designers want, (not what we want them to have to learn), we assume a responsibility for educating them to engineer with simulation, not just use it.  This consensus was especially important to me since, as a keynote speaker at the NAFEMS World Congress in Lake Como, Italy 8 years ago, I received some flack from these same companies for suggesting the same thing.  (It just takes some people longer to come around I guess!) 

Coming back to the question about keeping skills sharp, it is my belief that we, the software industry, must work harder to design tools that don't require a steep learning curve in application, not just in the UI.  Additionally, we must supplement that with education that fits into your schedule and works as you do.  That doesn't mean that all users aren't responsible for understanding the application to their products.  They do.  We'll just take some of the "art" out of the technology.

The other topic that warrants discussion centered around a presentation by a user on Simulation results that didn't appear to correlate with test.  The problem was complex enough that I won't get into details.  The important thing was that he shared this in detail with the group and the group responded with excellent feedback on possible causes.  This user, actually a manager, went home with a list of things to check. Some were in the simulation set up and some were in the test setup.  I can't stress enough how valuable these sorts of discussions are at user groups.  Anyone can look at a recorded presentation at any time. This sort of interaction is unique to these gatherings.  If you have access to a Simulation User Group, I highly encourage you to get involved. 

Quick take-away tip from this discussion, whether you "think" your simulation results correlate to test or expectations or not, you will always benefit from listing out (in writing!) all the causes or assumptions that might result in deviation between calculation and expectations.  You should try to sort these by sensitivity and bracket variability.  Frankly, you should do this in testing too!  You'd be surprised at how much more meaningful the whole process can be.

-- Vince

Who's the boss?

After reviewing the role of management in the design analysis process, I was asked, “You mentioned that a company's management team is often the "block" for the successful implementation of COSMOSWorks. In what way? Do they not want to pay for the extra training? Do they not believe the technology's efficacy? Do they distrust their employees to use it properly?”

Management resistance is one of the most commonly cited reasons design engineers feel analysis doesn't reach its potential at many companies. There are a number of factors & they can be lumped into ‘active’ and ‘passive’ resistance.

Active resistance comes in the form of restricting use, mandating that it is only for certain personnel, visible lack of faith or direct criticism, or making unrealistic demands on the software knowing that it will fail.  Sometimes active resistance comes from refusal to pay or allow time for training, forcing under-spec'd hardware for the task, or allowing a design team to use the right product level (COSMOSWorks Professional, COSMOSWorks Advanced Professional, or COSMOSFloWorks) so that useful data is hard or impossible to come by.

Passive resistance usually comes in the forms mentioned as "sometimes" in the previous paragraph. The difference is when the manager isn't aware that these restrictions are preventing the success of the technology. A common example is the manager who approved SolidWorks Office Premium with Linear Static COSMOSWorks capabilities but is withholding an upgrade to Advanced Professional pending some demonstrated progress. However, if the primary design responses involve nonlinear materials, fatigue, buckling or vibration, the company may NEVER see success at the Premium level.

Management resistance usually stems from ignorance of the technology, thus causing improper expectations, or a prior bad experience. I met with a client years ago who told me that FEA doesn't work for his problems so he'd shelved their plans for purchasing. It turns out that he'd hired a seemingly reputable consultant who botched their analysis. I showed him where the error in the analysis was and corrected it, thus giving him good test correlation. He acknowledged the difference but still had a sour taste in his mouth. If a so-called expert couldn't get it right the first time, what chance did his part-timers have?

The fact of the matter is that a botched metal to plastic design conversion project wouldn't prevent them from trying plastic again. A less than successful attempt at automation in the plant wouldn’t condemn their product to manual assembly forever. There are plenty of industry examples showing the merit of plastic in applications previously dominated by metals and the value of production automation is self-evident…today. What managers who have been burned by FEA need to understand is that there are plenty of examples at all levels of all industries showing the value of design analysis and acknowledge they need to “get back on the bike”. I regularly tell companies that if the technology isn’t providing the benefit expected, it is usually the implementation, not the software.

Those managers who don't understand and set improper expectations need to be educated. However, they first need to know they need to be educated which is a big part of the battle. I guess education is the key to both aspects of management resistance.

If we provide this sort of education for your management, will they come?

-- Vince

It's Your Choice...

On a recent COSMOS Companion Real-World Analysis webcast, I showed a COSMOSWorks user how to speed up a several hour static solution to 26 seconds (!) with some intuitive simplification techniques. The results were the same or even better since automatic adaptive convergence on mesh size was possible due to the more efficient model. Most of the "clean ups" were completed in a few minutes and stored in a separate Configuration. There were some other model adjustments I made that took a while longer (1-2 hours) but that was due in part to my less than stellar SolidWorks modeling skills and in part due to exploration of alternate conceptual ways to handle the transition from one feature to another.  One point I emphasized in this exercise is that all users have a choice. You are well within your rights to demand that COSMOSWorks mesh whatever you throw at it but in many cases, that will entail some frustrating battles with the mesher and local mesh control. I've seen customers fight for hours to get a feature meshed that didn't add any value to the result or enable to them make better design decisions. Suppressing it and moving forward would have taken seconds. While you do have this right, you need to acknowledge that meshing technology is not yet fool-proof and thoughtful simplifications on features that speed up a solution so you can proceed with your engineering work are often a better choice than forcing your software to deal with the completely featured and filleted geometry that adds no value.

I've been traveling to customers quite a bit lately and feel like I've been repeating this pretty regularly.  I certainly don't (and never will) advocate reducing the integrity of your model to satisfy the limitations of your mesher. However, simplifications that empower you to get as-good or better answers in less time such that you can get your project completed more quickly just make sense.

An even better approach... don't add features that won't impact your assessment of design integrity until the base concept has been validated.  It is faster & easier to get the concept right and add detail later than it is to suppress a ton of secondary detail only to learn that the hours you spent filleting were wasted because the design wasn't going to handle the load in the first place.

-- Vince (PS... sorry for the absence...)

"We've made 'contact'...

In preparing a text for NAFEMS (www.nafems.org) on analysis for design engineers, I made the decision to include a discussion of contact conditions (natural part-part interactions) in a chapter on boundary conditions.  Since contact requires a nonlinear solution, it is typically reserved for discussions on nonlinearities. Here are some excerpts to justify my decision…

“Historically, some of the most creative load and restraint schemes were developed to avoid having to utilize nonlinear contact conditions, or actual part-part interactions, in a finite element model.”  “The tools of today allow designers to simply indicate that that inter-part contact is to be included in the model and the software defines the appropriate parameters and mesh automatically.”

“With these advancements, choosing part-to-part contact has become a viable alternative to questionable applications of loads and restraints. In fact, for most users of FEA in product design, a case could be made to say that contact conditions should be the first thought for interactions near areas or bodies of interest and should be replaced with loads or restraints only when the substitution is obvious or unavoidable, as in the case of fluid pressure in a tank.”

Some of my earliest (& most painful) FEA memories were of manually toggling nodal restraints or springs-to-ground to get a more natural response in an area where part-part interactions invalidated a simple restraint definition since employing nodal gap element contact would have driven solution times beyond tolerable, even on my SGI workstation.  Today, in my work with design engineers, I see people choosing questionable restraints over contact regularly and can’t help but feel there is some tribal, sub-conscious suppressed memory that influences this decision… misty remembrances from engineers long ago… whispering “avoid contact…avoid contact…”  OK… design analysis has only really been around for about 20 years so the ancients probably aren’t influencing today’s users.  A more likely cause is that we’re teaching the technology using out-of-date preconceptions.  If we (& I don’t just mean SolidWorks… you know who you are!) lead off our education with “restrain this” and “load that” with a discussion of contact following much later, it is inevitable that our users avoid contact unless deemed absolutely necessary.

Let this be my Manifesto, nailed to the doors of design groups around the world…  more often than not, you don’t know how a face or body will react once the system reaches equilibrium.  However, the application of a restraint implies that you do.  Consider the more natural response at faces of interest that contact, either no penetration or bonded, provides as a primary modeling method and resort to restraints, as stated above, “…when the substitution is obvious or unavoidable.” Don’t be afraid to model a few more parts into the system and explore the results. If you are inclined to be critical and diligent in your evaluation of your results at your interactions, (which I hope you are!), I think you’ll find the added solution time is far less a hindrance than the time it takes to evaluate a restraint, try a few different alternatives and assess the best route, in most cases.  As computers and solvers get faster each year, this must become the norm, rather than the exception to stay competitive. You might as well realign your thinking today!

-- Vince

Putting the Fun Back(?) in FEA

In a recent Business Week article, Greg Blonder, a technologist and partner at Morgenthaler Ventures, describes a paradox in science education that may be responsible for the declining ranks of scientists & engineers in this country.  He points out that most children are born inquisitive and want to solve problems, invent new things and new worlds, and generally tinker.  I saw a clear indication of this at Camp Invention where my son attended this past summer.  Greg points out that our current educational program actually demotivates the enthusiastic future engineer by forcing terminology, theory, and rote memorization on them at a young age. This isn't fun... which, like it or not, is still the #1 motivator for kids thru most of high school, (& some...retirement.)  When it ceases to be fun, it ceases to be important. Yes, most students will slug thru it to get the grades they feel compelled to get but not because they are excited by it.  Blonder states:

"Change starts with the recognition that, while all of us need to be scientifically literate both for our own welfare and the nation's technological progress, we can't all be scientists. That requires teaching scientific literacy generally, while reserving the tools of the trade for those pursuing scientific careers — the exact opposite of the approach academics now take."

I see this with my kids and actually with my wife, who is going back to school to get her teaching degree for grades K-2 after more than 15 years as a pre-school day care teacher, owner & entrepreneur. I also see it with practicing designers and design engineers when it comes to FEA.  For the foreseeable future, there will be a need for full-time analysts to handle high end nonlinear & dynamic problems.  They'll need to know the terminology and theory of FEA to be successful. However, designers looking for quick answers to design decisions don't. As I've said previously, the more you know, the better you'll be. However, you should learn the detailed workings of FEA because you are intrigued and go looking for the info...not because you were force fed it before you've even bought off on the need for analysis.  A design engineer that worked for me once enrolled in a master's degree program & chose to specialize in FEA since he felt this would be an important aspect of his career. After a semester of theory, he gave it up as worthless and to my knowledge, never did anything with FEA again!

In a presentation at a local SolidWorks User Group, I tried to make this point by showing how quickly COSMOSWorks could resolve traditional and common engineering design decisions for sizing, shafting and fastener selection - not the things typically reserved for specialized FEA.  Tools like COSMOSWorks can make many tedious parts of any design project faster and more fun while providing insight to behaviors you might not have noticed before.  If you've been thinking about it as difficult, specialized, irrelevant, or complicated for whatever reason, I encourage you to fire up your license and explore how many design decisions can be simplified directly using your 3D geometry.  I used to call FEA "engineering Nintendo" (Does that date me?)  If you find yourself caught up in a discussion of nodes & elements before buying into the technology, even at one of our seminars, remember, there is NO QUIZ at the end so focus on the fun part and give it a try. 

-- Vince

What do we really know?

One of my oldest worn out sayings, “Vince-isms” as my friend Brian King, the chairman of the Illinois/Wisconsin COSMOS User Group calls them, is that engineers, especially ones utilizing analysis techniques, “need to learn to differentiate what they know from what they think they know.”  When you actually come to grips with how little you really know vs. what you always assumed you knew, it is a pretty humbling experience…and that’s OK.

Just recently, I was called in to sort of “referee” a discussion on buckling where one engineer who had been involved in analysis for several years thought a certain class of problems should be solvable but a colleague was adamant that this couldn’t be done.  Since the first engineer’s attempts at doing it were failing (Singular Matrix Error), the confidence the second had in his statement seemed justified.  However, the problem was really an easy one for COSMOSWorks, or any FEA with a buckling solver. The problem as modeled was missing one constraint in a direction that was needed for numerical stability. (The solver needs a path to ground in all degrees of freedom.)

I know a lot about this FEA stuff but more than anything, I know how much I don’t know.  Consequently, I try not to make definitive statements, especially in the negative, if I’m not 100% sure.  (I was a consultant for several years. In ‘consultant school’ we’re taught to be as ambiguous as possible… keep ‘em guessing!)  In this case, I read the buckling controversy e-mail in the car and wasn’t going to make a definitive statement about this either way until I’d checked, (& I ‘knew’ we should have been able to do this.).  This may be one of the hardest lessons an engineer can learn. No matter how much we think we know, we are only scratching the surface of what we should know.  I’ve been surprised too many times to have to worry about getting too confident in thinking I know all the answers. (If I start to slip on this, my wife brings me back to my senses!)  Learning to say “I don’t know.” with confidence and self-assurance will help all of us see the problem in front of us more clearly.

-- Vince

Where were you 5 years ago?

It's hard to believe it has been 5 years since the World Trade Ctr disaster.  Like many of you, I have those images burned into my memory and as I watched specials and commemorations over the weekend, those images were as clear as they were that day.

I was in Australia when the attack happened. I was invited to teach a class on FEA in Product Design by the Institution of Engineers; Queensland in Brisbane that week, starting on 9/12.  My wife woke me up in my hotel room the night before crying after the first tower had been hit and I stayed awake watching CNN until I had to leave for the class. The organizers offered to cancel the class for me but I felt it was important to keep going.

The outpouring of warmth from the Aussies I met in the class and as I traveled thru the area that week was incredible.  As soon as people heard me talk & identified me as an American, I'd get hugs and other truly sincere gestures.  It felt like the whole world was united in mourning over this tragedy.

The class went off without a hitch and, I was given, ironically, a stainless steel cased pocket knife with the Institution of Engineers logo as a Thank You.  As they had just announced that flyers would have to use plastic spoons to cut their dinners, I made sure that was buried deep in my checked luggage for the flight home. I actually made it to LA almost on-time. We were the first international flight allowed to land in the states after 9/11.  They hadn't figured out the new security procedures yet so we spend over an hour standing in customs. At one point, they pushed us against the pack wall of the room for about 20 minutes (it seemed much longer!) because they'd found an unidentified black bag in the hallway outside that area.  It turned out to be nothing and, after learning that my flight to Chicago was cancelled, I had to spend the night in at LAX before heading home the next day.

All this came back to me just recently as I was packing my bags for a flight home a few weeks ago when they thwarted the bomb plot in London and once again security was clamped down on air travel.  I have to say though that this time around, the authorities responded quickly and professionally and there was very little delay (for my airline at least) and everybody seemed to take the new measures in stride.  It is great to see the understanding and cooperation in times like that when, let's face it, people running late for planes or otherwised stressed about traveling, don't make airports the friendliest of places.

I know this little personal catharsis has nothing to do with design analysis but I wanted to say something to remember the day and the horrible loss we all experienced.  If you do nothing else on this 5th anniversary of the WTC disaster, please at least take 5 minutes to remember where you were, what you were thinking, how your life has changed, and hopefully how you have used this to strengthen your bonds with family & friends.  There are no guarantees and as I boarded that plane for LA, I couldn't help thinking about all the things I didn't do with my wife, my kids, my parents and my friends. I think, I hope, I'm better.

-- Vince

"...the more they stay the same."

I was recently referred to Rachael Dalton-Taggart's blog on PR for the CAE Industry, and more specifically, her comments on CAE ads from 1993.  She stated that while the ads looks slicker, the message is still the same.  In 1993, I was an AE for MSC ("The NASTRAN People").  As I was unpacking some dusty boxes following my move this year to the COSMOS team at SolidWorks, I uncharacteristically decided to purge some old paperwork. I came across sales, marketing, and competitive positioning, on how big the Design Analysis market will be and that someday all designers will be using FEA.  It struck me then, as it did with Rachael, that the ads and articles in the CAE mags are essentially caught in a loop, extolling the promise of design analysis.

So, here' s my question...are we, in the development industry, missing something?  If, in 12 years, (several lifetimes in today's Internet-paced market!), we're still pitching the same message, is there something wrong with the message? Are we preaching to the choir and everyone has already heard the message and made their choice about buying it?  Design Validation technology is faster, easier, more integrated, and more accessible than ever before.  Do you, the user-base, still need articles that explain what it is and why should you use it? (By the way...the Beatles broke up!)  If your managers aren't pushing this technology to the forefront of the design process, do you think repeating the message is going to change anything? Or, do you think repeating the message is going to change anything?  Lastly, do you think repeating the message is going to change anything?

Where is this going? In recent surveys, the two dominant reasons why design engineers don't use FEA more is time and management buy-in (which...in my mind...is the same thing.)  How can we help communicate to you and your management the importance of adopting this mature and proven technology?   

By the way, do you think this Internet-thing is just a fad or do you think it wil really catch on?

-- Vince

Can you read the writing on the 'ball"?

Stop me if you’ve heard this one… “Hey…what does the clock say?” “It doesn’t say anything, you have to read it!”  This old joke has special meaning in our household as our oldest, the college bound freshman, never quite made it a priority to learn to read an analog clock. Does this mean he never knows what time it is?  Of course not, there’s always a digital clock nearby.

You are probably thinking, “OK Vince, what does this have to do with design analysis?” Fair question…let me answer it by sharing a conversation I had with son #2, the high school junior-to-be. We were hauling sand from the front yard to the back in wheelbarrows. All noticed how the steel wheelbarrow was more stable than the aluminum one & there even was some concern about the aluminum frame collapsing. Most likely a buckling phenomenon, I shared with them…to blank stares. Then Erik asked me if the software I used could tell if the wheelbarrow would break or not. I almost said, “Yes.”  However, like the old clock joke, I responded instead, “No, you have to know how to read it.”

So, the next time your boss asks you to use that “FEA Stuff” to find out if a part is going to break, remember you can’t expect a Yes-or-No answer, it isn’t a Magic 8 Ball. You must first consider what you need to be able to read the analysis results. Is understanding the data a priority for you?

-- Vince