Home > User Guide > Model Management > History and Roll
Preserving Bounding Boxes and Other Lazy Data
Prior to R16, ACIS did not preserve backups of lazy data, which includes bounding boxes, parameter space boxes, and loop type identification, and has simply cleared this data when modeling operations fail or whenever the current state of a model was undone (by rolling delta states or bulletin boards of the history stream). Beginning with R16, a new option preserve_lazy_data has been added to preserve earlier states of lazy data to be reinstated when necessary, thereby eliminating the need to recalculate the data. This new capability can significantly enhance performance in situations where the states of models change often.
Topics include:
History
ACIS has historically not preserved backups of lazy data, which includes bounding boxes, parameter space boxes, and loop type identification, for undo/redo (rollback) purposes. This data has consequently always been recalculated after a history roll operation. The recalculation of this lazy data was presumed to be inexpensive (that is, cheaper to recalculate than to store), and furthermore, roll operations were presumed to be rare occurrences. The mechanism that identifies what needs to be recalculated has changed over the years, and this directly affects the amount of data that needs to be recalculated. Also, the data has generally become more expensive to calculate due to complexity. Finally, roll operations have become more common, mostly because of API_TRIAL_BEGIN/END blocks. These changes have led Spatial to redesign this behavior.
Process and Implementation
Prior to the ACIS 7.0 release, ACIS used the typical entity backup mechanism to assure that a change to the lazy data would be encountered in a roll operation. ACIS did not, however, preserve the original version of the data in the backup, but instead invalidated it (set it to NULL). This caused the entity that was rolled to an earlier state to not have lazy data readily available. The fact that the data had changed was known because of and at the expense of an entity change record (bulletin). The data that would ultimately have to be recalculated had a 1:1 relationship with the entity change bulletins.
Beginning with the ACIS 7.0 release, ACIS discontinued using the entity backup mechanism to denote a lazy data change, and instead cleared all lazy data that was reachable through topological traversal of all entity change bulletins during the roll process (this is the above mentioned "mechanism that identifies what needs to be recalculated"). This reduced the number of change bulletins at the expense of drastically increasing the amount of lazy data recalculations.
Beginning with the ACIS R16 release, ACIS again uses the entity backup mechanism to log changes to lazy data and also preserves the earlier data in the change bulletins. This allows an application to navigate the history stream without any loss of data. If a bounding box was available before an ACIS operation, and if that operation fails or is undone (by rolling or the use of API_NOP_BEGIN/END blocks), the box again becomes available.
As a consequence, some operations create a larger number of entity change records, because they are created as needed when calculating lazy data. If the increase in change bulletins is an issue, a workflow change may be necessary. Force the lazy data calculations (with api_get_body_box) in modeling states during which the entities are created (for example, after restore), or in states where many other changes are occurring (which is typically the case in modeling operations). The merging capabilities of the history stream should then virtually eliminate the overhead of additional backups.
If you use the api_get_modified_faces to determine the face changes of an operation, you may not notice any additional bulletins caused by lazy data calculations because these changes have never been and are not included in the criteria of the modified faces algorithm.
Additionally, the ACIS 7.0 through R15 behavior can be reinstated by disabling the option backup_lazy_data. This option, however, can only be changed once, before any entities are created (this is enforced programmatically). The option should be changed, if needed, directly after starting the modeler.
[Top]
© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.