By Bruce Jenkins, President, Ora Research
Automating the setup and execution of simulation and analysis problems has been a goal of both practitioners and software vendors since almost the beginning of the mechanical CAE software industry. After a long period of gestation and gradual progress, new solutions that benefit analysts, engineers and designers alike are coming to market at an ever-accelerating pace.
First wave: Scripting and custom programming
Early approaches relied heavily on scripting and custom programming. Repetitive, routine processes could be captured and reused in macro languages provided by CAE software vendors as adjuncts to their solvers and pre/post-processors. In addition, engineering organizations employed scripting languages such as Java and Python to build powerful, sophisticated layers of automation on top of their commercial analysis tools.
These approaches were a significant advance over having to set up every simulation problem entirely manually. A common misconception about CAE is that long computer run-times are the chief constraint on the analysis department’s ability to provide answers quickly enough to keep up with the pace of an overall product development project. But in reality, the time and labor required to set up models and input conditions for crash simulation, thermal analysis, and simulation of many other complex physical phenomena can far exceed the solver run-times for such problems. As an aerospace engineering manager once told us, “When it takes six weeks to prepare the input, the six-hour run time is irrelevant.” Automating problem set-up through scripting and programming helped relieve analysts of much of this tedious, time-consuming labor.
However, as powerful as this approach can be, it has significant limitations. Often narrowly case-specific, custom scripts are generally applicable only to the focused range of problems for which they were originally conceived. They tend to be tightly bound to the specific solvers and pre/post-processors for which they were first written, and require substantial rework to incorporate new tools entering the engineering organization. And their value is most often to help expert analysts work more efficiently and productively—they often do little to help make simulation and analysis capabilities available to engineers and designers outside the analysis department.
Second wave: Process automation frameworks
To move beyond these limits, a second wave of simulation process automation has gained momentum over the past decade-plus. This consists of environments and frameworks for simulation workflow capture and automation, often featuring drag-and-drop workflow editors that let analysts readily set up sophisticated process flows that can call functionality from a wide range of modeling, analysis, pre/post-processing and reporting software tools, and control data flows among them.
Once defined and validated by CAE experts, these workflows can often be used safely by non-experts—that is, engineers with expertise in their discipline, but without advanced training in CAE tools. Leading examples include Altair HyperWorks Collaboration Tools, ANSYS Workbench, ESI Virtual Integration Platform, MSC SimManager, Siemens Teamcenter Simulation Process Management, SIMULIA Simulation Lifecycle Management and others.
This approach to automating simulation processes has yielded substantial productivity gains for expert analysts, while at the same time capturing their expertise and making it available to engineers outside the analysis department. However, practitioners report that often enough, these solutions can still suffer from some of the same limitations as custom programming. What we hear most commonly is that when a problem being studied turns out to vary too greatly from the idealized scenario for which the automated workflow was constructed, the system freezes up, breaks down, or requires exactly the kind of manual intervention it was intended to eliminate.
Much of this is because the rules captured in these workflow templates are often based on the physical geometry of the generic product class whose design and analysis a given template is intended to automate. As any design progresses, changes to geometry or topology are frequently found to be necessary. But when these changes go too far afield from the generic model captured in the automation template, the rules fail. Software vendors are well aware of this limitation, and some have devoted substantial effort to remedy it. But we continue to hear from practitioners that more development is needed for this approach to scale across a sufficiently wide range of product families, initial design possibilities, and likely design changes to work in all or even a majority of their real-world use cases.
Third wave: Simulation apps
More recently, a third approach has emerged: simulation apps. These provide sophisticated simulation capabilities packaged as easy-to-use, tightly focused apps that automate the design, analysis and verification of a specific type of product, often tailored to the needs of a specific user company. In this approach, the expertise of an engineering organization’s analysts is captured as rules in a set of templates that automate the design of a specific class of product. In use, the templates call on general-purpose modeling, simulation and analysis software for geometry creation and modification, mesh generation, physics calculations in the various disciplines involved, and results presentation in the form of an optimized, validated design solution.
Ball bearing SmartApp. Source: Front End Analytics and EASA
How simulation apps escape some of the limits of older approaches is by capturing the expert rules based on the functional architecture of the product family, instead of on the geometry or topology of particular designs. This is what can make the templates robust even across significant geometry, topology and configuration changes, and across an entire product family. Automation templates constructed on this basis allow any user, expert or non-expert, to explore alternative architectures, and to swap out entire components to find the best design most effectively. Most important is that these apps, designed and certified by experts, are immediately usable by engineers and designers without requiring specialized training—and make the full power of the underlying simulation and analysis tools available, safely and reliably.
Also important to understand is that, for now, simulation apps are not only solution-specific, but also need to be company-specific to have their greatest impact. Every company that uses simulation in its engineering processes has developed best practices using particular simulation codes. Thus, solution providers need, at the least, to customize a “starter” app to conform exactly to the company’s best practices, in order for the company’s experts to embrace these tools, and for everyone in the organization to trust the results they produce.
Equally important is that simulation apps are not just a vision for the future, but are being deployed and delivering payback today. Products as diverse as automotive drivelines, integrated circuits, space-based optical sensing systems and others have all featured in case-study presentations of where simulation apps have been successfully applied and proven in production situations.
Hydraulic rod design example SimApp. Source: Comet Solutions
Pioneering software and service providers and offerings in this area include Comet Solutions SimApps, COMSOL Multiphysics Application Builder, EASA, Front End Analytics SmartApps, Xogeny and others. In short order we expect to see growth of a rich ecosystem of app development tools and frameworks, app development service providers, and off-the-shelf suites of product-specific apps ready for individual end-user companies to customize by capturing and embedding their in-house experts’ knowledge and best practices.
The model brittleness problem inherent with parametric feature-based modeling is a really big deal. And it’s something, honestly, that I don’t have a great answer for. I’ve even asked a few power users who I know, and their answers seemed to involve a bit of hand-waving, and a reference to having lots of experience.
Direct modeling—a syncretic melding of concepts pioneered by CoCreate, Trispectives, Kubotek (and many others)–has shown the most promise to cure the parametric curse.
