Variable Name Lookup and Geometric Scope
The value of an entered expression may in general depend on two external factors: the namespace used for looking up variable names, and the location in the geometry where the evaluation is performed. The latter does not affect the result for a global expression or parameter expression. Namespace lookup is done first, already when the expression is entered in an input field or table; geometric location takes effect only when the expression is evaluated.
Namespace Lookup
When an expression entered in an input field is used, it is first parsed in a namespace decided by the input field. The namespace is defined as a scope prefix that is inserted before all variable names in the expression. The scope prefix consists of a series of namespace identifiers starting with root. and separated by dots. For example, the scope prefix used when parsing inputs in a physics interface is often root.comp1. where comp1 is the name of the Component. Similarly, the scope prefix used when specifying the density in material mat1 in component comp1 is root.comp1.mat1.def. since the density is located in the default property group.
If the resulting composite variable name does not exist in a database containing all variables defined in the model, the scope prefix is shortened by one namespace identifier and a new attempt is made until either the variable is found or the entire scope prefix has been tried. For example, suppose that an input in a physics interface in Component comp1 is set to a+root.a where the variable a has been defined both as a component variable in comp1 and as a global variable or model parameter. That is, both root.comp1.a and root.a exist in the model. The input expression will therefore be parsed to root.comp1.a+root.a. If the expression contains an unknown variable name it will be assumed to belong in the root scope. No error is generated, but a warning may be shown.
Note that the most specific namespace takes precedence so that for example a component variable may hide a global variable or model parameter with the same base name. To access a variable definition in a surrounding namespace, use the fully scoped name starting with root.
Geometric Scope Lookup
A field variable in a component may be defined only on a selection which does not cover the entire geometry. It may also be defined differently and even be of different types on different selections. For example, the variable u (with full name root.comp1.u) may be the dependent variable of a physics interface on the physics interface’s selection, but a user-defined expression on some other domains, and undefined on remaining domains. The namespace lookup and variable name expansion when the expression is parsed does not consider this geometry dependence: the database of defined variables only knows that the variable name root.comp1.u exists.
When an expression containing field variables, such as u in the example above, is evaluated, the expression evaluation machinery will try to find the right definition of u at each location where the expression is evaluated. If the variable is undefined at some evaluation location, an error message will be displayed.
Note that a variable that is defined in a more specific namespace but only on part of the geometry still hides a variable with the same base name in the surrounding namespace - also at geometry locations where the more specific variable is not defined.
That is, if the variable root.comp1.a is defined anywhere in the geometry of Component comp1, then a in an expression will be interpreted as if root.comp1.a was defined everywhere. The interpretation will not fall back to a global definition of root.a on domains where the component variable is undefined.
Averaging of Missing Variables on Boundaries, Edges and Points
Defining a variable on a selection does not automatically make it defined on adjacent lower-dimensional entities. This applies both for user-defined variables and built-in ones introduced by a physics interface. For example, components of the gradient of the dependent variable, ux, uy, and uz, for a dependent variable u in a 3D model, are not defined on boundaries. Using an expression containing ux in the settings of a feature with a boundary selection is still allowed thanks to an automatic averaging mechanism.
If a variable does not exist when trying to evaluate an expression on a boundary, edge, or point an attempt is made to instead evaluate the variable on adjacent entities of higher dimension. Since there may be multiple adjacent entities (no more than two for a boundary, but arbitrarily many for an edge or point), and the variable name may be defined differently on each entity, the mean of the variable’s value over the adjacent entities is used. Only adjacent entities where the evaluation succeeds is included in the mean. For example, if the dependent variable u is defined only on one of two domains adjacent to a boundary, then evaluating ux on the boundary will effectively pick the value from the side where u is defined. Also see the documentation for mean.
Note that each missing variable in an expression is averaged individually. This means that variables in the expression which do exist on a boundary are evaluated as defined on the boundary and not averaged.