Boundary condition objects are used in GeMA to specify boundary conditions applied to a physics equation. Each boundary condition consists of several "lines", each attaching a set of values to an application point. Application points are either a node, a cell, a cell edge, a cell face or sets of them, represented by mesh borders or node sets. The properties attached to an application point are defined in the same way as any mesh attribute or state variable, and their values can be functions, allowing for an easy way to represent boundary conditions that change over time.

The meaning of each of those properties is collectively identified by the boundary condition object type, which is interpreted by the physics object that will ultimately make use of this boundary condition. When creating a model, the physics plugin is the authority that defines which are the available boundary condition types and their required properties. The boundary condition type also specifies the kind of application point for the boundary condition (nodes, cells, cell edges or cell faces).

There can be several boundary condition objects on the simulation file, created by the BoundaryCondition keyword.

Example

BoundaryCondition {
  id   = 'Border temperature',
  type = 'node temperature',
  mesh = 'mesh',
  properties  = {
    {id = 'T',  description = 'External temperature applied on the node', unit = 'degC'},
  },
  nodeValues = {
    {'gridLeft',   100},
    {'gridBottom', 100},
    {'gridRight',  100},
    {'gridTop',    500},
  }
}

Fields

Field	Description	Type	Required
id	The boundary condition name.	String	Yes
description	A description of the boundary condition purpose.	String	No
type	The type of boundary condition. This value should be a type name recognized by the physics object that will apply this boundary condition on the calculations. It provides the semantic interpretation of the boundary condition data.	String	Yes
mesh	The name of the mesh that this boundary condition is associated with.	String	Yes
merge	This option allows for automatic merging of single nodes or cell edges/faces, whose property values are the same, into automatically generated node sets / borders, internal to the boundary condition. This is usefull to conserve resources and is also better for printing boundary conditions. A value of 0 disables merging. A value greater than 0 limits merging to occur only if the boundary condition table has a maximum number of different line values (not number of lines) less than the given value, bounding the time needed for merging (merging will not be done if the table has more than the given number of distinct property values). If you want to do a merge even if the table has a large number of distinct boundary condition property values, just use a big number in here, but be warned that the merge can be slow on those cases. If this option is missing, the value of the `defBCMerge` simulation option will be used instead.	Number	No
properties	The table with the definition of the properties associated with each boundary condition line. Each table entry is a sub-table with a property definition following the syntax described in the Data options page. The set of properties should follow the layout expected by the physics object that will apply this boundary condition type. If you want to save boundary condition application point data to exported files, don't forget to add the `tag` attribute to property values. This option, used together with the `io` process's `saveNodeBcTags` export option, is usefull to check if the model boundary conditions are correct.	Table	Yes
nodeValues	The table with boundary condition values for node based boundary conditions. Each table entry is a subtable that begins with a node number, a border name or a node set name (both from the associated mesh), followed by values for the declared properties. If the application point is given by a border name or by a node set name, the values will be associated to every node in that border/set. If it is a node number, the values will be tied to that node only. Negative values are accepted for associating a boundary condition to a ghost node. See (1) for the syntax used for providing the boundary condition values.	Table	Yes, for B.Cs applied on nodes
nodeValues	Examples: `nodeValues = { { "myBorder", 100 } }` will attach the value 100 to every node in "myBorder" (which should be either a border name or a node set name), while `nodeValues = { { 10, 100 } }` will attach the value 100 to node 10 and `nodeValues = { { -2, 100 } }` will attach the value 100 to the second mesh ghost node.
edgeValues	The table with boundary condition values for edge based boundary conditions. Each table entry is a subtable that begins with an edge difinition or a border name (from the associated mesh), followed by values for the declared properties. If the application point is given by a border name, the values will be associated to every edge in that border. If it is an edge definition, composed by a table with two values, the first with the cell number and the second with the border number, the values will be tied to that edge only. See (1) for the syntax used for providing the boundary condition values.	Table	Yes, for B.Cs applied on cell edges
edgeValues	Examples: `edgeValues = { { "myBorder", 100 } }` will attach the value 100 to every edge in "myBorder", while `edgeValues = { { {10, 2}, 100 } }` will attach the value 100 to border 2 of cell 10. See the Element types documentation for a reference about border numbering for the available mesh element types.
faceValues	The table with boundary condition values for face based boundary conditions. Each table entry is a subtable that begins with a face difinition or a border name (from the associated mesh), followed by values for the declared properties. If the application point is given by a border name, the values will be associated to every face in that border. If it is a face definition, composed by a table with two values, the first with the cell number and the second with the face number, the values will be tied to that face only. See (1) for the syntax used for providing the boundary condition values.	Table	Yes, for B.Cs applied on cell faces
faceValues	Examples: `faceValues = { { "myBorder", 100 } }` will attach the value 100 to every face in "myBorder", while `faceValues = { { {10, 2}, 100 } }` will attach the value 100 to face 2 of cell 10. See the Element types documentation for a reference about face numbering for the available mesh element types.
cellValues	The table with boundary condition values for cell based boundary conditions. Each table entry is a subtable that begins with a cell number, followed by values for the declared properties. The given values will be tied to that cell only. See (1) for the syntax used for providing the boundary condition values.	Table	Yes, for B.Cs applied on cells
cellValues	Example: `cellValues = { { 10, 100 } }` will attach the value 100 to cell 10.
dumpFile	If the boundary condition data was previously saved to a dump file (see State dumping object methods), the contents of the `nodeValues`, `edgeValues`, `faceValues` or `cellValues` table can be loaded from that file, provided that the boundary condition structure, defined by its `id`, `type`, `mesh` and `properties` fields, remains the same as the strucuture of the saved boundary condition. The given file name can include path macros. In that case, said tables are still required (to define the boundary condition application point type), but should be created empty.	String	No
dumpFile	Example: dumpFile = "$SIMULATIONDIR/$SIMULATIONNAME.dmp"`

(1) Boundary condition property values are given in the values table after the application point. Each property value is given as a single table entry, following the same order as the properties where defined on the properties table.

Vector and matrix values should be given as Lua tables, the later either linearized in column major format or as a table of tables. If a boundary condition porperty supports functions, the value can be a string with a function name. It can also be a string if a constMap has been added to the property definition.

nil values in the list will be replaced by the associated property default value. Trailing nil values can be omitted. If a property is a vector or a matrix and one of its components is nil, that value will be replaced by the corresponding default value component. This later feature is used by several physics to allow prescribing only part of a multi-dimensional value (prescribing an x displacment without prescribing an y displacement, for example). Check the physics documentation.