ACIS Checker
From DocR23
ACIS Checker
The ACIS checking functionality (or the Checker) is provided to help customers to detect bad or invalid data in their models. ACIS operations may not work on invalid models and operations on invalid models may become ill-defined.
The architecture for which the Checker is designed is that applications will read ACIS data from an outside source (for instance reading a SAT file), and then use the Checker to identify problems within that data. Any invalid entities that are detected should be either discarded or repaired. At the end of the checking process, the application should have a model that is free of any known defects, and ACIS operations can then be called with confidence.
ACIS Checker Operations
| Operation | Description |
|---|---|
| api_check_entity | The standard checker interface. |
| api_check_face api_check_edge | Performs geometric checks only on a face or an edge respectively. They do not perform other checks or check the owned geometry (such as vertices of an edge, or edges, coedges and vertices of a face) of the entity. |
| api_check_entity_ff_ints | Performs the same face-face intersection checks that api_check_entity does at level 70, or when the check_ff_int option is turned on. At the direct interface level, the surface and curve classes have a check() method which can be used to perform geometric checks. |
| api_fix_check_problems | Some of the problems detected by the checker are inconsistencies in ACIS data structures or incorrect derived values. Some of these problems can be corrected by an automatic repair algorithm. This function is provided to perform such repairs when possible. It is not intended to be used as a general healing function. Its purpose is to tidy up minor flaws in data that do not affect the shape or construction of the model, but could cause difficulties when operations are performed using that data. As such, it does not guarantee to correct any particular problem, because it may be that in a particular situation a correction would require significant alterations to be made to the geometry or topology of the model. |
Things You Can Do ...
ACIS Checker Interface
The standard customer interface to the Checker is api_check_entity; or in Scheme, entity:check. The Scheme interface prints any error messages for invalid entities, and creates Scheme entities for each invalid entity. There may be more than one error message for any invalid entity. A BODY with an invalid entity may fail subsequent operations. There are additional, more specific APIs available for particular types of data.
The purpose of api_check_entity means that it is not subject to the standard rules for the behavior of ACIS API functions:
- api_check_entity is not expected to fail (that is, return an unsuccessful outcome), regardless of errors in the input data. Because the purpose of api_check_entity is to detect and report errors in the input data, its algorithms do not work on the input data in the same way as modeling operations. Some types of serious error may cause certain later checks not to be performed.
- As of Release R14, api_check_entity is versioned. When implementing feature-based modeling, versioning allows you to rebuild old parts using previous versions of ACIS algorithms. Although performing checks during a legacy rebuild operation is not usually necessary, versioning ensures that the check results for a given legacy rebuild is maintained as the application is migrated to newer versions of ACIS. Note that this is the only time when a versioned check should be performed. A part for which checking discovers no errors at a particular version is not "valid" for that version. If check errors are reported when the part is checked using the current version, then the part is defective. Operations using any version cannot be relied upon for that part.
