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
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:
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 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.
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.
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.
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
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:
Automotive preprocessing in Coreform Cubit
Preparing LS-DYNA input
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 —
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:
Mode/Geometry > Entity/Curve > Action/Modify > Tweak/Remove This effect of this tool is shown in figure 558 and figure 559
Mode/Geometry > Entity/Surface > Action/Modify > Remove/Extend
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:
- paver size limits { default | [minimum <value>][maximum <value>] }
See also the Graphics section of the Cubit commands quick reference chapter, and
The Pave material under Traditional meshing schemes
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 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 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:
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
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:
the underlying geometry is not smooth, or
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
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.
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:
*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.
*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:
$# 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:
*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:
*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:
*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
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.
Note, however, that the use of *CONSTRAINED_LINEAR_GLOBAL can produce an invalid simulation if any of the nodes involved are constrained in any other way, such as rigid materials, tied interfaces, and initial conditions. It has also been observed that for solid parts that have constrained nodes, an initial velocity applied to any node causes the simulation to fail. This can drastically limit the utility of parts that are joined with this method.
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.
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.
Stability of BEXT solids with applied boundary conditions It has been observed that a simulation can become unstable when the nodes of a BEXT solid part with a deformable material model applied are displaced due to an applied boundary condition on those nodes. This has been observed with *INITIAL_VELOCITY and *BOUNDARY_PRESCRIBED_MOTION 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.2 ANSYS 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
An unstable simulation can result when the node set contains node from a BEXT solid part with a deformable material model
- *INITIAL_VELOCITY
An unstable simulation can result when the node set contains node from a BEXT solid part with a deformable material model
*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.
*LOAD_NODE_SET
*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.