15.3 File Formats
The following file formats are used to export spline data from Cubit using Bézier extraction. For most applications, the json file format is preffered. The first section describes the current json format exported by Coreform Cubit. Unfortunely, many of the fields in this format were created adhoc, and there is a good deal of both repeated and deprecated data. The second section describes a new json format that aims to address these deficiencies. This will eventually completely replace the existing format. The last two sections describe the formats for Bézier extraction files for LSDYNA and Exodus, respectively.
15.3.1
15.3.2 The Bézier extraction file format
Change node to contol_point throughout.
Change to storing an array of degrees.
Update dense_coefficient_vectors to just story an array of arrays.
Dropped all references to sparse_coefficient vectors, as they are not used. May add in later when they are implemented and documented.
Update "coeff" to "coefficient".
Update "elem" to "elements".
Drop num_coefficient_vectors, as this is only needed in the sparse case.
Split into 3 high level objects: control_points, elements, and extraction_coefficients.
Rename subdomains to cell_sets.
Remove the block_elem_map key, as this information was already stored in the cell_sets.
The goal is to be relatively space efficient while still being human readable. For example, we use element blocks to avoid repeatedly storing element degree and type for every element in the block. However, to maintain readability, some implicit data is also stored explicitly. For example, the number of control points is implicit due to the length of coordinates, but we still store num_control_points.
Unless otherwise stated, all indexing is 0based and internal to the file.
Unlike the CellSets in the managers the cell_set filed can only encode dim and dim1 cells. However, this should be sufficient as an export format.
15.3.2.1 bezier_extraction_patch
A spline object represented in extracted form.
Name 
 Type 
 Description 
 Example 
 Default 
patch_id 
 NONNEGATIVE INTEGER 
 A unique patch ID. 

 
 SUB OBJECT 
 See linked documentation 

 
 SUB OBJECT 
 See linked documentation 

 
 SUB OBJECT 
 See linked documentation 


15.3.2.2 control_points
Name 
 Type 
 Description 
 Example 
 Default 
is_rational 
 truefalse 
 True if the spline is rational, false if not. 

 
spatial_dimension 
 NONNEGATIVE INTEGER 
 The spatial dimension. 

 
num_control_points 
 NONNEGATIVE INTEGER 
 The number of spline control points. 

 
coordinates 
 [ [ DOUBLE, ... ], ... ] 
 The control point coordiantes. If the spline is rational, these are given in projective space. 


15.3.2.3 elements
Name 
 Type 
 Description 
 Example 
 Default 
num_elements 
 NONNEGATIVE INTEGER 
 The total number of Bezier elements. 

 
num_element_blocks 
 NONNEGATIVE INTEGER 
 The number of element blocks. 

 
element_blocks 
 LIST 
 An array containing the blocks of elements. 

 
vertex_connectivity 
 [ [ INTEGER, ... ], ... ] 
 Maps internal cell indexing to internal vertex indexing. Vertex ordering follows the standard s, then t, then u fastest ordering. Note: These vertex ids are not the control point ids. They correspond to vertices in the underlying Bezier mesh. 

 
cell_sets 
 LIST 
 Encodes cell sets in the patch. 


15.3.2.4 element_blocks
An array containing the blocks of elements.
Name 
 Type 
 Description 
 Example 
 Default 
element_type 
 STRING 
 The type of element "Cube", "Simplex", or "Pyramid". 

 
degree 
 [ NONNEGATIVE INTEGER, ... ] 
 Degree of the Bernstein basis on elements in the block. 

 
num_elements 
 NONNEGATIVE INTEGER 
 Number of elements in this block. 

 
num_control_points 
 NONNEGATIVE INTEGER 
 Number of control_points for each element in this block. 

 
control_point_ids 
 [ [ NONNEGATIVE INTEGER, ... ], ... ] 
 The control point ids that define the elements in this block. 

 
coefficient_vector_ids 
 [ [ NONNEGATIVE INTEGER, ... ], ... ] 
 The coefficient vector ids that define the elements in this block. 


15.3.2.5 cell_sets
Encodes cell sets in the patch.
Name 
 Type 
 Description 
 Example 
 Default 
cell_set_id 
 NONNEGATIVE INTEGER 
 External cell group id. 

 
cell_set_name 
 STRING 
 Name for this cell set. 

 
cells 
 [ [ INTEGER, ... ], ... ] 
 An array of pairs. The first entry of each pair is the internal cell id, and the second is the cell side index. For cubetype cells, the sides are indexed as follows: s=1 : 0 , s=0 : 1 , t=1 : 2 , t=0 : 3 , u=1 : 4 , u=0 : 5 , and 1 denotes the cell interior. 


15.3.2.6 extraction_coefficients
Name 
 Type 
 Description 
 Example 
 Default 
num_dense_blocks 
 NONNEGATIVE INTEGER 
 The number of dense blocks. 

 
dense_blocks 
 LIST 



15.3.2.7 dense_blocks
Name 
 Type 
 Description 
 Example 
 Default 
num_coefficient_vectors 
 NONNEGATIVE INTEGER 


 
vector_length 
 NONNEGATIVE INTEGER 
 The length of each coefficient vector in this block. 

 
coefficient_vectors 
 [ [ DOUBLE, ... ], ... ] 



15.3.3 The Bézier extraction file format
15.3.3.1 Introduction
The support of novel computeraided geometric descriptions forming a potential future basis of isogeometric analysis in ANSYS LSDYNA is discussed in the present document. In particular, the design of a new keyword as well as the structure of the geometry input file meant to replace the current method using the *INCLUDE_TRANSFORM keyword is outlined. It is also aimed to generalize the geometric description as well as to focus on compressed storage in order to enable the run of larger and more complex examples.
The remaining part of the document is structured as follows. The new LSDYNA keyword is introduced in ANSYS LSDYNA keyword. Supported geometry file formats are discussed in Geometry file formats in greater depth.
15.3.3.2 ANSYS LSDYNA keyword
The *IGA_INCLUDE_{OPTION1}_{OPTION2} keyword is introduced to import geometry files to LSDYNA with BEZIER being one of the supported first optional arguments and blank or TRANSFORM as second optional argument, i.e.
Card 1 
 1 
 2 
 3 
 4 
 5 
 6 
 7 
 8 
Variable 
 FILENAME  
Type 
 C 
Card 2 
 1 
 2 
 3 
 4 
 5 
 6 
 7 
 8 
Variable 
 TYPE 
 PID 
 DIM 
 
Type 
 I 
 I 
 I 
 
Default 
 none 
 none 
 none 

Card 3 
 1 
 2 
 3 
 4 
 5 
 6 
 7 
 8 
Variable 
 IDPOFF 
 FCTLEN 
 TRANID 
 
Type 
 I 
 F 
 I 

Variable 
 Description 
FILENAME 
 Name of file to be included 
TYPE 


PID 
 Part ID 
DIM 


DIM 
 Offset patch ID 
IDPOFF 
 Length transformation factor 
FCTLEN 
 Transformation ID 
One file per *IGA_INCLUDE_BEZIER keyword. The file, however, may contain multiple patches with the same part ID and parametric dimension (PID and DIM on Card 2), i.e. section and material. Notably, default section properties may be modified on a patchbypatch basis; e.g., integration rule, number of interpolation elements.
The optional Card 3 contains fields from the INCLUDE_TRANSFORM keyword relevant for geometric entities extended with an offset of patch IDs. The capability to offset patch IDs is important if one wants to include the same file and affinely transform its content to define a new part—
e.g., four tires of a car— or if standard NURBS and Bézier extractionbased geometries are combined within a model.
15.3.3.3 Geometry file formats
The key differences with respect to the previous format are as follows:
Reduced storage: Bézier extraction operators are not stored in their full form henceforth. In what follows, we distinguish between tensor product, nontensorproduct, and mixed elements. A dimensional tensor product element is defined by d local knot vectors. A nontensorproduct element is defined by a set of coefficient vectors essentially representing a row in the Bézier extraction operator. Elements with mixed tensor and nontensorproduct structure, e.g. prism cf. ASCII format may be defined using a combination of local knot and coefficient vectors.
Sorted input: Local knot and coefficient vectors are collected into sorted blocks comprised in a library. Element definitions use local knot and/or coefficient vector identifiers, i.e. pointers to the entries of the library. Furthermore, a coefficient vector may be stored using either the dense or sparse storage formats. Noting that the latter may be beneficial as the element dimension increases but complicate the export of the data, the choice to invoke different storage formats is left to the preprocessor. Assuming, for instance, that tensor product elements are used to define most part of the discretization and nontensorproduct elements occur in the vicinity of a few extraordinary points only, it might be easier to export the data in dense format only.
Format and precision: In order to ensure consistency with the binary input, cf. Binary format, a fixed input format is proposed using (due to the relative indexing) short integers, i.e. , and double precision reals of the form 1PE24.16. Consequently, each line may contain up to ten integers or five reals yielding lines of up to 80 or 120 character long, respectively.
For brevity, local knot vectors are also referred to as coefficient vectors henceforth.
15.3.3.3.1 ASCII format
The following structured input has to be written for each patch separately, i.e.
BLOCK 1  PATCH 
PID, NN, NE, NCV, WFL 

BLOCK 2  NODES 


BLOCK 3  ELEMENTS 





BLOCK 4  COEFFICIENT VECTORS 
NDCVB, NSCVB 










Variable 
 Description 
PID 


NN 


NE 


NCV 


WFL 



 

 
NEB 



 

 

 

 

 

 

 

 

 

 

 

 

 

 


Element and node IDs are local/relative to the patch and therefore are not defined at input. Consequently, there is no need to offset them on the optional Card 3.
A cube may be defined in two and three dimensions (quadrilateral and hexahedron). Simplexes exist in all three dimensions (line, triangle, tetrahedron). A prism is a fivesided polytope defined in three dimensions and bounded by two triangular caps and three rectangular faces.
For the sake of generality, a nontensorproduct cube (ETYPE=1) may also be used to define tensor product cubes (ETYPE=0). This may be useful in case local knot vectors can not be retrieved from Bézier extraction operators in higher dimensions.
15.3.3.3.2 Binary format
In addition to the ASCII format outlined in the previous section, we intend and in most industrial cases prefer to support binary storage of the geometry using the open LSDA format and API developed and maintained by LSTC. Invoking the binary format will further reduce storage requirements, speeding up I/O. The data should be written using the following path: "keyword/[option]/patch[i8.8]/" where "[option]" is either "isoshell" or "isosolid" for two and threedimensional patches, respectively.
15.3.4 The Exodus Bézier extraction file format
This document describes a standard format for exporting Bézier extraction information in the ExodusII file format, v8.03 and newer (simply referred to as the Exodus format for the remainder of this document). We leverage the existing attribute capability in Exodus to output the data needed for Bézier extraction, including control point weights, additional element information, and coefficient vector information. In the following sections, we establish a set of common attribute names used to tag this information.
15.3.4.1 Control point information
Control point information in Bézier extraction is always encoded in homogeneous form. Nodal values, such as spatial coordinates, are always transfered to projective space through a multiplication by their respective weights. The spline control points are written to Exodus in homogeneous form as nodal control points using ex_put_coord. The nodal weights are stored as nodal attribute, bex_weight, as described below.
EX_NODAL  

 Description 
 Control weights associated with the control points 
 Attribute type 
 EX_DOUBLE  
 Array size 
 num_nodes 
In the table above, the (†) symbol indicates that the attribute is optional. If all control weights are one, as is the case for nonrational geometry, this attribute may be omitted. If no bex_weight attribute is specified, the weights are implied to be equal to 1.0.
15.3.4.2 Element information
To explicitly denote Bézier elements, they are named according to established Exodus element names with a BEX_ prefix. It is important to note that Bézier elements diverge from classical Exodus elements in a few important regards.
Bézier elements are not defined by interpolatory nodes as with classical finite elements. To make this distinction clear, we will use num_splines_per_elem to denote the number of global splines that are nonzero over each element in the block.
The Bézier element connectivity stores not only the connectivity into the global node array, but also the connectivity into the list of Coefficient vectors. We will use num_entries_per_elem to denote the total length of the connectivity for each element, rather than num_nodes_per_elem which is commonly used in the Exodus documentation. As a result, we see that num_entries_per_elem = 2 * num_splines_per_elem, where first num_splines_per_elem entries for the element encode the nodal connectivity, while the next num_splines_per_elem encode the coefficient vector connectivity.
 For each block we must encode the Bernstein polynomials that are defined on the elements in the block. We can uniquely define these Bernstein polynomials by specifying a vector of polynomial degrees for each block, as shown in the table below. >>>>>>> 8ea544c0d9 (docs: Fixes to the bexodus filke format spec.)
EX_ELEM_BLOCK
bex_elem_degrees
Description
Polynomial degree of the elements in the block
Attribute Type
EX_INTEGER
Array size
num_deg
Exodus element name 

 num_deg  
BEX_CURVE 
 1 
 1 
BEX_QUAD 
 2 
 2 
BEX_TRIANGLE 
 2 
 1 
BEX_HEX 
 3 
 3 
BEX_TETRA 
 3 
 1 
BEX_WEDGE 
 3 
 2 
Note that the Bézier extraction format does not currently support pyramid elements.
15.3.4.2.1 Node numbering
The node numbering for the Exodus Bézier elements follows an , then , then fastest ordering. While this is a departure from the node ordering traditionally used in Exodus, it is necessary for easily supporting elements with arbitrary polynomial degree. Figure 601 through Figure 605 give examples of this node ordering on quadratic elements.
Figure 606 gives an example of this indexing scheme on a Bézier hexahedron with polynomial degree .
Figure 601: Node ordering for a BEX_CURVE element with degree .
Figure 602: At left: Node ordering for a BEX_QUAD element with degree . At right: Node ordering for a BEX_TRIANGLE element with degree
Figure 603: Node ordering for a BEX_HEX element with degree . From left to right, the figures show the nodes corresponding to slices at , , and , respectively.
Figure 604: Node ordering for a BEX_WEDGE element with degree . From left to right, the figures show the nodes corresponding to slices at at , , and , respectively.
Figure 605: Node ordering for a BEX_TETRA element with degree . From left to right, the figures show the nodes corresponding to slices at at at , , and , respectively.
Figure 606: Node ordering for a BEX_HEX element with degree . From left to right, the figures show the nodes corresponding to slices at at at , , and , respectively.
15.3.4.3 Coefficient vectors
The final set of attributes that must be stored are the extraction operator coefficient vectors. Many Bézier extraction file formats allow for both dense and sparse storage of coefficient vectors. Dense storage entails storing every coefficient vector entry for the extraction operators on multivariate () elements. Sparse storage is an optimization scheme for tensorproduct elements, wherein only the coefficient vectors for univariate extraction operators are stored. The coefficient vectors for tensor product elements can then be computed from the tensor product of these univariate coefficient vectors. As an example, the coefficient vector for a degree BEX_QUAD element
can be computed as the Kronecker product of two univariate coefficient vectors
Currently, only dense coefficient vector storage has been specified for Exodus, but sparse storage will be added in the future. The coefficient vector is stored as an EX_BLOB with name bex_cv_blob Let NDCVB denote the number of dense coefficient vector blocks in the file. The attributes and variables stored on the blob are given in the table below.
EX_BLOB  

 Description 
 Array containing the number of coefficient vectors and coefficient vector lengths for each dense block. 
 Attribute Type 
 EX_INTEGER  
 Array size 
 2 * NDCVB  

 Description 
 Array containing the coefficient vector values 
 Variable Type 
 EX_DOUBLE  
 Array Size 


In the case of an Exodus file with transient data, the bex_dense_cv_blocks variable will always be stored at the first time step time_step=1.
15.3.4.3.1 Examples
In this final section, we supply three simple examples to illustrate how Bézier extraction information is encoded in the Exodus format.
15.3.4.3.1.1 Spline mesh with two elements
In this first example, we save a simple two element Uspline to an Exodus file. The mesh is a simple rectangle composed of two biquadratic elements, and the interelement continuity is one. Using Coreform Cubit, the Exodus file can be generated with the following commands:
reset create surf rect width 2 height 1 move surf 1 x 1 y 0.5 surf 1 size 1 mesh surf 1 uspline surf 1 export uspline 1 exodus ’two_elem_example’
The resulting Uspline surface is shown in figure 607.
Figure 607: Schematic of the simple Uspline surface created by the Coreform Cubit commands shown above. The surface is composed of two biquadratic Bézier elements, and , with continuity between elements. The global control points are shown in red.
Attribute or variable name 
 Value 
xcoord 
 { 2.0, 2.0, 2.0, 1.5, 1.5, 1.5, 0.5, 0.5, 0.5, 0.0, 0.0, 0.0 } 
ycoord 
 { 1.0, 0.5, 0.0, 1.0, 0.5, 0.0, 1.0, 0.5, 0.0, 1.0, 0.5, 0.0 } 
zcoord 
 { 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 } 
Attribute or variable name 
 Value 
elem_type 
 BEX_QUAD 
num_elem_blk 
 2 
num_entries_per_elem 
 18 
bex_elem_degrees 
 { 2, 2 } 
connect 
 { 1, 2, 3, 4, 5, 6, 7, 8, 9, 18, 12, 6, 15, 9, 3, 13, 7, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 16, 10, 4, 17, 11, 5, 14, 8, 2 } 
Attribute or variable name 
 Value 
bex_dense_cv_info 
 {18, 9} 
bex_dense_cv_blocks 
 { 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.5, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 } 
15.3.4.3.1.2 Rational spline mesh with four elements
This example shows just the data entries for a four element mesh of a quarter section of a plate with a hole.
Attribute or variable name 
 Value 
xcoord 
 {1,1.25,1.75,0.92388,1.25,1.75,0.382684,0.56066,0.853553,2,2,2,0,0,0,1,0} 
ycoord 
 {0,0,0,0.382684,0.56066,0.853553,0.92388,1.25,1.75,0,1,2,1,1.25,1.75,2,2} 
zcoord 
 {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 } 
bex_weight 
 { 1, 1, 1, 0.92388, 1, 1, 0.92388, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 } 
Attribute or variable name 
 Value 
elem_type 
 BEX_QUAD 
num_elem_blk 
 4 
num_entries_per_elem 
 18 
bex_elem_degrees 
 { 2, 2 } 
connect 
 { 1, 2, 3, 4, 5, 6, 7, 8, 9, 31, 23, 19, 16, 13, 11, 8, 4, 1, 2, 3, 5, 6, 8, 9, 10, 11, 12, 28, 30, 14, 15, 6, 7, 20, 12, 3, 4, 5, 6, 7, 8, 9, 13, 14, 15, 28, 21, 17, 29, 22, 18, 10, 5, 2, 5, 6, 8, 9, 12, 14, 15, 16, 17, 24, 26, 25, 27, 20, 8, 9, 12, 3 } 
Attribute or variable name 
 Value 
bex_dense_cv_info 
 {31, 9} 
bex_dense_cv_blocks 
 { 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.25 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.50 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 1.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.50, 0.25 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 1.00, 0.50 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.25, 0.00, 0.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.25, 0.50, 0.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.50, 0.00, 0.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.50, 1.00, 0.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00 0.00, 0.00, 0.00, 0.00, 0.00, 0.50, 0.00, 0.00, 0.25 0.00, 0.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00 0.00, 0.00, 0.00, 0.00, 1.00, 0.50, 0.00, 0.50, 0.25 0.00, 0.00, 0.00, 0.50, 0.00, 0.00, 0.25, 0.00, 0.00 0.00, 0.00, 0.00, 0.50, 1.00, 0.00, 0.25, 0.50, 0.00 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.50, 0.00, 0.00 0.00, 0.00, 0.25, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.00, 0.00, 0.25, 0.00, 0.00, 0.50, 0.00, 0.00, 0.00 0.00, 0.00, 0.50, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.00, 0.50, 0.25, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.00, 0.50, 0.25, 0.00, 1.00, 0.50, 0.00, 0.00, 0.00 0.00, 1.00, 0.50, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.25, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.25, 0.00, 0.00, 0.50, 0.00, 0.00, 0.00, 0.00, 0.00 0.25, 0.50, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.25, 0.50, 0.00, 0.50, 1.00, 0.00, 0.00, 0.00, 0.00 0.50, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.50, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 0.00, 0.00 0.50, 1.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 1.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00 } 