Automatic Recompute
From DocR23
Contents |
The Automatic Update Process
Cellular Topology automatically updates the cell data on a lump at the end of each ACIS API call. With nested API_BEGIN/END blocks, the update occurs at the API_END of the outermost block. At the end of the outermost API_BEGIN/END block, the current bulletin board is examined for any entity changes that cause a change to cell data. If any such changes are discovered, the appropriate cells are invalidated. For example, a coedge that has had a change to its partner pointer causes all cells around that edge to be invalidated.
Because individual cells are invalidated instead of the entirety of cell data on a lump, the update calculation is local instead of global. Only invalidated cells are examined and rebuilt during the update, with the exception of some of the sorting of rebuilt void c-shells into peripheral c-shells, which are global.
If supercells are present on the cell data (via api_ct_expand_cells) at the start of the update computation, they are removed at the beginning of the update but are recalculated before the end. Supercells can speed up global c-shell sorting.
Because invalid cells still point to any c-shells or c-faces not removed during the editing API, the update computation merges and splits cells and c-shells, and calls the related attribute handling routines.
A c-shell is split if its c-faces form more than one c-shell after it is rebuilt; it is merged if c-faces from another c-shell are needed to rebuild it. Similar logic applies to cells. The merging of volumes is not expressed by the cell merging and splitting in the update computation, because it is based only on arranging c-faces. Volume merging is detected and handled using c-face volume attributes (ATTRIB_CFACE_VOL), discussed in Volume Attribute Propagation.
Merging and splitting of the ATTRIB_CELL and ATTRIB_FACECFACE also occurs, but not during the update computation. Both attributes process merging and splitting of their related lumps and faces during any ACIS model editing API. ATTRIB_CELL merging concatenates the cell lists of the two lumps. Splitting distributes any cell data appropriately over the old and new lumps. If one of the lumps being merged has no ATTRIB_CELL but the other does, the merged lump receives an ATTRIB_CELL anyway. This means that a union, for example, between a lump with cell data and a lump without cell data gives the correct cell data update on the resulting lump. The automatic update computation creates c-faces for any faces that have none. ATTRIB_FACECFACE merging removes an ATTRIB_FACECFACE, and splitting creates a new one which replicates the old.
Disabling CT Updates and Invalidation
The automatic update facility may be disabled on a lump-by-lump basis using ATTRIB_CELL::set_auto_update; however, the cell invalidation process still occurs. Turning auto_update off delays automatic cell data updates; turning it back on causes an immediate update calculation. This approach permits suspension of updates during a series of model edits and execution of one update at the end. The same effect is achieved by placing all the edits inside one API_BEGIN/END block.
Both the update and the invalidation process are permanently suspended in an API by setting local variable call_update_from_bb to FALSE before the API_END macro in an API. call_update_from_bb is defined in the API_BEGIN macro, similar to result. If call_update_from_bb is set to FALSE, the bulletin board is not examined to determine the status of the cell data. Using call_update_from_bb in this manner allows a developer to create new API functions that simultaneously edit the model topology and the cellular topology. Editing the cell topology manually may be faster than using the automatic update. For example, a new API function to remove an internal face need only merge the cells on either side of the face as its cell update computation, whereas the automatic update algorithm rebuilds all cells around the remaining edges of the removed face.
Modifying the Behavior of the Recompute Algorithm
| ||
The behavior of the automatic recompute algorithm can be modified using the cell_recompute option. This option affects cell persistence, cell precedence, cell attribute propagation, and the efficiency of recomputing cellular topology after a model changing operation, in particular a Boolean operation. Modifying the behavior is recommended only for users with a thorough understanding of the recompute algorithm because it can lead to corrupted cellular topology data structures.
Invoking the Cellular Topology Checker During CT Compute or Recompute
Cellular Topology contains a cellular topology validity checker. The cellular topology validity checker is invoked when either the cell_compute or cell_recompute Debugging Module is set to DEBUG_DETAILS or DEBUG_ALL. The checker examines the cell data for correct pointers, c-faces, c-shells, c-shell containment, and cells, and prints a report to the debug file. The Direct Interface function for cellular topology checking is: void ct_check_lump_cells(LUMP*). This function should be encased in an API_BEGIN and API_END because bounding boxes may be recalculated. The API level function for cellular topology checking is: api_check_ct. The cellular topology validity checker is invoked by the ACIS Checker.
