freefem / freefem-sources Goto Github PK
View Code? Open in Web Editor NEWFreeFEM source code
Home Page: https://freefem.org/
License: Other
FreeFEM source code
Home Page: https://freefem.org/
License: Other
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
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.
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,
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);
This is a compiler bug, but this makes the compilation process very frustrating when using Intel compilers since it stall for no reason.
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.
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:
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
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
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
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++
The link I was using, http://www.freefem.org/ff++/ftp/freefem++-3.56.tar.gz, does not work anymore.
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
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?
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.
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?
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
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 ?
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 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,
The automatic conversion from .hgignore to .gitignore failed because of the usage of regex in the .hgignore.
Please, check the .gitignore (branch develop)
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;
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
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?
A compilation error occurs under MacOSX when using downloaded arpack library
The complete log is available here (MacOSX 10.9)
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
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
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
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.
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.
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?
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).
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
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.
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
FreeFem is using libMesh v5
See https://github.com/LoicMarechal/libMeshb
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é
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 ?
Freefem++ v3.47 on linux.
When trying to run the following script: FreeFem-doc/docs/documentation/MeshGeneration.md#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 ?
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:
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,
je tente le coup
blablabla link
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).
Does anyone successfully compile FreeFem++ with PaStiX solver enabled (linux/macosx) ?
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
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.
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
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?
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 »
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");
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.