Proving that FreeFem is capable of solving PDEs, in which a boundary’s values exist as a function, and not as a constant.

One of the subjects which have been fascinating me in recent days and weeks, has been the program ‘FreeFem’, which is an open-source program, that approximates solutions to “Partial Differential Equations” – ‘PDE’s – such that the solutions result as Finite Element functions, the interpolations of which are also continuous.

A stipulation is to be solved for each time, that an equation that subtracts some sort of ‘regular function’ from the gradients of the solution-function, results in values that converge on zero. Presumably, one of the many strategies which FreeFem applies, to achieve this result, is successive approximation. I’ve written in numerous postings, what my hypotheses are, as to the detailed calculations which FreeFem might be performing. But in reality, the program achieves its goals so well, that the underlying Math can be difficult if not impossible to reveal, in a scripting language which is supposed to solve the PDE instead, in such a way that evidence of the methodology cancels out, on the solution. Thus, I have no real proof for most of my hypotheses.

One recent observation which I did want to follow up my own postings about, was, that the default situation for the PDEs is one, in which a Test Function is to be matched by the gradients of the solution, and, that Dirichlet Boundaries are defined, at which the value of the solution must be one exact value for each boundary. In contrast with this situation, FreeFem allows PDEs to be defined using the ‘- int1d(...) (...)‘ expression, which then replaces such a Test Function, and which effectively tells the solver, ‘Please don’t integrate this function.’

And, because the developers became ambitious with their goal, that very complicated meshes can be constructed and then solved over, that have numerous boundaries and not just 2 or 4, I suppose this also means that a PDE of the sort which I just described will receive values of some sort, as long as at least 1 boundary receives a Dirichlet value.

The following script generates and then plots such a PDE:

 

// Load Cubic polynomial interpolator
load "Element_P3";

// Caution:
// Cubic interpolations are often unneccessary, and may
// overshoot their endpoints.
// They're usually only needed, for second-degree
// Derivatives, which lead to second-order Differential Equations.

// A P3-derived fespace will nevertheless be used here.

// For label definition.
int Outer = 1;
int Inner = 2;

// Define mesh boundary.
border C1(t=0, 2*pi){x=cos(t); y=sin(t); label=Outer;}
border C2(t=0, 2*pi){x=cos(t) * 0.5 + 0.2; y=sin(t) * 0.5 + 0.2;
						label=Inner;}

// The triangulated domain Th is on the left side of its boundary.
mesh Th = buildmesh(C1(100) + C2(-40));
plot(Th, ps="ThWithHole.eps", wait = true);

// Define a function f.
real Pi = 3.1415926536;
func f = sin(Pi * x) * cos(Pi * y);

// The finite element space defined over Th is called Vh here.
fespace Vh(Th, P3);
Vh u, v;	// Declare u and v as piecewise P3-continuous functions.

// Get the clock in seconds.
real cpu=clock();

// Define a PDE, in which the values of the outer boundary are defined by f...
solve Poisson(u, v, solver=LU)
	= int2d(Th)(    	// The bilinear part
		  (dx(u) * dx(v))
		+ (dy(u) * dy(v))
	)
	- int1d(Th, Outer)(	// Applying the 1-D boundary function.
		f * v
	)
	+ on(Inner, u=0);   // The Dirichlet boundary condition

// Plot the result...
plot(u, ps="VariableBoundaries.eps", value = true);

// Display the total computational time.
cout << "CPU time = " << (clock()-cpu) << endl;

 

(Revised 7/19/2021, 19h30. )

And, the following is the relevant plot that results:

 

VariableBoundaries

 

(Update 7/21/2021, 16h40: )

If I combine this observation, with what I wrote in a previous posting, I surmise that the solver will first process the boundary ‘Outer‘, by applying function ‘f()‘, with interpolation weights, over all of (v), negatively, but in a way that ultimately depends on what ‘f()‘ was on that boundary. And then, when the boundary ‘Inner‘ is to be processed, the solver will apply the value (0.) over (u) as well as (v), using the same methodology, that involves a new set of weights specific to ‘Inner‘.

Then, (u) will be adjusted, by multiplying the values of the expression with ‘sign(sign(dx(v) + dy(v)) + 0.5)‘, and subtracting (the values of the expression) from (u), until those values become sufficiently close to zero, for all combinations of (x,y).

Why not?


 

(Update 7/20/2021, 11h30: )

In order for changes which are being written to (u), to cause ‘the values of the expression’ to converge on zero, the contribution which the term starting on Line 38 makes to the value of the expression, must still be an integral.

Presumably, FreeFem stores the values of the expression, as two hidden properties of the mesh, which the user, who is writing and testing the script, has no access to. One of those properties would simply act as ‘a temporary buffer’, which allows interpolation between actual, computed values, while the other will receive the result from the interpolation.

If the optimization is desired, that the term starting on Line 42 is only to be computed once, since what is being computed there does not, itself, depend on (u), the mesh would need to possess a third hidden property, where that can be stored (or, which constant values from multiple, Linear terms in the expression can be added to).

And, it’s because Line 38 is still being computed as an integral, that the boundary values of (u) in the upper-right-hand quadrant of the plot (along the non-constant boundary ‘Outer‘), do not quite reach the (negative) amplitudes, which the boundary-values of (u), in the lower-right-hand quadrant of the plot, reach.


 

(Update 7/20/2021, 20h50… )

Note:

Throughout this blog, I’ve been referring to PDE boundaries that have a constant value as ‘the Dirichlet Boundaries’, while in this posting, referring to ‘the boundary that has a non-constant value’, as such. This is really just an arbitrary way I have of differentiating between two types of FreeFem syntax, that does not have much formal validity.

Be that as it may, FreeFem requires at least 1 boundary to have a constant value, in order to generate values for the plot, since this is also its starting point of an integration.

 

 

Enjoy,
Dirk

 

Print Friendly, PDF & Email

One thought on “Proving that FreeFem is capable of solving PDEs, in which a boundary’s values exist as a function, and not as a constant.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>