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.

• The size of "bc" array (primary bc) should be equal to number of DOFs in dof manager and i-th value relates to i-th DOF - the ordering and physical meaning of DOFs is determined by domain record and can be optionally specified for each dof manager individually (see next paragraph). The values of this array are corresponding boundary condition record numbers or zero, if no primary bc is applied to corresponding DOF. The compatible boundary condition type are required: primary conditions require "BoundaryCondition" records.
• The load "array" contains record numbers of natural boundary conditions that are applied. The required record type for natural condition is "NodalLoad". The actual value is the summation of all contributions, if more than one natural bc is applied. See section on boundary conditions for the syntax. Please note, that the values of natural bc for individual DOFs are specified in its record, not in dofmanager record.

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

• Node record

  Node	coords #(ra)
  	[lcs #(ra)]

  
  
  Represent an abstraction for finite element node. The node coordinates in space (given by global coordinate system) are described using coords attribute. This array contains x, y and possibly z (depends on problem under consideration) coordinate of node. By default, the coordinate system in node is global coordinate system. User defined local coordinate system in node is described using lcs array. This array contains six numbers, where the first three numbers represent a directional vector of the local x-axis, and the next three numbers represent a directional vector of the local y-axis. The local z-axis is determined using a vector product. A right-hand coordinate system is assumed. If user defined local coordinate system in node is specified, then the boundary conditions and applied loading are specified in this local coordinate system. The reactions and displacements are also in lcs system at the output.

  The node can create only master DOFs and SimpleSlave DOFs, so the allowable values of dofType array are in range 0,1. For the Node dof manager, the masterMask is the array of size equal to number of DOFs, and the i-th value determines the master dof manager, to which i-th dof is directly linked (the dof with same physical meaning are linked together). The local coordinate system in node with same linked dofs is supported, but it should be exactly the same as on master.

• Rigid arm record

  RigidArmNode	coords #(ra)
  	master #(in)
  	[masterMask #(ia)]
  	[lcs #(ra)]

  
  
  Represent node connected to other node (called master) using rigid arm. Rigid arm node DOFs can be linked to master (via rigid arm transformation) or can be independent. The rigid arm node allows to avoid very stiff elements used for modelling the rigid-arm connection. The rigid arm node maps its dofs to master dofs using simple transformations (small rotations are assumed). Therefore, the contribution to rigid arm node can be localized directly to master related equations. The rigid arm node can not have its own boundary or initial conditions, they are determined completely from master dof conditions. Currently it is possible to map only certain dofs - see dofType. Linked DOFs should have dofType value equal to 2, non-linked (primary) DOFs 0.

  Rigid arm node can be loaded independently of master. The node coordinates in space (given by global coordinate system) are described using coords field. This array contains x, y and possibly z (depends on problem under consideration) coordinate of node. The master parameter is the master node number, to which rigid arm node dofs are mapped. The rigid arm node and master can have arbvitrary local coordinate systems (if not specified, global one is assumed).

  The optional parameter masterMask allows to specify how particular mapped DOF depends on master DOFs. The size of masterMask array should be equal to number of DOFs. For all linked DOFs (with corresponding dofType value equal to 2) the corresponding value of masterMask array should be 1.

  The local coordinate system in rigid arm node is supported, the coordinate system in master and slave can be different. If no lcs is set, global one is assumed.the global cs applies.

• Hanging node

  HangingNode	coords #(ra)
  	dofType #(in)
  	[masterElement #(in)]
  	[masterRegion #(in)]

  
  

  Hanging node is connected to an a master element using generalized interpolation. Hanging node posses no degrees of freedom (except unlined dofs) - all values are interpolated from corresponding master elements and its DOFs. arbitrary FE mesh of concrete specimen or to facilitate the local refinement of FE mesh. The hanging nodes can be in a chain.

  The contributions of hanging node are localized directly to master related equations. The hanging node can have its own boundary or initial conditions, but only for primary unlinked DOFs. For linked DOFs, these conditions are determined completely from master DOF conditions. The local coordinate system should be same for all master nodes. The hanging node can be loaded independently of its master.

  Values of array dofType can have following values: 0-primary DOF, 2-linked DOF.

  The value of masterElement specifies the element number to which the hanging node is attached. The node can be attached to any arbitrary coordinate within the master element. The element must support the necessary interpolation classes. The same interpolation for unknowns and geometry is assumed.

  The no (or -1) value for masterElement is supplied, then the node will locate the element closest to its coordinate. If no (or zero) value for masterRegion is supplied, then all regions will be searched, otherwise only the elements in cross section with number masterRegion. If masterElement is directly supplied masterRegion is unused.

• Slave node

  SlaveNode	coords #(ra)
  	dofType #(in)
  	masterDofMan #(ia)
  	weights #(ra)

  
  

  Works identical to hanging node, but the weights (weights) are not computed from any element, but given explicitly, as well as the connected dof managers (masterDMan).

• Element side

  ElementSide

  
  
  Represents an abstraction for element side, which holds some unknowns.

• PFEMParticle

  PFEMParticle

  coords #(ra)

  
  
  Represent the particle used in PFEM analysis.

• InteractionPFEMParticle

  InteractionPFEMParticle	coords #(ra)
  	bc #(ia)
  	coupledNode #(in)

  
  
  Represent a special particle used in the PFEM-part of the FluidStructureProblem. The particle is attached to coupledNode from the structural counter part. InteractionBoundaryCondition 4.8 must be prescribed under bc to access the velocities from solid nodes.