.4C.yaml .. _boundaryconditions:

Boundary Conditions

Various types of boundary conditions can be defined on points (nodes), lines, surfaces and volumes. These conditions are defined in the general section format

DESIGN [POINT|LINE|SURF|VOL] <condition type> CONDITIONS:

with subsequent lines defining the region and the specific values of the boundary conditions. Note that some boundary condition types do not follow this general structure. For each particular condition, refer to the boundary condition reference.

What follows is a list of condition entries (a dictionary) starting with the entry pair E: <set>, where set is the number of the TOPOLOGY set defined in terms of points, lines, surfaces and volumes, respectively. The subsequent entries depend on the type of condition. As an example, namely a Neumann and a Dirichlet boundary condition are given below (taken from solid_runtime_hex8.4C.yaml):

DESIGN SURF NEUMANN CONDITIONS:
- E: 2
  NUMDOF: 3
  ONOFF:
  - 1
  - 0
  - 0
  VAL:
  - 10
  - 0
  - 0
  FUNCT:
  - 1
  - 0
  - 0
DESIGN SURF DIRICH CONDITIONS:
- E: 1
  NUMDOF: 3
  ONOFF:
  - 1
  - 1
  - 1
  VAL:
  - 0
  - 0
  - 0
  FUNCT:
  - 0
  - 0
  - 0

Note that all boundary conditions are given in terms of node sets. Boundary conditions may be applied in arbitrary coordinate directions, which do not need to coincide with the original coordinate system of the geometry. For this aspect one may define a local (rotated) coordinate system.

Local Coordinate System

Local coordinates may be defined on points, lines, surfaces and volumes. The coordinate system is given by an axis \(\mathbf{n}\) and an angle \(\alpha\) (in rad) around which the coordinate is rotated clockwise.

Since the axis is a unit vector, the angle is given as the length of the vector, so that the complete rotation can be entered in three values: \([\alpha \cdot n_x, \, \alpha \cdot n_y, \, \alpha \cdot n_z]\).

The complete definition of a local coordinate system writes:

DESIGN [POINT/VOL] LOCSYS CONDITIONS:
- E: <num>   #  num corresponds to the set_descriptor_id defined in DNODE/DVOL-NODE TOPOLOGY block
  ROTANGLE:
  - <angle_x>
  - <angle_y>
  - <angle_z
  FUNCT:
  - <func_num_x>
  - <func_num_y>
  - <func_num_z>
  USEUPDATEDNODEPOS: 0

for point and volume definitions, and

DESIGN [LINE|SURF] LOCSYS CONDITIONS:
- E: <num>   #  num corresponds to the set_descriptor_id defined in DLINE/DSURF-NODE TOPOLOGY block
  ROTANGLE:
  - <angle_x>
  - <angle_y>
  - <angle_z
  FUNCT:
  - <func_num_x>
  - <func_num_y>
  - <func_num_z>
  USEUPDATEDNODEPOS: 0
  USECONSISTENTNODENORMAL: 0

for lines and surfaces.

The rotation may depend on time and/or space, that is, it can be combined with a function definition, see the proper definition in the functions section.

In addition, it is possible to calculate a spatial dependence either on the original node coordinates or on the updated (displaced) node coordinate, which may be important in a large displacement analysis. This is done by the USEUPDATEDNODEPOS parameter (=0: original coordinates, =1: updated coordinates).

Todo

The parameter USECONSISTENTNODENORMAL can (at this time) only be used for ALE and fluid simulation. However, there is no test input using this parameter anyway.

Dirichlet Boundary Conditions

Dirichlet boundary conditions (BC) are defined by specifying the number of DOFs of the nodes in the respective node set (NUMDOF). A binary switch that indicates which of these DOFs should be constrained (ONOFF= 0 or 1, with 0=unconstrained and 1=constrained). A list of entries to which value the respective DOFs are constrained (VAL). If applicable, the specifier (FUNCT) giving the ID of a function that defines a dependence of the constraint DOFs on other simulation parameters like, e.g., the time (see below) and, if applicable, a (TAG) entry. It is noted that, the number of entries following ONOFF, VAL and FUNCT must be the same as NUMDOF value. The geometry entity that the Dirichlet boundary condition applies is specified by num value. Depending on which block description of the boundary condition, the type of corresponding geometry will be selected appropriately, see the comments of the table below for more information. The value of num can only be from 1 to the number of the design descriptor.

In the case that two or more boundary conditions are intersected, the intersection geometry must be constrained with the constraint information of both BCs. This feature shall be handled properly by the pre-processor.

Of course, the applied Dirichlet boundary condition may depend on time and on the position of the node. This is achieved by a function definition, after the keyword FUNCT. The number of the function (for each component) can be specified in order to define a spatial or temporal dependence. The proper definition of functions is given in the functions section.

The TAG option allows to monitor the reaction forces at the constraint nodes by setting it to monitor_reaction. With this (TAG) set, the reaction forces are written to .csv files in a newly created sub directory of the simulation directory. Note that even even the TAG parameter can be given for any dirichlet boundary condition, it only produces results for forces and moments in a structural analysis.

One needs also to set the corresponding IO, such as the following (taken from sohex8_dbc_monitor.4C.yaml):

IO/MONITOR STRUCTURE DBC:
  INTERVAL_STEPS: 1

This writes a csv file for each dirichlet boundary condition containing the above tag in the directory <output_name>_monitor_dbc/*.csv. For further parameters (as, for example, the accuracy), see IO/MONITOR STRUCTURE DBC, and set the right time integration strategy, INT_STRATEGY.

Note that the TAG parameter may only be set for linear elements, not for quadratic ones (HEX20, TET10)

Below is the valid block definition for various types of Dirichlet boundary conditions.

DESIGN [POINT|LINE|SURF|VOL] DIRICH CONDITIONS:
- E: <num>    # num corresponds to the point_descriptor_id defined in DNODE/DLINE/DSURF/DVOL-NODE TOPOLOGY block
  NUMDOF: <numdof>
  ONOFF: [ 0|1, 0|1, ... ]
  VAL: [val_dof1, ... , val_numdof ]
  FUNCT: [...]
  TAG: none
DESIGN [POINT|LINE|SURF|VOL] ALE DIRICH CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] TRANSPORT DIRICH CONDITIONS
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] THERMO DIRICH CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] PORO DIRICH CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] NURBS LS DIRICH CONDITIONS:
- E: <num>
  # same parameters as above

See the respective reference sections for mechanical, ALE, TRANSPORT, THERMO, PORO, NURBS LS.

Neumann Boundary Conditions

Neumann boundary conditions are flux conditions. This means that in contrast to the Dirichlet boundary conditions, they have to be provided in terms of flux per applied geometry. A POINT NEUMANN condition is, for example, a concentrated force or heat flux, while a SURF NEUMANN is a pressure or surface heat flux, accordingly.

DESIGN [POINT|LINE|SURF|VOL] NEUMANN CONDITIONS:
- E: <num>    # num corresponds to the point_descriptor_id defined in DNODE/DLINE/DSURF/DVOL-NODE TOPOLOGY block
  NUMDOF: <numdof>
  ONOFF: [ 0|1, 0|1, ... ]
  VAL: [val_dof1, ... , val_numdof ]
  FUNCT: [...]
  TYPE: <parameter>
DESIGN POINT MOMENT EB CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF] TRANSPORT NEUMANN CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] THERMO NEUMANN CONDITIONS:
- E: <num>
  # same parameters as above
DESIGN [POINT|LINE|SURF|VOL] PORO NEUMANN CONDITIONS:
- E: <num>
  # same parameters as above

See the respective reference sections for mechanical, MOMENT EB, TRANSPORT, THERMO, PORO.

Robin (Spring-Dashpot) conditions

A spring-dashpot condition, also called a Robin boundary condition, is used to give a surface boundary (and only surface boundaries!) a stiffness and/or viscosity with respect to its displacement. For each degree of freedom the stiffness and/or viscosity may be considered or not. Also, both stiffness and viscosity may depend on a function definition. The Direction can be given in the global coordinate system or with respect to the surface normal. The input looks like this:

DESIGN SURF ROBIN SPRING DASHPOT CONDITIONS:
- E: <surfset>
  NUMDOF: <numdof>
  ONOFF: [0 0 0]
  STIFF:
  - <X_STIFF>
  - <Y_STIFF>
  - <Z_STIFF>
  TIMEFUNCTSTIFF: [0, 0, 0]
  VISCO:
  - <X_VISCO>
  - <Y_VISCO>
  - <Z_VISCO>
  TIMEFUNCTVISCO: [ 0, 0, 0 ]
  DISPLOFFSET: [0.0, 0.0, 0.0]
  TIMEFUNCTDISPLOFFSET: [0, 0, 0]
  FUNCTNONLINSTIFF: [0, 0, 0 ]
  DIRECTION: xyz|refsurfnormal|cursurfnormal
  COUPLING: none|<couplingID>

  • Commonly the Robin boundary condition couples the nodes at the surface to its original position. However, by giving a value to DISPLOFFSET, one may introduce a prestressing of the spring. The point in space, to which it the surface nodes are coupled, may also move with time (TIMEFUNCTDISPLOFFSET).

  • The direction in which the spring and dashpot are acting can be specified by the parameter DIRECTION. This is either a global direction (DIRECTION xyz) or the surface normal (then only the x-axis has to be specified a finite value, but all three axis have to be given). The surface normal may then be either the reference one (refsurfnormal), or the current one (cursurfnormal).

  • The Robin boundary condition can also couple the surface to another surface by specifying a couplingID (COUPLING <int>). The coupled surface is then given by a DESIGN SURF ROBIN SPRING DASHPOT COUPLING CONDITIONS, see the following input:

DESIGN SURF ROBIN SPRING DASHPOT COUPLING CONDITIONS:
- E: <surfset>
  COUPLING: <couplingID>

See also DESIGN POINT ROBIN SPRING DASHPOT CONDITIONS and DESIGN SURF ROBIN SPRING DASHPOT COUPLING CONDITIONS.

Constraint conditions

Often, it is useful to prescribe not an absolute value of a nodal displacement or force, but rather a displacement relative to other displacements, which is commonly called constraint condition. 4C has a number of options to define such constraints.

Several nodes coupled for specific degrees of freedom

Some applications (typically in structural / solid mechanics) require the coupling of certain DoFs of two or more nodes at the same geometrical position, while certain other DoFs of those nodes shall remain independent (e.g. joints and hinges in frames). While it is very easy to couple all(!) DoFs of several nodes at the same geometrical position (by simply merging the nodes into one node), things are more complicated if only certain DoFs are to be coupled. While it would always be possible to introduce this coupling as a Dirichlet condition / Multipoint Constraint into the final system of equations, we have decided to implement this at a more fundamental level by changing the assignment of DoFs according to the existing coupling conditions. Thus, if a point coupling condition is introduced for a set of nodes, the DoFs to be coupled are identified and the same(!) DoFs are then assigned to all participating nodes, while the remaining uncoupled DoFs are created and assigned independently for each node. This required some changes in the way nodal DoFs are assigned and handled in 4C. However, after the initial DoF handling, the nice thing about this approach is that nothing needs to be done anymore at the system matrix level because the coupling is inherently included in the DoF-maps. If you think of a web-like frame structure with many joints and hinges, this also means that the global system size is drastically reduced as compared to a Dirichlet type handling of such constraints.

Features:

  • new point coupling condition - e.g. for joints / hinges in structural mechanics

  • no interference (hopefully) with element or face DoFs

  • DofSet class is now able to handle repeated assignment of DoFs to more than one node

  • DofSet class is now tracking and storing not only the first DoF ID of a node but all DoF IDs of a node

NOT included so far:

  • support for derived DofSet classed that overload AssignDegreesOfFreedom (e.g. MortarDofSet, PotentialDofSet)

  • support for special DofSet stuff (e.g. TransparentDofSet, Proxies…)

  • support for bandwidth optimization (#define BW_OPT), which is currently however not used anyway

Example input file where two nodes each are coupled in several point coupling conditions, taken from fbi_fluid_obstacle.4C.yaml:

DESIGN POINT COUPLING CONDITIONS:
- E: 2
  NUMDOF: 6
  ONOFF:
  - 1
  - 1
  - 1
  - 1
  - 1
  - 1
- E: 3
  NUMDOF: 6
  ONOFF:
  - 1
  - 1
  - 1
  - 1
  - 1
  - 1
- E: 4
  NUMDOF: 6
  ONOFF:
  - 1
  - 1
  - 1
  - 1
  - 1
  - 1
- E: 5
  NUMDOF: 6
  ONOFF:
  - 1
  - 1
  - 1
  - 1
  - 1
  - 1
DNODE-NODE TOPOLOGY:
- NODE 326 DNODE 1
- NODE 327 DNODE 2
- NODE 328 DNODE 2
- NODE 329 DNODE 3
- NODE 330 DNODE 3
- NODE 331 DNODE 4
- NODE 332 DNODE 4
- NODE 333 DNODE 5
- NODE 334 DNODE 5

The node couples of the given pointset have the same displacements and rotations in all directions; see also DESIGN POINT COUPLING CONDITIONS.

Surface coupled to a node in a given direction

In this constraint, the whole surface is displaced the same amount as a single master node (which is not defined by a DPOINT, but by its given node ID).

DESIGN SURFACE NORMALDIR MULTIPNT CONSTRAINT 3D:
- E: 3
  ConditionID: 1
  amplitude: 1
  activeTime: 0
  masterNode: 1
  direction:
  - 0
  - 1
  - 0

There is also a penalty version, which uses a different algorithm, where one has to provide a penalty parameter. See also DESIGN SURFACE NORMALDIR MULTIPNT CONSTRAINT 3D and DESIGN SURFACE NORMALDIR MULTIPNT CONSTRAINT 3D PEN.

Node displacement relative to a given surface or line

This is a rather specific constraint, where a plane (or a line, respectively) is defined by three nodes, which are given as index of the <surfset>|<lineset> (the index is starting from 1 for whatever reasons), and the other nodes of this set are displaced with respect to this plane/line. An example using this constraint for a line is given in constr2D_MPC_angle.4C.yaml:

DESIGN LINE MULTIPNT CONSTRAINT 2D:
- E: 1
  ConditionID: 1
  amplitude: 3.14159
  curve: 1
  constrNode1: 1
  constrNode2: 2
  constrNode3: 3
  control: angle
  activeTime: 0

For the surface condition and a complete list of possible parameters, see DESIGN SURFACE MULTIPNT CONSTRAINT 3D and DESIGN LINE MULTIPNT CONSTRAINT 2D

Periodic boundary conditions

Periodic boundaries are defined as conditions, where nodes on one surface (normal to any of the cartesian coordinate directions, i.e., xy, yz, or xz), are bound to the respective nodes on the opposite side, see the reference DESIGN SURF PERIODIC BOUNDARY CONDITIONS, DESIGN LINE PERIODIC BOUNDARY CONDITIONS. They can be defined at one or several sides of the structure.

Two types of periodic boundary conditions are implemented, one is for general periodic behavior, denoted as PERIODIC BOUNDARY CONDITIONS, the other one is only useful for structural mechanics, where the displacement on one side can differ from the displacement on the other side by a certain (spatially constant) amount, called PERIODIC RVE 3D BOUNDARY CONDITIONS. For both types, the coordinates on the opposite surfaces/lines must be on equal positions (except the constant plane/line distance).

The general case is used in a number of test files for various physics, see the one taken from an electro-chemical simulation, elch_gaussian_hill_pbc_genalpha.4C.yaml:

DESIGN SURF PERIODIC BOUNDARY CONDITIONS:
- E: 1
  ID: 1
  MASTER_OR_SLAVE: Master
  PLANE: yz
  LAYER: 0
  ANGLE: 0
  ABSTREETOL: 1e-09
- E: 2
  ID: 1
  MASTER_OR_SLAVE: Slave
  PLANE: yz
  LAYER: 0
  ANGLE: 0
  ABSTREETOL: 1e-09

Here, nodes at either side must be at equal plane coordinates within the tolerance given by ABSTREETOL. The definition of ANGLE is used for rotational symmetry. For this case, the master must always be in the defined PLANE, and the slave is rotated by the given angle, while the same plane must be given.

The mechanical periodic boundary conditions (mainly used in micro mechanics, where these conditions model a so-called representative volume element, thus the name RVE BOUNDARY) have a different structure, here the surfaces must comply with the global cartesian directions, x,y,z, and the surfaces have to be defined pairwise for each direction where they are applied (they don’t need to be applied for all directions). An example showing its application is given in rve3d_periodic_bcs.4C.yaml:

DESIGN SURF PERIODIC RVE 3D BOUNDARY CONDITIONS:
- E: 1
  SURF: z+
- E: 2
  SURF: z-
- E: 3
  SURF: y-
- E: 4
  SURF: x-
- E: 5
  SURF: y+
- E: 6
  SURF: x+

Contact conditions

Contact conditions, which in 4C are set up by the keyword MORTAR are defined along lines (2D) or surfaces (3D). At least one contact pair is necessary:

DESIGN LINE|SURF MORTAR CONTACT CONDITIONS 2D|3D:
- E <num>
  InterfaceID: <interfaceID>
  Side: <Master|Slave|Selfcontact>
  Initialization: <Inactive|Active>
  FrCoeffOrBound: 0.0
  AdhesionBound: 0.0
  Application: <Solidcontact|Beamtosolidcontact|Beamtosolidmeshtying>
  TwoHalfPass: 0.0
  RefConfCheckNonSmoothSelfContactSurface: 0.0
  ConstitutiveLawID: 0

The parameters FrCoeffOrBound, AdhesionBound, Application, TwoHalfPass, RefConfCheckNonSmoothSelfContactSurface, ConstitutiveLawID are optional. You’ll find more information about contact in the contact and meshtying section.

Defining boundary conditions for geometries from EXODUS files

Conditions can be applied on node sets or element blocks defined in the EXODUS file. Every condition takes an E parameter referring to the entity number that is subject to the condition. The ENTITY_TYPE parameter is used to distinguish between node_set_id and element_block_id.

A collection of all currently implemented boundary conditions is given in the Prescribed condition reference.