Domain record(s)

This set of records describes the whole domain and its type. Depending on the type of problem, there may be one or several domain records. If not indicated, one domain record is default for all problem types.

The domain type is used to resolve the default number of DOFs in node and their physical meaning. Format is following
domain domainType
The domainType can be one from the following

  • The 2dPlaneStress and 2d-Truss modes declare two default dofs per node (u-displacement, v-displacement),

  • The 3d mode declares three default dofs per node (u-displacement, v-displacement, w-displacement),

  • The 2dMindlinPlate mode declares three default dofs per node (w-displacent, u-rotation, v-rotation). Strain vector contains \(\kappa_{xx}\), \(\kappa_{yy}\), \(\kappa_{xy}\), \(\gamma_{xz}\), \(\gamma_{yz}\). Stress vector contains \(m_{xx}\), \(m_{yy}\), \(m_{xy}\), \(q_{xz}\), \(q_{yz}\).

  • The 3dShell mode declares six default dofs per node (displacement and rotation along each axis).

  • The 2dBeam mode declares three default dofs per node (u-displacement, w-displacement, v-rotation).

  • The 2dIncompFlow mode declares three default dofs per node (u-velocity, v-velocity, and pressure). The default number of dofs per node as well as their physical meaning can be overloaded in particular dof manager record (see section Dof manager records).

    The further records describe particular domain components - OutputManagers, DofManagers, Elements, CrossSection models, Material Models, Boundary and Initial Conditions and Load time functions.

Output manager record

The output manager controls output. It can filter output to specific solution steps, and within these selected steps allows also to filter output only to specific dof managers and elements. The format of output manager record is
[tstep_all] [tstep_step #(in)] [tsteps_out #(rl)] [dofman_all] [dofman_output #(rl)] [dofman_except #(rl)] [element_all] [element_output #(rl)] [element_except #(rl)]
To select all solution steps, in which output will be performed, use tstep_all. To select each tstep_step-nth step, use tstep_step parameter. In order to select only specific solution steps, the tsteps_outlist can be specified, supplying solution step number list in which output will be done. The combination of tstep_step and tsteps_out parameters is allowed.
Output manager allows also to filter output to only specific dof managers and elements. If these specific members are selected, the output happens only in selected solution steps. The dofman_all and element_all parameters select all dof managers or elements respectively. Parameter arrays dofman_output and element_output allow to select only specific members. Numbers of selected members are then contained in dofman_output or element_output lists respectively. The previously selected members can be explicitly de-selected by specifying their component numbers in dofman_except or element_except lists. A few examples:
dofman_output {1 3} prints nodes 1,3
dofman_output {(1 3)} prints nodes 1,2,3
element_output {1 3} prints elements 1,3
element_output {(1 3)} prints elements 1,2,3
element_output {(1 3) 5 6} prints elements 1,2,3,5,6

Components size record

This record describes the number of components in related domain. The particular records will follow immediately in input file. The general format is:
ndofman #(in) nelem #(in) ncrosssect #(in) nmat #(in) nbc #(in) nic #(in) nltf #(in) [nbarrier #(in)] where ndofman represents number of dof managers (e.g. nodes) and their associated records, nelem represents number of elements and their associated records, ncrosssect is number of cross sections and their records, nmatdnMat is number of material models and their records, nbc represents number of boundary conditions (including loads) and their records, nic parameter determines the number of initial conditions, and nltf represents number of time functions and their associated records. The optional parameter nbarrier represents the number of nonlocal barriers and their records. If not specified, no barriers are assumed.

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 #(in) [load #(ra)] [DofIDMask #(ia)] [bc #(ia)] [ic #(ia)] [doftype #(ia) masterMask #(ia)] <[shared]> \(|\) <[remote]> \(|\) <[null]> <[partitions #(ia)]>

The order of particular records is optional, the dof manager number is determined by (#(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.

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.

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 arbitrary 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 (see interactionbc) must be prescribed under bc to access the velocities from solid nodes.

Element records

These records specify a description of particular elements. The general format is following:

ElementType #(in) mat #(in) crossSect #(in) nodes #(ia) [bodyLoads #(ia)] [boundaryLoads #(ia)] [activityltf #(in)] [lcs #(ra)] <[partitions #(ia)]> <[remote]>

The order of element records is optional, the element number is determined by #(in) parameter. The numbering of individual elements is arbitrary, it could be even non-continuous. In this context, one could think of element number as a label that is assigned to individual elements and by which the element is referenced.

Element material is described by parameter mat, which contains corresponding material record number. Element cross section is determined by cross section with crossSect record number. Element dof managers (nodes, sides, etc.) defining element geometry are specified using nodes array.

Body load acting on element is specified using bodyLoads array. Components of this array are corresponding load record numbers. The loads should have the proper type (body load type), otherwise error will be generated.

Boundary load acting on element boundary is specified using boundaryLoads array. The format of this array is

\[2\cdot size \; lnum(1)~id(1)~\dots~lnum(size)~id(size),\]

where \(size\) is total number of loadings applied to element, \(lnum(i)\) is the applied load number, and \(id(i)\) is the corresponding entity number, to which the load is applied (for example a side or a surface number). The entity numbering is element dependent and is described in element specific sections. The applied loads must be of proper type (boundary load type), otherwise error is generated.

The support for element insertion and removal during the analysis is provided. One can specify optional time function (identified by its id using activityltf parameter). The nonzero value of this time function indicates, whether the element is active (nonzero value, the default) or inactive (zero value) at particulat solution step. Tested for structural and transport elements. This feature allows considering temperature evolution of layered casting of concrete, where certain layers needs to be inactive before they are cast. See a corresponding example in oofem tests how to enforce hydrating material model, boundary conditions and element activity acting concurrently.

Orientation of local coordinates can be specified using lcs array. This array contains six numbers, where the first three numbers represent a directional vector of local x-axis, and the next three numbers represent a directional vector of local y-axis. The local z-axis is determined using the vector product. The lcs array on the element is particularly useful for modeling of orthotropic materials which follow the element orientation. On a beam or truss element, the lcs array has no effect and the 1D element orientation is aligned with the global \(xx\) component.

Available material models, their outline and corresponding parameters are described in separate Element Library Manual.

Set records

Sets specify regions of the geometry as a combination of volumes, surfaces, edges, and nodes. The main usage of sets are to connect regions of elements to a given cross section or apply a boundary condition, though sets can be used for many other things as well.

Set #(in) [elements #(ia)] [elementranges #(rl)] [allElements] [nodes #(ia)] [noderanges #(rl)] [allNodes] [elementboundaries #(ia)] [elementedges #(ia)]

Volumes (elements) and nodes can be specified using either a list, elements, nodes, or with a range list elementranges, noderanges. Edges elementedges, and surfaces elementboundaries, are specified in a interleaved list, every other number specifying the element, and edge/surface number (the total length of the list being twice the number of surfaces/edges). The internal numbering of edges/surfaces is available in the Element Library Manual.

Note that edge loads (singular loads given in “newton per length” (or equivalent), should be applied to elementedges, surface loads “newton per area” on elementboundaries, and bulk loads “newton per volume” on elements.

Example 1: A deadweight (gravity) load would be applied to the elements in a set, while a distributed line load would be applied to the midline “edge” of the beam element, thus should be applied to a elementedges set. In the latter case, the midline of the beam is defined as the first (and only) “edge” of the beam.

Example 2: Axisymmetric structural element analysis: A deadweight load would be applied to elements in a set. A external pressure would be defined as a surface load an be applied to the elementboundaries in a set. The element integrates the load (analytically) around the axis, so the load would still count as a surface load.

Cross section records

These records specify a cross section model descriptions. The general format is following:

CrossSectType #(in)

The order of particular cross section records is optional, cross section model number is determined by #(in) parameter. The numbering should start from one and should end at n, where n is the number of records.

The crossSectType keyword can be one from following possibilities

  • Integral cross section with constant properties
    SimpleCS [thick #(rn)] [width #(rn)] [area #(rn)] [iy #(rn)] [iz #(rn)] [ik #(rn)] [shearareay #(rn)] [shearareaz #(rn)] beamshearcoeff #(rn)
    Represents integral type of cross section model. In current implementation, such cross section is described using cross section thick (thickVal) and width (widthVal). For some problems (for example 3d), the corresponding volume and cross section dimensions are determined using element geometry, and then you can omit some (or all) parameters (refer to documentation of individual elements for required cross section properties). Parameter area allows to set cross section area, parameters iz, iz, and ik represent inertia moment along y and z axis and Saint-Venant torsional constant. Parameter beamshearcoeff allows to set shear correction factor, or equivalent shear areas (shearareay and shearareaz parameters) can be provided. These cross section properties are assumed to be defined in local coordinate system of element.
  • Integral cross section with variable properties
    VariableCS [thick #(expr)] [width #(expr)] [area #(expr)] [iy #(expr)] [iz #(expr)] [ik #(expr)] [shearareay #(expr)] [shearareaz #(expr)]
    Represents integral type of cross section model, where individual cross section parameters can be expressed as an arbitrary function of global coordinates x,y,z. Similar to SimpleCS, for some problems (for example 3d), the corresponding volume and cross section dimensions are determined using element geometry, then you can omit many (or some) parameters (refer to documentation of individual elements for required cross section properties). Parameter area allows to set cross section area, parameters iz, iz, and ik represent inertia moment along y and z axis and Saint-Venant torsional constant. Parameters (shearareay and shearareaz determine shear area, which is required by beam and plate elements. All cross section properties are assumed to be defined in local coordinate system of element.
  • Layered cross section
    LayeredCS nLayers #(in) LayerMaterials #(ia) Thicks #(ra) Widths #(ra) [midSurf #(rn)] [nintegrationpoints #(in)] [layerintegrationpoints #(ia)] [beamshearcoeffxz #(rn)]
    Represents the layered cross section model, based on geometrical hypothesis, that cross sections remain planar after deformation. Number of layers is determined by nLayers parameter. Materials for each layer are specified by LayerMaterials array. For each layer is necessary to input geometrical characteristic, thick - using Thicks array, and width - using Widths array. Position of mid surface is determined by its distance from bottom of cross section using midSurf parameter (normal and momentum forces are then computed with regard to it’s position, by default it is located at average thickness position). The number of integration points per layer can be specified using nintegrationpoints parameter, default is one integration point. It is also possible to set up different number of integration points per individual layer using layerintegrationpoints array, where its size should be equal to number of layers configured. The layerintegrationspoints parameter overrides the nitengrationpoints setting. The Gauss integration rule is used for setting up integration points in each layer.
    The optional parameter beamshearcoeffxz allows to set shear correction factor for 2D beam sections, controlling shear effective area used to evaluate shear force (default value is 1.0). Elements using this cross section model must implement layered cross section extension. For information see element library manual.
  • Fibered cross section
    FiberedCS nfibers #(in) fibermaterials #(ia) thicks #(ra) widths #(ra) thick #(rn) width #(rn) fiberycentrecoords #(ra) fiberzcentrecoords #(ra)
    Cross section represented as a set of rectangular fibers. It is based on geometrical hypothesis, that cross sections remain planar after deformation (3d generalization of layered approach for beams). Paramater nfibers determines the number of fibers that together form the overall cross section. The model requires to specify a material model corresponding to particular fiber using fibermaterials array. This array should contain for each fibre corresponding material model number (the material model specified on element level has no meaning in this particular case). The geometry of cross section is determined from fiber dimensions and fiber positions, all input in local coordinate system of the beam (yz plane). The thick and width of each fiber are determined using thicks and widths arrays. The overall thick and width are specified using parameters thick and width. Positions of particular fibers are specified by providing coordinates of center of each fiber using fiberycentrecoords array for y-coordinates and fiberzcentrecoords array for z-coordinates.
  • Warping cross section
    WarpingCS WarpingNode #(in)
    Represents the cross section for Free warping analysis, see section Free warping analysis. The WarpingNode parametr defines the number of external node with prescribed boundary condition which corresponds to the relative twist of warping cross section.

Material type records

These records specify a material model description. The general format is following:

MaterialType #(in) d #(rn)

The order of particular material records is optional, the material number is determined by #(in) parameter. The numbering should start from one and should end at n, where n is the number of records. Material density is compulsory parameter and it’s value is given by d parameter.

Available material models, their outline and corresponding parameters are described in separate Material Library Manual.

Nonlocal barrier records

Nonlocal material models of integral type are based on replacement of certain suitable local quantity in local constitutive law by their nonlocal counterparts, that are obtained as weighted average over some characteristic volume. The weighted average is computed as a sum of a remote value multiplied by weight function value. The weight function typically depend on a distance between remote and receiver points and decreases with increasing distance. In some cases, it is necessary to disregard mutual interaction between some points (for example if they are on the opposite sides of a thin notch, which prevents the nonlocal interactions to take place). The barriers are the way how to introduce these constrains. The barrier represent a curve (in 2D) or surface (in 3D). When the line connecting receiver and remote point intersects a barrier, the barriers is activated and the corresponding interaction is not taken into account.

Currently, the supported barrier types are following:

  • Polyline barrier

    polylinebarrier #(in) vertexnodes #(ia) [xcoordindx #(in)] [ycoordindx #(in)]
    This represents a polyline barrier for 2D problems. Barrier is a polyline, defined as a sequence of nodes representing vertices. The vertices are specified using parameter vertexnodes array, which contains the node numbers. The optional parameters xcoordindx and ycoordindx allow to select the plane (xy, yz, or xz), where the barrier is defined. The xcoordindx is the first coordinate index, ycoordindx is the second. The default values are 1 for xcoordindx and 2 for ycoordindx, representing barrier in xy plane.

  • Symmetry barrier

    symmetrybarrier #(in) origin #(ra) normals #(ra) activemask #(ia)
    Implementation of symmetry barier, that allows to specify up to three planes (orthogonal ones) of symmetry. This barrier allows to model the symmetry of the averaged field on the boundary without the need of modeling the other part of structure across the plane of symmetry. It is based on modifying the integration weights of source points to take into account the symmetry. The potential symmetry planes are determined by specifying orthogonal right-handed coordinate system, where axes represent the normals of corresponding symmetry planes. Parameter origin determines the origin of the coordinate system, the normals array contains three components of x-axis direction vector, followed by three components of y-axis direction vector (expressed in global coordinate system). The z-axis is determined from the orthogonality conditions. Parameter activemask allows to specify active symmetry planes; i-th nonzero value activates the symmetry barrier for plane with normal determined by corresponding coordinate axis (x=1, y=2, z=3).

Load and boundary conditions

These records specify description of boundary conditions. The general format is following:

EntType #(in) loadTimeFunction #(in) [valType #(in)] [dofs #(ia)] [isImposedTimeFunction #(in)]

The order of particular records is optional, boundary condition number is determined by #(in) parameter. The numbering should start from one and should end at n, where n is the number of records. Time function value (given by loadTimeFunction parameter) is a multiplier, using which each component (value of loading or value of boundary condition) describes its time variation. The optional parameter valType allows to determine the physical meaning of bc value, which is sometimes required. Supported values are (1 - temperature, 2 - force/traction, 3 - pressure, 4 - humudity, 5 - velocity, 6 - displacement). Another optional parameter dofs is used to determine which dofs the boundary condition should act upon. It is not relevant for all BCs..

The nonzero value of isImposedTimeFunction time function indicates that given boundary condition is active, zero value indicates not active boundary condition in given time (the bc does not exist). By default, the boundary condition applies at any time.

Currently, EntType keyword can be one from

  • Dirichlet boundary condition

    BoundaryCondition prescribedvalue #(rn) [d #(rn)]

    Represents boundary condition. Prescribed value is specified using prescribedvalue parameter. The physical meaning of value is fully determined by corresponding DOF. Optionally, the prescribed value can be specified using d parameter. It is introduced for compatibility reasons. If prescribedvalue is specified, then d is ignored.

  • Prescribed gradient boundary condition (Dirichlet type)

    PrescribedGradient gradient #(rm) [cCoords #(ra)]

    Prescribes \(v_i = d_{ij}(x_j-\bar{x}_j)\) or \(s = d_{1j}(x_j - \bar{x}_j)\) where \(v_i\) are primary unknowns, \(x_j\) is the coordinate of the node, \(\bar x\) is cCoords and \(d\) is gradient. The parameter cCoords defaults to zero. This is typical boundary condition in multiscale analysis where \(d = \partial_x s\) would a macroscopic gradient at the integration point, i.e. this is a boundary condition for prolongation. It is also convenient to use when one wants to test a arbitrary specimen for shear.

  • Mixed prescribed gradient / pressure boundary condition (Active type)

    MixedGradientPressure devGradient #(ra) pressure #(rn) [cCoord #(ra)]

    All boundary conditions of ensures that the deviatoric gradient and pressure is at least weakly fullfilled on the prescribed domain. They are used for computational homogenization of incompressible flow or elasticity problems.

  • Mixed prescribed gradient / pressure boundary condition (Weakly periodic type)

    MixedGradientPressureWeaklyPeriodic order #(rn)

    Prescribes a periodic constant (unknown) stress tensor along the specified boundaries. For order set to 1, one obtains the same results as the Neumann boundary condition.

  • Mixed prescribed gradient / pressure boundary condition (Neumann type)

    MixedGradientPressureNeumann

    Prescribes a constant (unknown) deviatoric stress tensor along the specified boundaries. Additional unknowns appears, \(\boldsymbol{\sigma}_\mathrm{dev}\), which is handled by the boundary condition itself (no control from the input file). The input devGradient is weakly fulfilled (homogenized over the elementsides). As with the the Dirichlet type, the volumetric gradient is free. This is useful in multiscale computations of RVE’s that experience incompressible behavior, typically fluid problems. In that case, the element sides should cover the entire RVE boundary. It is also convenient to use when one wants to test a arbitrary specimen for shear, with a free volumetric part (in which case the pressure is set to zero). Symmetry is not assumed, so rigid body rotations are removed, but translations need to be prescribed separately.

  • Mixed prescribed gradient / pressure boundary condition (Dirichlet type)

    MixedGradientPressureDirichlet

    Prescribes \(v_i = d_{\mathrm{dev},ij}(x_j-\bar{x}_j) + d_\mathrm{vol}(x_i-\bar{x}_i)\), and a pressure \(p\). where \(v_i\) are primary unknowns, \(x_j\) is the coordinate of the node, \(\bar x\) is cCoords and \(d_\mathrm{dev}\) is devGradient. The parameter cCoords defaults to zero. An additional unknown appears, \(d_\mathrm{vol}\), which is handled by the boundary condition itself (no control from the input file). This unknown is in a way related to the applied pressure. This is useful in multiscale computations of RVE’s that experience incompressible behavior, typically fluid problems. It is also convenient to use when one wants to test a arbitrary specimen for shear, with a free volumetric part (in which case the pressure is set to zero).

  • Nodal fluxes (loads) NodalLoad components #(ra) [cstype #(in)] Concentrated nodal load. The components of nodal load vector are given by components parameter. The size of this vector corresponds to a total number of nodal DOFs, and i-th value corresponds to i-th DOF in associated dof manager. The load can be defined in global coordinate system (cstype = 0) or in entity - specific local coordinate system (cstype = 1, default).

  • PrescribedTractionPressureBC

    Represents pressure boundary condition (of Dirichlet type) due to prescribed tractions. In CBS algorithm formulation the prescribed traction boundary condition leads indirectly to pressure boundary condition in corresponding nodes. This boundary condition implements this pressure bc. The value of bc is determined from applied tractions, that should be specified on element edges/surfaces using suitable boundary loads.

  • Linear constraint boundary condition

    LinearConstraintBC weights #(ra) [weightsLtf #(ia)] dofmans #(in) dofs #(in) rhs #(rn) [rhsLtf #(in)] lhstype #(ia) rhsType #(ia)

    This boundary condition implements a linear constraint in the form \(\sum_i w_ir_i = c\), where \(r_i\) are unknowns related to DOFs determined by dofmans and dofs, the weights are determined by weights and weightsLtf. The constant is determined by rhs and rhsLtf parameters. This boundary condition is introduced as additional stationary condition using Lagrange multiplier, which is an additional degree of freedom introduced by this boundary condition.

    The individual DOFs are determined using dof manager numbers (dofmans array) and corresponding DOF indices (dofs). The weights corresponding to participating DOFs are specified using weights array. The weights are multiplied by value returned by load time function, associated to individual weight using optional weightsLtf array. By default, all weights are set to 1. The constant \(c\) is determined by rhs parameter and it is multiplied by the value of load time function, specified using rhsLtf parameter, or by 1 by default. The characteristic component, to which this boundary condition contributes must be identified using lhstype and rhsType parameters, values of which are corresponding to CharType enum. The left hand side contribution is assembled into terms identified by lhstype. The rhs contribution is assembled into the term identified by rhsType parameter. Note, that multiple values are allowed, this allows to select all variants of stifness matrix, for example. Note, that the size of dofmans, dofs, weights, weightsLtf arrays should be equal.

  • InteractionBoundaryCondition

    InteractionBoundaryCondition

    Is a special boundary condition prescribed on InteractionPFEMParticles (see interactionparticle in the PFEM part of the FluidStructureProblem. This sort of particles is regarded as it would have prescribed velocities, but the values change dynamically, as the solid part deforms. The velocities are obtained from coupled structural nodes.

  • Body loads

    • Volume flux (load)

      DeadWeight components #(ra)
      Represents dead weight loading applied on element volume (for structural elements). For transport problems, it represents the internal source, i.e. the rate of (heat) generated per unit volume. The magnitude of load for specific i-th DOF is computed as product of material density, corresponding volume and i-th member of components array.

    • Structural temperature load

      StructTemperatureLoad components #(ra)

      Represents temperature loading imposed to some elements. The members of components array represent the change of temperature (or change of temperature gradient) corresponding to specific element strain components. See element library manual for details.

    • Structural eigenstrain load StructEigenstrainLoad components #(ra)

      Prescribes eigenstrain (or stress-free strain) to a structural element. The array of components is defined in the global coordinate system. The number of components corresponds to a material mode, e.g. plane stress has three components and 3D six. Periodic boundary conditions can be imposed using eigenstrains and master-slave nodes. Consider decomposition of strain into average and fluctuating par .. math:: boldsymbol{varepsilon}(boldsymbol{x}) = langle boldsymbol{varepsilon} rangle + boldsymbol{varepsilon}^*(boldsymbol{x})

      where \(\langle \boldsymbol{\varepsilon} \rangle\) can be imposed as eigenstrain over the domain and the solution gives the fluctuating part \(\boldsymbol{\varepsilon}^*(\boldsymbol{x})\). Master-slave nodes have to interconnect opposing boundary nodes of a unit cell.

  • Boundary loads - Constant edge fluxes (load)

    ConstantEdgeLoad loadType #(in) components #(ra) [dofexcludemask #(ia)] [csType #(in)] [properties #(dc)] [propertytf #(dc)]

    • Constant surface fluxes (load)

      ConstantSurfaceLoad loadType #(in) components #(ra) [dofexcludemask #(ia)] [csType #(in)] [properties #(dc)] [propertytf #(dc)]

      Represent constant edge/surface loads or boundary conditions. Parameter loadType distinguishes the type of boundary condition. Supported values are specified in bctype.h:

      • loadType = 2 prescribed flux input (Neumann boundary condition),
      • loadType = 3 uniform distributed load or the convection (Newton) BC. Parameter components contains the environmental values (temperature of the environment) corresponding to element unknowns, and properties dictionary should contain value of transfer (convection) coefficient (assumed to be a constant) under the key ’a’,
      • loadType = 7 specifies radiative boundary condition (Stefan-Boltzmann). It requires to specify emmisivity \(\varepsilon\in\langle 0,1\rangle\), the components array contains the environmental values (temperature of the environment). Default units are Celsius. Optional parameter temperOffset = 0 can be used to calculate in Kelvin.

      If the boundary condition corresponds to distributed force load, the components array contains components of distributed load corresponding to element unknowns. The load is specified for all DOFs of object to which is associated. For some types of boundary conditions the zero value of load does not mean that the load is not applied (Newton’s type of bc, for example). Then some mask, which allows to exclude specific dofs is necessary. The dofexcludemask parameter is introduced to alow this. It should have the same size as components array, and by default is filled with zeroes. If some value of dofExcludeMask is set to nonzero, then the corresponding componentArray is set to zero and load is not applied for this DOF. If the boundary condition corresponds to prescribed flux input, then the components array contains the components of prescribed input flux corresponding to element unknowns.

      The properties can vary in time. Each property can have associated time function which determines its time variation. The time functions are set up using optional propertytf dictionary, containing for selected properties the corresponding time function number. The time function must be registered under the same key as in properties dictionary. The property value is then computed by product of property value (determined by properties) and corresponding time function evaluated at given time. If no time function provided for particula property, a unit constant function is assumed.

      The load can be defined in global coordinate system (csType = 0, default) or in entity - specific local coordinate system (csType = 1).

    • Linear edge flux (load)

      LinearEdgeLoad loadType #(in) components #(ra) [dofexcludemask #(ia)] [csType #(in)]

      Represents linear edge load. The meanings of parameters csType and loadType are the same as for ConstantEdgeLoad. In components array are stored load components for corresponding unknowns at the beginning of edge, followed by values valid for end of edge. The load can be defined in global coordinate system (csType = 0, default) or in entity - specific local coordinate system (csType = 1).

    • InteractionLoad

      InteractionLoad ndofs #(in) loadType #(in) Components #(ra) [csType #(in)] coupledparticles #(ia)

      Represents a fluid pressure induced load in the solid part of the FluidStructureProblem. The meanings of parameters ndofs, csType, and loadType are the same as for LinearEdgeLoad. In Components array are stored load components for corresponding unknowns at the beginning of edge (ndofs values), followed by values valid for end of edge (ndofs values). The load should be defined in global coordinate system (csType = 0) as it acts in normal direction of the edge. Array coupledparticles assign PFEMParticles from the fluid part of the problem providing fluid pressure.

Initial conditions

These records specify description of initial conditions. The general format is following:

InitialCondition #(in) conditions #(dc) The order of particular records is optional, load, boundary or initial condition number is determined by (num#)(in) parameter. The numbering should start from one and should end at n, where n is the number of records. Initial parameters are listed in conditions dictionary using keys followed by their initial values. Now ’v’ key represents velocity and ’a’ key represents acceleration.

Time functions records

These records specify description of time functions, which generally describe time variation of components during solution. The general format is following:

TimeFunctType #(in) [initialValue #(rn)]

The order of these records is optional, time function number is determined by #(in) parameter. The initialValue parameter allows to control the way, how increment of receiver is evaluated for the first solution step. This first solution step increment is evaluated as the difference of value of receiver at this first step and given initial value (which is by default set to zero). The increments of receiver in subsequent steps are computed as a difference between receiver evaluated at given solution step and in previous step.

The numbering should start from one and should end at n, where n is the number of records.

Currently, TimeFunctType keyword can be one from

  • Constant function

    ConstantFunction f(t) #(rn)

    Represents the constant time function, with value f(t).

  • Peak function

    PeakFunction t #(rn) f(t) #(rn)

    Represents peak time function. If time is equal to t value, then the value of time function is given by f(t) value, otherwise zero value is returned.

  • Piecewise function

    PiecewiseLinFunction [nPoints #(in) t #(ra) f(t) #(ra)] [ datafile #("string")]

    Represents the piecewise time function. The particular time values in t array should be sorted according to time scale. Corresponding time function values are in f(t) array. Value for time, which is not present in t is computed using liner interpolation scheme. Number of time-value pairs is in nPoints parameter.

    The second alternative allows reading input data from an external ASCII file. A hash commented line (#) is skipped during reading. File name should be eclosed with ” “.

  • Heaviside-like time function

    HeavisideLTF origin #(rn) value #(rn)

    Up to time, given by parameter origin, the value of time function is zero. If time greater than origin parameter, the value is equal to parameter value value.

  • User defined

    UsrDefLTF f(t) #(expr) [dfdt(t) #(expr)] [d2fdt2(t) #(expr)]

    Represents user defined time function. The expressions can depend on “t” parameter, for which actual time will be substituted and expression evaluated. The function is defined using f(t) parameter, and optionally, its first and second time derivatives using dfdt(t) and d2fdt2(t) parameters. The first and second derivatives may be required, this depend on type of analysis.

    Very general, but relatively slow.

Xfem manager record and associated records

This record specifies the number of enrichment items and simulation options common for all enrichment items. Functions used for enrichment (e.g. Heaviside, abs or branch functions) are not specified here, they are specified for each enrichment item separately. The same holds for the geometrical representation of each enrichment item (e.g. a polygon line or a circle). Currently, OOFEM supports XFEM simulations of cracks and material interfaces in 2D. The input format for the XFEM manager is:
XfemManager numberofenrichmentitems #(in) numberofgppertri #(in) debugvtk #(in) vtkexport #(in) exportfields #(in)
where numberofenrichmentitems represents number of enrichment items, numberofgppertri denotes the number of Gauss points in each subtriangle of a cut element (default 12) and debugvtk controls if additional debug vtk files should be written (1 activates the option, 0 is default).
The specification of an enrichment item may consist of several lines, see e.g. the test sm/xFemCrackValBranch.in. First, the enrichment item type is specified together with some optional parameters according to
EntType #(in) enrichmentfront #(in) propagationlaw #(in)
where enrichmentfront specifies an enrichment front (we may for example employ branch functions at a crack tip and Heaviside enrichment along the rest of the crack, hence the “front” of the enrichment is treated separately) and propagationlaw specifies a rule for crack propagation (this feature is still highly experimental though). Specification of an enrichmentfront and a propagationlaw is optional.
The next line specifies the enrichment function to be used:
EntType #(in)
This is followed by a line specifying the geometric description (e.g. a polygon line or a circle) according to
EntType #(in) extra attributes where the number and type of extra attributes to specify will vary depending on the geometry chosen, e.g. center and radius for a circle or a number of points for a polygon line.
If an enrichment front was specified previously, the type and properties of the enrichment front are specified on the next line according to
EntType #(in) extra attributes
If a propagation law was specified previously, it’s type and properties are also specified on a separate line according to
EntType #(in) extra attributes