Healing Component. Chapter 1.

Transcription

1 Chapter 1. Component Component: * The Component (HEAL), in the heal directory, fixes solid models usually imported from other modeling systems into ACIS in which tolerance problems affect how ACIS interprets the model. HEAL is designed to detect and correct accuracy problems in the geometry of an ACIS model. It is possible to create ACIS models that are not precise enough for ACIS to process. This most often happens when geometry is created in some other modeling system and translated into an ACIS model. Such models may be imprecise due to the inherent numerical limitations of their parent systems, or due to limitations of data transfer through neutral file formats. This imprecision can also result when an ACIS model is created at a different tolerance from the current tolerance settings. This imprecision leads to problems such as geometric errors in entities, gaps between entities, and the absence of connectivity information (topology). Since ACIS is a high precision modeler, it expects all entities to satisfy stringent data integrity checks for the proper functioning of its algorithms. Therefore, if such imprecise models must be processed by an ACIS based system, a healer for such models is necessary to establish the desired precision and accuracy. The Component (HEAL) is designed to detect and correct accuracy problems in the geometry of an ACIS model. HEAL is intended as a foundation on which an application can build a complete healing strategy. The HEAL functionality is available through both a C++ interface (APIs and classes) and a Scheme interface (Scheme extensions). HEAL is not a translator from another modeling system into ACIS the model must already exist in ACIS format (e.g., in a SAT file) before being healed. HEAL may not be able to correct all of the problems that may exist in a model, but it will detect and correct a large percentage of them. HEAL uses aggregate attributes attached to the body and individual attributes attached to the individual entities in the body to control the healing process. These attributes are used to store healing options, tolerances, and results. The attributes are implemented using the ACIS attribute mechanism, with C++ classes derived from the ACIS base attribute class, ATTRIB. The features of HEAL include:

2 Analyzes the input models and suggests appropriate tolerances for healing operations Provides user controllable tolerances for efficient healing Simplifies geometry by converting spline data to analytic data wherever possible Stitches faces together in the absence of connectivity (topology) information Builds geometry to correct the gaps in the model Supports healing of analytic and spline tangent junctions Uses attributes attached to the body to store the information and results for the various healing phases, allowing the HEAL changes of each phase to be reviewed Provides an automatic option for each of the various healing phases, including an autoheal operation that performs all healing operations automatically Allows analyzing individual entities to determine the errors before performing any healing operations Allows converting edges that can t be healed into ACIS tolerant edges Using the Component * The following steps outline the general use of the Component. The individual phases of HEAL are described later in this chapter. 1. Convert the data from the external representation (such as IGES or STEP) into an ACIS model (in a SAT file). This conversion/translation is not part of the HEAL functionality. However, this must be performed before using HEAL, which operates on an ACIS model. 2. Load the ACIS SAT file containing the model to be healed. 3. If necessary based on the nature of the input data, use ACIS to combine multiple entities (solid or wire bodies) into a single solid body. HEAL only heals solid bodies. It does not heal wire bodies. 4. Initialize the body for healing. 5. Preprocess the body to be healed. (Preprocess also performs initialization if it has not already been done.) 6. Use the geometry simplification functionality to convert spline data to analytic. 7. If topology is not present (i.e., the input model is just a set of faces), use the HEAL stitching functionality to stitch (sew) the model into a single ACIS solid body. 8. Use the HEAL geometry building functionality to heal the model s geometry.

3 9. Postprocess the healed body. 10. Terminate the body for healing. Note When using the C++ interface, the healing library must be initialized before using any HEAL functionality and terminated after HEAL operations are complete using the APIs api_initialize_healing and api_terminate_healing. Figure 1-1 illustrates these general steps in healing a model using HEAL.

4 ÑÑÑÑÑÑ Invalid ACIS ÑÑÑÑÑÑ Initialize Data Translator ÑÑÑÑÑÑ Body (SAT file) to ACIS ÑÑÑÑÑÑ ÑÑÑÑÑÑ ÑÑÑÑÑÑ Preprocess ÑÑÑÑÑÑ ÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ Ñ Is ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ Geometry Ñ Ñ Topology No Stitching ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ SimplificationÑ Present Ñ ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ? Ñ Yes ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ Ñ Geometry ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ Ñ Building ÑÑÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑ ÑÑÑ HEAL ÑÑÑ Phases Valid ACIS Model (SAT file) Postprocess Non ACIS Model ÑÑÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑ ÑÑÑÑÑÑÑÑ Terminate ÑÑÑÑÑÑÑÑ Body ÑÑÑÑÑÑÑÑ Figure 1-1. a Model Phases and Stages * The healing process is divided into the following three main healing operations, or phases:

5 Geometry simplification.... Simplifies geometry by converting spline data to analytic data wherever possible. Stitching Stitches together loose faces in the absence of connectivity (topology) information. Geometry building Builds geometry to correct the gaps in the model. This is the phase that actually repairs the bad geometry. Geometry building is further divided into 5 subphases (which must be performed in the order listed): Analytic solver Isospline solver Sharp edge solver Generic spline solver Wrap up Each of these main healing phases and subphases is divided into three stages: Analyze Analyzes the model and sets appropriate tolerances and options for this healing phase. Calculate Calculates the new geometry/topology for this healing phase based on the settings from the analyze stage and stores this new information in attributes attached to the body. Fix Applies (fixes) the new geometry (or topology) resulting from the calculate stage of the healing phase to the model by swapping the geometry/topology stored in the attributes with that of the body (the old information is saved in attributes). For the geometry building phase (and each of its subphases) the calculate and fix stages are combined into one calculate and fix stage. Note The geometry simplification phase and/or the stitching phase and some of the subphases of geometry building may not be needed, depending on the nature of the input data. In addition to the three main phases that perform healing operations (geometry simplification, stitching, and geometry building), HEAL also has phases for initializing, preprocessing, postprocessing, and terminating the body: Body initialization Initializes the body for healing. This attaches the aggregate attributes that will be used by the various healing phases. This phase must be performed before any healing phases (including any analysis).

6 Preprocess Performs initial cleanup of the model to be healed. This phase trims surfaces to the boundary curves of their faces (commonly needed for data translated from IGES) and cleans topology (removes such things from the body as zero length edges, sliver faces, and duplicate vertices). Preprocess attempts to smooth any discontinuous curves and surfaces. Preprocess must be performed before any healing operation (but is not necessary for just the entity analysis operations). Preprocess performs initialization if it was not already done. Postprocess Performs the final cleanup of the healed model. This phase repairs any bad topology created during healing (performs such operations as correction of negative area faces, duplicate vertices, and edge groups). Body termination Terminates the body for healing. This removes the attributes that were used by the various healing phases. This reduces the size of the saved SAT file (many large attributes are created during the healing process). The stages of each main healing phase/subphase can be performed in separate steps, or each healing phase/subphase can be performed in an automatic step that performs each of that phase s stages in sequence. can also be performed in one automatic step, known as automatic healing (autoheal), that performs all the phases/subphases of healing (except termination of the body). Figure 1-2 illustrates the phases, subphases, and stages of the healing process, in the order in which they occur. The automatic step for each phase or subphase is also shown (as is autoheal), illustrating which stages, subphases, or phases are executed by the auto step. The corresponding API is listed along with the name of the phase, subphase, stage, or automatic step. These phases, subphases, and stages are described in further detail elsewhere in this chapter. Note Figure 1-2 does not include all APIs available in HEAL; it only shows those that are used in the main operations. All HEAL APIs are documented in function reference templates.

7 Autoheal api_hh_auto_heal Auto Geometry Simplify api_hh_simplify_auto Auto Stitch api_hh_stitch_auto Auto Geometry Build api_hh_geombuild_auto Auto Analytic api_hh_analytic_auto Auto Isospline api_hh_isospline_auto Auto Sharp Edge api_hh_sharp_edge_auto Auto Generic Spline api_hh_gen_spline_auto Auto Wrap Up api_hh_wrapup_auto Body Initialization Phase api_hh_init_body_for_healing Preprocess Phase api_hh_preprocess Geometry Simplification Phase Analyze Stage api_hh_simplify_analyze Calculate Stage api_hh_simplify_calculate Fix Stage api_hh_simplify_fix Stitching Phase Analyze Stage api_hh_stitch_analyze Calculate Stage api_hh_stitch_calculate Fix Stage api_hh_stitch_fix Geometry Building Phase Analyze Stage api_hh_geombuild_analyze Calculate and Fix Stages api_hh_geombuild_calc_fix Analytic Solver Subphase Analyze Stage api_hh_analytic_analyze Calculate/Fix Stages api_hh_analytic_calc_fix Calculate Stage api_hh_analytic_calculate Isospline Solver Subphase Analyze Stage api_hh_isospline_analyze Calculate/Fix Stages api_hh_isospline_calc_fix Sharp Edge Solver Subphase Analyze Stage api_hh_sharp_edge_analyze Calc/Fix Stages api_hh_sharp_edge_calc_fix Generic Spline Solver Subphase Analyze Stage api_hh_gen_spline_analyze Calc/Fix Stages api_hh_gen_spline_calc_fix Wrap Up Subphase Analyze Stage api_hh_wrapup_analyze Calc/Fix Stages api_hh_wrapup_calc_fix Postprocess Phase api_hh_postprocess Body Termination Phase api_hh_end_body_for_healing Figure 1-2. Phases, Subphases and Stages Stages Each of the three main healing phases (geometry simplification, stitching, and geometry building) is divided into three stages, which are performed sequentially: analyze, calculate, and fix. (The geometry building phase and each of its five subphases have combined calculate and fix stages.)

8 For each phase/subphase, the corresponding analyze stage must be performed first (before the calculate stage). The analyze stage determines what needs to be done, sets some appropriate options, and calculates the recommended tolerance(s) to be used during the calculate stage. The analyze stage sets the corresponding tolerance(s) to this recommended value. Following the analyze stage, if the user believes different tolerance(s) will produce more desirable results, the tolerance(s) can be manually modified before the calculate stage is performed. For some phases/subphases, the analyze stage may determine that no calculate stage is needed, due to the nature of the data (e.g., no stitching may be required for some models). In such cases, the analyze stage sets an appropriate flag that is checked in the calculate stage, thus preventing HEAL from performing unnecessary calculations. The calculate stage calculates the new geometry/topology for each healing phase/subphase based on the settings from the analyze stage and stores this information in attributes attached to the body. Following the calculate stage, the user may review the results and decide whether to apply (fix) the changes to the body, or revise tolerances and perform the calculate stage again. An application can provide a comprehensive user interface to facilitate this process. The fix stage applies (fixes) the new geometry (or topology) resulting from the calculate stage of each healing phase/subphase to the model by swapping the geometry/topology stored in the attributes with that of the body. Thus, the original geometry/topology is retained in the attributes after the fix stage, which allows the user to compare the old and new geometry/topology. Rather than perform each stage of each phase separately, a user (or application) can also execute the automatic step for each phase (which performs each of the stages in that phase), then analyze the results of each phase. If the results are not what was expected, the model can be rolled back to the previous state and that phase of healing can be tried again using different methods or settings. The automatic step for each phase can be executed using the auto APIs, such as api_hh_stitch_auto. The auto APIs execute all the various stages, in the correct order. Preprocess * The preprocess phase performs initial cleanup of the model to be healed. This phase trims surfaces to the boundary curves of their faces (commonly needed for data translated from IGES) and cleans topology (removes such things from the body as zero length edges, sliver faces, and duplicate vertices). Preprocess may also be set (using options) to attempt to smooth discontinuous curves and surfaces. Preprocess must be performed before any healing operation (but is not necessary for just the entity analysis operations). Preprocess performs body initialization if it is needed (and was not already done).

9 Splitting or Smoothing Discontinuous Edges The preprocess phase provides functionality for handling discontinuous edges. This is controlled by the option bhl_smooth_edges. The purpose of this functionality is to improve stitching for those special cases in which the edge curves contain discontinuities. If option bhl_smooth_edges is off, discontinuities are left in. If the option is on, the edges are either split or smoothed, depending on the magnitude of the discontinuity. For any curve discontinuity detected, the angle of discontinuity A is computed. If angle A is less than the tolerance, then the edge is smoothed; else it is split at the discontinuity. The tolerance is not exposed to the application, and is set internally (0.01 radians). During smoothing, the Component reduces the knot multiplicity at the point of discontinuity. Refer to Figure 1-3. A A Edge is split at a sharp discontinuity Edge is smoothed at a marginal discontinuity Figure 1-3. Splitting or Smoothing Edges Surface Smoothing The preprocess phase provides functionality for repairing discontinuous B spline surfaces. This functionality is controlled by the bhl_smooth_surfaces option. The main aim of this utility is to facilitate better operations on the B spline surfaces by smoothing off the small discontinuities that often create problems in several surface operations. The surface smoothing routine uses knot reduction techniques to remove discontinuities. This routine only removes small discontinuities (those in which the angle of discontinuity A is less than a preset tolerance of 0.1 radians). Also, using knot insertions appropriately, the routine guarantees that the new smooth surface does not deviate from the old discontinuous surface by more than a preset tolerance of 0.01 units. Refer to Figure 1-4.

10 Surface with Discontinuity Smoothed Surface A Angle A is Amount of Discontinuity Figure 1-4. Smoothing Surfaces Geometry Simplification * The incoming models often contain surfaces that appear analytic when displayed on a screen, but are actually represented as splines. In the geometry simplification phase, such spline surfaces are converted to corresponding analytic forms (e.g., plane, cone, torus, or sphere) wherever possible. Geometry simplification results in a reduction of data size and speed improvements in geometric operations. This phase should be completed before proceeding with stitching or geometry building, unless it is known that the model contains only analytic data. The analyze stage must be performed before the calculate stage, and will determine if simplification is needed. Several APIs are available for forcing geometry simplification to a specific type of analytic. These APIs are generally intended to be used for standalone geometry simplification, rather than as part of the complete healing process. These API functions should be used with caution, as the distortions introduced may cause the model to not stitch or heal correctly. The APIs are: api_hh_force_simplify_to_plane Fits the best plane to the spline surface of the input face. Replaces the geometry of the face with the calculated plane. api_hh_force_simplify_to_cylinder Fits the best cylinder to the spline surface of the input face. Replaces the geometry of the face with the calculated cylinder.

11 api_hh_force_simplify_to_cone Fits the best cone to the spline surface of the input face. Replaces the geometry of the face with the calculated cone. api_hh_force_simplify_to_sphere Fits the best sphere to the spline surface of the input face. Replaces the geometry of the face with the calculated sphere. api_hh_force_simplify_to_torus Fits the best torus to the spline surface of the input face. Replaces the geometry of the face with the calculated torus. Stitching * Connectivity information (topology) may be missing or incomplete in input models. HEAL s stitching functionality provides a way to stitch or sew separate faces together to make a sheet or manifold solid body that is topologically complete. Stitching essentially involves the pairing of vertices and edges in the data. During stitching, HEAL uses an intelligent stitch algorithm, which involves an optimal pairing of vertices and edges using methods similar to api_stitch. However, HEAL stitches two faces even if the common edges/vertices have only approximately the same geometry, whereas api_stitch requires them to be exact. In addition, some geometry cleaning is simultaneously performed on the stitched data to handle small edges occurring in the body. The stitching functionality has the following characteristics (refer to Figure 1-5): Handles varying gaps Resolves multiple vertices Handles small edges Splits edges appropriately Ensures consistent face normals

12 Figure 1-5. Stitching Matches Vertices and Edges This phase must be completed before proceeding with the geometry building phase, unless it is known that the model contains only a single solid body. The stitching analyze stage must be performed before the calculate stage and will determine if stitching is needed. The stitching phase uses incremental stitching, which takes place in a continuous manner. HEAL attempts to stitch the body together by starting with a small tolerance (the minimum tolerance) and stitching together as many faces as possible. Then, the tolerance is increased by a small amount and as many remaining faces are stitched as possible. At each tolerance value, edges that are smaller than the tolerance are either removed or merged, depending on their relationship to the adjoining edges. This process is continued until the entire set of faces can be stitched together, or the maximum tolerance is reached. Geometry Building * The geometry building phase is the phase that actually heals the gaps (inaccuracies) in the model. It builds geometry as necessary to correct the gaps in the model. In this phase, a series of geometric operations are performed to improve the precision of face, edge, and vertex data. Geometry building essentially removes the gaps between adjacent surfaces by recomputing intersections. It uses ACIS surface surface and curve curve intersection functions to recalculate the bad curves and points in the body.

13 The movement of faces, edges and vertices are thoroughly checked to see that any change to their geometry doesn t distort the model. These checks are in addition to the normal tolerance checks. They are especially useful when the geometry being modified is a part of a sensitive region with tiny features, and when a movement less than tolerance can locally spoil the shape of the model. Surface Intersections The following types of surface intersections may occur: Transverse junctions (intersections) Tangential intersections of analytic surfaces Tangential intersections of spline surfaces Bounding edges of open surfaces In transversal intersections, the geometry gaps are filled by extending the adjoining surfaces and recomputing the surface surface intersections. Refer to Figure 1-6. This handles both analytic and spline transverse junctions. Extended Surface Recomputed Intersection Original Surface Extended Surface Original Surface The surfaces are extended and the intersection is recomputed based on the extended surfaces. Figure 1-6. Transverse Junctions

14 In tangential intersections of analytic surfaces, the surfaces are snapped to each other using linear transformations, including translate, rotate, and scale. The snapping is determined through a graph based solver that is capable of handling cyclic tangencies. The nodes of the graph are the faces, and the arcs of the graph represent the tangent edges. Cycles in the graph are broken by giving preference to surfaces of higher curvature (e.g., cylinders are snapped to planes rather than planes snapped to cylinders). Refer to Figure 1-7. The plane surfaces and the cylindrical surfaces snap together at the bold faced edges, as indicated by the arrows. Figure 1-7. Analytic Surface Tangential Intersection Tangential intersections of spline surfaces in which the intersection curves are along isoparametric lines of the surfaces are corrected via control point modification. Refer to Figure 1-8. Non isoparametric tangential spline intersections are fit with net surfaces.

15 Control points u u v v Control points of the two spline surfaces are modified so that the surfaces intersect. Figure 1-8. Isoparametric Spline Surface Tangential Intersection Subphases Geometry building is divided into five subphases. They must be performed in this order: 1. Analytic solver 2. Isospline solver 3. Sharp edge solver 4. Generic spline solver 5. Wrap up Any subphase except wrap up may be skipped if it is not needed. Wrap up must be performed, because it recomputes any new pcurves. Analytic Solver The analytic solver subphase attempts to heal all edges and vertices shared by analytic surfaces. This operation is designed to satisfy both the G0 and G1 constraints on analytic junctions in a body. The analytic solver first builds a graph of all the analytic tangent junctions, and then solves the graph using the set of liner transformations. After the tangent constraints have been satisfied, all the analytic analytic edge geometry is recomputed by using the ACIS surface surface intersection routines.

16 Isospline Solver The isospline solver (also referred to as the isoparametric spline solver, or uv spline solver) attempts to heal all edges shared by tangential isoparametric surfaces (e.g., the intersection curve is an isoparametric curve of both splines in the intersection). The new edge geometry is defined as the isoparametric edge of one of the surfaces, and the adjoining surface is modified to pass through this edge curve (by knot insertion techniques). G1 Continuity in Isospline The isospline solver subphase uses an algorithm that makes the spline surfaces meeting at an isospline edge G1 continuous. This algorithm is a step toward improving the quality of the healed model in order to increase the success of post healing operations, such as Booleans, blending, shelling etc. Refer to Figure 1-9. A blending operation such as shown here will be possible on the healed part if the spline surfaces across the isospline edge (in bold) are made G1 Spline A Spline B Isospline Junction Made G1 Figure 1-9. G1 Isospline Junction

17 To ensure that an isospline junction in isolation is C1 continuous, HEAL positions the penultimate row of control points of the spline surfaces such that they maintain collinearity across the spline surfaces, and also maintains a certain ratio of distances between the respective control points (determined by the knot vectors of the two spline surfaces). If there is a sequence of isospline junctions connected to each other at the ends, then to maintain C1 continuity across the entire sequence, HEAL maintains the same ratio of distances between control points (normalized with respect to the knot values) across the entire sequence. In cases where four isospline surfaces meet at a vertex (unstable isospline edges), HEAL also attempts to make the twist consistent across all four spline surfaces meeting at the vertex. Only simple isospline junctions (where complete surface boundaries match at the edge) are handled. Isospline junctions with partial boundaries, degenerate triangular patches, and spline/analytic junctions are not handled. In cases where the part contains a cyclic sequence of isospline edges, or contains unstable vertices at which some edges are complete range isospline junctions and the others are not, HEAL may fail to make some of the isospline junctions G1, because it may fail to compute a proper sequence of edges for G1 solving. Sharp Edge Solver The sharp edge solver attempts to heal all edges and vertices that are shared by surfaces that intersect sharply. The geometries of edges that connect two faces are computed by surface surface intersections of the underlying face geometries. The geometries of edges that lie on a single face (open edges) are computed using projection routines. Vertex geometries are also recomputed using curve curve intersectors or projectors. Generic Spline Solver The generic spline solver attempts to heal nonisospline tangential spline junctions, (e.g., the intersection curve is not an isoparametric curve of both splines in the intersection). This subphase uses the standard ACIS net surfaces to fit the spline surface. The surface edge curves are projected onto the adjoining surface (to satisfy G0 continuity). These curves become the boundary curves of the new net surface. The interior grid of curves are computed by linear offsets of the boundary curves in parameter space. The new fitted set of curves defines the net surface. Wrap Up The wrap up subphase recalculates coedge geometry (pcurves on spline surfaces) for all coedges.

18 Tolerances * The analyze stage of each of the various healing phases determines recommended tolerance values to be used. These tolerance values provide good results and optimal performance for most models. However, you may need to change some tolerances for particular models. The tolerances you may want to change include: Geometry simplification tolerance Minimum and maximum stitching tolerances Geometry building tolerances The tolerances are stored in attributes attached to the body. They can be modified in C++ using methods of the attribute classes, or in Scheme using Scheme extensions. HEAL provides a set of callback functions that are called after each analysis stage of the healing process (e.g., after stitch analysis). These callback functions can be used for such things as redefining the default tolerances set by HEAL. Refer to the Scheme file scm_ah.cxx for an implementation example. Geometry Simplification Tolerance The geometry simplification tolerance is the tolerance at which spline surfaces get simplified to analytic surfaces. The geometry simplification code attempts to fit an analytic surface that doesn t deviate from the original spline surface by more than the specified simplification tolerance, and so that the surface normals do not deviate by more than tolerance/10 (radians). If the tolerance is tight (as the default is), only spline surfaces that are exact analytic surfaces get simplified. If the tolerance is loosened, then approximate analytic fits to splines are obtained. In such cases, the gaps between surfaces may increase and healing in subsequent operations may be more difficult. The need for increasing tolerances typically arises when analytic surfaces are output as NUBS surfaces rather than NURBS surfaces. The geometry simplification analyze stage heuristically computes a suitable simplification tolerance, which is stored in attributes. This tolerance can be altered, if necessary, after the analyze stage, but before the calculate stage. The tolerance computation is based on the body box size. The heuristics used by HEAL to determine a suitable tolerance are: If the body box size is less than 0.01, the simplification tolerance is If the body box size is less than 0.1, the simplification tolerance is For greater body box sizes, the simplification tolerance is The default tolerance is (in whatever length units are being used in ACIS), which obtains a very good approximation of analytic surfaces to spline surfaces in most models.

19 Stitching Tolerances The minimum and maximum stitching tolerances specify the range in which stitching between edges is performed. The stitching begins from the minimum tolerance and increases in steps towards the maximum tolerance. Stitching is performed at incremental steps in between the minimum and the maximum tolerance. A logarithmic step is used, so a large range of tolerances is covered during the stitching process. For example, a possible sequence of steps could be , , 0.01, 0.025, 0.05, 0.075, 0.1, At every step, a pair of edges can get stitched if the curves of two edges are distant by less than the current stitch tolerance. To avoid stitching of relatively large gaps between small faces, local tolerances are calculated and set for each edge based on the box of the underlying face and the edge length. Considering edge length during computation of local stitch tolerance also prevents incorrect stitching of small edges that are separated by a distance of the same order as their edge lengths. The local tolerance acts as a clip on the current stitch tolerance, so that edges that are separated by more than the local tolerance never get stitched. Every decision about whether to pair two edges for stitching is made based on whether the two edges lie close to each other within a proximity of tol which is computed as the minimum of the current stitch tolerance and the local stitch tolerance as follows: tol = min (current_stitch_tol, local_stitch_tol) where The current stitch tolerance, current_stitch_tol, increases from the minimum stitch tolerance to the maximum stitch tolerance logarithmically, as previously described. The local stitch tolerance, local_stitch_tol, is the minimum of the edge tolerance (edge_tol) and the face box tolerance (face_box_tol). The edge tolerance is: edge_tol = min_edge length / edge_length_factor The face box tolerance is: face_box_tol = box_size / box_tol_factor The value box_size is the minimum of the lengths of the diagonals of the face boxes of the two adjoining faces. The factors edge_length_factor and box_tol_factor are heuristically computed values obtained after testing with a large number cases. These two values are not exposed and are only used internally by HEAL. Minimum Stitch Tolerance Value

20 The minimum tolerance specifies the tolerance at which stitching commences. Therefore, this should be sufficiently low so as to stitch very small edges. At each tolerance step, only the edges whose length is greater than the minimum tolerance are stitched. Therefore, the minimum tolerance must always be smaller than the length of the smallest edge in the model. (This ensures that all edges stitched are greater than the minimum tolerance.) However, if the minimum tolerance is further reduced, it may create spurious small edges that are not intended in modeling, but result due to small overlaps across faces. The minimum stitch tolerance is always set to a default value of 10e 5. Maximum Stitch Tolerance Value The maximum tolerance specifies the point at which stitching stops and therefore needs to be sufficiently large so as to stitch faces with large interface gaps in the body. The maximum stitching tolerance denotes the maximum gap size at which stitching is performed. The maximum tolerance could be reduced to prevent the stitching of gaps in the body that are too large. The maximum stitch tolerance is set to a value based on the body box size: Body Box Size Maximum Tolerance Less than Less than Less than Less than Greater than Geometry Building Tolerances The subphases of the geometry building phase use several tolerances. There are tolerances used by the analytic solver and the spline solvers. The analyze stage of the various geometry building subphases determines the recommended tolerance values to be used. The tolerances are based on the errors present in the incoming geometry. All the individual edges and faces of the incoming model are analyzed for distance errors and angle errors, and the errors are stored in their individual attributes. This stored data is then collectively analyzed and the various healing tolerances (translation tolerance for analytic surfaces, rotation angle tolerance for analytic surfaces, and angle tolerance for classifying tangential spline surfaces) are set. Analytic Solver Tolerances In the process of healing analytic surface geometry, the analytic solver subphase performs surface movements using three shape preserving transformations: translation, rotation and scaling. The analytic solver uses different tolerances for each of these transformations. No analytic surface is transformed by more than the corresponding tolerance value.

21 The units for the analytic translation tolerance and the analytic scaling tolerance are the same as that used for length/distance in ACIS. The analytic rotation tolerance is in radians. Analytic Translation Tolerance The tolerance for translation (also known as analytic tol ) is computed based on the body box size: Body Box Size Translation Tolerance Less than Less than Less than Less than Greater than Analytic Scaling Tolerance The tolerance for scaling (also known as analytic scale tol ) is computed in exactly the same manner as the tolerance for translation: Body Box Size Scaling Tolerance Less than Less than Less than Less than Greater than The amount of scaling is measured as the difference between the original and the final dimensions of the surface concerned. For example, if a cylinder of radius 10.0 is scaled by a factor of 1.001, the final radius will be In that case, HEAL would compare 0.01 ( ) against the scaling tolerance. Analytic Rotation Tolerance The tolerance for rotation (also known as analytic rot tol ) is set to a default value of radians, regardless of the body size. Spline Solver Tolerances Spatial Corp. determined that it is difficult to heuristically come up with a single value that can be used as a tolerance for spline geometry building throughout a given model. Certain parts of a model may have larger errors than the rest. If a high tolerance for geometry building is then used throughout the model, large movements might be allowed everywhere in the model, and certain sensitive regions in the model might get corrupted.

22 Therefore, Spatial decided that the tolerance for spline healing needs to be computed uniquely and locally for every entity being healed, and that the local tolerances should be computed based on the errors in the respective entities. A local edge tolerance and local vertex tolerance are used by the spline solvers. Both tolerances have the same units as that used for length/distance in ACIS. Spatial also determined that there is a need for a facility to be able to put a global upper limit on all the local tolerances for cases in which there is a strong restriction on the amount of surface movement allowed. In general, the local tolerances computed are very reliable. They allow only as much movement of surfaces as required for correcting the error, since the amount of local error itself is used in computing the local tolerances. Therefore, the default value of the upper limit of geometry building tolerance is set to This almost allows the local tolerances to have complete control. However, if a user needs to restrict the upper limit, then the maximum geometry building tolerance value can be reduced to the desired limit. Edge Tolerance The local tolerance for modification of the surface geometry at an edge is computed as the minimum of the maximum geometry building tolerance and the local tolerance: edge_tol = min (max_geombuild_tol, local_tol) where The maximum geometry building tolerance (max_geombuild_tol) is the upper limit on tolerance (user specified or the default value). The local tolerance (local_tol) is the minimum of the face box tolerance (face_box_tol) and the local error tolerance (local_error_tol). The face box tolerance (face_box_tol) is: min_face_box_size / 10 The minimum face box size (min_face_box_size) is the box size of the smaller of the two adjoining faces. The local error tolerance (local_error_tol) is the maximum of the stitch gap tolerance (stitch_gap_tol) and the deviation tolerance (deviation_tol). The stitch gap tolerance is: (stitch gap) x 3.0 The stitch gap is the gap between the edge curves before stitching. The deviation tolerance is: (deviation) x 3.0 The deviation is the maximum distance of the edge curve and the end vertices from the underlying surface (computed by sampling at a few points on the curve).

23 Vertex Tolerance The local tolerance for surface geometry modification at a vertex (e.g., the bending of surfaces to vertices) is computed as the maximum of the edge tolerances (calculated as described in section Edge Tolerance) for all the edges meeting at that vertex. Automatic * The entire healing process may be performed in one operation, called automatic healing (autoheal). Automatic healing determines appropriate tolerances to use in each healing phase/subphase by first analyzing the input model. The steps taken in automatic healing are: 1. Preprocess the body to be healed. 2. Test and simplify any spline surfaces that meet the testing criteria. For each spline surface, if it can be represented by an analytic surface within the simplification tolerance, then replace the spline surface with the appropriate analytic surface (plane, cylinder, etc.). 3. If the input consists of faces, determine a stitching tolerance, and attempt to stitch the faces into either a complete solid or a single sheet body. 4. Analyze and heal the stitched geometry (build geometry to repair the model). 5. Postprocess the healed body. Information about the automatic healing process is returned. This includes such things as statistics of the various healing phases, the results of automatic healing (e.g., whether the model was fully healed, partially healed, stitched only, or if automatic healing failed), and an analysis of the healed model. Autoheal does not terminate the body after healing. This preserves the healing attributes after autoheal, which allows applications to test for unhealed edges, vertices, etc. (Refer to the C++ implementation of the Scheme extensions for examples.) It is recommended that the healing attributes be removed (using HEAL body termination) before saving the healed body to a SAT file.

24 Entity Analysis * HEAL also provides functionality to perform error analysis of specific types of entities in the input body (or all entities in the body) without performing any healing operations. (The body must be initialized for healing before these analyses are performed.) This allows the user (or application) to check the input body to determine if there are any errors before actually performing healing operations. If any errors are found by the tests of these analysis routines, the results of the tests are stored in attributes attached to the bad entities. This information can help the user determine appropriate settings for healing tolerances. Note This entity analysis is the same as the analysis performed by the analyze stage of the various healing phases, but performed separately on individual entity types to provide more control over the analysis. The body and entity analysis APIs include: api_hh_analyze_body Checks the input body for errors and stores results in attributes attached to the bad entities. api_hh_analyze_coedges Checks the coedges of the input body for errors and stores results in attributes attached to the bad coedges. api_hh_analyze_edges Checks the edges of the input body for errors and stores results in attributes attached to the bad edges. api_hh_analyze_faces Checks the faces of the input body for errors and stores results in attributes attached to the bad faces. api_hh_analyze_loops Checks the loops of the input body for errors and stores results in attributes attached to the bad loops. api_hh_analyze_lumps api_hh_analyze_shells Checks the lumps of the input body for errors and stores results in attributes attached to the bad lumps Checks the shells of the input body for errors and stores results in attributes attached to the bad shells. api_hh_analyze_vertices Checks the vertices of the input body for errors and stores results in attributes attached to the bad vertices.

25 The body and entity analysis Scheme extensions include: hh:analyze body Checks the input body for errors and stores results in attributes attached to the bad entities. hh:analyze coedge Checks the coedges of the input body for errors and stores results in attributes attached to the bad coedges. hh:analyze edge Checks the edges of the input body for errors and stores results in attributes attached to the bad edges. hh:analyze face Checks the faces of the input body for errors and stores results in attributes attached to the bad faces. hh:analyze loop Checks the loops of the input body for errors and stores results in attributes attached to the bad loops. hh:analyze lump hh:analyze shell hh:analyze vertex Checks the lumps of the input body for errors and stores results in attributes attached to the bad lumps Checks the shells of the input body for errors and stores results in attributes attached to the bad shells Checks the vertices of the input body for errors and stores results in attributes attached to the bad vertices. Refer to the reference templates for each of these APIs and Scheme extensions for information about the tests performed for each type of entity. Tolerant Edges * If HEAL is unable to heal some edges of the model, these edges can be converted to ACIS tolerant edges. These tolerant edges (TEDGEs) allow the body to be used by the tolerant modeling technology of ACIS. Refer to the discussion of tolerant modeling in the Kernel Component Manual and the reference template for the TEDGE class for more information. HEAL provides an API and a Scheme extension for making these tolerant edges:

26 api_hh_make_tolerant Converts unhealed edges to tolerant edges. hh:make tolerant Converts unhealed edges to tolerant edges. C++ Interface * The HEAL C++ interface consists of a set of API functions and a set of attribute classes. The classes also use a variety of C++ structs for defining data structures for storing healing options, tolerances, and results. APIs The HEAL API interface contains APIs for every phase, subphase, and stage of the healing process. It also contains APIs for the auto step of each phase and subphase, as well as a comprehensive API for automatic healing (api_hh_auto_heal). These API functions are described in reference templates in Chapter 3, Functions. Attributes HEAL uses aggregate attributes attached to the body and individual attributes attached to the individual entities in the body to control the healing process. These attributes are used to store healing options, tolerances, and results. The aggregate attributes are attached either during the body initialization phase or by the analyze stage of a given phase/subphase. The individual attributes are attached via the aggregate attribute class methods during the calculate stage. Normally, a developer would only need to be concerned with the aggregate attributes and not with the individual attributes. The attributes are implemented using the ACIS attribute mechanism, with C++ classes derived from the ACIS base attribute class, ATTRIB. A user interface can be supplied by the application to provide access to, and possibly control of, the data in these attributes. The HEAL attribute classes are described in reference templates in Chapter 4, Classes. Aggregate Attributes Aggregate attributes are derived from the class ATTRIB_HH_AGGR and named ATTRIB_HH_AGGR_<something>. They are attached to the body for each of the main healing phases/subphases. These aggregate attributes store information related to the healing phase/subphase, provide methods for setting and querying the data related to the phase, and keep track of the individual attributes pertaining to that phase. They manage the individual attributes via methods. Aggregate attributes are attached to the body during the body initialization phase, but are used extensively during the analyze stage of each phase.

27 Individual Entity Attributes The individual attributes are derived from the class ATTRIB_HH_ENT and are named ATTRIB_HH_ENT_<something>. They are attached to entities in the calculate stages and store entity specific information relating to each phase. For example, in the geometry simplification phase, the individual entity would be a face whose attribute contains a pointer to the simplified surface. In the stitching phase, the individual entity would be an edge whose attribute contains the edge pairing information. The individual attributes can also be used to mark specific entities to be left unchanged by the healing process. Fields are available in the individual entity attributes to record changes of geometry and topology during the healing process. The description of the changes is stored as text in the attribute so that users are able to directly read the log of modifications made to each entity. APIs api_hh_store_entity_details and api_hh_get_entity_details can be used to access the history of the events that every entity undergoes during healing. Information related to the modifications to surfaces and curves is recorded in entity attributes on faces and edges respectively. Attribute Class Derivation Figure 1-10 illustrates the derivation of the HEAL attribute classes. The attribute classes shown in bold are the only classes that are directly used and can be instantiated. All other HEAL attribute classes are base classes and cannot be instantiated.

28 ATTRIB (ACIS base attribute class) ATTRIB_HH ATTRIB_HH_AGGR ATTRIB_HH_AGGR_SIMPLIFY_BASE ATTRIB_HH_AGGR_SIMPLIFY ATTRIB_HH_AGGR_STITCH_BASE ATTRIB_HH_AGGR_STITCH ATTRIB_HH_AGGR_GEOMBUILD_BASE ATTRIB_HH_AGGR_GEOMBUILD ATTRIB_HH_AGGR_ANALYTIC ATTRIB_HH_AGGR_ISOSPLINE ATTRIB_HH_AGGR_SHARP_EDGE ATTRIB_HH_AGGR_GEN_SPLINE ATTRIB_HH_AGGR_WRAPUP ATTRIB_HH_ENT ATTRIB_HH_ENT_SIMPLIFY_BASE ATTRIB_HH_ENT_SIMPLIFY_FACE ATTRIB_HH_ENT_STITCH_BASE ATTRIB_HH_ENT_STITCH_EDGE ATTRIB_HH_ENT_GEOMBUILD_BASE ATTRIB_HH_ENT_GEOMBUILD_FACE ATTRIB_HH_ENT_GEOMBUILD_EDGE ATTRIB_HH_ENT_GEOMBUILD_COEDGE ATTRIB_HH_ENT_GEOMBUILD_VERTEX ATTRIB_HH_ENT_GEOMBUILD_LOOP ATTRIB_HH_ENT_GEOMBUILD_LUMP ATTRIB_HH_ENT_GEOMBUILD_SHELL ATTRIB_HH_ENT_GEOMBUILD_CURVE ATTRIB_HH_ENT_GEOMBUILD_PCURVE ATTRIB_HH_ENT_GEOMBUILD_SURFACE Figure Component Attributes

29 Structures Some of the data members and methods defined in HEAL classes use variables defined as C++ structures (using the keyword struct). These structures may hold such information as options, tolerances, or results of the various healing phases. For example, the aggregate attribute class for the geometry building phase (ATTRIB_HH_AGGR_GEOMBUILD ) contains several data members defined using structures, such as hh_geombuild_options, which is used to store options for the geometry building phase, and bhl_geometry_results, which stores the results of geometry building. In some cases, the classes contain methods to set and query this structure data, but in some cases, the structure must be used directly to access the data. The structures are documented in Appendix D, Structure Definitions. Scheme Interface * The HEAL Scheme interface consists of a set of Scheme extensions for performing the various healing phases, as well as extensions for setting the various healing tolerances. The Scheme interface does not contain extensions for separately performing every stage of every phase. However, there are Scheme extensions for performing a variety of analyses on the body, as well as extensions for performing the automatic step of each healing phase and a Scheme extension for performing autoheal. The HEAL Scheme interface also contains a complete set of Scheme extensions for graphically displaying the results of the various analyses that are performed by highlighting such things as bad edges, degenerate curves, simplified faces, etc. Limitations * Imperfections in ACIS models can arise due to various reasons. Many of these occur during conversion of legacy surface/solid data to ACIS format. It is not feasible to have a single healing algorithm that will handle all types of imperfections, but the the ACIS healer has incorporated solutions to the most frequently occurring problems. This section outlines some of the current limitations of HEAL. Geometry Simplification Simplification of splines to analytic forms works for planes, cylinders, circular cones, tori, and spheres. No spline surfaces are simplified to a non circular cone.