For starters, a surprisingly small number of regular polygons can even be used to tile a surface. If we want to avoid leaving any gaps in the space, the condition that needs to be fulfilled is that the internal angle of the polygon has to evenly divide 360. Evenly is the keyword here. The internal angle of regular polygons is $(n-2)*\frac{180}{n}$, where $n$ is the number of sides. Here below is the list of regular polygons of up to 100 sides with the corresponding internal angle:

(3, 60.0)
(4, 90.0)
(5, 108.0)
(6, 120.0)
(8, 135.0)
(9, 140.0)
(10, 144.0)
(12, 150.0)
(15, 156.0)
(18, 160.0)
(20, 162.0)
(24, 165.0)
(30, 168.0)
(36, 170.0)
(40, 171.0)
(45, 172.0)
(60, 174.0)
(72, 175.0)
(90, 176.0)

Of these, only the triangle (60), the square (90) and the hexagon (120) fit well into 360. All the others simply don’t. This first evaluation is enough to shift the initial question from “why the triangle” to “why not the square or the hexagon“? All three of them are in fact theoretically equally capable of tiling whatever “infinite surface”, and it’s not a case that beehives are hexagonal in structure.

Now the practical constraints come in:

1. we don’t deal with boundless surfaces – we always have boundaries, and the meshing needs to follow them as accurately as possible. How much can you bend a square to make it fit a curvy boundary? Not much. With a hexagon the problem is pretty much the same. Triangles, although still not perfect, have one pointy end that can be arranged to follow a curly outline better.
2. in FEM, every vertex of every triangle is a degree of freedom of the linear system that is then solved. Put in twice as many triangles and you’ll get almost twice as many degrees of freedom (not exactly twice as many, but hey, you get the idea). What happens if we use hexagons? Now every tile will yield 6 degrees of freedom! The problem is that these 6 vertexes are not well distributed, since they are all concentrated on the perimeter of the small hexagon – no degree of freedom covers the interior of the hexagon, which will leave quite some non-computational space while still doubling the computational cost of the simulation.

All in all, the triangle is a much less constrained shape. Think of being given a random cloud of 2D points, with the instructions of linking them with a regular polygon of your choice. Obviously no shape will work on the cloud of points as it is, so you are allowed to move the points to fit your tiling. However, the metric that defines your success is how much, overall, you have had to move individual points to manage the tiling with the polygon of your choice. Triangles will inevitably require less adjustment, while hexagons more.

All this discussion gives for granted that we only allow regular polygons. If you want to allow irregular polygons, go on and see what happens, but good luck building a theory where, from the very first piece, “everything can happen”.

The post Why does Finite Elements Methods (FEM) tile domains with triangles? appeared first on Quick Math Intuitions.

(1)  

The first term is responsible of the smearing of the velocity field proportionally to , and is thus called the diffusion term. Intuitively, it controls how much the neighbors of a given point are influenced by the behavior of ; how much velocities (or temperatures: think of whatever you want!) diffuse in the domain.

The second term controls how much the velocities are transported in the direction of the vector field , and is thus called the convective term. A requirement for this problem to be well-posed is that — otherwise it would mean that we allow velocities to vanish or to come into existence.

The instability is particularly likely to happen close to a boundary where a Dirichlet boundary condition is enforced. The problem is not localized only close to the boundary though, as fluctuations can travel throughout the whole domain and lead the whole solution astray.

Transport instability in 1D

The simplest convection-diffusion equation in 1D has the following form:

(2)  

whose solution, for small is approximately just . This goes well with the boundary condition at 0, but not with the condition at 1, where the solution needs to go down to 0 quite abruptly to satisfy the boundary condition.

It’s easy to simulate the scenario with FEniCS and get this result (with and the unit interval divided in 10 nodes):

in which we can infer two different trends: one with odd points and one with even points! In fact, if we discretize the 1D equation with finite elements we obtain:

(3)  

aha! From this we see that, if is not of the same order of magnitude of (i.e. if ), then the first factor becomes negligible. The problem then is that the second term contains only and . but not . This will make it such that each node only talks to its second closest neighbor, explaining the behavior we saw in the plot before. It’s like even nodes make one solution and odd nodes a separate solution!

If , the solution that comes out is quite different:

As we expected: a linear solution rapidly decaying towards the right. This is because in the above plot we had , i.e. unit interval divided in 100 nodes.
Also notice how the problem does not pop up if the boundary conditions agree with the ideal solution (i.e. if the BC on the right is 1 instead of 0).

Solving the transport instability with a stabilization coefficient

The easiest dynamic way to fix the issue is to introduce an artificial component to to make sure that the first term of the transport equation is never neglected, regardless of the relationship between mesh size and . This is a stabilization parameter:

(4)  

where is the mesh smallest diameter. There is no single correct value for : it quite depends on the other values (although it must be ). Anyway, a good starting point is , which can then be tweaked according to results. This way feels a bit hacky though: “if we can’t solve it for , let’s bump it up a bit” is pretty much the idea behind it.

With this formulation it’s also possible to derive what mesh size is needed to actually use a particular value for . For example, if we’d like the second derivative term to have a coefficient, then we need a mesh size , achieved with a 300×300 mesh, for example (which you can find out with
m=300; mesh=fenics.UnitSquareMesh(m,m); mesh.hmin()
). A uniformly fine mesh might not be needed though: it is often enough to have a coarse mesh in points where not much is happening, and very fine at problematic regions (such as boundaries, for this example).

Code — Convection-diffusion equation 1D

from fenics import *
import matplotlib.pyplot as plt

mesh = UnitIntervalMesh(100)
V = FunctionSpace(mesh, 'P', 1)

bcu = [
DirichletBC(V, Constant(0), 'near(x[0], 0)'),
DirichletBC(V, Constant(0), 'near(x[0], 1)'),
]
u = TrialFunction(V)
v = TestFunction(V)
u_ = Function(V)
f = Constant(1)
epsilon = Constant(0.01)
beta = Constant(0.5)
hmin = mesh.hmin()

a = (epsilon+beta*hmin)*dot(u.dx(0), v.dx(0))*dx + u.dx(0)*v*dx
L = v*dx

solve(a == L, u_, bcs=bcu)

print("||u|| = %s, ||u||_8 = %s" % ( \
round(norm(u_, 'L2'), 2), round(norm(u_.vector(), 'linf'), 3)
))

fig2 = plt.scatter(mesh.coordinates(), u_.compute_vertex_values())
plt.savefig('velxy.png', dpi = 300)
plt.close()

#plot(mesh)
#plt.show()

The post Reproducing a transport instability in convection-diffusion equation appeared first on Quick Math Intuitions.