freefem / freefem-sources Goto Github PK

Hello,

I saw that it was possible to add new types of finite elements to freefem ++.
Do you think that the freefem ++ structure is compatible with the finite element family described in this paper (doi: 10.1109 / TAP.2012.2194660).
This kind of finit element should enable to treat the singularity of electric or magnetic field occuring at the junction of several dielectrics/ or sharp metal edges.

Best regards,

Bonjour,

J ai vu qu il etait possible d adjoindre de nouveaux types d elements finis a freefem++.
Pensez vous que la structure de freefem++ soit compatibles avec la famille d elements finis decrits dans ce papier de Webb (doi: 10.1109/TAP.2012.2194660)
Ce type d elements doit permettre de traiter les singularites de champ electrique ou magnetique advenant aux points de contacts de plusieurs dielectriques ou encore a proximite de pointes metalliques..

Bien cordialement,

Environment variable FF_INCLUDEPATH is not split when it contains several paths separated by ":" on Unix systems. Here is the error message coming from examples++/include.edp (take a look at the last try):

--lex open :funct.edp
--lex open :/home/cdoucet/Depots/github/FreeFem-sources/examples++:/home/cdoucet/Depots/github/FreeFem-sources/examples++-3d:/home/cdoucet/Depots/github/FreeFem-sources/examples++-load/funct.edp
Error openning file funct.edp in:
-- try :"funct.edp"
-- try :"/home/cdoucet/Depots/github/FreeFem-sources/examples++:/home/cdoucet/Depots/github/FreeFem-sources/examples++-3d:/home/cdoucet/Depots/github/FreeFem-sources/examples++-load/funct.edp"

when FF_INCLUDEPATH is defined by

export FF_INCLUDEPATH=$FF_INCLUDEPATH:/home/cdoucet/Depots/github/FreeFem-sources/examples++:/home/cdoucet/Depots/github/FreeFem-sources/examples++-3d:/home/cdoucet/Depots/github/FreeFem-sources/examples++-load

The extract function of the msh3 library run out of memory (128G RAM machine) on this example:
ExtractExample.txt
(the file extension is .txt due to Github limitations, it is an .edp file)

The error occurs in msh3.cpp - line 5952

Is it due to a mesh misdefinition or to the FQuadTree function ?

I have replicated the approach described in section 34.1.1 of the FEniCS manual (edge elements in X,Y and Lagrangian in Z) separating transverse and longitudinal E field components to find rectangular waveguide mode cutoff frequencies. https://launchpadlibrarian.net/83776282/fenics-book-2011-10-27-final.pdf

The problem replicates Example 3.1 in Pozar "Microwave Engineering."

If I run the attached file with "FreeFEM++ EFieldEigenCutoff.edp -s 40000" (-s sets the shift in meter^-2 for the eigenvalue problem) I can get the first few TM modes (a few spurious solutions pop up near 0 eigenvalue). Or if the boundary condition is modified to "+ on(horiz,vert,Ex=0,Ey=0);" I can get the first few TE modes. However, in both cases the solver works by treating only the Z field and forcing the transverse components to zero (not invalid in this case, but not the 3 component vector field solution it was supposed to find). My real interest is in more general non-TE/TM mode problems so this is rather discouraging.

Side note: I implemented other modesolvers in FreeFEM++ in 2D before using only the H field and found that with P2 elements the penalty on the divergence caused the eigenvalues to be very unreliable, so I was very hopeful the formulation attached with edge elements would work. The element issue is summarized nicely here: https://fenicsproject.org/docs/dolfin/2018.1.0/python/demos/maxwell-eigenvalues/demo_maxwell-eigenvalues.py.html

(The reduction matrix routine in the middle of the script was tested to help the eigenvalue solver, but it wasn't necessary.)

Thank you!
EFieldEigenCutoff2.txt

Hi there,

thank you for putting together the nice new looking documentation.
I'm trying to get started with FreeFem and read through the heat exchanger example.
I just wanted to say two things about this example:

• I first got confused about the modelling of this situation: one conductor is modelled as a boundary condition (C1 at 60°C) while the other is as a volume.
• the text says that kappa in conductor C2 is 5 times larger than in C0 but the code says 3 times larger Vh kappa=1 + 2*(x<-1)*(x>-2)*(y<3)*(y>-3);

I think that this example could be made more beginner friendly by clearly putting an illustration of the situation with C0, C1 and C2 at the beginning of the problem description. Otherwise, adjusting the description to the code would reduce confusion (Vh kappa=1 + 4*(x<-1)*(x>-2)*(y<3)*(y>-3);).

Best regards,
Florian

Does anyone successfully compile FreeFem++ with PaStiX solver enabled (linux/macosx) ?

What is the status of examples-bamg? When I type 'make check' inside it, the output is not standard and the command fails. Should it be ignored? Can we remove it?

Hi there !

I am a long-time user of the FreeFEM suite on Mac OS X platforms (I started using early versions around 2000). Everything has always run smoothly on all my machines until now.

The latest full version (3.61), which ran perfectly on Mac OS 10.13, suddenly stopped executing as soon as I upgraded to Mac OS 10.14. The 4.0 beta version does not seem to run on that version of the OS either. Note that I witnessed the same problem on different machines (Macbook and Macbook Pro), so it definitely seems to be an issue with the OS and not with the machine architecture.

Any clue as to how I may solve this problem ?
Thank you,

Pierre Carles
Sorbonne Université

Hi. I have downloaded the ubuntu-source-master zip file but I cannot run FreeFem++.
I cd into the binaries folder by typing
cd/freefem++-source-master/bin
and then I run
./FreeFem++
However, I am returned a message saying that the library libhdf5_serial.so.10 is missing. Could you please help me out?

I currently build a thermal radiation alogrithm using an external software to compute the thermal view factor.
This software returns me a "density map" at each edge center (2D), and I want to import this in FreeFem++ in order to use it directly as a parameter of my thermal radiation problem.

Does anyone know an elgent way to do this ?

PS: I can modify the thermal view factor software output if necessary

Freefem++ v3.47 on linux.
When trying to run the following script: FreeFem-doc/docs/documentation/MeshGeneration.md#mesh-connectivity-and-data

Mesh Connectivity and data

The following example explains methods to obtain mesh information.

// Mesh
mesh Th = square(2, 2);

cout << "// Get data of the mesh" << endl;
{
	int NbTriangles = Th.nt;
	real MeshArea = Th.measure;
	real BorderLenght = Th.bordermeasure;

	cout << "Number of triangle(s) = " << NbTriangles << endl;
	cout << "Mesh area = " << MeshArea << endl;
	cout << "Border length = " << BorderLenght << endl;

	// Th(i) return the vextex i of Th
	// Th[k] return the triangle k of Th
	// Th[k][i] return the vertex i of the triangle k of Th
	for (int i = 0; i < NbTriangles; i++)
		for (int j = 0; j < 3; j++)
			cout << i << " " << j << " - Th[i][j] = " << Th[i][j]
				 << ", x = " << Th[i][j].x
				 << ", y= " << Th[i][j].y
				 << ", label=" << Th[i][j].label << endl;
}

cout << "// Hack to get vertex coordinates" << endl;
{
	fespace femp1(Th, P1);
	femp1 Thx=x,Thy=y;

	int NbVertices = Th.nv;
	cout << "Number of vertices = " << NbVertices << endl;

	for (int i = 0; i < NbVertices; i++)
		cout << "Th(" << i << ") : " << Th(i).x << " " << Th(i).y << " " << Th(i).label
			 << endl << "\told method: " << Thx[][i] << " " << Thy[][i] << endl;
}

cout << "// Method to find information of point (0.55,0.6)" << endl;
{
	int TNumber = Th(0.55, 0.6).nuTriangle; //the triangle number
	int RLabel = Th(0.55, 0.6).region; //the region label

	cout << "Triangle number in point (0.55, 0.6): " << TNumber << endl;
	cout << "Region label in point (0.55, 0.6): " << RLabel << endl;
}

cout << "// Information of triangle" << endl;
{
	int TNumber = Th(0.55, 0.6).nuTriangle;
	real TArea = Th[TNumber].area; //triangle area
	real TRegion = Th[TNumber].region; //triangle region
	real TLabel = Th[TNumber].label; //triangle label, same as region for triangles

	cout << "Area of triangle " << TNumber << ": " << TArea << endl;
	cout << "Region of triangle " << TNumber << ": " << TRegion << endl;
	cout << "Label of triangle " << TNumber << ": " << TLabel << endl;
}

cout << "// Hack to get a triangle containing point x, y or region number (old method)" << endl;
{
	fespace femp0(Th, P0);
	femp0 TNumbers; //a P0 function to get triangle numbering
	for (int i = 0; i < Th.nt; i++)
		TNumbers[][i] = i;
	femp0 RNumbers = region; //a P0 function to get the region number

	int TNumber = TNumbers(0.55, 0.6); // Number of the triangle containing (0.55, 0,6)
	int RNumber = RNumbers(0.55, 0.6); // Number of the region containing (0.55, 0,6)

	cout << "Point (0.55,0,6) :" << endl;
	cout << "\tTriangle number = " << TNumber << endl;
	cout << "\tRegion number = " << RNumber << endl;
}

cout << "// New method to get boundary information and mesh adjacent" << endl;
{
	int k = 0;
	int l=1;
	int e=1;

	// Number of boundary elements
	int NbBoundaryElements = Th.nbe;
	cout << "Number of boundary element = " << NbBoundaryElements << endl;
	// Boundary element k in {0, ..., Th.nbe}
	int BoundaryElement = Th.be(k);
	cout << "Boundary element " << k << " = " << BoundaryElement << endl;
	// Vertice l in {0, 1} of boundary element k
	int Vertex = Th.be(k)[l];
	cout << "Vertex " << l << " of boundary element " << k << " = " << Vertex << endl;
	// Triangle containg the boundary element k
	int Triangle = Th.be(k).Element;
	cout << "Triangle containing the boundary element " << k << " = " << Triangle << endl;
	// Triangle egde nubmer containing the boundary element k
	int Edge = Th.be(k).whoinElement;
	cout << "Triangle edge number containing the boundary element " << k << " = " << Edge << endl;
	// Adjacent triangle of the triangle k by edge e
	int Adjacent = Th[k].adj(e); //The value of e is changed to the corresponding edge in the adjacent triangle
	cout << "Adjacent triangle of the triangle " << k << " by edge " << e << " = " << Adjacent << endl;
	cout << "\tCorresponding edge = " << e << endl;
	// If there is no adjacent triangle by edge e, the same triangle is returned
	//Th[k] == Th[k].adj(e)
	// Else a different triangle is returned
	//Th[k] != Th[k].adj(e)
}

cout << "// Print mesh connectivity " << endl;
{
	int NbTriangles = Th.nt;
	for (int k = 0; k < NbTriangles; k++)
		cout << k << " : " << int(Th[k][0]) << " " << int(Th[k][1])
			 << " " << int(Th[k][2])
			 << ", label " << Th[k].label << endl;

	for (int k = 0; k < NbTriangles; k++)
		for (int e = 0, ee; e < 3; e++)
			//set ee to e, and ee is change by method adj,
			cout << k << " " << e << " <=> " << int(Th[k].adj((ee=e))) << " " << ee
				 << ", adj: " << (Th[k].adj((ee=e)) != Th[k]) << endl;

	int NbBoundaryElements = Th.nbe;
	for (int k = 0; k < NbBoundaryElements; k++)
		cout << k << " : " << Th.be(k)[0] << " " << Th.be(k)[1]
			 << " , label " << Th.be(k).label
			 << ", triangle " << int(Th.be(k).Element)
			 << " " << Th.be(k).whoinElement << endl;

	real[int] bb(4);
	boundingbox(Th, bb);
	// bb[0] = xmin, bb[1] = xmax, bb[2] = ymin, bb[3] =ymax
	cout << "boundingbox:" << endl;
	cout << "xmin = " << bb[0]
		 << ", xmax = " << bb[1]
		 << ", ymin = " << bb[2]
		 << ", ymax = " << bb[3] << endl;
}

`-- FreeFem++ v 3.470000 (date 2017-12-20)
Load: lg_fem lg_mesh lg_mesh3 eigenvalue
1 : // Mesh
2 : mesh Th = square(2, 2);
3 :
4 : cout << "// Get data of the mesh" << endl;
5 : {
6 : int NbTriangles = Th.nt;
7 : real MeshArea = Th.measure;
8 : real BorderLenght = Th.bordermeasure No operator .bordermeasure for type

I've got the following error:

Error line number 8, in file Lap1D.edp, before token bordermeasure
current line = 8 Compile error : line number :8, bordermeasure error Compile error : line number :8, bordermeasure code = 1 mpirank: 0

Has .bordermeasure been replaced ? Is this script still working ?

I get the following error message from examples++/ccc-adp.edp

-- FreeFem++ v 3.500000 (date ' Wed Jul 18 09:02:54 CEST 2018')
Load: lg_fem lg_mesh lg_mesh3 eigenvalue
1 : // -----
2 : real eps = 0.0001;
3 : real h=1;
4 : real hmin=0.000005;
5 : real val=50;
6 : real coef=50; // err = 1/100
7 : int nbiter=10,firstplot=3;
8 : func f = yxx+yyy+htanh(val(sin(5.0y)-2.0x));
9 : ofstream fff("err.dat");
10 : cout << atanh The Identifier atanh does not exist

Error line number 10, in file /builds/workspace/FreeFem-source-feature-cmake-UbuntuAll/examples++/ccc-adp.edp, before token atanh

current line = 10
Compile error :
line number :10, atanh
error Compile error :
line number :10, atanh
code = 1 mpirank: 0

Attached is the edp file when executed on windows 7 64bit.
It seems that ".mesh" works but ".msh" does not.

load "msh3"

int In = 1;
int Out = 0;
real dl = 0.01;

border O1(t=-pi,pi) {x=3.*cos(t);y=3.*sin(t); label=Out; }
border I1(t=pi,-pi) {x=1.*cos(t);y=1.*sin(t);label=In;}

mesh Th2 = buildmesh(O1(6.*pi/dl)+I1(2.*pi/dl));

int[int] rup=[0,5], rdown=[0,6], rmid=[1,1,2,2,3,3,4,4];
mesh3 Th3=buildlayers(Th2,10,zbound=[-2,2],labelmid=rmid,labelup=rup,labeldown=rdown);
savemesh(Th3,"test.mesh");
savemesh(Th3,"test.msh");

Hi,
When I run make check on FreeFem++ compiled using the the Intel Libraries, it does not converge. MPIGMRES3D.edp convegres using the same FreeFem++ binary.

When I check with FreeFem++ compiled using GCC, MPIGMRES2D.edp converges.
I am not sure what is happening.

Professor,

I expect know the difference between GMRES in old version(v3.62) and in v4.0, thanks, because I find, in my code (that is right), the effect of using GMRES in v3.62 is different from the effect of using GMRES in v4.0. More specifically, the former can get convergent solution(I'm sure that's right), whereas the later is not convergent. I don't understand reasons. I would email my code to your mailbox. Thanks.

I need help to correctly fix some bugs in src/medit

[cube.c:52]: (warning) The array 'cubetr.axis' is too small, the function 'transformVector' expects a bigger one.
[gisfil.c:60]: (style) Redundant condition: If 'EXPR == ' '', the comparison 'EXPR != 13' is always true.
[inout_morice.c:727] -> [inout_morice.c:394]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:412]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:433]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:474]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:535]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:590]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:651]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:727] -> [inout_morice.c:710]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:776] -> [inout_morice.c:759]: (warning) Either the condition 'tictac==NULL' is redundant or there is possible null pointer dereference: tictac.
[inout_morice.c:1046]: (error) Uninitialized variable: nq
[inout_morice.c:1027]: (error) Uninitialized variable: nq
[inout_morice.c:1031]: (error) Uninitialized variable: nq
[inout_morice.c:1034]: (error) Uninitialized variable: nq
[inout_morice.c:1039]: (error) Uninitialized variable: nq
[inout_morice.c:1043]: (error) Uninitialized variable: nq
[inout_popenbinaire.c:44]: (style) Redundant pointer operation on 'ref' - it's already a pointer.
[inout_popenbinaire.c:54]: (style) Redundant pointer operation on 'ref' - it's already a pointer.
[inout_popenbinaire.c:64]: (style) Redundant pointer operation on 'ref' - it's already a pointer.
[inout_popenbinaire.c:68]: (style) Redundant pointer operation on 'v0' - it's already a pointer.
[inout_popenbinaire.c:69]: (style) Redundant pointer operation on 'v1' - it's already a pointer.
[inout_popenbinaire.c:70]: (style) Redundant pointer operation on 'ref' - it's already a pointer.
[inout_popenbinaire.c:571]: (error) Uninitialized variable: nq
[inout_popenbinaire.c:565]: (error) Uninitialized variable: nq
[inout_popenbinaire.c:568]: (error) Uninitialized variable: nq
[keyboard.c:907]: (style) Statements following return, break, continue, goto or throw will never be executed.

We can discuss here about the corrections

A coverage report is available here
It will be good to reach, at least, 80% of coverage for Lines and Functions.

PS: There is no automatic update at each commit right now but that will be done in the future

When one loads a mesh in an edp file, e.g. mesh3 Th("foo.mesh"), no path seems to be used (see Mesh::read in femlib/fem.cpp).

Unless there already exists some mechanism to use a path, I would like to modify Mesh::read so that it looks for mesh files in some path variable such as PATH, or FF_DATAPATH, or something like that.

Another strategy would be to look for mesh files in the same directory as the edp file which needs it, i.e. implementing the same behavior as the one submitted for include directive in issue #37.

What do you think of it?

Hello,
I am trying FreeFEM++v4 on ubuntu 18.04. There was a problem while compiling PETSc-complex (more specifically in MUMPS), but on configuring with PETSc available on my PC for v3.62 or modifying the Makefile for the ff-complex section with "--download-mumps" flag, everything was successfully compiled.

On trying the example++-ffddm, two problems fails (I guess, they involve complex algebra.)
I am working on electromagnetic scattering problems, it would be great if somebody can help me fix this issue.
on make check in example++-ffddm:

make  check-TESTS
make[1]: Entering directory '/home/tomathew/Libraries/freefem/v4beta/FreeFem-sources/examples++-ffddm'
make[2]: Entering directory '/home/tomathew/Libraries/freefem/v4beta/FreeFem-sources/examples++-ffddm'
PASS: Maxwell-3d-simple.edp
XFAIL: Maxwell_Cobracavity.edp
PASS: diffusion-3d-simple.edp
PASS: diffusion-3d-minimal-ddm.edp
PASS: Helmholtz-2d-simple.edp
PASS: diffusion-3d-minimal-direct.edp
PASS: elasticity-3d-simple.edp
PASS: elasticity-3d-thirdlevelgeneo.edp
PASS: Richards-2d.edp
PASS: natural_convection.edp
PASS: Helmholtz-3d-simple.edp
PASS: diffusion-2d-thirdlevelgeneo.edp
PASS: natural_convection_3D_obstacle.edp
XFAIL: Helmholtz-2d-HPDDM-BGMRES.edp
============================================================================
Testsuite summary for FreeFem++ 4.0
============================================================================
# TOTAL: 14
# PASS:  12
# SKIP:  0
# XFAIL: 2
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
make[2]: Leaving directory '/home/tomathew/Libraries/freefem/v4beta/FreeFem-sources/examples++-ffddm'
make[1]: Leaving directory '/home/tomathew/Libraries/freefem/v4beta/FreeFem-sources/examples++-ffddm'

more specifically for CobraCavity:

ORAS TWO-LEVEL + INEXACT COARSE SOLVE :
[M] Coarse space dimension: 23221
timings - building E : 8.26136 s
  ** Instance Error 1 in ZMUMPS_F77           1
application called MPI_Abort(MPI_COMM_WORLD, -99) - process 17

Thanks in advance

In Freefem's DSL, include directive does not look for files in the directory of the file calling this directive. For example, if include "bar.edp" is found in a file $FF_ROOT/foo.edp which is run from $SOMEWHERE, then bar.edp will be search in $SOMEWHERE instead of FF_ROOT.

I would like to modify this behavior (which is implemented in fflib/lex.cpp). The purpose of this modification is to be able to run edp files from anywhere without having to set FF_INCLUDEPATH for that. Note that $FF_ROOT is known because *(pilesource[level].filename) contains it.

Do you agree with this modification?

I prefer to ask before making a pull request.

For MacOS, Linux and Windows:
fatal error: umfpack.h: No such file or directory

Under Ubuntu 16.04:

• umfpack.h: The include directory /usr/include/suitesparse is missing in such Makefiles (src/fflib/Makefile and src/mpi/Makefile, possibly other), and using ff-c++

FreeFem is using libMesh v5
See https://github.com/LoicMarechal/libMeshb

je tente le coup

The automatic conversion from .hgignore to .gitignore failed because of the usage of regex in the .hgignore.

Please, check the .gitignore (branch develop)

Hello,

I am a long-time FF++ user (developing .edp scripts to model solid mechanics problems), and I just installed FreeFem++ on a new MacOS-10.13. I am noticing a strange performance issue on my Mac compared to my old Windows7 PC, and my troubleshooting attempts are below. Note that I have installed FreeFem++ v3.61-1 on both Mac and Windows using the respective binary packages, and these troubleshooting attempts are all executed in serial.

When I run a .edp script that computes a simple addition problem 1e6 times (speed_test.edp below), the execution time is almost 3 seconds on my Mac, while on my Windows7 computer, execution is 0.1 seconds. Much much slower on my Mac.

// speed_test.edp
real cpu = clock();
int j;
for (int i;i<(1e6);i++)
{
  j = j+1;
}
cout << "~~~~~~~~~solve time = " << clock()-cpu << "~~~~~~~~~ "<< endl;

When I compile and run a C++ script with the same purpose (simple addition 1e6 times), the execution time is 0.004 seconds on my Mac, and 0.01 seconds on my Windows PC. Much faster on my Mac.

When I run a .edp script that re-computes a varf on a 100x100 mesh 1e4 times (ts.edp below), execution time is ~45 seconds on my Mac, and ~55 seconds on my Windows PC. If I reduce the mesh size to 25x25, and run the same varf calculation 1e4 times, execution time is ~3.5 sec on my Mac and ~4.0 sec on my Windows PC. A bit faster on my Mac. (I found this script on a previous FF++ forum, and altered slightly to test performance)

// ts.edp
load "MUMPS_seq"
real cpu = clock();
func f = 1.0;
mesh Th = square(100,100);
// mesh Th = square(25,25);
real T = 1., dt = .1;
int nt = floor(T/dt), m;
fespace Vh(Th,P1);
Vh u=0;
varf vheat(u,v) =
int2d(Th)(u/dt*v+dx(u)*dx(v)+dy(u)*dy(v))
+ int2d(Th)(f*v) + on(1,2,3,4,u=0);
varf vmass(u,v) = int2d(Th)(u*v/dt);

real[int] b0=vheat(0,Vh);
real cpu0=clock();
matrix A = vheat(Vh,Vh,solver=UMFPACK);
cout << "  build un factorize = " << clock()-cpu0 << endl;;
matrix M = vmass(Vh,Vh,solver=UMFPACK);
cout << "  time before loop = " << clock()-cpu << endl;;

for (m=0;m<1e4;++m)
 {
  real[int] b=b0;
  b+= M*u[];
  real cpu=clock();
  u[] = A^-1*b;
}

Basically, execution is faster on my Mac when using the C++ loop script and the FF++ mesh varf script, as expected. However, when accomplishing simple addition, the Mac is remarkably slower than my Windows PC. My solid mechanics scripts use many looped calculations, and as a result their performance on my Mac is quite poor.

Note my Mac CPU is 6-core Intel Xeon E5, 3.5 GHz, 16 GB memory. My Windows CPU is 4-core Intel i7, 2.7 GHz, 8 GB memory. I should also point out that I installed FreeFem++ on a friend’s Mac (similar specs), using binary installation, and found the same performance issue.

Is there a way I can specify compilers, optimization flags, etc. within the FreeFem++ executable, to enhance performance? Do I need to install FreeFem++ from scratch using the compilation files to achieve good performance on a Mac? I have not found other FF++ forum posts discussing this problem, so my problem seems very strange.

Please let me know if you have any suggestions, or need further information.

Thanks,
Nathan

Dear all,

I noticed possible issues with the interpolate function and integration requiring interpolation of test functions in 3D.
For some 3D meshes, the following lines seem to create infinite loops:

mesh3 Th=readmesh3("Th_ff.mesh");
mesh3 Ths=readmesh3("Ths_ff.mesh");

fespace Fhs1(Ths,P1);

fespace Gh1(Th,P1);
cout << "So far everything is ok" << endl;
matrix Is = interpolate(Fhs1, Gh1);
cout << "Done." << endl;

When running with FreeFem++ -v 1000, I see endless lines such as

       tet it=72765  K.mesure=1.42437e-05 eps=-1e-10 :   l[0]=-0.783932  l[1]=-0.143761  l[2]=1.93394  l[3]=-0.00624189 n=3
       tet it=26457  K.mesure=1.77566e-05 eps=-1e-10 :   l[0]=-0.788321  l[1]=-0.143792  l[2]=0.00500702  l[3]=1.92711 n=2
       tet it=66817  K.mesure=1.95559e-05 eps=-1e-10 :   l[0]=-0.732128  l[1]=0.715793  l[2]=-0.802441  l[3]=1.81878 n=2
       tet it=52699  K.mesure=1.59095e-05 eps=-1e-10 :   l[0]=0.874142  l[1]=0.721797  l[2]=-1.49587  l[3]=0.899928 n=1
       tet it=85480  K.mesure=1.42962e-05 eps=-1e-10 :   l[0]=-0.612713  l[1]=-0.714089  l[2]=0.662124  l[3]=1.66468 n=2
       tet it=9498  K.mesure=1.30492e-05 eps=-1e-10 :   l[0]=-0.893403  l[1]=0.671265  l[2]=0.296692  l[3]=0.925446 n=1
       tet it=42686  K.mesure=1.16582e-05 eps=-1e-10 :   l[0]=0  l[1]=0  l[2]=0  l[3]=1 n=0
    0 tstart= 0x7f88fe4473b0 , it=42686 P=0.483437 0.262498 0.693662
       tet it=42686  K.mesure=1.16582e-05 eps=-1e-10 :   l[0]=-0.0408083  l[1]=-1.0452  l[2]=0.908641  l[3]=1.17737 n=2
       tet it=22879  K.mesure=1.21852e-05 eps=-1e-10 :   l[0]=0  l[1]=-0  l[2]=1  l[3]=-0 n=0
   Find: Close : 0.574955 0.440568 0.491754 0 , 637 dist 0
    0 tstart= 0 , it=83742 P=0.574955 0.440568 0.491754
       tet it=83742  K.mesure=2.08106e-05 eps=-1e-10 :   l[0]=0  l[1]=0  l[2]=1  l[3]=0 n=0
    0 tstart= 0x7f88fe6285b0 , it=83742 P=0.583729 0.434916 0.445721
       tet it=83742  K.mesure=2.08106e-05 eps=-1e-10 :   l[0]=-1.12579e-17  l[1]=1  l[2]=4.07551e-17  l[3]=-2.94972e-17 n=0
    0 tstart= 0x7f88fe6285b0 , it=83742 P=0.579747 0.378505 0.449529
       tet it=83742  K.mesure=2.08106e-05 eps=-1e-10 :   l[0]=-1.02461  l[1]=0.940164  l[2]=0.02379  l[3]=1.06065 n=1
       tet it=26356  K.mesure=2.13227e-05 eps=-1e-10 :   l[0]=0  l[1]=0  l[2]=1  l[3]=0 n=0
    0 tstart= 0x7f88fe387dd0 , it=26356 P=0.529479 0.395287 0.461506
       tet it=26356  K.mesure=2.13227e-05 eps=-1e-10 :   l[0]=0  l[1]=-0  l[2]=0  l[3]=1 n=0
   Find: Close : 0.374879 0.363823 0.493052 0 , 4548 dist 0
    0 tstart= 0 , it=85364 P=0.374879 0.363823 0.493052
       tet it=85364  K.mesure=1.67956e-05 eps=-1e-10 :   l[0]=-2.22045e-16  l[1]=0  l[2]=-0  l[3]=1 n=0
    0 tstart= 0x7f88fe63b5d0 , it=85364 P=0.380657 0.30177 0.475479
       tet it=85364  K.mesure=1.67956e-05 eps=-1e-10 :   l[0]=1  l[1]=0  l[2]=-0  l[3]=0 n=0
    0 tstart= 0x7f88fe63b5d0 , it=85364 P=0.414326 0.340156 0.472089
       tet it=85364  K.mesure=1.67956e-05 eps=-1e-10 :   l[0]=0.950992  l[1]=0.0500435  l[2]=-1.06438  l[3]=1.06335 n=1
       tet it=82584  K.mesure=1.7877e-05 eps=-1e-10 :   l[0]=1.11022e-16  l[1]=0  l[2]=-0  l[3]=1 n=0
    0 tstart= 0x7f88fe61ac90 , it=82584 P=0.39847 0.32495 0.511248
       tet it=82584  K.mesure=1.7877e-05 eps=-1e-10 :   l[0]=0.604977  l[1]=-0.793989  l[2]=0.949375  l[3]=0.239637 n=1
       tet it=26357  K.mesure=1.41941e-05 eps=-1e-10 :   l[0]=0  l[1]=-0  l[2]=-0  l[3]=1 n=0
   Find: Close : 1.1921 0.833706 0.551314 10 , 3443 dist 0
    0 tstart= 0 , it=37391 P=1.1921 0.833706 0.551314
       tet it=37391  K.mesure=3.31511e-05 eps=-1e-10 :   l[0]=1.11022e-16  l[1]=-0  l[2]=-0  l[3]=1 n=0
    0 tstart= 0x7f88fe4092e0 , it=37391 P=1.18094 0.896886 0.559475
       tet it=37391  K.mesure=3.31511e-05 eps=-1e-10 :   l[0]=-1.05523  l[1]=-0.18317  l[2]=0.802247  l[3]=1.43615 n=2
       tet it=33664  K.mesure=3.14328e-05 eps=-1e-10 :   l[0]=-0.372757  l[1]=-1.14585  l[2]=1.11291  l[3]=1.40569 n=2
       tet it=20658  K.mesure=2.82383e-05 eps=-1e-10 :   l[0]=-0.422186  l[1]=0.962592  l[2]=1.27548  l[3]=-0.815883 n=2
       tet it=9443  K.mesure=4.74572e-05 eps=-1e-10 :   l[0]=-0.951754  l[1]=0.251213  l[2]=0.837536  l[3]=0.863005 n=1
       tet it=36394  K.mesure=4.51675e-05 eps=-1e-10 :   l[0]=0  l[1]=-0  l[2]=0  l[3]=1 n=0
    0 tstart= 0x7f88fe3fd7f0 , it=36394 P=1.23672 0.891998 0.496122
       tet it=36394  K.mesure=4.51675e-05 eps=-1e-10 :   l[0]=0  l[1]=1  l[2]=0  l[3]=0 n=0
    0 tstart= 0x7f88fe3fd7f0 , it=36394 P=1.14195 0.86448 0.500638
       tet it=36394  K.mesure=4.51675e-05 eps=-1e-10 :   l[0]=-1.35342  l[1]=0.732912  l[2]=0.562075  l[3]=1.05844 n=1
       tet it=26358  K.mesure=6.11308e-05 eps=-1e-10 :   l[0]=0  l[1]=-8.12746e-17  l[2]=5.34394e-17  l[3]=1 n=0
   Find: Close : 1.45527 0.973411 0.547493 0 , 14904 dist 0
    0 tstart= 0 , it=84412 P=1.45527 0.973411 0.547493

See the code and mesh attached below for an example of such issue:
test3D.zip

The code

Gh1 v,V;
varf b(v,V)=int2d(Ths,10)(V);
real[int] rhs=b(0,Gh1);

also sometimes produce the same infinite loop, see the second file below attached:
test3D2.zip

Note : It could also be a problem with the mesh (produced by mmg3d, but I don't know what)....

Many thanks,

Compilation output:
make[3] : on entre dans le répertoire « /home/simon/Documents/Install/FreeFem/FreeFem-sources/src/nw »
g++ -g -DNDEBUG -O3 -mmmx -mavx -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -rdynamic -o FreeFem++ sansrgraph.o parallelempi-empty.o ffapi.o ../lglib/liblg.a ../fflib/libff.a -Wl,-rpath,/usr/local/ff-petsc/real/lib -L/usr/local/ff-petsc/real/lib -lumfpack -lklu -lcholmod -lbtf -lccolamd -lcolamd -lcamd -lamd -lsuitesparseconfig -larpack -llapack -llapack -lblas -ldl -lm -lrt /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../libgfortran.so /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../libquadmath.so -L/usr/lib -lm -ldl -lz -lsz -lhdf5_hl -lhdf5 -lhdf5_hl
../fflib/libff.a(lgfem.o) : Dans la fonction « TypeSolve<true, Solve>::SolveInit::operator()(void*) const » :
/home/simon/Documents/Install/FreeFem/FreeFem-sources/src/fflib/problem.hpp:493 : référence indéfinie vers « AnyTypeWithOutCheck Problem::eval<double, Fem2D::GFESpaceFem2D::Mesh3, v_fes3>(void*, Problem::Data<Fem2D::GFESpaceFem2D::Mesh3 >, CountPointer<MatriceCreuse >&, MatriceCreuse<CadnaType::Scalaire>&) const »
/home/simon/Documents/Install/FreeFem/FreeFem-sources/src/fflib/problem.hpp:491 : référence indéfinie vers « AnyTypeWithOutCheck Problem::eval<std::complex, Fem2D::GFESpaceFem2D::Mesh3, v_fes3>(void*, Problem::Data<Fem2D::GFESpaceFem2D::Mesh3 >, CountPointer<MatriceCreuse<std::complex > >&, MatriceCreuse<CadnaType<std::complex >::Scalaire>&) const »
/home/simon/Documents/Install/FreeFem/FreeFem-sources/src/fflib/problem.hpp:484 : référence indéfinie vers « AnyTypeWithOutCheck Problem::eval<double, Fem2D::FESpace, v_fes>(void*, Problem::DataFem2D::FESpace, CountPointer<MatriceCreuse >&, MatriceCreuse<CadnaType::Scalaire>&) const »
collect2: error: ld a retourné le statut de sortie 1
make[3]: *** [Makefile:578: FreeFem++] Error 1
make[3] : on quitte le répertoire « /home/simon/Documents/Install/FreeFem/FreeFem-sources/src/nw »

Hello,

I noticed that the computation of 3D integrals with [P1,P1,P1] elements is about ten times slower compared to the integration with P1 elements (after interpolating each coordinate), see the code below and the files attached below:

essai.zip

func int readData(string fileName, real[int] &data){
	{
		ifstream f(fileName);
		f>>data;
	}
}

mesh3 Ths=readmesh3("Ths.mesh");
fespace Fhs12d(Ths,[P1,P1,P1]);
fespace Fhs1(Ths,P1);
Fhs12d [ux,uy,uz];
Fhs1 ux1, uy1, uz1;
readData("ux.gptmp",ux[]);
plot(ux,cmm="ux");
ux1=ux;
uy1=uy;
uz1=uz;

real mu=1, lambda=1;
real sqrt2=sqrt(2);
macro e(vx,vy,vz)   				 	[dx(vx),dy(vy),dz(vz),(dx(vy)+dy(vx))/sqrt2, (dx(vz)+dz(vx))/sqrt2, (dy(vz)+dz(vy))/sqrt2]//
macro div(vx,vy,vz) 				 	(dx(vx)+dy(vy)+dz(vz))//
real cpu1=clock();
real objectiveValue=int3d(Ths)(2*mu*e(ux1,uy1,uz1)'*e(ux1,uy1,uz1)+lambda*div(ux1,uy1,uz1)*div(ux1,uy1,uz1));
cout << "Time 1 : "<<clock()-cpu1 << "  VALUE = " << objectiveValue << endl;

real cpu2=clock();
real objectiveValue2=int3d(Ths)(2*mu*e(ux,uy,uz)'*e(ux,uy,uz)+lambda*div(ux,uy,uz)*div(ux,uy,uz));
cout << "Time 2 : "<<clock()-cpu2 << " Value = "<< objectiveValue << endl;

Thanks,

What is the meaning of the assertion involved in the error message below?

Load: lg_fem lg_mesh lg_mesh3 eigenvalue
1 : load "metis" current line = 1
Assertion fail : (ii==MotClef.end())
line :112, in file /home/cdoucet/Depots/github/FreeFem-sources/src/fflib/lex.cpp
error Assertion fail : (ii==MotClef.end())
line :112, in file /home/cdoucet/Depots/github/FreeFem-sources/src/fflib/lex.cpp
code = 5 mpirank: 0

There is a problem with the current version of medit.cpp when displaying several plots on different meshes with medit.

I have added
lastTh=jj;
at line 1751 to fix the issue.

I don't now how to send the patch....(first time on Github sorry).

I was compiling the last version and everything went fine, until I made "make -j4".
I get the error that there is no rule for "eigenvalue.o" needed for "libff.a"

I don't know if this is a known bug.

We ran Infer(a static code analyzer developed by Facebook) on Freefem's code, excluding /download

See the report repository here and in html

A lot of bugs are criticals

blablabla link

A compilation error occurs under MacOSX when using downloaded arpack library

The complete log is available here (MacOSX 10.9)

Hello，

I'd like to ask if FreeFem++ support h- and p-adaptation respectively, and "trunc" in 3D(when I test Poission equations' convergence rate on norm H1 by using Th = trunc(Th, 1, split=2); to nestedly refine mesh in 3D, I find the convergence rate may be wrong) ? Thanks.

The code to test "trunc" in 3D is as following

load "msh3"
load "tetgen"
load "MUMPS"

macro fe P1 //

//-----------------+
//   Parameters    |
//-----------------+
int M = 32;
int nblayers = 1;

//-----------------------+
//    Exact Solution 1   |
//-----------------------+
func u = cos(2*pi*x) * cos(2*pi*y) * cos(2*pi*z);
func ux = - 2 * pi * sin(2*pi*x) * cos(2*pi*y) * cos(2*pi*z);
func uy = - 2 * pi * cos(2*pi*x) * sin(2*pi*y) * cos(2*pi*z);
func uz = - 2 * pi * cos(2*pi*x) * cos(2*pi*y) * sin(2*pi*z);
func uxx = - 4 * pi^2 * cos(2*pi*x) * cos(2*pi*y) * cos(2*pi*z);
func uyy = uxx;
func uzz = uxx;
func f = - uxx - uyy - uzz;
func g = u;

//-----------------+
//   Build Mesh    |
//-----------------+
border bd1(t = 0, 1) {x = t;   y = 0;   label=1;}
border bd2(t = 0, 1) {x = 1;   y = t;   label=2;}
border bd3(t = 0, 1) {x = 1-t; y = 1;   label=3;}
border bd4(t = 0, 1) {x = 0;   y = 1-t; label=4;}
mesh Th0 = buildmesh(bd1(M) + bd2(M) + bd3(M) + bd4(M));
mesh3 Th1 = movemesh23(Th0, transfo=[x, y, 0]);
mesh3 Th2 = movemesh23(Th0, transfo=[x, y, 1]);
mesh3 Th3 = movemesh23(Th0, transfo=[0, x, y]);
mesh3 Th4 = movemesh23(Th0, transfo=[1, x, y]);
mesh3 Th5 = movemesh23(Th0, transfo=[x, 0, y]);
mesh3 Th6 = movemesh23(Th0, transfo=[x, 1, y]);
mesh3[int] Th(nblayers);
Th[0] = Th1 + Th2 + Th3 + Th4 + Th5 + Th6;
Th[0] = tetg(Th[0]);
//plot(Th[0], cmm="Initial Mesh", wait=1);
for (int l = 1; l < nblayers; ++l)
{
	Th[l] = trunc(Th[l-1], 1, split=2);
}
cout << "Th[" << nblayers-1 << "].nt = " << Th[nblayers-1].nt << endl;
cout << "Th[" << nblayers-1 << "].nv = " << Th[nblayers-1].nv << endl;
//plot(Th[nblayers-1], cmm="Solve Mesh", wait=1);

//--------------------------------+
//   Build Finite Element Space   |
//--------------------------------+
fespace Vh(Th[nblayers-1], fe);
Vh uh = 0;

//-----------------------------+
//   Assemble Matrix and RHS   |
//-----------------------------+
varf vA(u, v) = int3d(Th[nblayers-1]) (dx(u)*dx(v) + dy(u)*dy(v) + dz(u)*dz(v)) + on(0, u=g);
varf vl(unused, v) = int3d(Th[nblayers-1]) (f * v) + on(0, unused=g);
matrix A = vA(Vh, Vh);
real[int] b = vl(0, Vh);

//-------------------+
//  Solve Equations  |
//-------------------+
set(A, solver=sparsesolver);
uh[] = A^-1 * b;

//-------------------------+
//   Compute Error Order   |
//-------------------------+
real H1Error = sqrt(int3d(Th[nblayers-1]) ((ux - dx(uh))^2 + (uy - dy(uh))^2 + (uz-dz(uh))^2 + (u - uh)^2));
cout << "=============================================" << endl;
cout << "H1Error = " << H1Error << endl;
cout << "=============================================" << endl;
//plot(uh, wait=1);

H1Error is 1.8384, but when changing code in line 11 into int nblayers = 2, H1Error is 1.12211. The convergence order would be bad (even though I refine grid again).

There are to header files named eigenv.h, one in src/medit and the other in src/libMesh.
Their contents are different (diff output below):

1,4d0
< #ifdef __cplusplus
< extern "C" {
< #endif
<
7,10d2
<
< #ifdef __cplusplus
< }
< #endif

In examples++-load/Curvature.cpp, one finds #include "eigenv.h".

Which file does it refer to?
Can we delete the other one?

(The "extern C" version seems to be the correct one, even though it may not be the original version.)

Dear professor,
I compared CG solver in old version(v3.62) with CG in new version(v4.0), noticing that the later(v4.0) is slower than the former(v3.62) in term of solve time.
As solve Poisson equations with homogeneous in tutorial, I have done test as following:

int nn = 320;
int[int] L = [1, 2, 3, 4];
func f = 1;

border bd1(t = 0, 1) {x = t;   y = 0;   label=1;}
border bd2(t = 0, 1) {x = 1;   y = t;   label=2;}
border bd3(t = 0, 1) {x = 1-t; y = 1;   label=3;}
border bd4(t = 0, 1) {x = 0;   y = 1-t; label=4;}
mesh Th = buildmesh(bd1(nn) + bd2(nn) + bd3(nn) + bd4(nn));
fespace Vh(Th, P1);
Vh uh;

varf vA(u, v) = int2d(Th) ( dx(u)*dx(v) + dy(u)*dy(v) ) + on(L, u=0);
varf vl(unused, v) = int2d(Th) (f * v) + on(L, unused=0);
matrix A = vA(Vh, Vh);
real[int] b = vl(0,Vh);
real start = clock();
set(A, solver=CG);
cout << "Set solver time is " << clock()-start << endl;
start = clock();
uh[] = A^-1 * b;
cout << "Solve system time is " << clock()-start << endl;

then using command "FreeFem++/FreeFem++-mpi filename.edp" to compile and run. when calculating the total time of "Set solver time" and "Solve system time", I find that the total time consumption solved by CG in v4.0 is beyond the total time of CG in v3.62. I don't understand why?

Dear sir:
I want to use FreeFem as my adaptive mesh generator, how to output the mesh informs (cell neighbor, cell central, etc.)from FreeFem.

I try to compile sources with cmake and I get the following error message.
Is it obvious for someone before I try to solve it?

In file included from /usr/include/c++/5/cassert:43:0,
from /home/cdoucet/Depots/github/FreeFem-sources/src/femlib/GenericMesh.hpp:40,
from /home/cdoucet/Depots/github/FreeFem-sources/src/femlib/Mesh3dn.hpp:48,
from /home/cdoucet/Depots/github/FreeFem-sources/src/femlib/FESpacen.hpp:54,
from /home/cdoucet/Depots/github/FreeFem-sources/src/fflib/ff++.hpp:29,
from /home/cdoucet/Depots/github/FreeFem-sources/examples++-load/Element_Mixte3d.cpp:36:
/home/cdoucet/Depots/github/FreeFem-sources/examples++-load/Element_Mixte3d.cpp: In constructor ‘Fem2D::TypeOfFE_RT1_3d::TypeOfFE_RT1_3d()’:
/home/cdoucet/Depots/github/FreeFem-sources/examples++-load/Element_Mixte3d.cpp:2277:10: error: ‘QFe’ was not declared in this scope
assert(QFe.n);
^
/home/cdoucet/Depots/github/FreeFem-sources/examples++-load/Element_Mixte3d.cpp:2278:10: error: ‘QFf’ was not declared in this scope
assert(QFf.n);

There are two copies of mortar-msh.idp. The first one is located in examples++-tutorial. The other one is located in examples++-mpi. One of them should be deleted and the other one should be placed in a common directory if needed.

OS: ArchLinux
FreeFem++ version: develop

The MUMPS/MUMPS_seq plugin does not work anymore.
The compilation process complete correctly, but during the check, LapMUMPS_seq.edp fails

For example with this file mumps.edp.txt, the result is:

FreeFem++ mumps.edp

 Matrix morse type:6
 BuildSolverMUMPSseq<double>
[---:09016] *** An error occurred in MPI_Comm_rank
[---:09016] *** reported by process [3860070401,0]
[---:09016] *** on communicator MPI_COMM_WORLD
[---:09016] *** MPI_ERR_COMM: invalid communicator
[---:09016] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[---:09016] ***    and potentially your MPI job)

Any idea about this bug ?

I do not understand why include.edp fails (with CMake). I added to PATH the full path of examples++ (containing funct.edp) but it does not solve the problem (unless I made a mistake somewhere).

Load: lg_fem lg_mesh lg_mesh3 eigenvalue
1 : { include "funct.edp" Error openning file funct.edp in:
-- try :"funct.edp"

Error line number 1, in file /home/cdoucet/Depots/github/FreeFem-sources/examples++/include.edp, before token funct.edp
lex: Error input openning file
current line = 1
Compile error : lex: Error input openning file
line number :1, funct.edp
error Compile error : lex: Error input openning file
line number :1, funct.edp
code = 1 mpirank: 0

This is a compiler bug, but this makes the compilation process very frustrating when using Intel compilers since it stall for no reason.

Continuous integration on feature-cmake branch has launched metis.edp for several hours without achieving computation:

https://ci.inria.fr/freefem/job/FreeFem-source-feature-cmake-UbuntuAll/7/console

Here is the output which make me guess that the next test is metis.edp:

�[0;32m OK (Exec) �[m /usr/bin/mpiexec -np 4 /builds/workspace/FreeFem-source-feature-cmake-UbuntuAll/build_cmake/src/FreeFem++-mpi -nw lapack.edp ( see lapack.edp-out )
�[0;32m OK (Exec) �[m /usr/bin/mpiexec -np 4 /builds/workspace/FreeFem-source-feature-cmake-UbuntuAll/build_cmake/src/FreeFem++-mpi -nw layer.edp ( see layer.edp-out )
�[0;32m OK (Exec) �[m /usr/bin/mpiexec -np 4 /builds/workspace/FreeFem-source-feature-cmake-UbuntuAll/build_cmake/src/FreeFem++-mpi -nw load.edp ( see load.edp-out )
�[0;32m OK (Exec) �[m /usr/bin/mpiexec -np 4 /builds/workspace/FreeFem-source-feature-cmake-UbuntuAll/build_cmake/src/FreeFem++-mpi -nw meditddm.edp ( see meditddm.edp-out )

I think it is important to understand why (load errror, high complexity, ...) and make it run faster.

Original post from FreeFem-doc #5 :

Sorry if this is the inappropriate place or way to complain, but i had some problems compiling Freefem++ on arch (Manjaro to be exact).
the error occured after the "./reconfigure" step
expected behaviour:
"make" causes freefem to compile
actual behaviour:
there is a "missing seperator" error and the compilation stopped after the command "make" is execured.

i think i solved the issue, by removing all lines that only said "dir" from all files called "Makefile" since this line caused the error. to my very limited knolege of makefiles this line made no sence there. here is a INCOMPLETE list of places this line occured:
File Line String
./examples++-eigen/Makefile 396 dir
./examples++-mpi/Makefile 419 dir
./examples++-tutorial/Makefile 398 dir
./examples++/Makefile 398 dir
./examples++-load/Makefile 437 dir
./examples++-hpddm/Makefile 419 dir
./examples++-chapt3/Makefile 398 dir
./src/bamglib/Makefile 199 dir
./src/Makefile 257 dir
./src/Algo/Makefile 199 dir
./src/bamg/Makefile 237 dir
./src/mpi/Makefile 275 dir
./src/lglib/Makefile 253 dir
./src/fflib/Makefile 277 dir
./src/medit/Makefile 254 dir
./src/bin-win32/Makefile 192 dir
./src/femlib/Makefile 199 dir
./src/Graphics/Makefile 192 dir
./src/nw/Makefile 268 dir
./examples++-other/Makefile 396 dir
./examples++-bug/Makefile 194 dir
./examples++-3d/Makefile 398 dir

The link I was using, http://www.freefem.org/ff++/ftp/freefem++-3.56.tar.gz, does not work anymore.

I met the following error, when I make it. could you please give me some suggstions

g++ -shared -fPIC -g -DNDEBUG -O3 -mmmx -mavx -std=c++11 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -I/home/ztdep/Downloads/freefem++-4.0/download/include 'ff-Ipopt.o' -o ff-Ipopt.so '-L/home/ztdep/Downloads/freefem++-4.0/download/lib' '-lipopt' '-L/home/ztdep/Downloads/freefem++-4.0/download/lib' '-ldmumpsFREEFEM-SEQ' '-lzmumpsFREEFEM-SEQ' '-lmumps_commonFREEFEM-SEQ' '-lpordFREEFEM-SEQ' '-lpthread' '-lblas' '-L/home/ztdep/Downloads/freefem++-4.0/download/lib' '-lmpiseqFREEFEM-SEQ' /usr/lib64/gcc/x86_64-suse-linux/7/libgfortran.so /usr/lib64/gcc/x86_64-suse-linux/7/libquadmath.so
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lipopt
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:2020: ff-Ipopt.so] Error 1
make[3]: *** Waiting for unfinished jobs....

g++ -shared -fPIC -g -DNDEBUG -O3 -mmmx -mavx -std=c++11 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -I/home/ztdep/Downloads/freefem++-4.0/download/include 'ff-NLopt.o' -o ff-NLopt.so '-L/home/ztdep/Downloads/freefem++-4.0/download/lib' '-lnlopt_cxx'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lnlopt_cxx

I need to use P1nc elements in 3d to validate an algorithm.
When I try, I get this error message : sorry no cast to this 3d finite element
Would it be possible to create this finite element space?

I reported a bug to the Debian BTS regarding FreeFem++ crashing with exti status 132. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924009
This bug exists also in the debian package v3.62 downloaded from github.

It manifests on one computer with 2 CPUs but not on another single CPU computer with the same installed software. Here are the last lines of the strace output:

sched_getaffinity(17907, 8, [0, 1, 2, 3, 4, 5, 6, 7]) = 8
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
fstat(2, {st_mode=S_IFREG|0644, st_size=21874, ...}) = 0
futex(0x7f7c238d707c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f7c238d7088, FUTEX_WAKE_PRIVATE, 2147483647) = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x55b7ad046801} ---
+++ killed by SIGILL +++
Illegal instruction

Dear Professor,

I do a simple test to solve block matrix equations using MUMPS in freefem++-4.0-beta.tar.gz(Source version), and find that it always report errors. But it works well when using MUMPS in FreeFem++-4.0-MacOS_10.11.pkg. I don't understand reasons behind the problem. (In running, the code would report error no matter which FreeFem++-mpi test_MUMPS.edp or FreeFem++ test_MUMPS.edp)

///////////////////////////////////////////////////////////////
/**
 * @file: test_MUMPS.edp
 * @brief: to test MUMPS solver
 */
///////////////////////////////////////////////////////////////

load "MUMPS"

matrix A = [[2, 0],
            [0, 2]];
matrix B = [[1, 0],
            [0, 1]];
matrix C = [[8, 0],
            [0, 8]];
matrix F = [[A, B],
            [B, C]];
real[int] b = [1, 0, 1, 0];
set(F, solver=sparsesolver);
real[int] u = F^-1 * b;
cout << u << endl;