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

Comments

[Richard Williams]

Hi Vince,
Nice report. What I came away with is a more meaningful understanding on how important it is t document testing parameters and also the possible variables that can be possible. That leaves the possibility of someone not familiar with the test to get an insight into what you did in order to possible see another possibility. As Spock said, "there are alwasy possibilities." Nice job Vince.