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.

Predictable.

(Updated 7/25/2021, 22h00… )

Cheating a little bit, and teasing a shaded surface, out of a Computer Algebra System.

One of the subjects which I posted about some time ago was, how easy it is for a Computer Algebra System – a CAS – to output a single variable, in order to colour an Iso-Surface, and how hard it is in contrast, to output a normal vector, from whatever Geometry Shader computes the Iso-Surface, such that this normal vector can be used to shade the surface, in a later Fragment Shader invocation.

What needs to be done in ‘3D Game Design’ and (other) ‘CGI’, is essentially that.

But, given that a CAS can be used both, to plot a 3D surface, as well as, to define what the colour-range of this surface is supposed to be, a bit of a trick can be used, to bypass the need actually to compute a normal vector, but to achieve an equivalent result. And this posting will begin with an example which is slightly simpler, than what my earlier posting had assumed. Iso-Surfaces tend to smack of ‘implicit’ functions, while this example is going to start with an ‘explicit’ plot, in which (X) and (Y) are parameters of the function, but where it was already easy to achieve, that a single (Z) value results, such that (X, Y, Z) are in fact the coordinates plotted.

Because we have a Computer Algebra System in the first place, for continuous functions, it’s easy to compute the derivative with respect to one of the parameters. That derivative can be used, just to modulate the brightness of the surface. The simplest example is shown blow:

(Updated 7/10/2020, 6h10… )

How 3D-plotted, implicit functions are often inferior, to ISO-Surfaces rendered for 3D Gaming.

One of the subjects which I revisited in recent weeks has been, that either Computer Algebra Systems, or other numeric toolboxes, may plot functions. And a fact that should be pointed out is, that to plot a function, either as a 2D or a 3D plot, is always numeric, even if it’s being offered as part of what a ‘CAS’ can do (a “Computer Algebra System”). And so, a subcategory of what is sometimes offered, is a 3D plot, of an implicit function, kind of like this one:

This is a plot, of complementary hyperboloids, which are the 3D counterparts to 2D hyperbola.

What some people might just wonder is, how the refined toolbox works, that plots this type of implicit function. And one way in which this can be done, is by generating an ISO-Surface, which is a derived mesh, along which a Density that has been computed from X, Y and Z parameters, crosses a threshold-value, which can just be named (H) for the sake of this posting.

And, in turn, such an ISO-Surface can be computed, by using the ‘Marching cubes algorithm‘. If it gets used, this algorithm forms a geometry shader, which accepts one Point as input topology, and which outputs a number of triangles from (0) to (4).

The question which this posting poses is, whether the mesh which is output by such an algorithm, will always include vertex-normals. And the short answer is No. Applications exist, in which normals are computed, and applications exist where normals are not computed. And so, because some users are used to high-end gaming, and used to seeing shaded surfaces, which can only really be shaded if normals have been made available to a fragment shader, those users might find themselves asking, why Mathematical plotting algorithms might exist, which never compute real normals.

(Updated 5/07/2020, 16h15… )