# Finite Element Method Usage Tips

## Introduction

The aim of this tutorial is to point out possible issues when using the finite element method with NDSolve and offer best practices to avoid potential issues.

In[1]:= |

## Monitoring Progress of Time Integration of Transient Partial Differential Equations

Time integration of partial differential equations can take time. This is especially true if the boundary conditions or coefficients are time dependent or if the PDE region at hand is three dimensional. An easy way to monitor progress of an integration of a transient PDE is by using an EvaluationMonitor.

Using the EvaluationMonitor within NDSolve works as in other cases. Here is an example wave equation with a time-dependent Dirichlet condition.

In[1]:= |

In[6]:= |

In[8]:= |

Once the initialization of the PDE is done, the status area will display the current time during the time integration.

In[11]:= |

## Solving Memory-Intensive PDEs

The amount of memory needed by NDSolve to solve a particular problem with the finite element method is proportional to the number of equations and the space dimension in which you are operating. For coupled systems in 3D, the amount of memory provided by the underlying hardware can be a barrier. The following section identifies easy-to-use options to alleviate this potential barrier.

During the finite element analysis there are two key memory bottlenecks. The first is the creation of the discretization and the second is the solution (LinearSolve) of the system of equations. NDSolve provides options to both mesh generation and the LinearSolve step that have an effect on the memory requirement during discretization and solving. As a rough estimate, the number of coordinates in the internal generated mesh multiplied by the spatial dimension gives the degrees of freedom (number of rows and columns) of the discretized system matrix to be generated.

As an example, consider a stress operator from elastostatics. The stress operator is a system of three coupled PDEs in 3D space. Since the main focus of this section is to create a large system of equations, no additional information about the PDE itself is presented.

In[14]:= |

A series of measurements illustrates how various options influence the solution time and the amount of memory needed to find a solution. For this purpose, a helper function is implemented. The function receives as input any number of NDSolve options and returns the time and the amount of memory in MB needed to solve the PDE. It is also instructive to get a feeling for the size of the system matrices NDSolve internally establishes. The size of the system matrices is its degrees of freedom, or in other words, the number of rows and columns in the system matrices.

In[15]:= |

The default settings in NDSolve are set up such that the solution is accurate and found fairly efficiently. To make this example applicable for a larger class of computers, tetrahedron elements are used. The use of these results in smaller system matrices.

With the default setting, NDSolve will call LinearSolve with no special options. This will route to a direct solver that is very accurate but has a high requirement of available memory.

One way to reduce the memory consumption is to have NDSolve generate a mesh with fewer elements.

This has reduced both solution time and memory requirements at the price of accuracy. How many elements a mesh needs to represent an accurate solution is problem dependent. A good method is to start with a coarse mesh and refine until the solutions stop differing substantially.

A way to further reduce the amount of memory needed for computing the solution is to use a mesh that is only first-order accurate.

This has reduced both solution time and memory requirements at the price of accuracy. Making use of a first-order mesh results in much smaller system matrices, which can be solved more efficiently. Using a first-order mesh may significantly reduce accuracy.

The previous suggestions worked by reducing the size of the system matrices internally generated. A different approach is to instruct NDSolve to use a different solver method for LinearSolve. All options that LinearSolve take can be directly given to NDSolve.

While this takes longer to solve, it uses substantially less memory while at the same time retaining the accuracy, compared to the default solution. The reason that this method is not the default is that the default LinearSolve method is guaranteed to converge if the discretized PDE has a solution. This benevolent property is not true for all solvers implemented in LinearSolve.

The options discussed above can also be combined. A more in-depth treatise of options that can be given to NDSolve can be found in the finite element tutorials.

## Extrapolation of Solution Domains

Interpolation functions in the Wolfram Language will extrapolate if they are queried outside of their domain. In a finite element analysis, this is not wanted, since the extrapolation will almost certainly not give the physically correct value. The interpolation functions NDSolve returns from a finite element analysis will return Indeterminate as an extrapolation value. This behavior can be switched off.

The following PDE is going to be solved over the solution domain.

In[41]:= |

In[42]:= |

The resulting interpolation function can be queried at points that do not belong to the solution domain. This will result in a warning message and Indeterminate as an extrapolated value.

To change the behavior, you can have the interpolation function return an extrapolation value and quiet the warning message.

In[44]:= |

A query point outside the solution domain now returns an extrapolation value and no warning message.

The "DefaultExtrapolationHandler" system option can be set to change the default behavior.

## Stabilization of Convection-Dominated Equations

Consider a convection-diffusion type of equation.

In a situation where the convective component becomes large, the solution of the PDE may become unstable, as shown in the following example.

In[49]:= |

The message indicates that the solution may not be stable. The Péclet number is a dimensionless number and expresses the ratio between convection and diffusion of a physical quantity. The Péclet number is computed as

where is the convective component, is a minimum element diameter, and is the diffusion coefficient. If the Péclet number is larger than the mesh order, then the stability of the solution may become a concern and the message is given.

The result is disastrous. There are a few things that can be done in such situations. First, however, investigate how the Péclet number is computed.

One way to improve the stability of the solution is to add so-called artificial diffusion. This artificial diffusion is then added to the diffusive term in order to stabilize the PDE.

Note that the newly computed Péclet number is smaller than the mesh order.

In[59]:= |

This is already much better. The disadvantage with this method is that the PDE is modified. This may not always be a good approach. As an alternative, the mesh can be modified. For more information about mesh generation, please consult "Element Mesh Generation".

In[64]:= |

The solution is improved compared to the previous example, at the cost of some additional computational time. In principal, it would be sufficient to only refine the right and top boundaries of the mesh. This would then decrease the computational time.

## The Coefficient Form of a PDE

In this example, the importance of the coefficient form of PDEs for the finite element method is demonstrated. The coefficient form for a single dependent variable PDE is given in equation (1).

The PDE is defined in . Here is the dependent variable for which a solution is sought. The coefficients , , , and are scalars; , , and are vectors; and is an × matrix.

The key point of this example is that this equation (and coupled versions of it) is in essence the only equation the finite element method can solve. To emphasize this point, consider the simpler equation (2).

Set up the equation and its coefficients. As a spatial domain for the PDE, is used, and the time integration will be set up to stop at . The diffusion coefficient is set to 1, which will internally get transformed to the identity matrix. For the damping coefficient , a piecewise continuous function is used that has the value of 1 for values of , and 2 otherwise.

In[2]:= |

One could be tempted to reformulate equation (4) in the following manner:

In[6]:= |

Clearly, solution 1 and solution 2 differ. To investigate what happens, write a little helper function that extracts the actually parsed PDE coefficients from NDSolve data structures. For more information on the internal workings of the finite element method, please consult the Finite Element Programming tutorial.

In[10]:= |

The coefficients for equation (7) look as expected.

The coefficients for equation (9) come as a surprise. The coefficient got pulled into the diffusion coefficient . Why is that? The key is to understand that the finite element method can only solve this type of equation.

Note that there is no coefficient in front of the term . To get equations of the type to work, is reset to and is adjusted to get rid of the derivative caused by . Here is an example.

Following the same procedure for the equation (10), you get:

This is effectively the same as explicitly specifying . Mathematically, because of the discontinuity, the coefficient is like a Dirac delta function, which would be omitted in the time integration anyway.

In[17]:= |

For time-dependent PDEs with a discontinuous diffusion coefficient, it is best to arrange the equations such that the coefficient is eliminated from the diffusion term.

## Formal Partial Differential Equations

Formal partial differential equations are equations that have Inactive components. This section explains when PDE need to be inactive. To start with an example, a plane stress operator is defined. For Young's modulus and Poisson's ratio, values for steel are used.

In[67]:= |

The first eigenvalue and eigenfunction of a beam held fixed at the left with length 10 meters and height 0.7 meters are computed.

In[69]:= |

As a means of comparison, the first resonance frequency utilizing Euler–Bernoulli beam theory is computed analytically.

Compare the difference in results; about half the difference is attributable to the different theoretical approaches.

Next, the Active version of the PDE is inspected and the resulting resonance frequency is computed.

The above result is wrong. What happened? In short, the non-inactive version cannot account for unsymmetric coefficients. Looking at the original inactive PDE of the four coefficient matrices, two, the off-diagonal ones, are not symmetric.

In other words, even before NDEigensystem (and other related functions like NDSolve) can parse the PDE in its intended form, it will have evaluated.

From the evaluated PDE, there is no way to recover the antisymmetric coefficients. For this reason Inactive has been introduced. For antisymmetric coefficients, the Inactive version of the PDE is a must.

To inspect the coefficients that have been parsed, NDSolve`ProcessEquations can be used.

## NeumannValue and Formal Partial Differential Equations

This section explains the interaction between formal partial differential equations and Neumann values. In the stationary case, a partial differential equation can be expressed as follows:

On the other hand, generalized Neumann boundary values specify a value . The value prescribes a flux over the outward normal on some part of the boundary:

The derivation of the Neumann boundary value is outlined in Partial Differential Equations and Boundary Conditions. It is important to note that the coefficients , , and in equation (11) are not specified directly by the use of NeumannValue. The coefficients , , and are specified in equation (12). The use of NeumannValue will replace with the value of on the boundary.

Now, the usage of Div and Grad alone is not enough to fully specify equation (13). Consider the specification of

and its corresponding Neumann value:

Consider a case where is given as , is the identity matrix and is a zero vector. Note that the evaluation of the divergence results in

where is and is the divergence of , in this example. Equations (14) and (15) are equivalent.

The evaluation poses a problem, however. Even though the equations are equivalent, the Neumann specifications are not. The corresponding Neumann value for equation (16) has implicitly changed to

To illustrate this further, a helper function is created that parses a PDE and extracts the PDE coefficient data from the finite element data, as explained in "Finite Element Programming".

In[84]:= |

PDECoefficientData is a data structure that contains the parsed PDE coefficients.

During evaluation, the coefficient split into a and term. The proper mechanism to input differential equations where coefficients are evaluated prematurely is by either Inactivate or directly through the use of Inactive.

If a γ term is present one might use the following inactive PDE:

The following example illustrates the difference in meaning of an active and inactive PDE with respect to Neumann values, from a practical perspective. The example shows a diffusion confined in a region subject to a biasing potential .

In[103]:= |

In[104]:= |

Dirichlet boundary conditions are set up at the top and bottom () of the region with a potential of 1 and 0, respectively.

In[106]:= |

At the remaining two sides () natural boundary conditions (Neumann zero) apply. This means zero flux across these two edges.

The PDE to be modeled is given by:

and its corresponding Neumann value at is

In[115]:= |

First the satisfaction of the Neumann values at is inspected.

With zero flux boundary conditions at (no flux across these two edges) and no source terms, the flux into the box at should be the same as the flux out of the box at .

The flux into the box is roughly the same as the flux out of the box. As a comparison, the activated PDE is solved.

In[120]:= |

The coefficient is parsed as a convection and a reaction coefficient.

In the activated case, the boundary condition computed is .

## The Relation between NeumannValue and Boundary Derivatives

The following example explains the relation of a NeumannValue and boundary derivatives, and is set up such that the parameters are easy to modify. First, the region is specified.

The PDE has one dependent variable . Note that since this is a one-dimensional system, the diffusion coefficient is a 1×1 matrix, which can be specified as a number.

Dirichlet boundary conditions specify a value for the dependent variable .

Neumann values are specified by the following form.

Next, the boundary conditions are set up.

In[6]:= |

In[8]:= |

Note how in the DSolveValue formulation of the equation, the generalized Neumann boundary equation has to be given explicitly, and how the coefficients match those in the PDE.

To compare the analytical result to the numerical result, make a plot of the difference between the two.

## Ordering of Dependent Variable Names

In some cases, when analyzing coupled systems of PDEs, the finite element method as implemented in NDSolve may return what seem to be unexpected results. This section explains when this happens and presents solutions to avoid the problem. In the last section, a more in-depth explanation is presented.

First a system of equations with appropriate boundary conditions and a region are set up.

In[125]:= |

In[126]:= |

In[127]:= |

In[128]:= |

The dependent variables for this example are u, v and w. The system is solved and a visualization of the dependent variable w is given.

In a second experiment, the dependent variable name w is changed to p and the system of equations is solved yet again.

The result is unexpected. Before explaining in detail what happens, a way to enforce the expected behavior is presented.

NDSolve offers a finite element method option to specify an interpolation order that should be used for the dependent variables during the discretization of the PDE. The specification of the interpolation order will implicitly enforce the same ordering of the equations and the dependent variables.

Generally, specifying the same interpolation order for each dependent variable is fine. In this specific case, the equations are fluid flow equations (Stoke's flow), and stabilization can be enforced if the pressure variable's Interpolation order is one less than the interpolation order for the velocities u and v.

To investigate this behavior further, an NDSolve state object is created.

In[137]:= |

Note that the ordering of the dependent variables in the FEMMethodData in the FiniteElementData is {p,u,v}.

Inspecting the diffusion and convection coefficients of the PDECoefficientData reveals the structure of the coupled PDE coefficients.

When the finite element interpolation order method option is set, the coefficient structure is adjusted to the canonical order of the dependent variables.

In[141]:= |

In fact, reordering the equations' input to match the canonical order of the dependent variables also gives the expected result.

A remaining question is, why can this reordering not happen automatically?

The inherent challenge is that the boundary conditions specified can only be applied to diagonal components of the coefficients. The reason is that the way the boundary conditions are entered causes the information about how a specific boundary condition relates to a specific equation in the PDE to be lost.

Here each sublist has two parts. The first part indicates the row and column in which the second part—the boundary condition—will be applied during the discretization.

Another option is to associate the Dirichlet boundary conditions with the respective equation to which they are related.

In[148]:= |

In summary, the best option is to specify the interpolation order.