Dof manager records

These records describe individual DofManager records (i.e. nodes or element sides (if they manage some DOFs)). The general format is following:

*DofManagerType (num#)(in)
[load #(ra)]
[DofIDMask #(ia)]
[bc #(ia)]
[ic #(ia)]
[doftype #(ia) masterMask #(ia)]
$ \langle$[shared]$ \rangle$ $ \vert$ $ \langle$[remote]$ \rangle$ $ \vert$ $ \langle$[null]$ \rangle$
$ \langle$[partitions #(ia)]$ \rangle$

The order of particular records is optional, the dof manager number is determined by (num#)(in) parameter. The numbering of individual dof managers is arbitrary, it could be even non-continuous. In this context, one could think of dof manager number as a label that is assigned to individual dof manager and by which the dof manager is referenced. In parallel mode, the label represents a global id across all partitions.

By default, the nodal DOFs are determined by asking all the connected elements. Specifying additional dofs can be done using the using the DofIDMask array which determines their physical interpretation. Each item of DofIDMask array describes the physical meaning of corresponding DOF in dof manager. Currently the following values are supported: {u-displacement=1, v-displacement=2, w-displacement=3, u-rotation=4, v-rotation=5, w-rotation=6, u-velocity=7, v-velocity=8, w-velocity=9, temperature=10, pressure=11, special dofs for gradient-type constitutive models=12 and 13, mass concentration=14, special dofs for extended finite elements (XFEM)=15-30}. It is not allowed to have two DOFs with the same physical meaning in the same DofManager.

The applied primary (Dirichlet) boundary conditions are specified using "bc" record, while natural boundary conditions using "load" parameter.

By default, if "bc" and/or "load" parameters are omitted, no primary and/or natural bc are applied. Analogously, initial conditions are represented using ic array. The size of ic array should be equal to number of DOFs in dof manager. The values of this array are corresponding initial condition record numbers or zero, if no initial condition is applied to corresponding DOF (in this case zero value is assumed as value of initial condition).

Parameters dofType and masterMask allows to connect some dof manager's dofs (so-called ``slave'' dofs) to corresponding dof (according to their physical meaning) of another dof manager (so-called ``master'' dof). The master slave principle allows for example simple modeling of structure hinges, where multiple elements are connected by introducing multiple nodes (with same coordinates) sharing the same displacement dofs and each one possessing their own rotational dofs. Parameter dofType determines the type of (slave) dof to create. Currently supported values are 0 for master DOF, 1 for simpleSlave DOF (linked to another single master DOF), and 2 for general slave dof, that can depend on different DOFs belonging to different dof managers. If dofType is not specified, then by default all DOFs are created as master DOFs. If provided, masterMask is also required. The meaning of masterMask parameter is depending on type of particular dofManager, and will be described in corresponding sections.

The shared indicates, that dofmanager is shared by neighboring partitions. The contributions from all contributing domains are summed. Typical for node cut algorithm (see figures 6.6 and 6.7).

Remote DofManager is indicated by remote parameter. Then DofManager in active domain is only mirror of some remote DofManager and it is necessary to copy remote values into local ones. Typical for element cut (see fig. 6.9). The null parameter indicates so-called null DofManager. The null DofManager should be shared only by remote elements (these are only introduced for nonlocal constitutive model to allow effective local averaging, so only local material value to be averaged are transferred for these remote elements). Null nodes are therefore used only for computing real integration point coordinates of remote elements and there is no reason to maintain their unknowns (they have no equation number assigned, see fig. 6.7). They do not contribute to local partition governing equation. Only one of the null remote shared parameters can be used for particular DofManagers. If no one is used, the DofManager is maintained as local for particular partition.

The list of remote partitions sharing corresponding DofManager or list containing remote partition containing remote DofManager counterpart is specified using partitions parameter. The local partition should not be included in the list. The slaves are allowed, but masters have to be in the same partition. The masters can be again remote copies.

Supported DofManagerType keywords are

Borek Patzak