2021.11

### 14Cubit Workflows

Here we provide a number of suggested workflows based on the capabilities within Coreform Cubit™ including:

#### 14.1Building U-spline lattices

The principal entry point to the lattice structure capabilities in Coreform Cubit™ is the build uspline lattice command, which as a minimum will reference an existing U-spline as the embedding mesh and a reference cell tessellation.

This command will build and slice a lattice structure subject to user input parameters, and will output slice data in a .cli file format that can be used for printing.

Additionally, Coreform Cubit can output visualization files of a lattice structure in either a OBJ or VTK file format.

##### 14.1.1Basic lattice workflow

A valid volumetric U-spline parameterization of the desired embedding mesh must exist in the session and be fitted to the source CAD model prior to running the build uspline lattice command. For information on building volumetric U-splines, see Building U-spline volumes.

The basic steps to build and fit a U-spline mesh in Coreform Cubit are:

• Create or import volume geometry

• Mesh the volume(s) using the sweep mesh scheme

• Create the U-spline by running the build uspline command, i.e.

build uspline volume <volume_id> as <uspline_id>

• Fit the U-spline mesh to the CAD by running the fit uspline command, i.e.

fit uspline <uspline_id>

A volumetric U-spline can only be built from a swept mesh, so it may be necessary to defeature or partition the geometry to allow it to be meshed using the Cubit sweep scheme. See Basic CAD to U-spline workflow for more information.

The U-spline embedding mesh should be oriented so that the desired slice direction lines up with the $z$ coordinate direction, which is the slice direction used by Cubit.

For the purposes of this guide we will consider the cylinder shown in figure 546 as the embedding mesh. Both the cylinder volume and the corresponding U-spline have an ID of 1.

Figure 546: Cylinder mesh (left) and the corresponding U-spline mesh (right)

Coreform Cubit includes resource files for four reference cell types that may be used to build and slice lattice structures. The included reference cell types are jack, octettruss, truncated sphere, and pvb. These reference cells each have a 10 percent volume ratio.

Figure 547 shows the geometry of Cubit’s included lattice reference cells.

Figure 547: Included reference cell types are (in image order): jack, octettruss, truncated sphere, and pvb.

Once a U-spline mesh has been created, it may be used as the embedding mesh to create a lattice with any of the included reference cell tessellations.

For example, to build, slice, and visualize a lattice with the octet truss reference cell embedded in the cylinder mesh with a spline ID of 1, the command would be:

build uspline lattice uc "octettruss" base spline id 1 filename for vtk vis "cylinder.vtk"

Figure 548 shows the resulting lattice, visualized in Paraview.

Figure 548: A U-spline lattice composed of the octettruss reference cell embedded in a cylindrical mesh.

The slice file will have the format gcls_cli_output_(timestamp).cli and will be written to the current working directory.

The visualization file will also be written to the current working directory.

The valid string parameters to define the keyword uc are documented in Lattice GC command reference.

##### 14.1.2User-defined reference cells

User-defined reference cells can also be used to build lattice structures in Coreform Cubit. This is accomplished by creating reference cell geometry, reducing it to its fundamental unit, and symmetrically tesselating the fundamental unit surfaces. The resulting tesselation data in JSON form constitutes the reference cell input needed for the workflow described above. The process for creating user-defined reference cell data is described below.

##### 14.1.2.1Creating reference cells in Coreform Cubit

Coreform Cubit provides several useful commands for creating user-defined reference cells. The suggested process is illustrated below for creating a circular cross-section modification of the jack reference cell.

1. Create geometry The first step in creating a user-defined reference cell tessellation is to create the geometry, either directly in Coreform Cubit or by importing from some other source.

The valid domain for the reference cell geometry is defined as an axis-aligned box that extends from -0.5 to 0.5 in each coordinate direction. The reference cell geometry must not extend outside this bounding box, and some part of the geometry must lie on each face of the bounding box.

As an example, we consider a jack reference cell with a circular cross section. Figure 549 shows the desired geometry and how it fits inside the bounding box.

Figure 549: Top: example of a possible user-defined reference cell, in this case a jack that has been modified with a circular cross section. Bottom: The user-defined reference cell geometry shown in an axis-aligned box that extends from -0.5 to 0.5 in each coordinate direction. The reference cell geometry does not extend beyond the box but does lie on each face of the box.

The geometry must have octahedral symmetry, which is the highest level of symmetry associated with a cube. To build a lattice structure, the reference cell only needs to have this level of symmetry at its boundaries, but for simplicity we enforce octahedral symmetry over the whole cell.

2. Isolate and mesh the fundamental unit Octahedral symmetry allows the reference cell geometry to be compressed or folded down to a fundamental unit, which can be used to recover the original geometry by applying the appropriate reflections and rotations prescribed by the symmetry.

We use this property to guarantee a symmetric tessellation on the surface of the reference cell geometry by folding the geometry down to a fundamental unit, tessellating the surfaces of the unit and then applying the prescribed permutations to the vertices of the tessellation to achieve a symmetric tessellation of the full reference cell geometry.

Once an appropriate geometry for the reference cell has been defined, the fold uspline lattice ref geom command can be used to isolate the surfaces of the fundamental unit of the geometry, e.g.,

fold uspline lattice ref geom volume <volume_id> mesh 0.1.

The command will perform the partitions necessary to isolate the surfaces of the fundamental unit and mesh those surfaces with the specified mesh size. These surfaces will be placed inside a Cubit group titled folded_surfaces.

Figure 550 shows the result of running the above command. Note that the mesh keyword can be omitted if the user does not want the surfaces of the reference cell to be automatically meshed.

Figure 550: The result of folding the jack reference cell.

3. Export tesselation The tessellation of the surfaces of the fundamental unit can be exported to a JSON file format using the export uspline lattice tessellation command, e.g.,

export uspline lattice tessellation group name "folded_surfaces" filename <export_file_path>.

Note that if the name of the group containing the tessellated surfaces has been changed, then the parameter input to the export uspline lattice tessellation command will need to reflect that change.

##### 14.1.2.2Building lattice structures with user-defined reference cells

To build a lattice with the user-defined reference cell that was created in the previous section, the command would look like:

build uspline lattice tess file path <file_path> base spline id 1 filename for vtk vis "cylinder_rounded_jack.vtk"

Figure 551 shows the resulting lattice visualized in Paraview.

Figure 551: A U-spline lattice of the user-defined rounded jack reference cell embedded in a cylindrical mesh.

##### 14.1.3Creating a surface offset

If the slice data for a lattice structure is to be combined with slice data for a solid skin, it is often desirable to offset the outer boundaries of the lattice structure so that the lattice will intersect the solid.

This can be done in Coreform Cubit by offsetting the outer surfaces of the embedding geometry before meshing. The command to offset a surface in Cubit looks like:

create sheet offset from surface <surface_id_list> offset <offset_value>

This can also be done in the GUI interface under Mode/Geometry > Operation/Create Geometry > Entity/Surfaces > Offset.

By interacting with the GUI interface, the user can use the graphics window to select the surfaces from which to create the offset.

To easily select all surfaces that enclose a volume, the user can select one surface in the graphics window, right click to open the context menu, and choose "Select Continuous." In most cases this will automatically select all the surfaces that are connected to the initially-selected surface.

If all the surfaces used to create the offset enclose a volume, then the result of this command will be a new volume, where each surface has been offset from the original volume by the specified distance. An example is shown in figure 552.

The user must then take care to either delete the original volume or be sure to reference the offset volume when running the build lattice command.

Figure 552: Section view of a new volume (outer) created by offsetting the surfaces of the original volume (inner).

#### 14.2Building U-spline meshes for ANSYS LS-DYNA analyses

This section provides a workflow guide for building U-spline meshes in Coreform Cubit™ for use in analyses performed with supporting versions of the ANSYS LS-DYNA explicit dynamics solver.

The process overview is as follows:

##### 14.2.1Automotive preprocessing in Coreform Cubit

This section covers CAD import, geometry cleanup operations, meshing, subdomain creation, geometry partitioning, U-spline construction, and model export.

Dassault Systèmes’ CATIA is one of the predominant CAD modelers in the automotive and aerospace industries. It is based on Dassault’s "Convergence Geometric Modeler" (CGM) geometry kernel.

Coreform Cubit users may experience several issues when working with models exported from CATIA. Details and available solutions are detailed in the sections below.

##### 14.2.1.1.1Stitching single-surface bodies

The primary issue is that CATIA will often export a STEP file in which all the individual surfaces of a part are disconnected. Effectively, what was a single part with 100 surfaces is exported into a STEP model consisting of 100 parts, each with a single surface.

Figure 553 shows such a STEP file opened in Coreform Cubit. Parts (bodies) are distinguished by color automatically. It is evident from the coloration that each surface has been imported as a separate body.

Figure 553: CATIA often exports STEP files of midsurface geometry as many single-surfaced bodies rather than a single many-surfaced body.

For simple models (e.g. a few CATIA parts) the user may find it most convenient to stitch these surfaces together to form a contiguous part. This process is shown in figure 554, figure 555, and figure 556.

The first step is to apply the stitching operation in Cubit by first selecting all the component surfaces of the body to be stitched.

The user may find it useful to use a drag-selection. In Windows, this is done by pressing the ctrl key while left-clicking and dragging to select multiple bodies for stitching.

When using drag-selection the user may want to enable the x-ray option, which selects all objects contained within the selection area regardless of whether they are concealed from present view by other entities. The GUI button for this option is designated by an arrow at the top center of figure 554.

Figure 554: Stitch the component bodies into a single surface by using the stitch operation in Cubit. Using the classic navigation hierarchy in Cubit, this command can be found in numbers 1 - 4 under "Mode/Geometry" > Entity/Volume > Action/Modify > Stitch. The user should then (5) change the selection mode to Body ID(s), select the bodies to stitch together (ctrl-click to select multiple bodies), and then (6) click Apply to execute.

After stitching, the stitched body will be assigned a new entity ID in Cubit, determined by incrementing the largest ID previously occupied by the original multi-body STEP file. That is, as illustrated in figure 555, if a STEP import containing 136 single-surface bodies undergoes a stitching operation to make a single multi-surface body, that resulting multi-surface body will be assigned an entity ID of 137.

Figure 555: The stitch operation destroys the original bodies and creates a new body. The ID assigned to this surface is the next largest ID that was available prior to the stitch operation.

To resimplify the model’s entity IDs, execute compress ids in the Cubit command window. This will re-assign the single stitched body to an ID of 1 and increment from there.

Figure 556: Executing compress ids in the command line compresses all entity IDs to a contiguous list beginning at one.

If the user experiences difficulties with the stitching operation, it can be helpful to add the option no_simplify to the command. It is also sometimes desirable to add a stitching tolerance, taking into account the size of the model.

##### 14.2.1.1.2Dealing with non-analytic spline entities in CAD

As shown in figure 557, another common issue with importing STEP models that were generated by CATIA is that many of the surfaces will be exported as non-analytic, spline entities.

While typically not an issue if the user merely wishes to directly mesh the geometry as-is, this can cause a myriad of issues when performing various operations on the geometry that are common in finite element modeling.

For instance, a common operation is to remove small fillets by extending the surfaces adjoining the fillet, to their intersections — a procedure which we demonstrate in figure 558. When these adjoining surfaces (or the surface to be removed) are spline entities, the standard remove operation will almost always fail to execute.

To resolve this problem, a first course of action is to attempt to convert the spline surfaces to analytic surfaces using the autoheal command, which can be found in the command panel under Mode/Geometry > Entity/Volume > Action/Heal. If the default auto-healing operations do not simplify the offending surfaces, the user can force these simplifications using the healer force command on the individual surfaces.

The healer force command can result in invalid geometry if the surface spline’s parameterization is not close enough to the requested target ACIS surface type, so the user is cautioned to verify the model validity after applying this operation.

While these workarounds are often viable solutions, it is generally preferable to utilize the CATIA CAD Translator add-on, which makes it possible to directly import *.CATPart and *.CATProduct files into Coreform Cubit.

The CATIA CAD Translator effectively replaces two translation steps (CGM > STEP > ACIS) with a single translation step (CGM > ACIS). Additionally, as Dassault is the developer of both geometry kernels involved in this process (CGM and ACIS) as well as the "3DInterop" library utilized by the add-on for CAD translation, this is a very robust procedure that typically results in a high-quality translation.

Figure 557: The STEP file exported from CATIA has many spline surfaces (blue) and curves (red), many of which are numerically equivalent to analytic surfaces (green) and curves (black).

Figure 558: Removing the pink surface, which is an ACIS cylinder surface entity, by extending its adjoining surfaces. The surfaces involved in this operation are the two purple surfaces (ACIS plane), the two yellow surfaces (ACIS cylinder), and the two red surfaces (ACIS plane). One yellow and one red surface are obscured by the view perspective, and are located on the backside of the geometry. At top: Before. The operation is previewed with a blue outline. At bottom: After. Note the extended surfaces.

##### 14.2.1.2Cleanup model geometry (Optional)

In many LS-DYNA analyses, the analyst may be constrained by a minimum allowable stable timestep that must be satisfied. The standard method for controlling stable timestep is to control the minimum element size. In some cases, however, CAD geometry may have features that are smaller than this minimum element size.

In such cases, Cubit’s built-in geometry editing tools can be used to defeature and/or "clean up" the offending geometry.

Geometry cleanup tools may also be required to resolve fitting problems that can arise when U-splines are constructed on composite geometry, as discussed further in Composite Curves.

Tools that users will find particularly valuable in such cases include:

Figure 559: Building a U-spline on a surface with composited bounding curves can result in single low-order elements attempting to fit regions of high local curvature, the effect of which can be seen in the lower left element.

Figure 560: Using the tweak curve remove command to remove small curves can result in a better U-spline fit while avoiding small stable timesteps.

##### 14.2.1.3Modify BREP topology for quality meshing (Optional)

CAD geometry models often contain a large amount of unnecessary topological entities that are a result of the modeling process, but that are not required or even desirable to capture within an analysis.

These additional entities can cause the creation of very small elements, which drive the stable timestep undesirably small, as mentioned in Cleanup model geometry (Optional). Extraneous topology also often involves acute angles which can only be filled with poor quality elements.

In such cases, it is often desirable use Cubit’s real and virtual geometry editing tools to generate a new BREP topology. A representative example case follows.

We begin by performing the real splits shown in figure 561 on two surfaces associated with multiple blend features, such that each split results in two new surfaces that align with their respective blend features.

Figure 561: Split surfaces via the command panel: Mode/Geometry > Entity/Surface > Action/Modify > Split - Through Vertex

After splitting the surfaces, we begin compositing surfaces together into virtual macrosurfaces, as shown in figure 562. Once the macrosurfaces are constructed we assign meshing parameters (i.e. sizing and scheme assignments) onto the surfaces.

Figure 562: Composite surfaces into virtual macrosurfaces via the command panel: Mode/Geometry > Entity/Surface > Action/Modify > Composite

While the suppression of restrictive topological constraints by macrosurfaces can enable highly-regular paved meshes, it can also occasionally result in very distorted meshes. If this occurs, judiciuous application of Cubit’s mesh smoothing functionality can often restore high quality mesh elements on these domains. Figure 564 shows the result of mesh smoothing for an illustrative case.

Finally, while it is beyond the present scope, the reader may be interested in exploring manual mesh refinement within regions of interest, such as refining the elements next to a curve, as demonstrated in figure 565.

Figure 563: Assign the pave mesh scheme: Mode/Mesh > Entity/Surface > Action/Mesh > Pave. We recommend using the Pave > Paver Cleanup > Extend option to minimize extraordinary points in the resulting mesh.

Figure 564: Smoothing a distorted region using the Laplacian smoothing scheme, via the GUI under Mode/Mesh > Entity/Surface > Action/Smooth > Laplacian. By further electing to Include Boundary Nodes we allow these elements the freedom to fully smooth themselves. This option does not always yield desireable results. We also specify a tight tolerance for the smoother via Specify Tolerance > Set Tolerance which sets a global, persistant value. If the user iterates the mesh generation process, they may wish to reset this tolerance when finished with their current smoothing operation so that subseqeunt meshing operations don't perform auto-smoothing to this same tolerance.

Figure 565: Optionally, the user can locally refine the mesh using a quasi-local conforming mesh refinement. In this case, the user has used the GUI tool under Mode/Mesh > Entity/Curve > Action/General Refinement. Equivalent functions also exist for Entity/Volume, Entity/Surface, Entity/Vertex, Entity/Quad, Entity/Edge, Entity/Node.

##### 14.2.1.4Mesh model geometry

Currently Cubit only builds U-splines on all-hex swept volumetric and all-quad surface meshes. Within these constraints, mesh parameter options the analyst may wish to explore include:

• paver size limits { default | [minimum <value>][maximum <value>] }

• paver cleanup {on | extend}

• The default on option leads to a uniformly sized mesh that has a considerable amount of extraordinary points that are typically undesirable for spline meshes as they currently require $C^{0}$ smoothness.

• The extend option attempts to remove many of the extraordinary points which can result in an overall smoother U-spline basis that may be desirable for analysis. However this option often accomplishes this by reducing the element size in some regions.

Figure 566: Comparing the effect of the options for paver cleanup setting. The first image shows the result of the default on option. The second shows the effect of the extend option.

##### 14.2.1.5Create subdomains for *SET_ keywords

After generating the mesh, we create Cubit sideset objects, which can consist of curves and/or surfaces which will later be used by Cubit to export LS-DYNA *SET_NODE_LIST_TITLE keywords. These *SET_NODE_LIST_TITLE keywords can then be referenced by relevant boundary/load conditions in LS-DYNA.

Tools to create and modify sidesets can be found in Cubit under the command panel, Mode/Analysis Groups and Materials > Entity/Sideset > Create sideset and Mode/Analysis Groups and Materials > Entity/Sideset > Modify respectively.

To illustrate, we will create two displacement boundary conditions:

1. An encastre condition along the outer region, as shown in figure 567, of the part that approximates a weld to a significantly stiffer part, and

2. A prescribed displacement on the inner surface, as shown in figure 568, that approximates a weld to a significantly-stiffer part that will press on the surface.

Creating sideset 1, "OuterWeld", with an initial surface selection.Adding the selected curves to sideset 1.

Figure 567: Using the Cubit GUI to create the sideset corresponding to a *BOUNDARY_SPC_SET_ID keyword that will approximate a welded, stiff boundary along the outside of the part. In this case the user has used the command panel tool under Mode/Analysis Groups and Materials > Entity/Sideset > Action/Create sideset.

Figure 568: Using the Cubit GUI to create the sideset corresponding to a *BOUNDARY_PRESCRIBED_MOTION_SET_ID keyword that will approximate a displacement on the selected interior surface. The outer boundary of this surface will need to be set to $C^{0}$ by adding the bounding curve to a Cubit group entitled cf_crease_and_project_entities.

##### 14.2.1.6Partitioning for multiple LS-DYNA parts

It is sometimes desireable to partition a contiguous piece of geometry into multiple parts so that they can be assigned different material or section attributes.

In Coreform Cubit this is accomplished using Cubit entities called blocks. When a U-spline is exported to BEXT format, elements assigned to different blocks are output to different BEXT files, and can be read in by LS-DYNA as different parts.

Tools to create and modify blocks can be found in Cubit under the command panel: Mode/Analysis Groups and Materials > Entity/Blocks > Action/Create and Mode Analysis Groups and Materials > Entity/Blocks > Action/Modify.

Additionally, blocks can be created and examined in the model tree.

Blocks can be created by selecting individual mesh entities (elements, edges etc) or by selecting geometric entities (surfaces, curves). In the latter case, all the elements that lie on the selected geometric entity are assigned to the block in question.

It is not necessary to place every element of a contiguous mesh in a block. All elements not assigned to any block are implicitly grouped together and exported to an additional, separate BEXT file. For details, see Exporting multiple BEXT files.

##### 14.2.1.7Constructing the U-spline

When the initial mesh layout is complete, U-spline construction can begin. A critical initial task is to identify all Bézier interfaces that should be assigned $C^{0}$ continuity, or creased.

Creasing may be required when:

1. the underlying geometry is not smooth, or

2. we wish to apply a Dirichlet boundary condition, either on the interface in question, or on a surface enclosed by a loop of Bézier interfaces, as described in Create subdomains for *SET_ keywords and figure 568

Recall that unlike the Flex Representation Method (FRM) being developed by Coreform, traditional FEA programs apply boundary and load conditions directly on constituent mesh entities such as nodes and element faces. Thus a mesh whose basis functions interpolate the applied condition’s domain is required. This is in stark contrast to FRM, which weakly enforces boundary and load conditions.

To designate Bézier interfaces for creasing, we (1) select the curves that contain the Bézier element interfaces that need to be creased and (2) assign them to a crease group, which the U-spline algorithm in Coreform Cubit automatically consumes as input.

We create the group by executing build uspline crease group in the Cubit command line. This command creates a group called cf_crease_and_project_entities and searches for candidate curves (and vertices) to include in this group.

Alternatively, the user can do this manually, creating the group via the command create group cf_crease_and_project_entities and then manually adding (or removing) entities to the group by selecting them in the model-viewer as we demonstrate in figure 569.

Note that in figure 569 we have selected a loop of curves that bound a surface. That surface is geometrically smooth with its neighboring macrosurface. We have done this because we intend to apply a boundary condition on this surface and, per the previous discussion, need a $C^{0}$ interface along this surface’s boundary.

Figure 569: Creating the "cf_crease_and_project_entities" group in the GUI via: Mode/Geometry > Entity/Group > Action/Create > Group

Once this group has been created we proceed with building the U-spline on the mesh.

U-spline construction is currently accomplished via commands in the Cubit command window; no GUI components have yet been implemented for this functionality.

The relevant U-spline construction commands are

*set uspline {([volume <ids>]) ([surface <ids>]) ([curve <ids>])|default} [degree <degree>] [continuity <default continuity>] [creasing {full|minimal}]*

[build] uspline ([volume <ids>]) ([surface <ids>]) ([curve <ids>]) [optimized for timestep] [as <id>]

fit uspline <uspline id> [tessellation tol <tessellation multiplier>]

In the present case we create a quadratic surface U-spline with maximal continuity via:

set uspline surface all degree 2 continuity 1 creasing minimal build uspline surface all as 1 fit uspline 1

##### 14.2.1.8Exporting U-splines for use in LS-DYNA

After successful U-spline construction, the draw uspline on command will draw the U-spline to the model viewer, allowing users to interrogate the model to ensure its validity.

In some cases the user may identify poorly-fitted regions that need a different mesh layout to better support a good fit, in which case the user should run the uspline removal command to delete the U-spline object, after which they may remesh the model and build a new U-spline, iterating as needed:

remove uspline <uspline_ids>

After building the U-spline to satisfaction, we export it in the BEXT file format via another command:

export uspline <uspline_id> bext <"file_name_prefix"> dyna_cards

In the present case, we use:

export uspline 1 bext "simple_bracket_uspline" dyna_cards

The format of the exported BEXT file is shown in figure 570. It must be free of the comment insertions found in standard BEXT files.

Figure 570: Contents of simple_bracket_uspline.bext
 B E X T 2.0 0    2871    2239   19033       0 -11.00000000000001      -35.00264458164452       13.96147476940812                       1 -10.98702419677929      -39.50256254533454       13.56564500262226                       1 -10.99132564419304      -36.78669777748533       18.32421352597482                       1 -11      -29.69829914148978       10.72477044502588                       1 .                       .                       .                       . .                       .                       .                       . .                       .                       .                       . -10.86230896627243      -40.52387531296156       17.40648215520376                       1 -50.99999999999999      -310.7935980303177      -38.73917762282269                       1 -50.99999999999997       -316.276877526612      -39.46687932697125                       1 1 1    2239       9       9       2       2 1950    1951    1952    2250    2251    2252    2253    2254    2255 9680    8132    1380   16799   16204   13680   13110    5247    4824 1948    1949    1950    2097    2098    2120    2121    2250    2251 .       .       .       .       .       .       .       .       . .       .       .       .       .       .       .       .       . .       .       .       .       .       .       .       .       . 850     851     853     854     856     857    1349    1351    1353 4011    1831   14806   10570   15832   10711   15105   14072    3598 1       0 19033       9 0                       0                       0                       0                       0 0                       0                       0     0.08124398290165157 0                       0                       0                       0                       0 .                       .                       .                       .                       . .                       .                       .                       .                       . .                       .                       .                       .                       . 0                       0                       0                       0 1                       0                       0                       0                       0 0                       0                       0                       0

The dyna_cards flag causes Cubit to also output an LS-DYNA keyword file that contains the *SET_NODE_LIST_TITLE definitions. This keyword file should have the following general format:

Figure 571: Contents of simple_bracket_uspline_node_sets.k
 *SET_NODE_LIST_TITLE OuterWeld $# sid da1 da2 da3 da4 solver 1 0 0 0 0 MECH$#    nid1      nid2      nid3      nid4      nid5      nid6      nid7      nid8 616       617       618       619       620       621       622       625       626 628       629       631       632       634       635       637       638       640 .         .         .         .         .         .         .         .         . .         .         .         .         .         .         .         .         . *SET_NODE_LIST_TITLE PushRegion $# sid da1 da2 da3 da4 solver 2 0 0 0 0 MECH$#    nid1      nid2      nid3      nid4      nid5      nid6      nid7      nid8 1         4         6         7         8         9        10        11        12 13        14        15        16        17        18        19        20        21 .         .         .         .         .         .         .         .         . .         .         .         .         .         .         .         .         . 213       214       215       216       217       218       219       220

##### 14.2.1.8.1Exporting multiple BEXT files

The export uspline command can accept a list of U-spline IDs, allowing the export of multiple U-splines via the creation of multiple BEXT files. In such cases, the file name prefix specified by the user will be appended with the U-spline ID.

Similarly, when exporting a U-spline whose elements are contained in multiple blocks, the BEXT file name prefix will be appended with _<block id>. Elements not assigned to any block are automatically grouped for export into a BEXT file appended with a block ID of _0.

Thus, when exporting multiple, multi-block U-splines, the resulting BEXT files will be written with the file name <file name prefix><uspline id>_<block id>.bext.

##### 14.2.2Preparing LS-DYNA input

In this section we cover the creation of rigid connections, common node connections, and tied contact, as well as BEXT and input file management.

##### 14.2.2.1Creating boundary conditions

Coreform’s support for the creation of LS-DYNA *SET_NODE_LIST_TITLE keywords derived from Cubit sideset objects is intended to support any LS-DYNA boundary/load conditions that are compatible with *SET_NODE_LIST_TITLE.

To illustrate, we create the two boundary conditions described in Create subdomains for *SET_ keywords and we provide the LS-DYNA keywords in the example below.

Example LS-DYNA Keywords to Define Boundary Conditions
 *BOUNDARY_PRESCRIBED_MOTION_SET_ID $# id heading 0Push_Inner$#    nsid       dof       vad      lcid        sf       vid     death     birth 2         1         2         1        10         01.00000E28       0.0 *BOUNDARY_SPC_SET_ID $# id heading 0Hold_Outer$#    nsid       cid      dofx      dofy      dofz     dofrx     dofry     dofrz 1         0         1         1         1         1         1         1 *DEFINE_CURVE_TITLE Linear_Ramp $# lcid sidr sfa sfo offa offo dattyp lcint 1 0 1.0 1.0 0.0 0.0 0 0$#                a1                  o1 0.0                 0.0 1.0000000000e-04                 1.0 1.0                 1.0

##### 14.2.2.2Creating rigid connections

The LS-DYNA *SET_NODE_LIST_TITLE keywords derived from Cubit sideset objects can also be used to create rigid interpart connections with the keyword *CONSTRAINED_NODAL_RIGID_BODY.

Node sets can be combined using *SET_NODE_ADD, allowing the creation of a nodal rigid body from several node sets. An example of this usage is provided below:

Example LS-DYNA Keywords to define a nodal rigid body doc:simple-bracket-nrb
 $# nsid da1 da2 da3 da4 solver 3 0 0 0 0 MECH$#   nsid1     nsid2     nsid3     nsid4     nsid5     nsid6     nsid7     nsid8 1         2 *CONSTRAINED_NODAL_RIGID_BODY $# pid cid nsid pnode iprt drflag rrflag 100 3$

##### 14.2.2.3Creating common node connections

As described above, when a U-spline whose elements lie in multiple Cubit blocks is exported, the elements that compose each block are exported as separate BEXT patches.

Nodes are written to the BEXT files that correspond to each block that they are associated with. Consequently, nodes that lie on the interface (or near the interface in cases of higher order elements) between blocks will be written to multiple BEXT files.

When BEXT files are read into LS-DYNA, the nodes for each patch are always given a unique node ID, even if those nodes that occupy the same coordinate location.

Without the ability to merge nodes from different BEXT patches, the traditional method of connecting neighboring parts through shared node IDs is not possible.

To facilitate this type of connection, Cubit will output an additional file when exporting a multi-block U-spline to BEXT format when the dyna_cards flag is used. This file has the naming scheme <file_name_prefix><uspline_id>_constrained_nodes.k and will contain a series of *CONSTRAINED_LINEAR_GLOBAL cards that will tie each pair of nodes that represent a single shared node between blocks.

A single *CONSTRAINED_LINEAR_GLOBAL card will constrain two nodes in single degree of freedom, therefore six such cards are necessary to fully constrain two nodes together.

The constrained nodes file can be included in the main analysis input deck, and it will tie together the nodes that have support on the boundary between the parts that represent a partitioned U-spline.

An example of the cards necessary to tie nodes with the IDs 1 and 2 is shown below:

Constraint cards to tie a pair of nodes in all degrees of freedom, breakable
 *CONSTRAINED_LINEAR_GLOBAL $# lcid 1$#     nid       dof     coeff 1         1         1 2         1        -1 *CONSTRAINED_LINEAR_GLOBAL $# lcid 2$#     nid       dof     coeff 1         2         1 2         2        -1 *CONSTRAINED_LINEAR_GLOBAL $# lcid 3$#     nid       dof     coeff 1         3         1 2         3        -1 *CONSTRAINED_LINEAR_GLOBAL $# lcid 4$#     nid       dof     coeff 1         4         1 2         4        -1 *CONSTRAINED_LINEAR_GLOBAL $# lcid 5$#     nid       dof     coeff 1         5         1 2         5        -1 *CONSTRAINED_LINEAR_GLOBAL $# lcid 6$#     nid       dof     coeff 1         6         1 2         6        -1 $A known limitation of this method is that if one or more of the parts that are constrained together is assigned a rigid material model, it will result in an unstable simulation. The cause is currently unkown and will require further development by ANSYS. If the intent of the user is to connect two subsytems through a rigid body connection, this can be accomplished with *CONSTRAINED_NODAL_RIGID_BODY. Additionly, it has been observed that if there are two nodes from different BEXT files that occupy the same coordinate location and are not constrained together, in an analysis these nodes can become tangled and result in highly distorted elements. ##### 14.2.2.4Creating tied contact Tied contact can be enforced between a BEXT shell part and a traditional linear FE solid part using the *TIED_CONTACT_SHELL_EDGE_TO_SURFACE_OFFSET card. ##### 14.2.2.5Including generated files Once nodes and connections have been specified to satisfaction, both the .bext and .k files exported from Coreform Cubit should be included via keywords in the completed LS-DYNA input file, as shown below. The .bext file is included via the *IGA_INCLUDE_BEZIER keyword, while the *INCLUDE keyword is used to include the .k file that contains the *SET_NODE_LIST_TITLE keywords. Also, it is critical that the *SECTION_SHELL element formulation (ELFORM) be set to 201. An example of a completed input file is provided below: Contents of simple_bracket.k, breakable  *KEYWORD$#IGA_INCLUDE_FILE *IGA_INCLUDE_BEZIER $# FILENAME simple_bracket_uspline.bext$#    TYPE       PID       DIM 1         1         2 $#END FILE *INCLUDE simple_bracket_uspline_node_sets.k$#END FILE *CONTROL_TERMINATION $# endtim endcyc dtmin endeng endmas nosol 0.001 0 0.0 0.0 0.0 0 *CONTROL_TIMESTEP$#  dtinit    tssfac      isdo    tslimt     dt2ms      lctm     erode     ms1st 0.0       0.9         3       0.0       0.0         0         0         0 $# dt2msf dt2mslc imscl unused unused rmscl 0.0 0 0 0.0 *DATABASE_BINARY_D3PLOT$#      dt      lcdt      beam     npltc    psetid 1.00000E-5         0         0         0         0 $# ioopt *PART$#                                                                         title Block 1330 $pid sid mid eosid hgid grav adpopt tmid$#     pid     secid       mid     eosid      hgid      grav    adpopt      tmid 1      1330       100         0         0         0         0         0 *SECTION_SHELL $# secid elform shrf nip propt qr/irid icomp setyp 1330 201 1.0 2 1.0 0 0 1$#      t1        t2        t3        t4      nloc     marea      idof    edgset 1.0       1.0       1.0       1.0       0.0       0.0       0.0         0 *MAT_ELASTIC $# mid ro e pr da db not used 1008.05000E-62.07000E10 0.3 0.0 0.0 0.0 *BOUNDARY_PRESCRIBED_MOTION_SET_ID$#      id                                                               heading 0Push_Inner $# nsid dof vad lcid sf vid death birth 2 1 2 1 10 01.00000E28 0.0 *BOUNDARY_SPC_SET_ID$#      id                                                               heading 0Hold_Outer $# nsid cid dofx dofy dofz dofrx dofry dofrz 1 0 1 1 1 1 1 1 *DEFINE_CURVE_TITLE Linear_Ramp$#    lcid      sidr       sfa       sfo      offa      offo    dattyp     lcint 1         0       1.0       1.0       0.0       0.0         0         0 $# a1 o1 0.0 0.0 1.0000000000e-04 1.0 1.0 1.0 *END ##### 14.2.2.6Required file inclusion order for multiple BEXT files When preparing an input deck that includes multiple BEXT files and also makes use of the node set and node constraints files generated by Cubit, BEXT files must be included in a particular order. The correct order is to start with the lowest U-spline ID and block ID, then increment block ID first, then U-spline ID. The following shows an example of the correct ordering of BEXT files: Including multiple BEXT files, breakable  *KEYWORD$#IGA_INCLUDE_FILE *IGA_INCLUDE_BEZIER $# FILENAME example1_2.bext$#    TYPE       PID       DIM 1         1         2 $#IGA_INCLUDE_FILE *IGA_INCLUDE_BEZIER$# FILENAME example1_3.bext $# TYPE PID DIM 1 2 2$#IGA_INCLUDE_FILE *IGA_INCLUDE_BEZIER $# FILENAME example2_0.bext$#    TYPE       PID       DIM 1         3         2 $#IGA_INCLUDE_FILE *IGA_INCLUDE_BEZIER$# FILENAME example2_1.bext \$#    TYPE       PID       DIM 1         4         2

The reason for this ordering is the fact that LS-DYNA will assign node IDs to BEXT control points sequentially as they are read in when initializing the simulation.

When BEXT parts are initialized, they will occupy a block of node IDs starting from the lowest available node ID up to the number of control points in the BEXT files. In order to write out information for node sets and node constraints, Cubit has to make an assumption on the ordering of the BEXT files. If the order which the BEXT files are included in the simulation input deck is not consistent with the assumption made by Cubit as described above, then incorrect or erroneous behavior will most likely be the result when using the node set and constrained nodes files generated by Cubit.

If the user knows that the lowest node ID available when the BEXT parts are initialized is not 0, then this can be compensated for using the node offset option of the export uspline command i.e.

export uspline <uspline_id> bext "<file_name_prefix>" dyna_cards node offset <node offset>

##### 14.2.3Executing ANSYS LS-DYNA

Reference analyses for this documentation were carried out on a development build of LS-DYNA received in August of 2021. The ability to process BEXT files was not a production feature of LS-DYNA at that time, and production software may still lack this capability. Users are encouraged to verify that the version of LS-DYNA being run has the functionality required to process BEXT files. Development builds of LS-DYNA with IGA capabilities can be requested from ANSYS by current ANSYS customers.

##### 14.2.3.1Post-processing

Simulation output files can be visualized in LS-PrePost as shown in figure 572, where we display a fringe plot of displacement in the $x$-direction at the final timestep.

Note that the Bézier elements will be rendered as though they were an element with interpolatory nodes, thus a single quadratic Bézier element will be drawn as though it were a 2 x 2 element. In figure 573, we provide a schematic of how to interpret the rendered mesh in LS-PrePost.

Figure 572: Displaying a fringe-plot of the results at the final timestep of the analysis.

Figure 573: A marked-up image of the IGA results in LS-PrePost. The thin black lines are the actual lines plotted in LS-PrePost and subdivide each Bézier element, whose boundaries have been manually drawn over with thick black lines, into a 2 x 2 partioning. Note that behind each thick line that has been drawn on the Bézier element boundaries, there is a thin black line. U-spline control points are rendered as small white dots, over which a large white dot has been manually drawn to assist with visualizing in this figure.

#### 14.3Initial set of ANSYS LS-DYNA keywords that support LS-DYNA BEXT input

It should be noted that the keywords listed below have been tested on a development version of LS-DYNA that includes funtionality for IGA and BEXT. Standard production versions of LS-DYNA may not have the same functionality.

• Coincident nodes In LS-DYNA, it is possible to connect adjacent parts by merging coincident nodes so that they have the same node ID. This is a practice common among our automotive customers to connect adjacent parts of a continuous geometry that has been partitioned into multiple analysis parts, for the purpose of assigning different material models and/or section parameters (thickness etc).

Under the current BEXT file format, the control points of the Bézier patch are listed in an array, and they are assigned node IDs by LS-DYNA when they are read into the analysis. As a result, all the control points from BEXT files will have a unique node ID and there is currently no structure to signify that any two control points from different BEXT files should be merged. Thus it is not possible to force parts derived from different BEXT files to share a common node ID.

One workaround is to use *CONSTRAINED_LINEAR_GLOBAL, which can be used to tie together the displacement of any two nodes.

It has been observed, however, that the use of *CONSTRAINED_LINEAR_GLOBAL can produce an invalid simulation if any of the nodes involved belong to a part to which a rigid material model has be applied.

• Coincident node tangling It has been observed that if there are two BEXT nodes that are coincident but not constrained together, that they can become tangled and cause excessive deformation in adjacent elements.

• Stability of BEXT solids in tied contact It has been observed that a simulation can become unstable when the nodes of a BEXT solid are displaced indirectly through a tied contact. The issue will most commonly manifest as large deformations of the BEXT solid elements and usually will cause an error termination due to a negative jacobian at an integration point in the BEXT solid.

• Set segment It has been observed that attempting to define a *SET_SEGMENT_GENERAL with the PART option and a BEXT part will result in an empty segment set.

• BEXT shell and *ELEMENT_SHELL Any attempt to include a BEXT shell part and a *ELEMENT_SHELL in the same input deck will result in a fatal memory error

• IGA_INCLUDE_BEZIER_TRANFORM The TRANFORM option for IGA_INCLUDE_BEZIER does not seem to be implemented. Any attempt to include a second line in the card will result in an error.

##### 14.3.2ANSYS LS-DYNA supported keywords
• *IGA_INCLUDE_BEZIER
• The only value that has been tested for the TYPE field (card 2, field 1) is 1, corresponding to ASCII input.

• The only values that have been tested for the DIM field (card 2, field 3) are 2, and 3, corresponding to surface and volume. It is important that this value is correctly set to correspond with the dimension of the geometry represented in the BEXT file.

• *PART
• The value in the PID field must match the value in the PID field of the *IGA_INCLUDE_BEZIER card

• *SECTION_SHELL
• The value for the ELFORM field must be set to 201

• *SECTION_SOLID
• The value for the ELFORM field must be set to 201

• *BOUNDARY_PRESCRIBED_MOTION_SET

• *BOUNDARY_PRESCRIBED_MOTION_RIGID

• *BOUNDARY_SPC_SET

• *CONSTRAINED_NODAL_RIGID_BODY

• *CONSTRAINED_LINEAR_GLOBAL
• If a node from a rigid body is included in this card, an unstable simulation can result.

• *SET_NODE_LIST

• *CONTACT_TIED_SHELL_EDGE_TO_SURFACE_OFFSET
• Tied contact between a BEXT shell and a BEXT solid has been shown to result in an unstable simulation.

• *MAT_PIECEWISE_LINEAR_PLASTICITY

• *MAT_RIGID

• *MAT_ELASTIC

• *CONTROL_TERMINATION

• *CONTROL_TIMESTEP

• *CONTROL_CONTACT
• The IGA_CTC parameter is documented to improve IGA contact.

• *DATABASE_BINARY_D3PLOT

• *CONTACT_AUTOMATIC_SURFACE_TO_SURFACE
• This has been shown to work when the master and slave surfaces are defined by BEXT parts.