## 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.

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

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:

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… )

## 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….

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

## Getting FreeFem++ to display impressive visuals under Linux.

One of my Computing habits is, to acquire many frameworks, for performing Scientific or Analytical Computing, even though, in all honesty, I have little practical use for them, most of the time. They are usually of some Academic curiosity to me.

Some of the examples familiar to me are, ‘wxMaxima‘ (which can also be installed under Linux, directly from the package manager), ‘Euler Math Toolbox‘ (which, under Linux, is best run using Wine), and ‘SageMath‘ (which IMHO, is best installed under Linux, as a lengthy collection of packages, from the standard repositories, using the package manager, that include certain ‘Jupyter’ packages). In addition to that, I’d say that ‘Python‘ can also be a bit of a numerical toolbox, beyond what most programming languages can be, such as C++, yet, a programming language primarily, which under Linux, is best installed as a lengthy collection of packages through the package manager. And a single important reason is the fact that a Python script can perform arbitrary-precision integer arithmetic natively, and, with a small package named ‘python3-gmpy2′, can also perform arbitrary-precision floating-point arithmetic easily. If a Linux user wanted to do the same, using C, he or she would need to learn the library ‘GMP’ first, and that’s not an easy library to use. Also, there exists IPython, although I don’t know how to use that well. AFAICT, this consists mainly of an alternative shell, for interacting with Python, which makes it available through the Web-interface called “Jupyter”. Under Debian Linux, it is best installed as the packages ‘ipython3′, ‘python3-ipython-genutils’, ‘python3-ipykernel’, ‘python3-nbconvert’, and ‘python3-notebook’, although simply installing those packages, does not provide a truly complete installation… Just as one would want a ‘regular’ Python installation to have many additional packages, one would want ‘IPython’ to benefit from many additional packages as well.

But then, that previous paragraph also touches on an important issue. Each Scientific Computing platform I learn, represents yet-another scripting language I’d need to learn, and if I had to learn 50 scripting languages, ultimately, my brain capacity would become diluted, so that I’d master none of them. So, too much of a good thing can actually become a bad thing.

As a counter-balance to that, it can attract me to a given Scientific Computing platform, if it can be made to output good graphics. And, another Math platform which can, is called “FreeFem“. What is it? It’s a platform for solving Partial Differential Equations. Those equations need to be distinguished from simple derivatives, in that they are generally equations, in which a derivative of a variable is being stated on one side (the “left, bilinear side”), but in which a non-derivative function of the same variable is being stated on the other (the “right side”). What this does, is to make the equation a kind of recursive problem, the complexity of which really exceeds that of simple integrals. (:2)  Partial Differential Equations, or ‘PDE’s, are to multi-variable Calculus, as Ordinary Differential Equations, or ‘ODE’s, are to single-variable Calculus. Their being “partial” derives from their derivatives being “partial derivatives”.

In truth, Calculus at any level should first be studied at a University, before computers should be used as a simplified way of solving its equations.

FreeFem is a computing package, that solves PDEs using the “Finite Element Method”. This is a fancy way of saying, that the software foregoes finding an exact analytical solution-set, instead providing an approximation, in return for which, it will guarantee some sort of solution, in situations, where an exact, analytical solution-set could not even be found. There are several good applications. (:1)

But I just found myself following a false idea tonight. In search of getting FreeFem to output its results graphically, instead of just running in text mode, I next wasted a lot of my time, custom-compiling FreeFem, with linkage to my many libraries. In truth, such custom-compilation is only useful under Linux, if the results are also going to be installed to the root file-system, where the libraries of the custom-compile are also going to be linked to at run-time. Otherwise, a lot of similar custom-compiled software simply won’t run.

What needs to be understood about FreeFem++ – the executable and not the libraries – is, that it’s a compiler. It’s not an application with a GUI, from which features could be explored and evoked. And this means that a script, which FreeFem can execute, is written much like a C++ program, except that it has no ‘main()‘ function, and isn’t entirely procedural in its semantics.

And, all that a FreeFem++ script needs, to produce a good 2D plot, is the use of the ‘plot()‘ function! The example below shows what I mean:

I was able to use an IDE, which I’d normally use to write my C++ programs, and which is named “Geany”, to produce this – admittedly, plagiarized – visual. The only thing I needed to change in my GUI was, the command that should be used, to execute the program, without compiling it first. I simply changed that command to ‘FreeFem++ "./%f"‘.

Of course, if the reader wants in-depth documentation on how to use this – additional – scripting language, then This would be a good link to find that at, provided by the developers of FreeFem themselves. Such in-depth information will be needed, before FreeFem will solve any PDEs which may come up within the course of the reader’s life.

But, what is not really needed would be, to compile FreeFem with support for many back-ends, or to display itself as a GUI-based application. In fact, the standard Debian version was compiled by its package maintainers, to have as few dependencies as possible (‘X11′), and thus, only to offer a minimal back-end.

(Updated 7/14/2021, 21h45… )

## A little trick which can be used in programming, to reduce the CPU load, if the value of a Hypotenuse is being Compared.

A scenario which often happens in computing is, that there exists a quantity, call that (a), which will result accurately by squaring the quantities (x), (y) and (z) first, and then computing the square root of the sum. It could then also be said, that the following explicit function has been defined:


F(x, y, z) := sqrt(x^2 + y^2 + z^2)



Further, the idea exists in Computing, that when all one wants to compute, is (x2) for example, it takes fewer CPU cycles actually to compute (x*x), than it takes, to compute a real power function.

But, the object of the exercise could actually be, not to derive (a) from (x), (y) and (z), but rather, to compare two instances of F(x, y, z).

The biggest issue as such, with actually computing F(x, y, z), is, that to compute the square root, is even slower, than it was to compute (x2), (y2) and (z2). Therefore, if one has the luxury of knowing what (a) is in advance, what one can do, for real-number comparisons, is just to square (a), and then, not to compute the square root, which should exist within the function F(). Therefore, when two known quantities are simply being compared, the following way to do it, will run slightly faster:


a^2 < (x^2 + y^2 + z^2)



In Modern Computing, what is often done is, that actual CPU usage is ignored, to make the task of writing complex code easier, and, the situation may not always be recognizable, that two values are going to be compared, which would both have been computed as the square root of one other value. And so, to avoid having to stare at some code cross-eyed, the practice can be just as valid, to compute two instances of F(x, y, z), but, to compute them with the square root function in each case, and somewhere later in the code execution, just to compare the two resulting values.

Dirk