acis的sat文件格式说明

SAT Format D 7.0 Chapter 2. SAT Save File Format Topic: SAT Save and Restore ACIS can store modeling information in external files, called save files. These files have an open format so that external applications, even those not based on ACIS, can have access to the ACIS geometric model. The basic information needed to understand the ACIS file format (focusing on the reading, or restore, operation), includes the structure of the save file format, how data is encapsulated, the types of data written, and subtypes and references. Save File Types Topic: *SAT Save and Restore ACIS supports two kinds of save files, SAT and SAB, which stand for “Standard ACIS Text” and “Standard ACIS Binary”, respectively. Although one is ASCII text and the other is binary data, the model data information stored in the two formats is identical, so the term SAT file is generally used to refer to either (when no distinction is needed). SAT files are ASCII text files that may be viewed with a simple text editor. A SAT file contains carriage returns, white space and other formatting that makes it readable to the human eye. A SAT file has a .sat file extension. SAB files cannot be viewed with a simple text editor and are meant for compactness and not for human readability. A SAB file has a .sab file extension. A SAB file uses delimiters between elements and binary tags, without additional formatting. The binary formats supported are: int 4--byte 2s complement (as long). . . . . . . . . . long 4--byte 2s complement. . . . . . . . . double 8--byte IEEE. . . . . . . char 1--byte ASCII. . . . . . . . . SAT Format D 7.0 where “byte” is eight bits, and files are considered to be byte strings. For multi--byte data items, byte order normally just matches that of the processor being used, but a specific order may be imposed by compiling with the preprocessor macro BIG_ENDIAN or LITTLE_ENDIAN defined. Structure of the Save File Topic: SAT Save and Restore A save file contains: D Three-line header D Entity records, representing the bulk of the data D [optional] Marker for begin history data D [optional] Old entity records needed for history and rollback D [optional] Marker for end history data D End marker Beginning with ACIS Release 6.3, it is required that the product ID and units be populated for the file header (using class FileInfo) before you can save a SAT file. Refer to the reference templates for class FileInfo and function api_set_file_info for more information. Reserved Characters in SAT Files Topic: *SAT Save and Restore Several characters have special meaning when found in “unknown entity” string data in ACIS SAT (.sat) files. Therefore, these characters should not be contained in any user string data written to SAT files. This includes string data in attributes, but applies to string data in any unknown entities. Note This only applies to unknown entity string data written to text save files (.sat); binary files (.sab) are not affected. The portion of the ACIS save (.sat) file restore code that processes unknown entities reserves the following special characters (these are discussed elsewhere in this chapter): { An opening (left) curly brace begins a subtype definition. } A closing (right) curly brace terminates a subtype definition. $ A dollar sign indicates a pointer definition. # A pound sign terminates an entity record. SAT Format D 7.0 @ An at sign starts a string record. If these reserved characters are encountered in unknown entity string data when a .sat file is restored (read in), the unknown entity reader will not process the data correctly because these characters are interpreted as special tokens. Because this processing only applies to unknown entities, applications that “know about” entities containing these characters should be able to process the files. However, if the files are shared with other applications, problems may arise. Save File Header Topic: *SAT Save and Restore The first record of the ACIS save file is a header, such as: 712 0 4 0 11 Scheme AIDE 11 ACIS 7.0 NT 24 Mon Apr 09 16:44:18 2001 -1 9.9999999999999995e-007 1e-010 Integer An encoded version number. In the example, this is “712”, which means the. . . . . . . release is major release 7, minor release 1, and point release 2. Integer The total number of saved data records, or zero. If zero, then an end mark is. . . . . . . required. Integer A count of the number of entities in the original entity list that were saved to. . . . . . . the part file. Integer The least significant bit of this number is used to indicate whether or not. . . . . . . history has been saved in this save file. Integer String length for the product string: “11”.. . . . . . . String ID for the product which produced the file: “Scheme AIDE”.. . . . . . . . Integer String length for the ACIS version string: “11”.. . . . . . . String ACIS version which produced the file: “ACIS 7.0 NT”. This may be. . . . . . . . different from the file version and can include the major release number, the minor release number, and the point release number. It also includes the platform on which it was produced. Integer String length for the date string: “24”.. . . . . . . String Date file produced (in C ctime format): “Mon Apr 09 16:44:18 2001”.. . . . . . . . Double Number of millimeters represented by each unit in the model: “--1”.. . . . . . SAT Format D 7.0 Real Value of resabs when the file was produced: “9.9999999999999995e--007”.. . . . . . . . . Real Value of resnor when the file was produced: “1e--10”.. . . . . . . . . Version Numbers Topic: *SAT Save and Restore Spatial has always maintained the concept of a current version (release) number in ACIS, as well as a save version number. The save version allows one to create a SAT save file that can be read by a previous version of ACIS. Beginning with ACIS Release 4.0, the SAT save file format does not change with minor releases, only with major releases. This allows applications that are based upon the same major version of ACIS to exchange data without being concerned about the save version. To provide this interoperability in a simple implementation, ACIS save files have contained a symbol that accurately identified the major version number, but not the minor version. This meant that applications created using the same major version of ACIS would produce compatible save files, regardless of their minor versions. This was accomplished by simply not incrementing the “internal” minor version number between major versions. Beginning with Release 7.0, ACIS will again provide accurate major, minor, and point version numbers, which can be queried using the functions get_major_version, get_minor_version, and get_point_version. To summarize how release numbers and SAT changes are related: D Major release: SAT file changes may be made; significant functionality changes likely; may require significant changes to existing applications D Minor release: No SAT file changes are made; may provide new functionality; may require some minimal changes to existing applications D Point release: Minor changes only (bug fixes) Entity Records Topic: *SAT Save and Restore The header is followed by a sequence of entity records. Each entity record consists of a sequence number (optional), an entity type identifier, the entity data, and a terminator. Pointers between entities are saved as integer index values, with NULL pointers represented by the value --1. ACIS pointer indices are preceded by $ in the SAT file, or by a binary Tag 12 in the SAB file. Top level entities (e.g., body entities) are always the first records in the save file. The rest of the data records are in no particular order. SAT Format D 7.0 Beginning with ACIS Release 7.0, the format of ENTITY and HISTORY_STREAM records has been changed to accommodate the addition of entity IDs. A new integer field has been added to the entity record to hold the entity’s ID. A value of --1 indicates that an ID has not yet been requested for the ENTITY. This is field #2 in any entity record, where the entity type is field #0. A new integer field has been added to history stream records (part of the history data section) to hold the next available entity ID in that stream. This is field #3 in the history stream record, where “history_stream” is the first field. Optional Sequence Numbers Topic: *SAT Save and Restore The indexing of the entity records depends on the active ACIS options when the model was saved. If they are indexed, the indexing is sequential starting at 0. -0 body $1 $2 $-1 $-1 # . . . -25 point $-1 10 0 25 # In this example from a SAT file, “--0” and “--25” are sequence numbers. In the first line, “$1 $2” happen to be pointers to records (not shown) with sequence numbers “--1” and “--2”, respectively. Even when the sequence numbers are not written to the file, they are implied by the order of the records in the file. Pointers to other records correspond to these implied sequence numbers. If sequence numbers are turned off, a record cannot be simply moved or removed from the save file, because this will create invalid index referencing when the file is restored. If sequence numbers are turned on, an entity may be deleted by simply removing its record from the save file. Any references to the removed record’s index become NULL pointers when the file is restored by ACIS. With sequence numbers on, records may also be rearranged within the file. Save Identifier Topic: *SAT Save and Restore A save identifier is unique, reader-friendly string which has a one-to-one correspondence with an ACIS class. For example, “body” is a save identifier for the BODY class, which is derived from ENTITY. ACIS classes perform most of the work associated with reading and writing save files. The restore methods of a given class can make references to the restore methods of other classes. Class names do not appear in the save file, but the save identifiers do. Both class names and save identifiers are contained within the index. SAT Format D 7.0 The save file sometimes strings save identifiers together using a dash (“--”). This often reflects the ACIS class derivation. For example, the save identifiers “plane--surface” have a class derivation consisting of ENTITY, SURFACE, and PLANE. The save identifiers “colour--tsl--attrib” have the class derivation ENTITY, ATTRIB, ATTRIB_TSL, and ATTRIB_COL. Unique save identifier strings are required for private attributes that a developer may create. This is achieved by deriving a private base class from ATTRIB and giving it a unique name. Developers may use any class name for their private attributes, yet the full identifiers are unique in the save file. If the save identifiers are not completely recognized by ACIS, a data structure from just the recognized classes is constructed and restored. The remaining data at the end of the record is remembered so that it is not lost by a later save. For unrecognized classes whose derivation is two or more levels removed from ENTITY, such as classes derived from CURVE, SURFACE, or ATTRIB, the minimum is to create a recognizable data structure so that references to the data structure are correct. For example, if a record from a derived class of ATTRIB is not recognized, an ATTRIB record is created in such a way that the chain of attributes remains connected for the entity owning the unrecognized attribute. Character Sets Supported Topic: *SAT Save and Restore Beginning with ACIS Release 7.0, the SAT file will delimit strings using an @ sign. This allows SAT files to contain and support any character set, including Japanese or graphics characters. For backward compatibility, SAT files with strings that contain SAT delimiters will be modified when being saved in an earlier version. The SAT delimiters in the string will be replaced with underscores. This will insure that the file can be read in earlier versions of ACIS. Entity Encapsulation in a Record Topic: *SAT Save and Restore The data for an entity is encapsulated in the order of its derivation from the basic ENTITY, from left to right. This is in the opposite order of the derivation of the identifier. The data for ENTITY is written first, followed by the data for the class directly derived from ENTITY, continuing down to the leaf class. For readability in the SAT file, each data field is separated by white space: a space, carriage return, or new line. Because it is known that the encapsulation (and derivation) starts from ENTITY, the ENTITY save identifier is not written. In figure 2-1, this is shown in the middle by the empty double quotation marks, (“”). SAT Format D 7.0 identifier data type ntype2type1type n-- type2-- type1 “” data #. . .. . . ENTITY Figure 2-1. Format Entity Record Starting from inside and going out, the ENTITY data is preceded by identifiers and is followed by the data for the identifiers. The identifiers correspond to classes derived directly from ENTITY. This type of encapsulation continues for all class derivations until the leaf class is reached. In figure 2-1 for a SAT file, the class identifiers are separated from one another with dashes, while their data fields are separated with white space. The white space is typically a space, but may also be a new line. The last element of the record is the terminator character (#). Terminator Topic: *SAT Save and Restore The pound sign (#) terminates the entity data in the SAT file. Tag 17 is the terminator in the SAB file. This allows unknown entities and attributes to be read and the start of the next entity to be located. Subtypes and References Topic: *SAT Save and Restore Subtypes are frequently used in a save file in many of the entity records. Subtypes specify in more detail the characteristics of a geometry type. Interpolated curves (intcurve) and spline surfaces (spl_sur) are two of the major geometry types that make extensive use of subtypes. Subtype definitions contain the bulk of the geometry information of a model and generally span numerous lines within a record of a SAT file. The subtype definition can be preceded and followed by other data pertinent to that record, and subtypes can be nested. When a subtype definition is created as part of a record in the save file, it is numbered in an index table starting with 0. Because entity elements within a model often share geometry, the subtype index numbers can be referenced by other entity element records. When a particular record uses a subtype object which has been defined by another record, the latter record simply references the index number of the subtype rather than writing the entire set of data out again. These references are written out as “ref n”. The ref indicates that this particular item has already been written out to the save file. The n stands for the subtype reference number, counting from the beginning of the file. SAT Format D 7.0 All subtype and reference designations are enclosed between subtype_start and subtype_end designators, which are curly braces “{ }” in a SAT file and Tag 15 and Tag 16 in a SAB file. Geometry with Laws Topic: *SAT Save and Restore When a law is used to create geometry, as for curves, surfaces, a wire offsetting, and sweeping, the string denoting the law and any supporting data is saved to the save file. A law is composed of one or more law symbol character strings. The law symbols are very similar to the adaptation of mathematical notation for use in computers. The valid syntax for the character strings is given in the law symbol templates. Laws support nesting of law symbols. Laws are most likely to appear in the save file as part of a curve or surface subtype definition in the form of a lawintcur or a lawsplsur. Typically, the subtype definition starts with generic geometry information. Then the law specific information is presented. The law itself can reference and/or define any number of other model geometric elements and subtypes using law data definitions. Following the law definition and all associated law data in the save file, other common subtype information can appear. End Marker Topic: *SAT Save and Restore The last entity record is followed by End-of-ACIS-data to mark the end of the ACIS save data. End-of-ACIS-data If the history save/restore option is turned on, the Begin--of--ACIS--History--Data and End--of--ACIS--History--Section markers together with old entities are listed before the End-of-ACIS-data marker. History Markers Topic: *SAT Save and Restore When the history save/restore option is turned on, a new section is added to the save file before the End--of--ACIS--data marker. This new section comes immediately after the information pertaining to the entities of the active model. Begin-of-ACIS-History-Data SAT Format D 7.0 The new history section starts with a marker Begin--of--ACIS--History--Data. Everything between this section marker and the End--of--ACIS--History--Section marker obeys the rules of history save. This section of the save file lists entities which may no longer exist at the active state. However, these entities did exist at some point during the creation of the current model and are necessary for roll back and roll forward operations. Entities that were part of pruned branches are not saved. When the history save/restore option is turned on, the End--of--ACIS--History--Section marker immediately follows the history data. Between this marker and the Begin--of--ACIS--data marker are more entity records. These adhere to the entity record structure. End-of-ACIS-History-Section The End--of--ACIS--History--Section marker is followed by the End--of--ACIS--data marker. Class Restore Methods Topic: SAT Save and Restore Every ACIS class that can have information retrieved from a save file typically has a restore method. In most cases, this is either restore_common or restore_data. When the restore methods are documented for a given class, they contain a function prototype, a description, and some pseudo-code to describe the actual data that is retrieved from the SAT file. The pseudo-code can include references to other class restore functions or to other generic functions to handle known data types in the save file. For example, when restoring a cone entity from a save file, the cone::restore_data method references the ellipse::restore_data method as well as the surface::restore_data method. It also references common input functions like read_real and read_logical. Likewise, the ellipse::restore_data method references the common input functions read_position, read_unit_vector, and read_vector. Hence, finding out exactly all of the data associated with a given save identifier may involve tracing through several classes and common input functions. Tracing SAT Data Topic: SAT Save and Restore Using the ACIS online help “index search can speed the interpretation of the information in a SAT file. The index search lists both class names and save identifiers. SAT Format D 7.0 1. Locate the index entry for the save identifier of interest, for example, the class BODY. Follow the index entry to the class information, of which the save identifier is a part. 2. The first three lines of the SAT file contain header information. Parse these lines for information of value, such as the modeling units. For more details about the header, refer to the section Save File Header. 3. For an entity record within the SAT file, read the inner-most save identifier. a. For more details about entity records, refer to the section Entity Records. b. For more details about the save identifiers, refer to the section Save Identifiers. c. For more details about finding the inner--most save identifiers, refer to the section Entity Encapsulation in a Record. 4. Locate the index entry for the save identifier. 5. Follow the index entry for the save identifier to its owning class description in t