For decades, analysis was the exclusive domain of expert analysts. They would develop carefully crafted mesh models to assess only the most critical applications, such as automotive crash tests or the tension in a threaded connector. The stakes were immense. Accuracy was paramount. The significant effort invested in those simulations was worth it.
Fast forward to today, and many things have changed with simulation. Automated meshers can produce robust, high-quality simulation models. Cloud-based solvers can yield results in minutes. Easier-to-use interfaces make analysis available to practically anyone. And while that technological progress is irrefutable, many companies labor to figure out how to incorporate analysis into their development processes.
MANY QUESTIONS FOR SIMULATION
Today, there are many outstanding questions:
- How accurate do analyses need to be? Should they always be as precise as possible?
- What effect does simulation have on prototyping? Does it eliminate it? Decrease it?
- Do analysis results take the place of experience in decision-making?
- Where else in development can simulation be used? Is it for verification and validation only?
The intent of this white paper is to answer these questions and more. Along the way we also provide details on how SOLIDWORKS Simulation tools support these efforts. The role of analysis in development has changed and expanded. Analysis can provide value in whole new parts of the development process.
How accurate does a simulation need to be?
For many, answering this question is a scary and confusing proposition. If you make a decision based on an analysis that isn’t accurate enough, you set yourself up for failure at some point in the development. As a result, many fall back to the most conservative position: Simulations must always be highly accurate. That creates an impossibly high bar for the use of analysis. For some, analysis solutions with any uncertainty are a risk. For others, assessing the accuracy of a solution is too burdensome and, as a result, they shun its use entirely. The truth is that the need for simulation accuracy varies from stage to stage during the development process.
Early in concept design, engineers use simulations to compare the performance of different design ideas, much like any trade study. These simulations are often highly simplified models under generic loads that don’t resemble the design’s detailed conditions. Why? The purpose is to uncover each concept’s underlying behavior early, when the final details of operation may not even be known yet. Engineers use these analyses to gain insight into the feasibility and innovation potential for each idea, ultimately selecting one to take to detailed design. Keep in mind that this isn’t some final check for the design; it is the first, simple assessment. Such designs will be refined and digitally tested to greater depth in detailed design and beyond. As a result, the cost of inaccuracy here is very low.
In detailed design, the needs of engineers change. They use simulations to contrast the impact of specific decisions in fine-tuning a design. This process includes selecting the right material grade, determining wall thicknesses, or selecting off-the-shelf components. These simulation models roughly represent the design’s final operating environment. The purpose of these analyses is still directional; the results here are comparative and not absolute. More formal simulations and tests will catch design flaws later. The cost of inaccuracy here is low. The need for simulation accuracy ramps up significantly in digital verification and validation. At this point in development, engineers and analysts perform a final and formal check of a design’s performance before moving to prototyping and testing, where hard monies are spent to build something physical. The idea is to catch and address design issues here to avoid costly physical prototype failures. The cost of inaccuracy here is moderate. The reality is that the need for analysis accuracy increases as you progress from concept design through digital verification and validation, corresponding to the risk of the task. It starts low. It ends high.