Enbedded FEA - The Future of Design

By Tony Abbey

The origins of many traditional preprocessors such as FEMAP and PATRANgo back some way. The earliest third-party preprocessor I rememberusing was SUPERTAB, long absorbed into the Master Series family fromSDRC, now absorbed into UGS. This used a purely mesh-based operation.No geometry creation was possible or even understood. The cutting-edgewas digitizing a 2D mesh from a paper drawing!

FEA has evolved a long way since then, but geometry creation andanalysis have remained separate and not necessarily equal parts of theprocess. Logically, therefore, the next step in that evolutionary pathis the seamless integration of FEA and MCAD. Here’s a look at our past,where we stand today, and what we can see of tomorrow.

Early Struggles
The original PATRAN of the early 1980s was a radical departure in thatgeometry was the basis of all mesh creation techniques. This was adifficult concept to grasp initially. There were no 3D MCAD products inexistence then, so the merit of geometry was not obvious—we wanted toget on and mesh. However, after a very short but steep learning curve,the benefits of association with geometry were clear. Remeshing wasindependent of existing mesh; loads and boundary condition remainedafter mesh deletion. The irony now was that there was no MCAD data toimport, as none existed. 3D MCAD was slowly emerging in the form of CV,CADAM, CATIA, etc.The geometry tools of those days inside the preprocessors wereverymuch up to scratch with the 3D MCAD products themselves, with basicsolid modeling, lofting, and skinning techniques in wide usage. GEOMODfrom SDRC was a tool far ahead of it’s time, able to model verysophisticated 3D shapes. The Royal College of Art, London, adopted itfor a period for pioneering work in 3D modeling and visualization.

The new challenge was importing MCAD data into a preprocessor. Theearliest attempts were with the IGES protocol. That was basically adisaster. Getting over 80% of curve data successfully imported wasconsidered a success. Surfaces were a faint hope. Many analysts, stilltraumatized by that experience, have kept clear of MCAD data ever sinceand happily build geometry in the preprocessor environment. Now dataimport is far cleaner and robust geometry in an MCAD sense is usuallyobtainable with some tweaking of tolerances. My definition here ofsuccess is that the geometry is exported identically to the geometry asit is read in.
Sadly the preprocessors have largely followed their own direction interms of geometry creation and manipulation. To some extent this is areaction to the rapid growth of 3D geometry functionality in the MCADindustry. Rather than compete with true MCAD products head on,development has been patchy with some attempts made to integrate withACIS or Parasolid kernels.

Embedded Analysis the Solution
These days the best advice is to create and manipulate geometry in theMCAD environment and to mesh in the preprocessor. Both are good attheir own tasks, but do not crossover well.This brings us back to the issue ofimporting MCAD. How well does theaverage preprocessor understand the native geometry it finds? Thechallenges are twofold: interpreting the mathematics behind thegeometry definition and dealing with all the well-known geometryissues, such as incomplete, infeasible, or distorted entities. A wholeindustry has been built around fixing up MCAD data to make it meshable.Many palliatives exist but no real cure.
Embedded FE analysis inside the MCAD environment is a very attractivesolution. After all, the analyst should find geometry creation andmanipulation inside products such as SolidWorks and Autodesk Inventor alot more straightforward than the hoops he is used to jumping throughin a modern preprocessor. And since the designer lives and breathes inthat MCAD environment, the introduction to analysis can at least bemade in a familiar environment.

For both of these professionals, they can see the influence of the meshas it adapts to the evolving design at every stage. The quality of themesh is fundamental to accuracy and to the minimization of manual fixes.

The key to making this work is the quality and performance of the FEsolver. At Noran Engineering we have recently released V1.1 of ourembedded MCAD solution, NEiWorks. This brings Nastran, an industrialstrength solver with wide acceptance, into the SolidWorks environment.The key to success here is that the Nastran data structure istransportable and can break down barriers between design and analysis.Not only will SolidWorks users be able to send their work to otherNoran Engineering analysis applications like NEiEditor and NEiModeler,but also to other vendors’ Nastran interfaces as well, such asMSC.Patran.

We have already seen success stories with clients using NEiWorksembedded in SolidWorks defining the design, carrying out basicanalysis, and then passing the project off to analysts to carry outcomplex nonlinear analysis. The analyst is not constrained to theSolidWorks environment; he has access to the established Nastrananalysis community with the option of using the NEiEditor andNEiModeler to harness the full capabilities of NEiNastran as needed. Hecan also share results with vendors, suppliers, and partners who mayhave other vendor Nastran interfaces.

The future of FEA is firmly linked to the embedded MCAD solution.

Tony Abbey is Technical Manager at Noran Engineering and is part of theteam developing NEiWorks. He has nearly 30 years’ experience in the FEindustry, both as an analyst in the defense sector and lead technicalroles at MSC.Software before joining Noran Engineering. Send comments about thisarticle to [email protected]

Product Information

NEiWorks
Noran Engineering, Inc.
Westminster, CA
nenastran.com