+, 1

,..

THE COMMON GEOMETRY MODULE (CGM): A GENERIC,EXTENSIBLE GEOMETRY INTERFACE

Timothy J. Tautges’

Sandia National Laboratories, Albuquerque, NM. ~tautg(ijsandia.’gov

ABSTRACT

Geometry modeling has in the past five years emerged as a commodity capability several geometry modeling engines areavailable which provide largely the same capability, and most high-end CAD systems provide access to their geometry throughAPIS. However, subtle differences still exist between these modelers, both at the syntax level and in the underlying topologicalmodek. A modeler-independent interface to geometry is critical to solving many of the geometry-based problems which exist inapplications like mesh generation. The Common Geometry Module, or CGM, provides such an interface to geometry.

CGM consists of a set of wrapper functions which translate function calls such that they access geometry in its native format.However, CGM also provides functionality not found in most modelers, like support for non-manifold topology, and alternativegeometric representations, including mesh-based and facet-based geomeby. CGM is designed to be extensible, so thatapplications can define application-specific behavior for geometry entities. CGM is also designed to be easily portable to othergeometry modeling engines. Ports to SoIidWorks and Pro/Engineer are underway.

Keyword= geometry; solid modeling componentization.

1. INTRODUCTION

Geometry is a critical part of mesh generation and otherdiscretization-based simulation techniques. It forms theinitial description of the analysis domain, is used insubsequent refinement and other modeling operations, andoften is at the heart of bottlenecks in mesh generation andother processes. Geometric modeling capability has’advanced rapidly in the past ten years, to the point where itcan be considered a commodity [1]. Geometric modelinghas been provided in Iibrary form for some time, and manythird party applications have been developed on top of thiscapability mesh generation is just one of theseapplications. For various reasons, attempts have been madeto port these third party applications to multiple geometricmodeling engines. In the process of developing such anapplication, methods for encapsulating geometrictlmctionality and simplifying the porting process have beendeveloped, and have been packaged in a set of higher levelcode libraries. These libraries, grouped in the CommonGeometry Module, or CGM, are described in this paper.

Solid modeling libraries and Application ProgrammingInterfaces (APIs) have over the last five years become acommodity, ‘i.e. rnukiple sources exist for this capability,

all providing iimctionality similar enough to meet mostneeds. Examples of such “solid modeling engines” areACIS [2], the SolidWorks API [3], IDEAS Master SeriesOpen I-DEAS [4], Parasolids [5], and Pro/Engineer’sProfloolkit [6]. All such engines provide bothrepresentation of geometry (both topological andgeometric) as well as API fimctions for constructing andmodifiing that geometry. Some engines expose thesoftware design of their datastmctures, allowing thederivation of application-specific datastructures based onthem (e.g. ACIS), while others just expose functionalinterfaces to these datastructures (e.g. Pro/Toolkit,SolidWorks). While there are subtle differences betweenthe core datastructures and fictional interfaces in eachsolid modeling engine, in general the overall capability isquite similar, and fundamental capabilities (e.g. topologicaltraversal, surface evaluation functions) are alwaysprovided.

Recent experience has demonstrated that geometry lies atthe heart of many difficulties in the mesh generationprocess. First, the mesh generation tool of choice may notbe capable of working directly with the solid modelingengine in which the part to be analyzed has been designed.In these cases, translation between geometry formats isnecessary. This translation often introduces variousgeometric artifacts because of differences in modeling

1 SANDIA IS A MULTIPROGRAM LABORATORY OPERATED BY SANDIA CORPORATION, A LOCKHEED MARTINCOMPANY, FOR THE UNITED STATES DEPARTMENT OF ENERGY UNDER CONTRACT DE-AC04-94AL85000.

DISCLAIMER

This repoti was prepared as an account of work sponsoredby an agency of the United States Government. Neitherthe United States Government nor any agency thereof, norany of their employees, make any warranty, express orimplied, or assumes any legal Iiabiiity or responsibility forthe accuracy, completeness, or usefulness of anyinformation, apparatus, product, or process disclosed, orrepresents that its use wouid not infringe privately ownedrights. Reference herein to any specific commercialproduct, process, or service by trade name, trademark,manufacturer, or otherwise does not necessarily constituteor imply its endorsement, recommendation, or favoring bythe United States Government or any agency thereof. Theviews and opinions of authors expressed herein do notnecessarily state or reflect those of the United StatesGovernment or any agency thereof.

DISCLAIMER

Portions of this document may be illegiblein electronic image products. Images areproduced from the best available originaldocument.

. ,

accuracy [7]. After those artifacts are removed, and allgeometric features represent design intent, these featuresare often at a resolution different than that targeted foranalysis. This results in modifications to the geometry,usually simplifying the model. Finally, various meshgeneration approaches, especially in hex mesh generation,require further decomposition of the solid model.

Since geometry is so important to applications like meshgeneration, and because the fundamental problems likedetail suppression and decomposition are diftlcult enpughto deal with on their own. it does not make sense tointroduce further complications by requiring translation ofthe geometry from its native format to that required by anapplication. This is especially true when there are multipleapplications, each requiring a different representation type,and even more unnecessary considering that most CADsystems now provide APIs for accessing geometry directly.Rather, the applications should be written such that theycan access geometry in any format, as long as the interfaceto those data provides the proper functionality needed bythe application.

This paper describes a geometry library called the CommonGeometry Module, or CGM. CGM provides a modeler-independent means of accessing geometry, while leavingthe geometry in its native format. In addition, CGMprovides capability not found in many geometry engines,but useful in many applications; these capabilities includesupport for non-manifold topology, virtual geometry, andsupport for simultaneous access to geometry in multiplegeometry engines. CGM was constructed by isolating andmodularizing the geometry capability in the CUBIT meshgeneration toolkit [8].

This paper is arranged as follows. Section 2 exploresti,uther why generic interfaces to geometry are needed, andoutlines the requirements of such an interface, from boththe applications’ and underlying representations’ points ofview. Section 3 describes the basic design of CGM,including the topological model used by CGM and howthat model is created, modified and accessed through theCGM APL Section 4 gives more detail on the extensibilityfeatures of CGM, and describes the implementation ofCUBIT using CGM. Section 5 includes a discussion ofoutstanding issues and fiture work planned for CGM.Section 6 gives conclusions of this paper.

2. BACKGROUND AND REQUIREMENTS

Before describing CGM, it is instructive to explore thegeneral issues of why a generic interface to geometry isneeded; this is done in the following subsection.Afterwards, some general requirements are given for ageneric interface to geometry such that these needs aresatisfied. This section concludes with a discussion ofprevious efforts in this area, and why these efforts do notmeet the requirements laid out here. #

Generic interfaces Needed

Until recently, it was very difficult if not impossible tobuild applications in a way which was portable to multiplegeometry engines. Either the target engine did not provideaccess to its geometry, or the geometry system providingthis type of access was not robust enough to supportmainstream design activities. These barriers have beenremoved with the development of the ACIS [2] andParasolids [5] modelers, among others. However, smallbarriers to portability persist.

One major area of difficulty is in non-manifold topology,for two reasons. First, most modelers provide either nocapability in this area or capabilities which are closely tiedto how the modeler handles assembly models. Second,users are responsible for identifying “mating” surfaceswhich are common to adjacent parts. This is a tedious task,and furthermore is a geometric operation that should besupported directly by the modeler.

Another area of difficulty is the slight differences betweentopological models used in each modeler. For exaniple,ProfToolkit sometimes provides topological faces havingtwo or more disjoint regions. Another common differenceis whether support for periodic geometry is provided.While relatively small, these differences can affect the wayapplications are written. For example, parametric spacemeshing algorithms must account for the jumpdiscontinuity along a periodic boundary. Restricting anapplication to working only on a specific type of geometry,e.g. non-periodic geometry, inhibits portability by requiringgeometry to be modified before access by theseapplications.

These differences can be overcome by defining a common,generic interface to geometry, along with a standardtopological model. Standardizing the interface allowsapplications to work on multiple geometry engines;defining a standard topological model is necessary fordetermining what kind of assumptions applications canmake about model topology. Implementing some changesto geometry at the interface layer allows the interface to“smooth over” the slight differences between the variousmodeling systems. We refer to this as a “tall” interface,that is an interface which provides not only translationbetween the common and engine-specific syntax, but alsoany modifications required for the engine-specifictopological model to correspond with the chosen ‘“standard” . Ideally, these modifications are minimal.

Solutions to some geometry problems have resulted in thedevelopment of alternative representations of geometry.One of the first solutions of this type was the representationof non-manifold topology, used for the generation of meshmodels with contiguous mesh through material interfaces.The CUBIT mesh generation toolkit [8] has longrepresented this in code outside the underlying ACESrepresentation. Another example is the removal of smallfeatures in the model (either translation artifacts or finedesign details). This is done in CUBIT using “virtualgeometry”, where the topology of the model, as exposed to

the meshing tool, is modified while keeping the originalsolid model entities in their original state [9]. Otheralternative representations which have been developedinclude mesh-defmed geometry [10] and faceted geometry[11].

Using “tall” interfaces introduces the possibility of buildingthese alternative representations, while still delivering themin a form which looks like more traditional representations.This allows applications to use these alternativerepresentations without modification. If designed carefidly,this me of interface can also simplify the porting of theinterface itself to different geometry engines. This isdescribed further in a following section.

Interface Requirements

Before describing other interface efforts, or the CGMdesign, it is useful to outline the basic requirements of thegeometric module,1. Linkable:

Obviously, a geometry interface must be linkable intoapplications needing geometry fimctionality. Thisallows the geometry fimctionality to be separated tlomapplications that use it.

2. Independence from non-geometric dat~ codeBecause applications use widely varying datastructures, even within applications of the same class(e.g. mesh generation codes), this data must be keptseparate fkom the geome&y interface. This not onlyreduces the size of the interface (both data size and thenumber of functions), but, more importantly, allowsdevelopment of applications and geometryrepresentations independently. This greatly simplifiesthe development and maintenance overall, while alsofacilitating the testing of each capability in productionapplication environments.

3. EncapsulationFor the geometry module as a whole, encapsulationensures that the geome~ interface is not dependenton other code, e.g. meshing algorithms. Within theimplementation of the interface, encapsulation meansthat code specific to a particular geometric modelingengine, e.g. ACIS, is separate tlom the more generalgeometric modeling capability implemented in theinterface, e.g. detection and representation of non-manifold topology. This simplifies theimplementation of the interface on additional solidmodeling engines.

4. ExtensibilityGeometry forms the basis of most modem meshgeneration toolkits[12]. In fact, geometry datastructures are typically used as the objects aroundwhich meshing capabilities are implemented (this isthe approach used by CUBIT, for example). ~ Asgeometry propagates further into the analysis pr~cess,this will become the case in analysis codes as well.For this to be possible at the same time as requirement

#2, the geometric data structures must be extensible byapplications built on the interface.

5. PortabilityOne of the goats of this effort is to simplify the portingof geometry-based applications to other geometricmodeling engines. We also require that this geometryinterface be portable to other modeling engines belowthe interface. The porting of CGM to other geometricmodeling engines is described later in this paper.

6. Multiple, simultaneous geometric representationsSometimes, the modeling capabilities of onerepresentation can be used to overcome shortcomingsof another. For example, virtual geometry can be usedto remove small geometric artifacts introducedinadvertently by a geometry engine.

Simultaneous access to multiple representations is alsodesirable when applications need to reference parts ofa model designed in different CAD systems. From thecode design point of view, this requirement dependson the code within CGM being encapsulated(requirement #3), so that representations can beinterchanged without extensive code modifications.

7. Support for query, modification and creation:Obviously, a geometry interface needs to supportquerying of geometry entities (e.g. closest point tosurface, point in body, etc.) However, as describedearlier, many of the current bottlenecks to meshgeneration are really geometry problems; theseproblems are difficult or impossible to overcomewithout making modifications to the geometry. Forexample, most approaches to hexahedral meshgeneration currently require geometry decomposition.Thus, if it is to meet needs in mesh generation, ageometry interface must allow modification to orcreation of geometry.

8. support for non-manifold topology:FEA capabilities have advanced to the point where itis possible (and common, in some contexts) to analyzemodel assemblies consisting of multiple parts. Forstructural problems, these assemblies have multiplematerials or parts, which meet at shared surfaces.Modeling such assemblies requires the representationof non-manifold geometr~.

Conspicuously missing tlom the list of requirements aboveis a requirement of rninirmdity of the interface, or ofallowed types of access to the geometric data structures.These requirements were left out not because they wouldnot be desirable, but because they are not crucial to thebasic fknction of such a geometry interface. However, itcould be argued that these characteristics would either

2This is not strictly true, a shared interface could beconstnrcted by representing the interface twice, butrequiring mesh on either side be duplicated on the other. Itis clear that this process is much simpler if it is supported ingeometry rather than as a mesh matching operation.

simplifi the interface or make it more efficient. This isdiscussed more in Section 5.

Previous Work

There have been several past attempts to generalize theinterface to geometry these efforts are now reviewed.

The DJINN API attempts to define an interface common tomost geometry engines, based on set theoretic definitionsfor accessing and modifying geometry [13]. Since there isno implementation provided with this API, it is difficult toevaluate with respect to requirements 1-3 and 5-6,Requirements 7-8 are met, according to the DJINNspecification. However, since DJINN provides only afunctional interface to geometry, it follows that theinterface would probably not be extensible. As will bedescribed later, extensibility is critical for buildingapplications on top of geometric models.

Another attempt at defining a common interface togeometry is the CAPRI effort [14]. Here, interfacefunctions are defined independently of an underlying solidmodeling engine. Query-only operations are supported, butgeometry cannot be modified or created through thisinterface. Also, it does not appear that CAPRI has supportfor non-manifold topology, at least in a manner that isindependent from the underlying solid modeling engine. Itis not stated which if any implementations exist for widelyavailable solid modeling engines.

Another effort at specifying a geometry interface is theOLE for Design & Modeling standard, or OLE for D&M.This standard, promoted by DMAC, defines functions foraccessing geometry and topology in a manner independentof any particular solid modeling engine [12]. However, thefunctionality is limited to query operations, and does notdefine functions for creating or modifing geometry. Sincemany of the tools used in mesh generation require thedefinition of additional geometry (e.g. decomposition), theOLE for D&M interface would be insufficient forsupporting this application. It is unclear whether there aremany full implementations of this specification.

The Virtual Geometry Interface, or VGI, was implementedin CUBIT to serve as a middle layer of geometry betweenapplications above and specific solid modeling enginebelow [16]. The VGI is the predecessor to CGM, and thetwo share many of the same design concepts andcapabilities. However, CGM has extended the designconcepts of the VGI in key areas, simpli@ing andsometimes enabling extensibility, portability, and otherrequirements. Differences between CGM and the VGI aredescribed later in this paper.

CGM is the result of isolating all geometric capabilitiesavailable in CUBIT into a standalone set of libraries. Itacts as a wrapper around the functionality in ACIS, wJichserves as the primary geometry engine underneath CUBIT.However, CGM also includes key functionality not foundin ACIS, such as non-manifold topology detection andrepresentation, virtual geometry, and mesh-based and

faceted geometry representations. Although CGM grewout of existing code, substantial efforts were made toimprove its extensibility, and to simplify its porting to othergeometry engines.

One obvious question is whether any existing solidmodeling engines meets enough of the requirements aboveto serve as an adequate starting point. Of those available,ACEScomes the closest to providing this level of support.ACIS gives full access to its data structures, both forcalling functions from specific data classes, and even forderiving application-specific data structures horn themThere are two reasons we chose to not take this approach.First, using the ACIS data model would require us to eitheruse ACIS code directly in CGM, even in versions notincludhg the ACLS solid modeling engine as one of thegeometry representations, or to rewrite ACIS classes forthose versions of CGM. Either way, it would becumbersome to maintain compatibility with ACIS, sinceCGM would depend on both fictional interfaces and datastructures in ACIS. Secondly, a concept fundamental to thedesign of CGM is the topology model used. Thetopological model in CGM differs horn that in ACIS in keyarea of non-manifold geometry. Extending ACIS datastructures to represent non-manifold topology would bedifilcult and would exacerbate the ditllcuky of maintainingCGM in the face of changes to ACIS. Finally, using datastructures derived from those in ACIS might make itdifficult to implement fundamentally different kinds ofgeometry representations. For example, theimplementation of virtual geometry in CGM depends onhiding geometric entities from the model visible toapplications, but using these hidden entities directly forgeometic evaluations. This requires specific changes tothe topology data and traversal functions that would bevery difficult to make in ACIS.

For these reasons, and also because this effort started longbefore ACIS was robust enough to support these needs, wedecided to use our own data structure on top of thoseprovided by ACIS or other solid modeling engines. Thisdata structure, and the topological model reflected by it, aredescribed in the next section.

3. CGM DESIGN

CGM can be thought of as a “tall” interface. That is, itprovides both wrapping functions for the underlying solidmodeler(s), and data and functions to provide missingcapabilities and smooth over differences between varioussolid modeIers.

In this section, CGM is described at the “user” level, that is,horn the perspective of how it would be used, withoutmodification, to access geometric models. This sectionconcludes with a short example of how CGM is used toquery and modifi geometry.

TOPOLOGY AND GEOMETRY ENTITIES

The basic geometric representation used in CGM is that ofa Boundary Representation, or BREP. CGM defines two

,

.,

primary levels of entities or objects that make up thisrepresentation; these levels are referred to as TopologicalEntity’s (TEs) and Geometry Entity’s (GEs).

At the highest level, CGM defines its own TEs, which arethe primary means of access to geometry and topology byCGM applications. The TEs are separated into threegroups: “basic” topology entities, grouping entities, andsense entities. Basic topology entities (BTEs) are the onlyTEs which have an underlying geometric description.Grouping entities (GEs) group together basic topologyentities to form the boundary of higher level BTEY forexample, a Loop groups together edges bounding a face.Sense information is represented explicitly in SenseEntities (SES). The three groups of Topology Entities arelisted in Table 1, for reference.

Table 1: Topology entities used in CGMtopological model. --

BasicTopologyEntities

GroupingEntities

SenseEntities

EntityRefVertex

RefEdge

RefFace

RefVolume

Body

Shell

Loop

CoFace

CoEdge

DescriptionOd entity in topologicalmodel.ld entity in topologicalmodel.2d entity in topologicalmodel.3d entity in topologicalmodel.One or more volumes, share atransform and participatetogether in geometrytransforms and booleans.Group of CoFaces describinga closed or open shell; ifclosed, describes a boundaryof a volume. Can be inner orouter boundary.Group of CoEdges describinga boundary of a face. Can beimer or outer boundary.Entity describing theorientation of a face as usedin a shell, with respect to theface’snormal.Entity describing theorientation of an edge as usedin a loop, with respect to theedge’s tangent direction.

At the lowest level, Geometry Entity’s are created to matchone to one the topological entities in the underlying solidmodeler. For example, there is a CGM Geometry Entitycorresponding to each FACE, EDGE, etc. in an ACISmodel. GEs also provide geometric evaluations throughcalls to the solid modeling engine. The types of GeometryEntity’s used in CGM are defined in Table 2.

“,:There are several specific arrangements of topologicalmodels that are allowed in CGM models that are notcommon to all modeling engines. First, CGM allowsRefEdges to be bounded by a single RefVertex; these are

called periodic curves, in reference to the periodic nature ofthe curve’s parameter space. Likewise, periodic Reffacesare allowet these are surfaces whose parameter spacecontains jump discontinuities, for example a cylindricalsurface. Not all modelers are capable of modeling periodicentities, and will not generate entities of that type; howeverthe capability of CGM to model periodic entities is asuperset of these, and so can be used with either type ofsolid modeling engine.

In rare cases, topology exists where an entity of dimensiond is not strictly bounded by an entity of dimension d-1.The best example of this is a cone, where the apex isrepresented topologically by a vertex. Although there is noapparent curve corresponding to this vertex, CGM modelsthis using a zero-length RetEdge. Applications not desiringthis behavior can request that the periodic entities in a Bodybe split into non-periodic ones.

Geometry can be envisioned whereby a single basictopological entity bounds a higher order entity twicq anexample would be a torus with a split face on one end.While this geometry can be represented using judiciousapplication of CoFaces, it is not typically found in designgeometry. Cases involving surfaces included twice by asingle shell are not supported in CGM; however, edges canoccur twice in a given loop.

Non-Manifold Topology

Non-manifold topology is a general term describingallowabIe combinations and arrangements of the basictopological entities into a solid of arbitrary dimension. Inthe context of CGM, the term “non-manifold topology” isused to indicate the presence of entities of dimension d-1shared by more than one entity of dimension d. In practice,we use “non-manifold” to describe groups of volumeswhich share surfaces between them. CGM implementsnon-manifold topology by associating multiple GeometryEntity’s with single Topology Entity’s. This isimplemented using a TopologyBridge object, which linksone TopologyEntity object to one or more GeometryEntityobjects. Thus, the underlying solid model is typicallymanifold, whereas the CGM model can be manifold or non-manifold. Since the CGM topology can be different thanthe underlying solid model topology, CGM implements itsown data and fhnctions for representing and implementingtopology traversal data and functions. When using a singleunderlying solid model representation containing no non-manifold topology, this data is identical to that in theunderlying modeler. CGM constructs this model startingwith an entity in the solid modeling engine by firstconstructing the corresponding geometry entities, in anengine-specific tool, then passing the highest-ordergeometry entity to a generic tool, which fills in thetopology entity layer.

,

Table 2: CGM Geometw Entity’s and theirassociated Topology Entity;s. -

I Geometry Entity I Associated Topology !—.I Entity

Point I RefVertex

I CoFaceI CoEdgeSM I CoEdge

The CGM class hierarchies for TopologyEntityGeometryEntity are shown in Figure 1 and Figure 2.

OTHER CGM DATA, TOOL OBJECTS

and

In addition to the TEs and GEs used to define the basicentities making up the CGM geometric model, there areother data and tool objects defined by CGM that are usefulfor creating, modifjirrg or otherwise interacting withgeometric models. These are described below.

RefEntitys

RefEntity is a special class of TopologyEntitys that isuseful for meshing and other applications. RetEntitysinclude all the BTEs, as well as Bodys and RefGroups(explained in the next section). This class complicates theimplementation of CGM considerably, and may beremoved in the future.

RefGroups

The Grouping Entitys listed in Table 1 are specific to thekinds of geometry they contain and bound; for example,Shells consist only of one or more CoFaces, and boundRetVolumes. In contrast, RefGroups are used in CGM tostore one or more RefEntitys of arbitrary type. The entitiesstored in a given group are grouped only for convenience,either for the user or for a specific application. Forexample, users may want to create a group of all entitiesfalling on one side of a coordinate plane. RefGroups areused extensively in the CUBIT application of CGM, as wellas for some internal actions inside CGM itself.

Attributes

Attributes are defined as information which can beassociated with a particular geometric entity, but which arenot intrinsic to the representation of that ,enti~. ForexampIe, the name of a geometric entity, while not requiredto represent an entity, is associated directly to that entity.CGM provides functions for storing application-specificattributes directly on geometry entities, and fimctioxqsformanaging that data when geometry is stored to disk.

Tools

The primary interface to CGM is through its tools, and inparticular through the GeometryTool class. GeometryToolis implemented as a singleton, or static, class, whichimplies that the GeometryTool functions can be viewed asAPI functions rather than functions associated with ageometry entity. GeometryTool implements functions forreading and writing geometry files, creating geometry fromprimitives, and most other general geometric functionality.GeometryTool is also the point of access for global lists ofgeometric entities. Other tools in CGM, most of them alsoimplemented as singleton classes, perform functions inspecific areas. Two of the most important tools in CGMare MergeTool, which detects coincident geometry andchanges manifold to non-manifold geometry, andVirtualGeometryEngine, which builds the representationfor virtual geometry.

Implementation Notes

Reffintity: This class is a parent of the basic topologyentities as well as Body and RefGroup. As describedearlier, the RefEntity class is a convenient mechanism forgrouping entities of most common interest to users. Bodyand RefGroup are included in this hierarchy because usersoften perform operations on these entities which simply getapplied to all the basic topology entities included in them,e.g. meshing, drawing and listing operations.

CoVertex, Chain, CoVolume: These classes are simplyplace-holders in the topology hierarchy. Though they donot perform any functions, they are retained forconsistency. This guarantees that, for example, every BasicTopology Entity (e.g. RefEdge) will contain a lower levelGrouping Entity (e.g. Chain), and each grouping entity (e.g.Chain) will consist of a list of sense entities (e.g.CoVertex).

EXAMPLE: BASIC CGM USAGE

1~ this section, a simple CGM driver application isdescribed. This application, called mergechk, imports oneor more geometry files, imprints the entities together, andmerges geometry into non-manifold geometry. Althoughvery simple, this application demonstrates how to importgeometry, perform boolean operations on it, then furtherquery the geometry. The source code for this application isshown in Table 3. Some declarations and comments in thedriver code have been removed for brevity the completemergechk application is distributed with the CGM libraries.

There are three primary parts of this application:initialization, importing geometry, and modifjir~queryinggeometry. In the initialization phase, certain objects (staticCubitApp and GeometryTool objects) are created byrequesting instances of the objects. Instantiating theseobjects also initializes internal data structures for globalentity lists and other things. Reading in the geometry isaccomplished by calling a function in the GeometryToolclass. This function reads geometry from the specified file,storing pointers to that geometry in global lists stored in theGeometryTool class. In the final part of mergechk, bodies

are imprinted together, which ensures that neighboringgeometry aIso shares like topolo~, and the entitiessatisfying the topological and geometric proximity tests aremerged together.

Several important points about using CGM should be notedhere:● CGM keeps track of its internal state, e.g. by keeping

geometric entities in global lists. However, individualentity pointers can be retrieved and accessed ifdesirable as well. This keeps the CGM interface bothsimple and powerfid.

● CGM provides data structures which it uses to passarguments back and forth, e.g. lists, coordinate triples,etc. These data structures can be used directly insideapplications, or they can be copied into application-specific data structures.

Table 3: Mergechk, a simple CGM application.

// include tool and datastructure// declarations#include “GeometryTool.hpp”#include “MergeTool.hpp”(“.)

/// main program - initialize, then send// to proper functionint main (int argc, char **argv)

{

// Initialize the applicationCubitApp *app = CubitApp::instanceo;

// Initialize the GeometryToolGeometryTool ●gti .

GeometryTool::instanceo;

// Read in the geometry from files// specified on the command line

filefitr = fopen(argv[l], “r”);status =

gti->import_solid_model(file~tr,argv[i], “ACIS SAT”);

// imprint the bodies together, discarding// old bodiesDLBodyList old_bodies, new_bodies;gti->bodies (old_bodies);gti->imprint (old_bodies, new_bodies);

// Merge bodiesstatus . MergeTool: :instanceo

->merge_all_bodieso ;1

This examole is meant to be illustrative of the basiccapabilities’ of CGM. For a full description of CGM dataclasses and functions, see Ref. [17].

4. EXTENSIBILITYAND ENCAPSULATIONFEATURES

J’

One of the primary differences between CGM and otherstandard geometry APIsisthatCGM isdesignedtobe bothextensible and encapsulated. CGM is extensible in that it

allows derivation of application-specific entity classes hornits topology and geometry entity classes; because of itsencapsulation, this can be done without modification of theCGM code itself. CGMisalso encapsulated on the lowerend, from the solid modeling engine(s), to simplify theaddition of alternative geometry representations. Thesefeatures, along with how they facilitate specific flmctions inCGMorits applications, aredescnbed inthis section. -

CGMENTITYCONSTRUCTION

In its simplest form, CGM constructs its TE and GE entitiesstarting with a topological object represented in anunderlying solid modeling engine. Constructing theseCGM objects requires some operations that are specific tothesolid modeling engine andsome which are not. Theseoperations are separated carefully, in order to simplify theporting of CGM to other solid modeling engines.

Starting with a solid modeling engine BODY (which hasdata and tlmctions defining lower order entities andtraversal between them), the procedure shown in Table 4 isused to build the corresponding CGM Body (in thisdescription, the entity names correspondingto ACIS areused for illustrative purposes, but these could correspond toany modeler giving access to the BREP model). Severalthings should be noted from this procedure:● Linking TEs to GEs to solid modeling engine

objects: There are three levels of hi-directionalpointers; one is betsveen solid modeling entities andthe corresponding CGM GE objects (this is aone-to-one relationship, and is implemented using attributes);snother is between a GE and its correspondingBridgeManager object (there can be multiple GEs perBridgeManager, incsses ofnon-manifold topology);and finally, a link between TEs and theircorresponding BridgeManager (this is a one-to-onerelationship).

● Solid modeling engine encapsulation: Theconstruction of TEs from the highest-level GE object(usually BodySM) is done in a solid modeling engine-independent msnner. This requires traversal timctions

‘defined for the GE objects, which return other GEobjects. For example, BodySM defines a function,surfaceso, which returns a list of Surface objectscomected to the BodySM. These traversal fimctionsare implemented in a solid modeling engine-specificmanner, however, to avoid duplicating solid modeltopology at the GE level.

● Missing entities in solid modeling engine topology:In some cases, the solid modeling engine may notdetinesn entity definedin CGM; for example, somesolid modeling engines do not use CoFaces, since theydo not support non-manifold topology. In this case,CGM defines its own representation for CoFaceSMswhich provides the finctions necessary to relate it toother GEs. This is a case where the “tall interface”approach can smooth over differences between solidmodeling engines. Another example ofthis concept istheconstruction ofmultiple GE Surface objects forasingle face in Pro/Engineer topology, this is necessarybecause Pro/Engineer can represent topological faces

having disjoint regions, a topological configurationwhich is not allowed in CGM.

● Persistent objects: Using attributes and the fact thatCGM implements the construction of TEs in solidmodeler-independent code, CGM provides a persistentobjects capability which can easily be ported tomultiple solid modeling engines. This allowspersistence of some topological entities in the CGMmodel even atler these entities are involved ingeometry modification operations like booleans. Forexample, if a body is cut in half, the CGM objectscorresponding to unmodified faces, edges and verticesin the solid modeling engine body are unchanged.This greatly facilitates the process of geometrydecomposition in applications like CUBIT. Thiscapability does depend however on the use ofa~butes in the u~derlying solid modeler and thepersistence of solid modeler objects through theseoperations. This is described in more detailin[18].

Table 4: Procedure for creating CGMTopoIogyEntitys from solid modeling engineentities; items with asterisks are engine-dependent.

> Construct one GE object for each solid modeling1.

2.

3.

4.

engine topological entity in the new BODY(VERTEX, EDGE, COEDGE, etc.)*.Assip double pointers between GE andcorresponding ACIS entity using an owner attribute*.Starting with a BodySM, construct one CGM TEobject for each unique GE object that is part of theBodySM.Link TE objects in CGM topology graph in the sameway the GE objects are linked together.

APPLICATION-SPECIFIC ENTITYDERIVATION AND CREATION

Topology entities in CGM have data and tlmctionsassociated with geometry modeling, like topologyfiurctions, geometric extent data, etc. Embeddinginformation about mesh data or meshing algorithms insideCGM would violate the encapsulation of CGM. In order toadd meshing data and functionality to topology entities,application-specific entities must be derived tlom the CGMentities; these application-specific entities exhibitgeometric modeling behavior and also have the capabilityto store mesh and define meshing al~orithm data. For--example, in CUBIT, this is accomplished by derivingCUBIT-specific classes from each of the child- classes o~RefEntity. These child classes are also given a commonparent class in CUBIT, named MRefEntity, whichcentralizes the mesh data and functions common to alltypes of RefEntitys. This class structure is shown inAppendix A, Figure 5.

J

The creation and deletion of geometric entities in CGM andother geometry modeling packages must be done carefidly,to avoid situations where entities need to be referenced

afier they have already been deleted. Therefore, theconstruction and destruction of topology entities is initiatedin a very specific manner from within CGM. This raisesthe issue of how application-specific entities can be createdwhile still maintaining independence of CGM tlom itsapplications. That is, how does CGM initiate theconstruction of topological entities, when those entities (orat least part of them) are defined in application-specificclasses. This problem is solved by routing the constructionof Topology Entitys through a common entity ~ac~o~,which itself can be derived tlom in an application. Thissoftware construct follows closeIy the Abstract Factorydesign pattern from Ref. [16]. Functions defined inRefEntity are redefined in MRefEntity, such that theyconstruct objects like MRefEdge and MRefFace and returnthem as RefEdge and RefFace, respectively. Theapplication-specific factory is substituted for. the defaultCGM RefEntityFactory by passing it to the initializationfimction for GeometryTool (see [17] for a completedescription of this process). In this way, when CGM callsthe factory function to construct a particular RefEntityobject, it does not need to know whether that factory objectis the default or an application-specific one; either way, theRefEntity gets constructed and passed back to the callingcode in CGM. This is an example of the polymo~hismprinciple in object-oriented programming languages.

ATTRIBUTES

CGM uses attributes like entity groups, merge information,and virtual geometry information to achieve persistence ofgeometric constructs across sessions. This isaccomplished by storing this information directly with thesolid model description, e.g. in the ACIS “sat” file.

Support for arbitrary application-specific attributes isincluded in CGM, and these attributes are passed to thesolid modeling engine (and to CGM for application-specific attributes) in attribute-independent data structures.These data structures include only basic data types (ints,doubles, character strings). This minimizes therequirements placed on the attributes fimctionality in anyparticular solid modeling engine; specifically, solidmodeling engines are only required to provide attributesthat can store data in the form of ints, doubles and characterstrings. All major solid modeling engines (e.g. ACIS,SolidWorks API, Parasolids) provide attributes that meetthese requirements. The design of the CGM attributescapability, and of the various types of attributes used inCUBIT and CGM, are described in a separate paper [18].

Similarly to CGM-defined attributes, applications oftendefine data which is associated directly with geometricentities, and which would be convenient to store directlywith the solid model entities. In CUBIT, information likemesh intervals, mesh schemes, and even mesh itself isassociated directly with geometry objects. Similar to howapplication-specific RefEntity objects are managed, CGMutilizes an abstract factory pattern for the creation ofattributes. A pure virtual base class, namedCubitAttribFactory, is defined in CGM with two purevirtual fiurctions, both named create_cubit_attrib; these

r

,-.-.:.

functions create an application-specific attribute from anattribute type and a simple attribute pointer, respectively,After writing the application-specific attributes, anapplication-specific attribute factory is derived komCubitAttribFactory

Class AppCAFactory :

public CubitAttribFactory

{.”}

Before importing any geometry, the application creates anAppCAFactory and registers it with CGM:

ApplicationCAFac tory *factory .

new ApplicationCAFactoryo ;CubitAttrib ::set_cubit_attrib_factory

(factory);

When CGM imports geometry in which attributes havebeen embedded, it creates the attributes having definitionsinsideCGM; if anyattributesare encounteredwhich donothave definitions inside CGM, and an application-specificattribute factory has been registered, that application-specific factory is asked to create those attributes.

OBSERVERS

The behavior of an application often depends on whathappens to the geometry in the model. For example,CUBITmustknow whenaBodygets deleted, sothatitcarralso delete any mesh on that body. Since many operationswhich modify geometry are initiated within CGM or theunderlying solid modeling engine (e.g. geometry booleans),that means CGM must have a means of notifjingapplications when geometry changes. Similar to attributes,this must be done in a way which maintains theencapsulation of CGM. This notification is accomplishedusing an Observer design pattern [16]. In tlis pattern,application-specific observers “register” themselves withthe entities which they observe (the “observable”). Whenan observable is destructed or otherwise modified, anyregistered observers are notified of the operation.Observers are used to implement entity groups, boundaryconditions, and graphics rendering in CGM and CUBIT,among other things. Again, using a derivationmethodology with associated virtual functions, thesecapabilities are provided in CGM without embedding anyapplication-specific code or data types there.

TOOLDATAS

Various tools often have a need of storing transientinformation associated directly with an entity. Forexample, a tool evaluating local and global constraints forfinding geometry features may need to leave informationabout local constraints directly on topology entities. Thesedata could be stored directly in the TopologyEntity class,however this would waste space when that tool was notoperating, and would violate the encapsulatiofi ofTopologyEntity. To solve this problem we use a datastructure called a ToolData. Various types of ToolDatachild classes are defined by various tools, and are stored ina linked list off of each RefEntity object. Since a linked list

is used, this increases the data size of each entity by onlyone word, no matter how many ToolData objects areassociated with that entity (at the expense of increasedaccess time because of the traversal of the linked list).

CUBIT uses ToolData objects to embed information onTopologyEntitys pertaining to automatic scheme selectiontraversal [20], submapping parameter information [21],vertex and edge types [22], and many other types ofinformation. As an aside, the ToolData construct is alsoquite useful for embedding tool-specific information onmesh objects, where storage space is at an even higherpremium than for geometry.

5. IMPLEMENTATION, OUTSTANDINGISSUES AND FUTURE WORK

CGM grew out of a large body of code extant in CUBIT.Since the isolation of that code in CGM, CUBIT has beenmodified to use CGM without modification of CGM. Thiswas done for many reasons. First, using CGM to supportgeometry needs in CUBIT guarantees support and furtherdevelopment of CGM. More importantly, CUBIT providesa means for testing both the encapsulation and theextensibility features of CGM. Thus, the extensibilityfeatures described in this paper are already working tosupport CUBIT in a production sense. Finally, as CUBITgeometry needs grow, these needs are met, by extendingCGM, which in turn enhances CGM itself.

The current version of CGM is built on the ACLS solidmodeling engine however, CGM also provides a faceted-based representation, as well as virtual geometry. Ports toSolidWorks and Pro/Engineer are underway, and otherports are being considered.

Since CGM grew out of a large body of code already extantin CUBIT, there remains a great deal of code in CGMwhich remains to be “cleaned up”. In addition, there areseveral specific issues which are discussed below andwhich should be addressed:● Entity types: A number of areas of CGM, and of

CUBIT, rely on retrieving an entity type for a givenobject. Since Run Time Type Identification was onlyrecently supported in most C++ compilers, CUBITand CGM embed type information explicitly in thecode. CUBIT type identifiers are still stored in CGM,in enumerated variables and type name strings. To becompletely separable tlom CUBIT, the CUBIT typesshould be removed tiom CGM. This will probably beaccomplished using the C++ language support forRTTI, rather than embedding type information in theCUBIT code.

● Memory space: When linked into an application, theCGM libraries add approximately 50MB to the size ofa static executable; the ACIS libraries account forabout 900/0of this space. Obviously, this is a concern,especially when using CGM on parallel processingmachines or in other memory-limited environments.There are sevqral potential solutions to this problem.First, CGM could be linked with only a facet-based or

:::

.

primitive representation capabili~, however, thiswould remove the capability to represent and evaluateACIS geometry. The other option is to split CGM intoquery-only and non-query-only parts; this would allowapplications to link in only those parts of ACIS theyneed. We estimate that this would reduce the size ofCGM by about 507.. Investigations into bothapproaches are ongoing.

In addition to the porting work addressed above, there isalso ongoing work on applications using CGM. Some ofthis work is described here.● Applications: Several applications besides CUBIT

which use CGM are being developed. The PMESHcode is being re-written based on geometrycapabilities provided by CGM. PMESH is a set oftools used to do user-assisted block-structuredmeshing in a massively parallel computingenvironment [23]. CGM is also being used tointroduce CAD geometry capability to the MCNPXmonte carlo transport code [24]. This will greatlysimplify the construction of particle transport models.This code is used to model neutral and chargedparticle transport in nuclear and medical physicsapplications.

● Parallel mesh generation: Many attempts have beenmade to parallelize the mesh generation process[25][26][27]. In these efforts, the spatial domain isusually decomposed in some way, then meshed, eitherflom the inside out or outside in. Spatial subdomainsare in most cases treated as agglomerations ofelements or other representations. In our work, spatialsubdomains are modeled in the same way as geometricvolumes, differing only in the representation methodunderlying the CGM interface. In the case of parallelmeshing, subdomain geometry will be built using acombination of facet-based and geometric boundaries,depending on whether an interface is artificial (i.e. aninter-processor boundary only) or is in fact a realgeometric boundmy in the domain. In essence, CGMis serving as the basis around which a parallel meshingcapability is being built. This process has beendemonstrated in an earlier effort, before theintroduction of the VGI [28].

● Other representations: In large-deformation transientsolid dynamics, mesh often distorts to a point where itis unsuitable for fisrther analysis. At this point, thedomain must be re-meshed with elements of sufficientquality for further analysis. However, the originaldomain, obtained tlom a CAD system, is no longer thedomain being analyzed; rather the analysis mustcontinue from a deformed geometry. The new meshmust be constructed starting from the deformed mesh,for which there is no CAD description.

The two options available for modeling thesegeometries is to reconstruct a CAD description hornthe deformed elements, or to simply usez$hosedeformed elements as the underlying geometricrepresentation. The latter approach is being used.Because of the common interface provided by CGM,the mesh tools do not need to be modified in any way

to mesh geometry based on this representation.However, care is being taken to provide geometryevaluations with the required level of continuity acrossthe topology entities based on these representations.

One other representation already provided with CGMis that of “virtual geometry”, i.e. composites orpartitions tide above the solid modeling engine level[9]. This capability provides a means fordecomposing or combining topology entities withoutcostly solid modeling operations. It also providesgeome~ through the same CGM interface, someshing tools require no modification to operation onit.

6. CONCLUSIONS

Geometry plays a critical role in applications such as meshgeneration. Despite the availability of APIs to geometricmodeling engines, there remain barriers to porting a givenapplication to multiple engines. Some of these barriersinclude lack of support for non-manifold topology, subtledifferences in the topological models, and support or lackthereof for periodic geometry. This paper describes theCommon Geometry Module, which is a “thick interface” togeomehy that is, it provides both wrapping fimctionswhich access geometry in its native format, as well asgeometry modeling capability which makes slight changesto the underlying solid model (e.g. manifold to non-manifold representation), or more substantial changes (e.g.virtual geometry). CGM provides a means of accessinggeomehy through a common interface, even though thegeometry may be stored in one or multiple representations.

CGM is designed for extensibility, both above and belowthe CGM implementation. Above CGM, applications canderive application-specific geometry entities; this capabilityis used by the CUBIT code to impliment geometry entitieswhich also define meshing algorithms and which can storemesh and meshing algorithm data. Below CGM, differentgeometic representations can be defined, which can beaccessed through the same geometry interface. Thissimplifies the development of alternative representations,e.g. mesh-based or facet-based geometry.

CGM has been demonstrated using an ACIS-basedimplementation; virtual geometry representation is alsoimplemented. The extensibility features of CGM aredemonstrated by implementing the CUBIT mesh generationtoolkit on top of CGM. Ports of CGM to SolidWorks andPro/Engineer are underway. Several new applications basedon CGM are also being developed.

7.

[1]

[2]

[3]

REFERENCES

D.H. Brown, “CAX Modeling APIs Where’s theSubstance?’, 1/9/1998.“ACIS 3D Toolkit”, Spatial Technology Inc.,httu:lAvww.sDatiaI.com/Products/Toolkit/tooIkit.htm.“SolidWorks API”, SolidWorks Corp.,http:/Avww.solidworks.comMml/Productslapi/.

[4]

[5]

[6]

[7]

[8]

[9]

.

“Open I-DEAS”, Structural Dynamics Research Corp.,h~:llwww.sdrc.com/pub/catalo~ideas/oDen-archlopen-ideasl“Parasolid - Powering the Digital Enterprise”, UGSolutions, Inc,htto://www.umohrtions. com/oroducts/mrasolid/“Application Programming Toolkit”, PTC, Inc,htttxlhnvw.vtc. cornlvroductstvroela~~ toolkit.htm“More on the 3D Model Interoperability ProbIem”,Spatial Technology Inc.,httu://wv.spatial. cordProducts/healing&translation/healing&translation4 .htmT. D. Blacker et al., ‘CUBIT mesh generationenvironment, Vol. 1: User’s manual’, SAND94-1 100,Sandia National Laboratories, Albuquerque, NewMexico, May 1994.Jason Kraftcheck, “Virtual Geometry”, Master’sThesis, University of Wisconsin-Madison, inpreparation.

[10] David R. White, personal communication, June 2000.[11] Steven J. Owen, David R. White, personal

communication, June 2000.[12] M. S. Shephard, “Meshing environment for geometry-

based analysis”, Int. J. Numer. Meth. Engrg, 47: (l-3)169-190 (2000).

[13] Adnan Bowyer, Stephen Cameron, Graham Jared,Ralph Martin, Alan Middleditch, Malcolm Sabin andJohn Woodwark, “Introducing Djinn: A GeometricInterface for Solid Modeling”, 1995, ISBN 1-874728-08-9, httv:lhww.in~e.comfdiindintro.htm.

[14] Haimes, R., Follen, G., “Computational AnalysisProgramming Interface”, Proceedings of the 6*International Conference on Numerical GridGeneration in Computational Field Simulations, Eds.Cross, Eiseman, Hauser, Soni and Thompson, July1998.

[15] Sikandar Saitldlah, “OLE for Design and ModeIingAn Open Standard for the CAD/CAM/CAE Industry”,Solid Edge -- Unigraphics Solutions,httdhmnv.dmac. ordmarketindPapers/@enStandard/OLE4DMP.htm.

[16] Malcolm Panthaki, Raikanta Sahn, and Walter Gerstle,“An Object-Oriented Vtil Geometry Interface”,Proc. 6* International Meshing Roundtable, SAND97-2399, Sandia National Laboratories, September,1997.

[17] Timothy J. Tautges, “The Common Geometry Module(CGM)”, Sandia National Laboratories report, inpreparation.

[18] Timothy J. Tautges, “Geometry Attributes”, SandiaNational Laboratories report, in preparation.

[19] E. Gamm% R. Helm, “Design Patterns Elements ofReusable Object-Oriented Software”, AddisonWesley, 1994.

[20] David R. White and Timothy J. Tautges, ‘AutomaticScheme Selection for Toolkit Hex Meshing’, Int. J,Numer. Meth. Engr., 49:127-144 (2000).

[21] David R. White, ‘Automated Hexahedral MeshGeneration by Virtual Decomposition, Proc. 5th Int.Meshing Roundtable, SAND96-2301, Sandia NationalLaboratories, Albuquerque, New Mexico, September1996.

[22] J. Shepherd, S. Benzley, S. A. Mitchell, ‘IntervalAssignment for Volumes with Holes, Int. J. Nurner.Meth. Engrg., 49:277-288 (2000).

[23] David D. Hardin, “PMESH: A Massively ParallelMesh Generator”, Lawrence Livermore NationalLaboratory,htto://www.llnLszov/liv comp/meiko/aDus/hardin/hardin.html

[24] ~Hughes, Kenneth J. Adams, Mark B. Chadwick,Jack C. Cornly, Stephanie C. Frankle, John S. Hen-dricks, Robert C. Little, Richard E. Prael, Laurie S.Waters, and Phillip G. Young, Jr., ‘meMCNPWLCSTM Merger Project,” in Topical Meetingon Nuclear Applications of Accelerator Technology,American Nuclear Society Proceed-ings(Albuquerque, NM, November 1997) 213.

[25] Chew-L-Paul; Chrisochoides-Nikos; Sukup-Florian,“Parallel constrained Delaunay meshing”, Trends-in-Unstructured-Mesh-Generation-American-Society-of-MechanicaI-Engineers,-Applied-Mechanics-Division,-AMD.v220 1997, ASME, New York, NY, USA. p 89-96.

[26] deCougny HL, Shephard MS, Ozturan C, “Parallelthree-dimensional mesh generation on distributedmemory MIMD computers”, Engineering WithComputers, 12: (2) 94-1061996.

[27] A. Shostko, R. Lohner, “3-Dimensional UnstructuredGrid Generation”, Int. J. Numer. Meth. Engrg., 38:905-925 (1995).

[28] Randy R. Lober, Timothy J. Tautges, Courtenay T.Vaughan, “Parallel Paving: An Algorithm forGenerating Distributed, Adaptive, All-quadrilateralMeshes on Parallel Computers”, SAND97-0545,Sandia National Laboratories, Albuquerque, NM,March 1997.

. ..

APPENDIX A CGM CLASS DIAGRAMS

FT

................ ........; (xxxSM) :

9

AckBndge........................

i ...... ........................................................................................................ . I I.,. .i ,,I I .f I .(’

.:.

BodyACIS ShellACISLeepACIS CoEdgeACIS“‘i

L ................................. .... .......... .,............... .............. ......................................,, ~.:

r ., I I .,,. I +.IPointACISI lCurveACISl lSurfaceACISl -1

SenseEntiV BasicTopologyEnthy

CoVolume RefVolume

CoFaceI 4

RefFace

CoEdge RefEdge

Figure 3: ACIS-based implementation for lowerlevel geometry entity hierarchy.

“$=GroupingEntity

Body GeometricModelingEngine

V’-PE!EEI+IEE5ZEPShell

m=%=-’ ......................................................~(xxxGeometryEngine)jP 1 I ................ .......................... ...........

k Figure 4: Geometry tool structure with respect tosolid modeling engines.

Figure 1: Core topological classes in CGM.

APPENDIX B: CUBIT CLASS DIAGRAMS

I.............. ............... .

BridgeManager + ................................ (TopolosyEntw) ~..... ...... ... . . .......................

h

MeshToolUser I MeshContainer

7-: ...............................1

I1 I

PointY1l’11’lCurve Surface Lump

PointSM CurveSM SurfaceSM LumPSM

I I

I1’

I . ...... ...................:

I--lE5lI . . ...........................

@@l

J6M ....... ............................!fRefEntityFactory~.................. . ..........

!jx&ij ~ f,“.>..

Figure 2: Geometry entity classes in CGM.Figure 5: Derivation of meshable classes fromRefEntity child classes in CGM (top). Derivationof app~cation-specific entity factory, whichcreates application-specific entities (bottom).

.,