Tensors in COMSOL Multiphysics

The equations underlying physics interfaces have typically been formulated in terms of tensors, before being converted into the component form that is required by the expression evaluator and matrix assembly code in the core of COMSOL Multiphysics. This conversion is to a large extent automatic: inside the physics interfaces, the equations are represented using vector and matrix objects with well-defined tensor (transformation) properties. When equations are exported for assembly, or for display in nodes, these objects are flattened into collections of variables representing their components in some coordinate system. In order to interpret the values of these variables in postprocessing, or to use them correctly in other equations, it is important to know what kind of components they are, which coordinate system they refer to, and sometimes how they transform between systems.

For some component variables, the coordinate system they refer to is written out in the variable’s description, which is visible in postprocessing, in and in menu trees. But in many cases, component properties are implied by the type of variable the components belong to and by the indices uses to generate unique variable names for its components. This section intends to provide some guidance for interpreting the meaning of tensor component variables based on their name and origin.

Tensor component variable names are generally generated from a base name (the tensor name) by adding one or two indices. This is done using one of two available principles: either indices are coordinate names from the coordinate system to which the index refers, or they are numbers 1, 2 and 3.

The most common situation is that a vector or matrix variable is exported as components in one of the four standard frames, and then normally uses that frame’s coordinate names as indices. All frame coordinate names which are currently used in a Component can be inspected (and changed) in the node’s window. The default names for the spatial and material frames in a 3D model are x, y, z and X, Y, Z, respectively. For example, a vector a in the material frame has components denoted by aX, aY, and aZ, while one in the spatial frame would have components ax, ay, and az.

Tensors which are represented as component variables referring to a user-defined coordinate system often but not always use the coordinate names specified in the coordinate system nodes window as indices. For example the normal direction component of a vector a in the default would typically be called an.

Remaining tensors have their components denoted by numerical indices. For example, a vector a can have components a1, a2, and a3. Such indices are always used when components refer to some implicit coordinate system (which does not exist as a node in the Model Builder tree), but also in other situations where it has been found more convenient to avoid dynamically changing component names when frame or coordinate system coordinate names are changed. This is for example the case for components of base vectors and transformation matrices defined by coordinate system nodes, and for tensors used internally in structural mechanics interfaces.

It is not possible to tell whether or not the indices are covariant or contravariant just from the component variable names, since they are not subscripted or superscripted. It is up to the user to keep track of these properties when necessary. It is also not possible to tell whether proper interpretation of the component requires a volume reference, and if so, which volume reference that would be. For example, you cannot just by looking at component names tell the difference between a nominal stress vector (referring to the material frame surface area) and a true stress vector (referring to the spatial frame surface area). One possible way of checking the variance and density properties of a tensor’s component variables is to insert it into one of the transform features (Vector Transform or Matrix Transform), and observe how the input coordinate system settings are updated.

The bottom line is that when a component variable uses a frame or coordinate system coordinate as index, you can rest assured that the component value refers to the corresponding system. When the index is a number, you have to check the variable’s description and the context in which it is used to find out which system it refers to. And the same thing applies when covariance, contravariance, or density properties are important

Tensor objects used inside a physics interface are tied to a coordinate system, that can be a standard frame, one defined by the user under , or created implicitly inside the interface. Each component (each index) of a tensor is also set to be either covariant or contravariant. In some cases, it is important to keep track of this.

For example, contravariant components of a vector are transformed from a user-defined coordinate system to the underlying frame system by contracting over the first index of the transformation matrix defined by the coordinate system feature (multiplying the vector with the transformation matrix from the left). Covariant components are transformed in the same direction by contracting over the second index of the inverse of the transformation matrix (multiplying the vector from the left with the transpose of the inverse). If the coordinate system is orthonormal in the underlying frame, the transpose of the transformation matrix is equal to its inverse, and the transpose of the inverse is the transformation matrix itself. So in that case covariant and contravariant components transform in the same way. But if the coordinate system is nonorthonormal, covariant components transform using a different matrix.

By convention, all user inputs that may have matrix or vector form are set to be fully contravariant. This is not explicitly stated. For example, in the Heat Transfer in Solids interface, two possible inputs are the velocity vector v and the thermal conductivity matrix k. What is entered as the components for those tensors is treated as being contravariant components. This does not matter as long as only orthonormal coordinate systems are used, but it will make a difference otherwise. Just like the unit needs to be specified when entering numerical values, the basis in which the components represent the tensor needs to be known in order for the values to have a meaning.

Consider now the physical variables that the equations are solved for, and whether they “should” be covariant or contravariant. A tensor is not inherently covariant or contravariant - the different kinds of components are just two ways of expressing the same thing. For the sake of consistency, the convention is that most variables are stored as their contravariant components. However, in order to avoid unnecessary transformations of the components between bases, it is sometimes advantageous to store the covariant components instead.

A few examples of this can be taken from different physics interfaces. In the Structural Mechanics Module, two second order tensors are the stress tensor σ and the strain tensor ε. The colon product between these tensors appears in expressions for energy, and in particular in the weak formulation used to build the stiffness matrices in the finite element formulation. It is therefore more convenient if one is covariant and one is contravariant, since then

without the need to involve or even specify a metric.

In the COMSOL Multiphysics software, the stress tensor is stored with contravariant components while the strain tensor is stored with covariant components. Another example can be taken from the AC/DC Module, having variables as the electric field vector E, the magnetic flux density B, and the magnetic vector potential A. Two of Maxwell’s equations containing these can be written as

and

Since the gradient of a scalar originally has covariant components, it is practical if the other vectors appearing in the first equation are covariant as well, for consistency. Because the curl operator changes the variance of its argument, this would require the magnetic flux density to be contravariant, in order to have consistency in the second equation. This is exactly how these variables are stored—the electric field and the magnetic vector potential with covariant components and the magnetic flux density with contravariant components.

In general, you can expect gradients to be represented by covariant components, and fluxes to be represented by contravariant components. The constitutive tensors will then be contravariant in all indices.

There is one more important property that variable components can have, namely whether they are tensor densities or not. A tensor density is, generally speaking, something that is measured per volume or per area. Such variables need an extra multiplication by a volume factor when transformed between coordinate systems. There are also tensor capacities which transform as a volume or under a change of coordinate system. Note that in addition to vectors and matrices, also scalars can be densities or capacities. The common mass density is an example of the former, while the dvol variable representing mesh element volume is a scalar capacity.

It is important to note which physical variables should have which tensor density weights. This is stricter than whether or not the components are covariant or contravariant because it is a physical fact rather than a matter of interpretation. Some variables must be tensor densities because of their physical origin. This applies in particular for all fluxes of a conserved quantity, for example the electric current density J. Many material properties must be densities because of the way they appear in constitutive relations: multiplying a gradient (which is a plain vector) to produce a flux (which is a vector density).

There are two kinds of transformations of tensor objects that need to be performed on a regular basis during manipulation of variables and equations. Inside the physics interfaces they are automatically carried out when necessary.

Raising and lowering indices is done by contraction with the metric tensor, which in COMSOL is denoted by gSub or gSup, depending on whether it is covariant (subscripted indices) or contravariant (superscripted indices). It is used when tensors are entered into expressions on the ‘wrong’ form. For example, if a dot product is taken between two vectors a and b, they need to be on the opposite form since

If both vectors are entered as covariant, or both contravariant, the metric is used to raise or lower the index of one of them. The same applies for other operations, like the colon product or the cross product, where it is important which components are used.

Transformations between the different coordinate systems are also needed when generating equations and variables, both between the different standard frames and between user defined coordinate systems. For example, if the two input tensors for some kind of operation have their components defined in different frames, one needs to be transformed to the other’s frame. When making such coordinate transformations it becomes important whether components are covariant or contravariant. Otherwise, the components will transform with the inverse transpose of the correct transformation matrices, having components on the form

instead of

, or vice versa. For orthonormal systems it does not technically make a difference, but for consistency and to ensure that it works in all systems equations are expected to be formally correct. It also becomes important that they are correctly labeled as tensor densities with the right weight, since that also affects the transformation.