On this page:
14.1 Building U-spline lattices
14.1.1 Basic lattice workflow
14.1.2 User-defined reference cells
14.1.2.1 Creating reference cells in Coreform Cubit
14.1.2.2 Building lattice structures with user-defined reference cells
14.1.3 Creating a surface offset
14.1.4 Building and slicing a lattice in the GUI
14.2 Building U-spline meshes for ANSYS LS-DYNA analyses
14.2.1 Automotive preprocessing in Coreform Cubit
14.2.1.1 Importing CAD model geometry
14.2.1.1.1 Stitching single-surface bodies
14.2.1.1.2 Dealing with non-analytic spline entities in CAD
14.2.1.2 Cleanup model geometry (Optional)
14.2.1.3 Modify BREP topology for quality meshing (Optional)
14.2.1.4 Mesh model geometry
14.2.1.5 Create subdomains for *SET_ keywords
14.2.1.6 Partitioning for multiple LS-DYNA parts
14.2.1.7 Constructing the U-spline
14.2.1.8 Exporting U-splines for use in LS-DYNA
14.2.1.8.1 Exporting multiple BEXT files
14.2.2 Preparing LS-DYNA input
14.2.2.1 Creating boundary conditions
14.2.2.2 Creating rigid connections
14.2.2.3 Creating common node connections
14.2.2.4 Creating tied contact
14.2.2.5 Including generated files
14.2.2.6 Required file inclusion order for multiple BEXT files
14.2.3 Executing ANSYS LS-DYNA
14.2.3.1 Post-processing
14.3 Initial set of ANSYS LS-DYNA keywords that support LS-DYNA BEXT input
14.3.1 Preliminary comments
14.3.2 ANSYS LS-DYNA supported keywords
8.5

14 Cubit Workflows

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

    14.1 Building U-spline lattices

      14.1.1 Basic lattice workflow

      14.1.2 User-defined reference cells

        14.1.2.1 Creating reference cells in Coreform Cubit

        14.1.2.2 Building lattice structures with user-defined reference cells

      14.1.3 Creating a surface offset

      14.1.4 Building and slicing a lattice in the GUI

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

      14.2.1 Automotive preprocessing in Coreform Cubit

        14.2.1.1 Importing CAD model geometry

          14.2.1.1.1 Stitching single-surface bodies

          14.2.1.1.2 Dealing with non-analytic spline entities in CAD

        14.2.1.2 Cleanup model geometry (Optional)

        14.2.1.3 Modify BREP topology for quality meshing (Optional)

        14.2.1.4 Mesh model geometry

        14.2.1.5 Create subdomains for *SET_ keywords

        14.2.1.6 Partitioning for multiple LS-DYNA parts

        14.2.1.7 Constructing the U-spline

        14.2.1.8 Exporting U-splines for use in LS-DYNA

          14.2.1.8.1 Exporting multiple BEXT files

      14.2.2 Preparing LS-DYNA input

        14.2.2.1 Creating boundary conditions

        14.2.2.2 Creating rigid connections

        14.2.2.3 Creating common node connections

        14.2.2.4 Creating tied contact

        14.2.2.5 Including generated files

        14.2.2.6 Required file inclusion order for multiple BEXT files

      14.2.3 Executing ANSYS LS-DYNA

        14.2.3.1 Post-processing

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

      14.3.1 Preliminary comments

      14.3.2 ANSYS LS-DYNA supported keywords

14.1 Building 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.1 Basic 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:

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 coordinate direction, which is the slice direction used by Cubit.

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

Figure 542: 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 543 shows the geometry of Cubit’s included lattice reference cells.

Figure 543: 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 544 shows the resulting lattice, visualized in Paraview.

Figure 544: 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.2 User-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.1 Creating 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 545 shows the desired geometry and how it fits inside the bounding box.

    Figure 545: 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 546 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 546: 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.2 Building 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 547 shows the resulting lattice visualized in Paraview.

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

14.1.3 Creating 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 548.

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 548: Section view of a new volume (outer) created by offsetting the surfaces of the original volume (inner).

14.1.4 Building and slicing a lattice in the GUI

Summary: It is possible to use the Coreform Cubit GUI to create a geometry-conforming lattice, select the coordinates of slice planes, and visualize the slice planes together with the geometry.

We first have to create some geometry, mesh it, and then fit a U-spline to it.

brick x 5 y 5 z 5 surf 1 size 1 mesh surf 1 vol 1 size 1 vol 1 scheme sweep source surf 1 target surf 2 mesh vol 1 set uspline vol 1 deg 2 build uspline vol 1 fit uspline 1

These Cubit commands have been run in the GUI, as shown below.

Figure 549: Building a U-spline to slice.

The lattice widget is found by clicking on the icon labeled Geometry and then the icon labeled Lattice Slice Parameters in the Command Panel. Required parameters for slicing include the U-spline ID of the sliced volume (1, in this case), a tessellation, and the Overall Slice Parameters. The tessellation may come from one packaged with Coreform Cubit or a custom-built tessellation. In the latter case, path to the file where the tessellation is saved has to be provided; the file format must be JSON. The Overall Slice Parameters include the z-coordinate of the lowest slice plane (Slice Start), the z-coordinate of the highest slice plane (Slice End), and the distance between slice planes (Interval Size). In this example, Slice Start and Slice Stop are the minimum and maximum z-coordinates of the geometry. One reason to choose z-coordinates outside the bounds of the geometry is when offsetting the boundary caps of the tessellation. The Apply button is clicked to slice the geometry. The figure below shows how this is done in the widget.

Figure 550: Slicing the U-spline with uniformly-spaced slice planes.

It is possible to provide ranges of z-coordinates over which the density of slice planes is different than the overall slice-plane density. These are created by pushing the plus button on the Custom Slice Ranges table and again, providing the z-bounds and spacing between slice planes. Add additional custom slice ranges by pressing the plus button repeatedly; remove a slice range by highlighting its row in the table and clicking the minus button. Once all desired slice ranges are in the table, the geometry is sliced by pressing the Apply button. The Cubit command that was run, together with all the z-coordinates of the slices, will appear in Cubit’s command line. To visualize the slice planes and the geometry, press the Preview button. This will bring up semi-transparent planes at the minimum and maximum z-coordinates of the custom slice ranges.

Optional slicing arguments may be added by clicking its corresponding checkbox near the bottom of the widget and providing a value in its entry field.

Figure 551: Varying the density of slice planes in some z-ranges and visualizing the extents of those regions.

14.2 Building 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.1 Automotive preprocessing in Coreform Cubit

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

14.2.1.1 Importing CAD model geometry

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.1 Stitching 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 552 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 552: 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 553, figure 554, and figure 555.

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 553.

Figure 553: 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 554, 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 554: 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 555: 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.2 Dealing with non-analytic spline entities in CAD

As shown in figure 556, 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 557. 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.

The CATIA CAD Translator is available for purchase from Coreform. Contact us to obtain a license.

Figure 556: 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 557: 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.2 Cleanup 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 558: 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 559: 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.3 Modify 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 560 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 560: 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 561. Once the macrosurfaces are constructed we assign meshing parameters (i.e. sizing and scheme assignments) onto the surfaces.

Figure 561: 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, judicious application of Cubit’s mesh smoothing functionality can often restore high quality mesh elements on these domains. Figure 563 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 564.

Figure 562: 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 563: 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, persistent 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 subsequent meshing operations don't perform auto-smoothing to this same tolerance.

Figure 564: 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.4 Mesh 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:


Figure 565: 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.5 Create 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 566, 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 567, 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 566: 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 567: 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 by adding the bounding curve to a Cubit group entitled cf_crease_and_project_entities.

14.2.1.6 Partitioning 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.7 Constructing 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 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 567

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 568.

Note that in figure 568 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 interface along this surface’s boundary.

Figure 568: 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.8 Exporting 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 It must be free of the comment insertions found in standard BEXT files.

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:

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.1 Exporting 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.2 Preparing 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.1 Creating 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

It should be noted that applying boundary conditions directly to nodes in a BEXT solid part has been shown to produce unstable simulation results. Simulation with BEXT parts is a development feature in LS-DYNA and is subject to these kinds of limitations, but it is expected to improve as further development is completed. Currently, the best practice is to constrain the solid part to another body (BEXT shell or linear solid) and apply the boundary condition to that other body.

14.2.2.2 Creating 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

$#    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.3 Creating 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 nodes that are constrained this way cannot be members of another constraint equation, a constraint set that contains the same degrees-of-freedom, tied interface or rigid bodies.

If the intent of the user is to connect two subsystems through a rigid body connection, this can be accomplished with *CONSTRAINED_NODAL_RIGID_BODY.

Additionally, 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.4 Creating 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.5 Including 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.6 Required 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.3 Executing 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.1 Post-processing

Simulation output files can be visualized in LS-PrePost as shown in figure 569, where we display a fringe plot of displacement in the -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 570, we provide a schematic of how to interpret the rendered mesh in LS-PrePost.

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

Figure 570: 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 partitioning. 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.3 Initial 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.

14.3.1 Preliminary comments
14.3.2 ANSYS LS-DYNA supported keywords