Preprocessing

4C reads the mesh, boundary conditions, materials and simulation parameters from an ASCII file in a proprietary format, which usually has the suffix .dat, but this suffix is not necessary, it can be anything.

There are not so many means to create a valid input file. At this point, we know of the following different ways to create an input file. In general, you’ll have two options:

  1. Either you create the input file in 4C’s native format directly,

  2. or you create an input file in a general binary format for finite element information, called Exodus II, develeloped by Sandia National Laboratories. This can be converted into 4C s native format by an internal converter, pre_exodus.

Since the conversion from the Exodus II format is the most versatile way to generate a 4C input file, this method is explained first.

Exodus II to 4C file conversion

The main procedure to generate a valid 4C input file is from a binary mesh file in Exodus II format, see above, which includes nodes, elements, node sets, element sets, and side sets, as can be created by Cubit. Since this file does not contain boundary conditions, element type information, materials and solver details, additional information is needed, which is given by two additional files:

  1. for the global system parameters (solver, material, step information, etc.), called the headerfile, and

  2. a file for the correlation between element sets and type declarations, as well as boundary conditions definitions. This is the so-called the bcfile.

These three files are merged into an input file for 4C by the program pre_exodus. The created 4C input file is then automatically validated using all available 4C validation and is therefore likely to run.

The program is created together with 4C executable, if make full has been invoked, but it can also be compiled solely by make pre_exodus.

$> pre_exodus --exo=<exodusfile> --bc=<bcfile> --head=<headerfile> --dat=<4Cinput> \
            [ --d2 | --d3  ]           \
            [ --quadtri  ]             \
            [ --gmesh=<startelement> ]

In general one might not have already a proper header-file and matching bc-file. By typing

./pre_exodus --exo=<yourmesh>.e

two preliminary files default.head and default.bc are created. The first contains the currently valid header parameters with default values and commented options which you can edit to adapt it to your means. Similarly, default.bc consists of all your mesh entities and a list of all currently valid conditions. See next section for details how to work with it and how to get valid input files.

Note

When you have an already existing input file, you can always validate it by simply executing ./pre_exodus --dat=inputfile.dat, before(!) you start a parallel 4C computation on a cluster, for example.

Optional parameters

The optional parameter --quadtri reads the exodus file and converts all quad elements in two triangular elements. It does not write a dat file, but writes a new exodus file instead named tri_<problemname>.e. NOTE: This feature is only for 2D elements, it does not modify 3D elements.

Generating Exodus II files

Even though the generation of Exodus II files might be out of scope of a 4C manual, users are informed on how to generate these files conveniently, so options are given in the following:

CUBIT

CUBIT http://cubit.sandia.gov/ is a powerful pre- postprocessing tool. (The commercial version of the software was called Trelis, but has been renamed into CUBIT now as well, so we may stick to the name CUBIT).

CUBIT can create Exodus II files which can be converted into a valid 4C inpufile using the pre_exodus filter, so the preprocessing is a two step process:

  1. Cubit - create geometry, mesh, and necessary node sets - export to exodus file format (*.e)

  2. pre_exodus - define appropriate boundary conditions and element types - convert into a 4C *.dat file.

Note that

  • it is not necessary to define boundary conditions in Cubit, since they are not converted to the dat file later on.

  • you should only define node sets, but not sidesets (surface sets). The node sets are converted into surface sets if the surface definition is given in the boundary condition control file (<problem>.bc) anyway.

Other Software

Geometry as well as element and node sets can be created in any finite element preprocessor. However, the preprocessor should be capable of exporting a file format, which can be converted by the python toolset meshio (see <https://pypi.org/project/meshio/>) into an exodus file, with which the input can be converted into a 4C .dat file.

Also, the exported input file can probably be imported in Cubit, then further edited and eventually exported as an exodus (.e) file.

So the steps are

  1. Create finite element model and sets in your favorite preprocessor

  2. Export to some format, like Exodus II or the Gmesh format .msh file.

  3. Optional: Read in the model to Cubit for further editing

  4. Optional: If you are not able to write in Exodus II format, use the python module meshio (packed in pip) to convert the mesh to an exodus (.e) file (<https://pypi.org/project/meshio/>)

  5. Run pre_exodus from your 4C build to convert the data (see above).

Other ways to create a 4C input directly

ABAQUS

There is an in-house Python module abaqus_meshio for the conversion from an ABAQUS input file (.inp) to dat file. This python module is available in the scripts gitlab. Since the .inp file can also be generated using Cubit, this submodule can be used in conjunction with Cubit as well, see above. The usage of this submodule starts firstly by importing it providing the path where it is located.

import sys

abaqus_meshio_path = "path_to_abaqus_meshio"
sys.path.append(abaqus_meshio_path)

Subsequently, the inp shall be read using the command

model = abaqus_meshio.read("path_to_inp.dat")

Unlike meshio.read, the command abaqus_meshio.read will return a model, which is instance of BModel, where:

  • model.rootAssembly.instances[instance_name].mesh is a BMesh. ``BMesh is a subclass of meshio.Mesh with additional attributes sections (for material assignment) and surfaces (for distributed load).

  • model has attributes materials (from MATERIAL), parts (from PART/END PART) and steps (from STEP)

  • model.parts[part_name].mesh is again a BMesh, model.rootAssembly.instances[instance_name].mesh is a transformation of this mesh.

BModel is designed to mimic the way Abaqus systematically stores its data. To access the original meshio.Mesh one has to use model.parts[part_name].mesh.

Proving that the information from inp is properly stored, the transformation to dat file is done by a simple command

fourc_io = abaqus_meshio.Inp2Baci(model, [params_step_1])
fourc_io.write("prefix")

If the inp has many steps defined by STEP/END STEP keywords, the list of parameters for each step has to be provided, e.g. [params_step_1, params_step_2, ...]. Default parameters for a structural analysis can be obtained using

params_step_1 = abaqus_meshio.GenerateDefaultParams()

Modify 4C input files

4C input files are text files so you can modify them using your favorite text editor. You can see all possible parameters and keywords in the reference part.