Proof that FreeFem allows a Simple Integral, to be restated as a PDE, and then solved over 1 axis.

My recent postings have rambled at some length, about the open-source program ‘FreeFem’, the purpose of which is, to solve Partial Differential Equations, which are strictly defined, but which often won’t have exact, analytical solutions. FreeFem approximates their solutions numerically.

My own formal background doesn’t extend much beyond Calculus 2, such that I wasn’t even taught “Ordinary Differential Equations” – aka ‘ODE’s – in a classroom. But what that really means, is just, that I can’t solve one manually. I can still comprehend what problem is being defined, and, given computers that can solve those, can also feed them to my computers to solve.

Of course, ‘PDE’s are more difficult than ODEs, because PDEs are multi-variable.

Long story short, my recent postings have had two main subjects: They have asserted that real-world PDEs, like real-world ODEs, are usually more complicated, than just a form that can be converted directly into an integral. And secondly, I’ve mused over how, then, FreeFem will go about solving them anyway. That second part is speculative.

But, just to make my point, the following is a PDE, which only makes full use of 1 out of its 2 available variables, and which happens to be simple enough, to state a simple integral, but to state it implicitly. Here the FreeFem script:

 

// For label definition.
int Bottom=1;
int Right=2;
int Top=3;
int Left=4;

// The triangulated domain Th is on the left side of its boundary.
mesh Th = square(10, 10, [(x*2)-1., (y*2)-1.]);
plot(Th, ps="ThRectX.eps", wait = true);

// Define a function f.
func f = x * y;

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

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

// Define a PDE, that just integrates f with respect to Y...
solve SimpleXInt(u, v)
	= int2d(Th)(
		dy(u) * v			// Let this be valid syntax.
	)
	- int2d(Th)(
		f*v
	)
	+ on(Bottom, u=0);		// The boundary condition at the start of the integral.

// Plot the result...
plot(u, cmm="Is this an example of the Poisson Equation? f=x*y",
	ps="SimpIntX.eps", value=true, wait = true);

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

 

The way this script works hinges on a simple idea: ‘dx(u)‘ can accurately be computed by FreeFem as ‘the derivative of (u) with respect to (x)’, and evaluates to a real number. Since it was possible just to multiply a function that also evaluates to a real number by ‘v‘, and thus form the RHS of the equation, it should be just as easy, to write ‘dx(u) * v‘ as the LHS. And, after having fixed some minor technicalities peculiar to computing first-order integrals, one can see that this valid syntax computes ‘f(x,y):=x*y‘, and then integrates it once, in the direction that the Y-axis is positive.

 

ImplInt_1

 

SimpIntX

 

Predictable.

(Updated 7/25/2021, 21h50… )

Continue reading Proof that FreeFem allows a Simple Integral, to be restated as a PDE, and then solved over 1 axis.

Print Friendly, PDF & Email

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

Implicitly restating a classical, double integral, using FreeFem.

One of the programs which I’ve been experimenting with, is called “FreeFem”. Actually, it exists both as a library, as well as a set of executables, the latter of which are meant to facilitate its use, in that scripts can be written in a loose but C++-like syntax, that will already produce interesting plots. But, plots can also be meaningless, unless the user understands how they were generated, as well as the underlying Math.

In an earlier posting, I already wrote that a basic weakness of the ~standard~ 2D integrals which FreeFem will solve for, was, that those do not correspond closely to “Double Integrals”, as I was taught those in Calculus 2.

 

Parabola_C_1

 

Just to recap basic Calculus 2: If an integral is supposed to be plotted over two dimensions, then the standard way to do so is first, to declare a variable that defines one of the dimensions, and to declare a second variable that defines the second. Next, a 1-dimensional integral is defined over the inner variable, which results in a continuous function. Next, this continuous function is integrated a second time, over the outer variable, thereby resulting in a double integral.

Even though this could be extended to more dimensions than 2 or 3, there is usually little practical value in actually doing so, at least, in my limited life.

Further, the fact is clear to me that integrals exist, which go beyond this basic definition. For example, “Curl Integrals” also exist… However, for the moment I’m focusing on how to overcome some of the limitations which are imposed by FreeFem. And while working on this problem, I have found a way to force FreeFem to compute the sort of double integral which I was taught. The script below shows how I did this…

 

// For label definition.
int Bottom=1;
int Right=2;
int Top=3;
int Left=4;

// The triangulated domain Th is on the left side of its boundary.
mesh Th = square(10, 10, [(x*2)-1., (y*2)-1.]);
plot(Th, ps="ThRectX.eps", wait = true);

// Define a function f.
func f = x;

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

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

// Define a simple PDE...
solve SimpleXInt(u, v, solver=LU)
	= int2d(Th)(dx(u)*dx(v)+dy(u)*dy(v))	// Show me a kludge.
	- int2d(Th)(
		f*v
	)
	+ on(Bottom, u=0)   // The Dirichlet boundary condition
	+ on(Right, u=0)
	+ on(Top, u=0)
	+ on(Left, u=0);

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


// Now, let's try to plot a double integral...
Vh A, Fh;

func real f2(real xx, real yy) {
//	return xx * yy;
	return xx;
}

func real Fx() {
	real s = 0.;
	for (int i = -5; (i * 0.2) < x; ++i) {
		s += int1d(Th, Left) ( f2(i * 0.2, y) );
	}
	return s;
}

// Compute the x-integrals for reference purposes...
Fh = Fx();

solve Double(A, v)
	= int2d(Th) (
		  dy(A) * dy(v)
	)
	- int2d(Th) (
		Fx() * v
	)
	+ on(Bottom, A=0)   // The Dirichlet boundary condition
	+ on(Right, A=0)
	+ on(Top, A=0)
	+ on(Left, A=0);

plot(A, ps="DoubleIntX.eps", value=true, wait=true);
plot(Fh, value=true);

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

 

This script actually outputs 4 plots and saves the first 3. But, for the sake of this posting, I’m going to assume that there is no reason to show the reader a plot, of a plain, rectangular mesh… The following plot shows the result, when ‘the Poisson Equation’ is simply given for a function of (x), such that:

f(x) = x

 

RectX

 

A simple linear function was given. It can be integrated once or twice, and the plot above shows how FreeFem usually does so, resulting in u(x,y).

One interesting fact about FreeFem is, that this program can be made to compute a 1-dimensional integral explicitly, i.e., without imposing any need, to solve an equation. The resulting sum (a real number) can then simply be returned with a variable, for every maximum value the function was summed to. So, what would be tempting to do next is, to integrate this variable a second time, which might result in a 2-dimensional array. However, there is a basic limitation in how FreeFem works, that would next stand in our way… (:1)

And so, in order for the second (outer) integral actually to be with respect to (y), I used the little trick in the script above. I defined the gradient of Finite Element function (A), with respect to (y) only, and stipulated that it must equal the 1-dimensional integral which was computed before, for all combinations of (x,y). Hence, this second step of my solution is similar to a degenerate Poissson equation, in that the addition of the (x) gradient has simply been dropped.

When this approach gets applied, the following plot results:

 

DoubleIntX

 

Now, there is still something which FreeFem does, which is supposed to be a feature, and which I cannot switch off. That is, to impose that at the boundaries, a certain exact value needs to exist for (A), just as was needed for (u). Documentation states, that by merely defining an equality, the (2D) derivative of a function is supposed to have with some other function, one has not fully defined that function. A boundary value must also be given, and then the resulting “Partial Differential Equation” (‘PDE’) actually defines, either the FE function (u), or the FE function (A). (:2)  Further, the way ‘int1d()‘ is implemented, also applies such boundaries.

For that reason, I can also not just shut off, anything which I feel FreeFem might be doing wrong, every time it tries to solve a PDE. What I can do is, request that this boundary occupy the left-hand side of the rectangular plot, and additionally, make sure that I begin my summation with the same value, thus resulting in a definite and not an indefinite integral every time. Also, I had suspected somewhere, that in order to resolve this issue with 2D plots, it really only needs to be resolved along one inconspicuous axis. In this case, I resolved it explicitly for the X-axis, and the behaviour of the Y-axis fell in line.

Yet, what I can do is observe, that the two plots shown above don’t match. And as long as they don’t, what FreeFem computed in its first plot, was also not a double integral.

(Updated 7/25/2021, 17h30… )

Continue reading Implicitly restating a classical, double integral, using FreeFem.

Print Friendly, PDF & Email

Scilab emphasizes, that the Linux world is rich with Technical / Scientific Computing platforms…

In my previous posting, I listed several (Open-Source) platforms for Computing, available under Linux at no cost, which have emphasis on Technical and Scientific applications. These platforms differ from conventional programming languages, in that conventional languages mainly specialize in allowing applications to be built, that perform a highly specialized function, while technically oriented platforms allow a user to define Math problems to be solved, to do so, and then to define a whole new Math problem to be solved…

My previous posting had also hinted that, when it comes to Computing tools of this kind, I prefer ‘the lean and mean approach’, in which the learning of specialized scripting languages would be kept to a minimum, but where, through his or her own resourcefulness, the User / Scientist knows how to apply Math, to solve their problem…

Yet, solutions do exist which go entirely in a different direction, and I’d say that “Scilab” is one of them. Under Debian Linux, one usually installs it as a collection of packages, from standard repositories, using the package manager.

Scilab is an application – and a workbench – with a rich GUI. It combines many features. But again, If somebody wanted to use it for real problem-solving, what would really count is, to learn its scripting language (which I have not done). Yet, Scilab typically comes with many Demos that tend to work reliably out-of-the-box, so that, even without knowing the scripting language, users can treat themselves to some amount of eye-candy, just by clicking on those….

 

Screenshot_20210709_062947

Screenshot_20210709_063146

Screenshot_20210709_063651

 

As I’ve stated repeatedly, sometimes I cannot gauge whether certain Scientific Computing platforms are really worth their Salt – especially since in this case, they won’t cost much more than a household quantity of salt does. ;-)  But, if the reader finds that he or she needs a powerful GUI, then maybe, Scilab would be the choice for them?

 

Dirk

 

Print Friendly, PDF & Email