-
bugs
renard
7501
1161597969
paolog
Fixed
Happens on WXP SP2 with MS's compiler version 14, the one included with Visual Studio 2005 Express.
Code to reproduce:
=============== test.cc
#include <iostream>
#pragma warning( disable : 4996 )
#include "gmm.h"
#pragma warning( default : 4996 )
int main() {
gmm::dense_matrix<double> results(12, 4);
std::cout << results;
} // main
===============
To compile and link:
cl /EHsc /Igmm-2.0\include test.cc
crashes after printing the 1st line of the matrix:
( 0, 0, 0, 0 )
(
I am attaching a screenshot with the stack trace and the location in gmm_matrix.h which according to me is causing the problem.
4 - Important
5 - Normal
1163770475
gmm++ 2.0 crash while printing dense_matrix in MS Visual Studio
Public
0
None
1581
Closed
Unlocked
1161597969
-
Added Capture-10-23-00001.png, #1433
paolog
1161760939
Original_Submission
the example is working fine with MS compiler v2003, g++ and icpc.
renard
Status
None
Need Info
renard
1162892355
Original_Submission
Yes indeed I used to use that compiler a while ago. I can see as well that the example I provided does not crash when compiled with it:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
But my submission was on the much more recent (2005) compiler:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
This is available at no cost from MS as was the Visual C++ Toolkit 2003, just check at http://msdn.microsoft.com/vstudio/express/visualc/
I see on your download page that this compiler (or for what matters VC++ 2003) is not among the tested configuration for getfem++ and gmm++.
This ia a pity, the 2005 version of VC++ is much faster and standards compliant that 2003 and all in all one of the best compilers around for Win32.
I hope that you will make an effort to support this compiler as well..
paolog
1163406782
Assigned_to
100
4654
renard
Status
Need Info
In Progress
renard
1163770475
Open/Closed
Open
Closed
renard
Original_Submission
The problem is fixed for Gmm++ since the compilation is made with the additional option
/D_SCL_SECURE_NO_DEPRECATE
to MSVC 14.00
MSVC 14.00 declare deprecated the use of std::copy with pointers. This does not correspond to any recommandation of the standard. The C++ standard allows the use of pointers where iterators are required. The option /D_SCL_SECURE_NO_DEPRECATE
disable this too much restrictive rule.
renard
Status
In Progress
Fixed
renard
1164017127
Original_Submission
Yeah, SCL_SECURE_NO_DEPRECATE is a pain. But with that enabled or disabled I still get the crash. Do you reproduce the crash on launching the executable test.exe ?
cl /EHsc /D_SCL_SECURE_NO_DEPRECATE /Igmm-2.0\include test.cc
test.exe
matrix(12, 4)
( 0, 0, 0, 0 )
(
[crashed after having printed these 2 and a half lines]
The expected output is:
matrix(12, 4)
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
( 0, 0, 0, 0 )
paolog
1164029672
Original_Submission
Yes, I did try your example and it works.
But I did not change the archive on the Getfem site.
The corrected sources are on the Gna repository
(https://gna.org/svn/?group=getfem)
you have to extract the gmm files (all the files begining by "dal_" and "gmm_" from the directory trunk/getfem++/src.
renard
-
bugs
None
7628
1162674685
giovanifaccin
Fixed
Hello people!
First of all, thanks for this library! It seens very promising. I'm starting to learn it, and I'm enjoying the way it's modeled.
I've written a very short program that imports a mesh generated with gmsh, then writes this mesh to the disk in the getfem native format. Finally, it tries to load again the mesh it has just saved (the one in getfem format), and at this point the library throws an exception.
The cause of this exception is that the file written by the library has duplicated points (they appear with different indexes, however having the same coordinates). Since the import function does not complain when it reads the gmsh file, I believe that maybe either the mesh.write_to_file routine is doing something wrong or the import function is not working as it should.
I'm attaching to this post a zip file containing the original gmsh geometry file, the mesh generated from it, the little C++ test program and my system full info. It should be enough to easily reproduce the error. Using the provided geometry file you can also generate different meshes with gmsh to test for errors.
I'm using getfem++ version 2.0.1, the stable one.
Thanks
Giovani
3 - Normal
5 - Normal
1163162529
getfem_mesh::read_from_file error
Public
0
None
1581
Closed
Unlocked
1162674685
-
Added getfembug.tar.gz, #1466
giovanifaccin
1163161903
Original_Submission
Thanks Giovani for pointing out that bug. The gmsh import of getfem-2.0 was indeed very buggy. It is fixed now, in the svn trunk and in the getfem++-2.0.2.tar.gz file that I have put on our website (it is just an update of getfem_import.cc)
pommier
1163162529
Open/Closed
Open
Closed
renard
Status
None
Fixed
renard
-
bugs
renard
7877
1164747108
nessumo
Fixed
Hi,
I've got a very simple file using GetFem with Mooney-Rivlin law and large strain incompressibility.
It seems to work well with a rough mesh, but when I try to refine the mesh, I've got the following message:
Level 2 Warning in /usr/local/include/gmm_precond_ilu.h, line 138: pivot 59429 is too small
And the program do not converge.
Please help! (I've joined the file).
3 - Normal
5 - Normal
1164794687
Problem with Mooney-Rivlin
Public
0
None
1581
Closed
Unlocked
1164747108
-
Added SIMPLE_COMP.cc, #1620
nessumo
1164794687
Open/Closed
Open
Closed
renard
Original_Submission
Hi,
In fact, what you point out is not really a bug of Getfem.
You try to solve a problem with more than 50000 degrees of
freedom in 3D with an incompressibility condition. Unfortunately, the standard_solve proposed in getfem_model_solvers.h is not adapted to all cases.
In 3D, for less than 15000 dofs, the selected linear solver is Superlu for which a version is proposed with Getfem++ distribution. Unfortunately, for more than 15000 dofs and full 3D problems (this is not the case for 2D problems), Superlu often takes a lot of time to solve the system (but you can try it). Thus, standard_solve switches to gmres solver with an ilu
preconditionner (see default_linear_solver(pb) in getfem_model_solvers.h). Unfortunately again, this kind of preconditionner is not well adapted to "augmented" problems where a large number of multipliers is used (this is the case here, because the pression is introduced as a multiplier). You can try ilutp but it is usually very slow.
Thus, in this case, I would suggest you to rewrite your own solver, taking standard_solve as a model and trying different solvers.
One suggestion is that you can try to install MUMPS. It is interfaced in Getfem and gives better results than Superlu in the 3D cases.
I observed also in your program that Gmres did more or less converge despite the bad computed ilu preconditionner. So, In your case, it is possible that the Newton is not convergent because you start too far from the solution. You can try to put you load progressively (similarly as in the test program of Getfem).
It would be interesting to post a message to the Getfem user list if you find a solution to solve your problem.
renard
Assigned_to
100
4654
renard
Status
None
Fixed
renard
-
bugs
None
10510
1197540463
richard_g
Fixed
Hello
The getfem++-3.0.3 configure script contains an error in documentation that confuses new users attempting to
compile and install getfem.
./configure --help
reports:
....
--with-matlab-toolbox-dir : directory in which the matlab interface will be installed
....
However, the configure script ignores this parameter and is in fact looking for an argument called:
--with-toolbox-dir
Please verify this by looking at line 509 of config.in
===============
AC_ARG_WITH(toolbox-dir, [ --with-matlab-toolbox-dir : directory
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
and line 23970 of the ./configure script
===============
# Check whether --with-toolbox-dir was given.
if test "${with_toolbox_dir+set}" = set; then
withval=$with_toolbox_dir; TOOLBOXDIR="$withval"
else
TOOLBOXDIR="$prefix/getfem_toolbox"
fi
===============
Please could you make these two parameter names consistent?
Thanks
Richard
3 - Normal
5 - Normal
1197540928
Mistake in configure script for getfem++-3.0.3
Public
0
None
1581
Closed
Unlocked
1197540927
Status
None
Fixed
renard
1197540928
Open/Closed
Open
Closed
renard
1197541750
Original_Submission
thanks, it is fixed now (the correct option is now --with-matlab-toolbox-dir )
http://svn.gna.org/viewcvs/getfem/trunk/getfem%2B%2B/configure.in?rev=2730&r1=2728&r2=2730
pommier
-
bugs
renard
13014
1234894677
lsaavedr
Fixed
Dear developers,
many functions of stdlib, as strtod, are locales dependent, if Getfem uses them, then Getfem is locales dependent, the bug is in LC_NUMERIC, in some locales it's defines LC_NUMERIC="." (that is the suppose of Getfem), but in others locales it's defines LC_NUMERIC="," and in that locales getfem++ is break (for example, with "Error in bgeot_geometric_trans.cc"),
regards,
Luis.
3 - Normal
3 - Low
1235060789
GetFEM++ (C++ library) is locale dependent.
Public
0
None
1581
Closed
Unlocked
1235060789
Status
Confirmed
Fixed
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
14302
1252841514
pht
Fixed
../../src/gmm/gmm_inoutput.h:411: error: assignment of read-only location '* strchr(Valfmt, 68)'
../../src/gmm/gmm_inoutput.h:429: error: assignment of read-only location '* strchr(Rhsfmt, 68)'
4 - Important
5 - Normal
1252849624
assigning to const is not a good idea
Public
0
None
1581
Closed
Unlocked
1252849624
Status
None
Fixed
renard
Original_Submission
This is fixed in svn repository. The corresponding lines are not used in gmm.
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
14340
1253263378
mwalker
Fixed
I have made several attempts to use getfem++ via the python interface. I am running fedora 10 with numpy installed. The solvers won't solve properly, although the same code works perfectly well on a work-mates machine with numarray (and ubuntu). I am currently using the latest install,
__version__ = "$Revision: 3056 $"
The error I get is :
logic_error exception caught
Traceback (most recent call last):
File "test diffusion.py", line 78, in <module>
D.solve(mds,'lsolver','superlu')
File "/usr/local/lib/python2.5/site-packages/getfem/getfem.py", line
1435, in solve
return self.get("solve", mds, *args)
File "/usr/local/lib/python2.5/site-packages/getfem/getfem.py", line
1313, in get
return getfem('mdbrick_get',self.id, *args)
RuntimeError: (Getfem::InterfaceError) -- Error in getfem_superlu.cc, line
214 void gmm::SuperLU_solve(const gmm::csc_matrix<T, 0>&, T*, T*, double&,
int) [with T = double]:
SuperLU solve failed: info=9
3 - Normal
5 - Normal
1253705485
GETFEM with NUMPY via python
Public
0
None
1581
Closed
Unlocked
1253373757
Assigned_to
100
4654
renard
Original_Submission
When Superlu fails this means that the matrix of system to solve is not invertible. This could be a problem with boundary condition for instance.
This is strange that the same program works on another configuration. Are you sure this is exactly the same case ?
I just released version 4.0.0. Can you try with it ?
Otherwise, please post the smallest program wich is not working.
renard
1253624025
Original_Submission
Thanks for your reply.
Yes it is definitely the same program.
I shall attach a smaller version of the program, and the corresponding mesh.
Michael
(file #6780, file #6781)
mwalker
-
Added mesh.txt, #6781
mwalker
-
Added diffusion_help.py, #6780
mwalker
1253626020
-
Added mesh.jpg, #6782
renard
1253626134
Original_Submission
The attached mesh seems not to be coherent
See the drawing obtained with the Matlab interface
(file #6781)
renard
1253705139
Status
None
Fixed
renard
1253705485
Open/Closed
Open
Closed
renard
-
bugs
None
14484
1255072649
ycollet
Fixed
I use the Scilab interface.
When I launch for the first time demo_fictitious_domains, the demo works fine.
If I launch it a second time, it hangs:
Trace 2 in getfem_models.cc, line 1506: Mass term assembly for Dirichlet condition
Can't expand MemType 0: jcol 27855
logic_error exception caught
gf_model_get(md, 'solve');
!--error 999
gf_model_get: Error in getfem_superlu.cc, line 214 void gmm::SuperLU_solve(const gmm::csc_matrix<T, 0>&, T*, T*, double&, int) [with T = double]:
SuperLU solve failed: info=113082790
at line 114 of exec file called by : exec demo_fictitious_domains.sce;
I do a gf_workspace('clear all');
Then, I do a gf_workspace('stats'):
->gf_workspace('stats')
gf_workspace: message:
Workspace 0 [main -- 14 objects]
ID 0 gfMesh 143856 bytes used by ID1 ID2 ID3 ID4 ID5 ID6 ID7 ID9 ID11
ID 1 gfLevelSet 52572 bytes used by ID4
ID 2 gfLevelSet 105060 bytes used by ID4
ID 3 gfMeshFem 231688 bytes * Const
ID 4 gfMeshLevelSet 1196044 bytes used by ID5 ID6
ID 5 gfMeshIm 7164 bytes used by ID13
ID 6 gfMeshIm 7164 bytes used by ID13
ID 7 gfMeshFem 595080 bytes used by ID13
ID 8 gfFem 0 bytes * Const
ID 9 gfMeshFem 327048 bytes ID 10 gfFem 0 bytes * Const
ID 11 gfMeshFem 130760 bytes used by ID13
ID 12 gfFem 0 bytes * Const
ID 13 gfModel 18035060 bytes
-->gf_workspace('clear all')
-->gf_workspace('stats') gf_workspace: message:
Anonymous workspace (objects waiting for deletion)
ID 0 gfMesh 143856 bytes used by ID3
Workspace 0 [main -- 4 objects]
ID 3 gfMeshFem 231688 bytes * Const
ID 8 gfFem 0 bytes * Const
ID 10 gfFem 0 bytes * Const
ID 12 gfFem 0 bytes * Const
So, some objects are still not erased and it seems that these remaining objects make the demo hangs.
3 - Normal
7 - High
1255197309
gf_workspace('clear all') doesn't clear all the objects
Public
0
None
1581
Closed
Unlocked
1255197042
fixed bug #14484 on gf_workspace('clear all')
3215
renard
1255197309
Original_Submission
fixed in revision 3215. Now gf_workspace('clear all') clear also the static objects (they are not destroyed, they no longer appear in the workspace). Otherwise, a mesh on which a level set depend is never deleted due to the fact that when the mesh_fem associated to the level set is accessed, it appear in the workspace as a const object depending on that mesh.
renard
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
-
bugs
None
14485
1255072908
ycollet
None
While building the python interface, the following bug shows up:
My configure command line:
./configure --prefix=/opt/stow/getfem-dev/ --enable-python --enable-matlab --enable-shared --enable-qhull --enable-muparser --with-matlab-toolbox-dir=/home/collette/repositories/getfem-matlab/ --enable-boost
-----
currentclass='LevelSet'
currentclass='MeshLevelSet'
cp getfem.py getfem_python_reference.py
(export LD_LIBRARY_PATH=:../../../src/.libs && pydoc -w getfem_python_reference) && if test -d ../../../interface/doc; then cp getfem_python_reference.html ../../../interface/doc/getfem_python_reference.html; fi;
problem in getfem_python_reference - <type 'exceptions.ImportError'>: ../../../src/.libs/libgetfem.so.4: undefined symbol: _ZN3dallsERSoRKNS_10bit_vectorE
rm -f getfem_python_reference.py
make[1]: quittant le répertoire « /home/collette/repositories/getfem/getfem++/interface/src/python »
3 - Normal
5 - Normal
1257423812
Problem while building the python interface
Public
0
None
1581
Closed
Unlocked
1255189897
Original_Submission
I tried with exactly the same option to ./configure and I do not ave the problem. May be it is because of your configuration ...
renard
1255432652
Original_Submission
Doesn't seems to happen anymore.
maybe a make clean has cured the problem.
I will wait a little bit and if the problem doesn't happen anymore, I will close the bug.
YC
ycollet
1257423812
Original_Submission
This bug doesn't happen anymore. So, I close it.
YC
ycollet
Open/Closed
Open
Closed
ycollet
-
bugs
renard
14512
1255432858
ycollet
Fixed
The matlab / scilab interface functions:
- gf_mesh_levelset
- gf_mesh_levelset_get
- gf_mesh_levelset_set
- gf_fem_permuts
- gf_plot_mesh_quality
- gf_solve
are not documented.
YC
3 - Normal
1 - Later
1257254423
The matlab / scilab interface functions gf_mesh_levelset are not documented
Public
0
None
1581
Closed
Unlocked
1257254423
Original_Submission
addition/improvment documentation done. Obsolete matlab scripts gf_mesh_permuts.m and gf_plot_quality.m deleted.
renard
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
14683
1257423743
ycollet
Fixed
make install install some matlab files wether or not the --enable-matlab has been set via configure.
Doing make install, I saw some .m files installed in
prefixdir/getfem_toolbox/
For examples:
/usr/bin/install -c '../../../../getfem/interface/tests/matlab/private/assert.m' '/home/collette/repositories/install_dir/getfem-dev/getfem_toolbox/tests/assert.m'
/usr/bin/install -c '../../../../getfem/interface/tests/matlab/private/asserterr.m' '/home/collette/repositories/install_dir/getfem-dev/getfem_toolbox/tests/asserterr.m'
YC
3 - Normal
1 - Later
1257453242
make install install some matlab files wether or not the --enable-matlab has been set via configure
Public
0
None
1581
Closed
Unlocked
1257453242
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
Original_Submission
Modification done in interface/test/Makefile.am
renard
Status
None
Fixed
renard
1257453335
Fixed bug #14683
3334
renard
-
bugs
renard
15479
1267088899
till83
Fixed
Hello!
I may have a bug to report: I don't think that (on my system, see below) the method basic_dof_qdim(p) on a mesh_fem object really does what it's supposed to do (i.e. return the component of a dof, so for simple displacement on linear Lagrange in 3D 0,1,2 for x,y,z component of the displacement).
For testing I've modified the elastostatic test example (code see below, should be original though) with the following code lines (inserted in line 415)
// Testing basic_dof_qdim
if(1){
cout<<"=============================="<<endl;
for (size_type i=0; i<mf_u.nb_basic_dof(); ++i){
cout<<"----------"<<endl;
cout<<"dof # "<<i<<" point "<<mf_u.point_of_basic_dof(i)
<<" first convex # "
<<mf_u.first_convex_of_basic_dof(i)<<endl;
cout<<"mf_u.basic_dof_qdim("<<i
<<") = "<<size_type(mf_u.basic_dof_qdim(i))<<endl;
}
}
If the program reads the original elastostatic.param, the output gives same qdim of different dofs on the same node; excerpt:
----------
dof # 0 point [0.05, 0.05] first convex # 0
mf_u.basic_dof_qdim(0) = 0
----------
dof # 1 point [0.05, 0.05] first convex # 0
mf_u.basic_dof_qdim(1) = 1
----------
dof # 2 point [0, 0] first convex # 0
mf_u.basic_dof_qdim(2) = 1
----------
dof # 3 point [0, 0] first convex # 0
mf_u.basic_dof_qdim(3) = 1
So I looked into the source code in getfem_mesh_fem.cc of the definition of basic_dof_qdim(d), which looks the following:
dim_type mesh_fem::basic_dof_qdim(size_type d) const {
context_check(); if (!dof_enumeration_made) enumerate_dof();
size_type cv = first_convex_of_basic_dof(d);
GMM_ASSERT1(cv != size_type(-1), "Inexistent dof");
size_type tdim = f_elems[cv]->target_dim();
return dim_type(dof_structure.ind_in_convex_of_point(cv, d) % (Qdim/tdim));
}
Here's a logical error to me: The qdim number of a dof (as I understand it) should be defined by the modulus of the dof's local index on the convex, by Qdim/tdim. I don't see how the index of point(!!) d in convex cv has anything to do with this.
I think we use a method designed for a point number with the dof number here?
Please to excuse any inconvenience if I misunderstand the true conception here, but it really seems odd to me.
Best regards
Till
-----------------
getfem version 4.0.0
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
Ubuntu 8.04
3 - Normal
5 - Normal
1274298473
faulty getfem::mesh_fem::point_of_basic_dof (size_type d) ?
Public
0
None
1581
Closed
Unlocked
1267088900
-
Added elastostatic.cc, #8265
till83
-
Added Makefile, #8266
till83
-
Added elastostatic.param, #8267
till83
1267097391
Assigned_to
100
4654
renard
Status
None
In Progress
renard
Original_Submission
You are right, this method is not correct. The right code of the function should be somethething like
dim_type mesh_fem::basic_dof_qdim(size_type d) const {
context_check(); if (!dof_enumeration_made) enumerate_dof();
for (size_type i = d; i != d - Qdim && i != size_type(-1); --i) {
size_type cv = dof_structure.first_convex_of_point(i);
if (cv != size_type(-1)) return dim_type(d-i);
}
GMM_ASSERT1(cv != size_type(-1), "Inexistent dof");
return 0;
}
Can you try this and tell me if it works correctly, please ?
renard
1267128981
Original_Submission
Hi,
it works for FEM_PK(2,1), FEM_PK(3,3), FEM_QK(2,1) and FEM_PK_WITH_CUBIC_BUBBLE(1, 1) as far as I have tested, great!
I guess that it is generally functional, but I don't know about possible fancy FEM types that could be an issue to the method.
size_type cv has to be declared before the for loop because of the following assertion. The assertion also does catch the error if you try the method on a nonexisting dof number.
dim_type mesh_fem::basic_dof_qdim(size_type d) const {
context_check(); if (!dof_enumeration_made) enumerate_dof();
size_type cv;
for (size_type i = d; i != d - Qdim && i != size_type(-1); --i) {
cv = dof_structure.first_convex_of_point(i);
if (cv != size_type(-1)) return dim_type(d-i);
}
GMM_ASSERT1(cv != size_type(-1), "Inexistent dof");
return 0;
}
Thank you very much!
till83
1267173395
Status
In Progress
Fixed
renard
1274298473
Open/Closed
Open
Closed
renard
-
bugs
None
16270
1279272655
putanowr
Fixed
On my machine
Linux version 2.6.26-2-amd64 (Debian 2.6.26-15lenny3)
gcc (Debian 4.3.2-1.1) 4.3.2
getfem svn revision 3652
the test for bilaplacian fails with the message:
Trace 1 in bilaplacian.cc, line 559: Running sequential Getfem
MESH_TYPE=GT_PK(2,1)
FEM_TYPE=FEM_ARGYRIS
INTEGRATION=IM_TRIANGLE(13)
MESH_TYPE=GT_PK(2,1)
DIRICHLET_FEM_TYPE=FEM_PK(2,3)
Selecting Neumann and Dirichlet boundaries
Number of dof for u: 1046
============================================
| An error has been detected !!! |
============================================
Error in getfem_models.cc, line 415 :
Undefined model data or variable nu
If I move the line 367 in bilaplacian.cc up befor if statement
the the test fails with segmentation fault:
Trace 1 in bilaplacian.cc, line 559: Running sequential Getfem
MESH_TYPE=GT_PK(2,1)
FEM_TYPE=FEM_ARGYRIS
INTEGRATION=IM_TRIANGLE(13)
MESH_TYPE=GT_PK(2,1)
DIRICHLET_FEM_TYPE=FEM_PK(2,3)
Selecting Neumann and Dirichlet boundaries
Number of dof for u: 1046
Trace 2 in getfem_fourth_order.cc, line 469: Source term assembly for normal derivative Dirichlet condition
Trace 2 in getfem_fourth_order.cc, line 494: Mass term assembly for normal derivative Dirichlet condition
Total number of variables : 1170
Segmentation fault
3 - Normal
3 - Low
1279298734
Failed bilaplacian test
Public
0
None
1581
Closed
Unlocked
1279298734
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Original_Submission
This is fixed.
renard
-
bugs
None
16290
1279819436
progchild
Fixed
GMM++ loads hemitian/symmetric/skew symmetric matrix market files incorrect. If A matrix is hemitian, symmetric or skew symmetric then the matrix market format stores only half of the entries in the file. When loading such a file, GMM++ should restore these entries, but at the moment it only loads half of the elements.
I attached a corrected version of the "gmm_inoutput.h" header.
3 - Normal
5 - Normal
1283866145
GMM++ loads hemitian/symmetric/skew symmetric matrix market files incorrect
Public
0
None
1581
Closed
Unlocked
1279819436
-
Added progchild
progchild
-
Added gmm_inoutput.h, #9545
progchild
1279875973
Status
None
Fixed
renard
Original_Submission
Ok Hendrik, I incorporated your fix. Thank you for your contribution.
renard
1283866145
Open/Closed
Open
Closed
renard
-
bugs
None
16320
1280473635
sylvestre1
Fixed
In the example of the help page "Linear and non-linear elasticity", there is a reference to the tripod.GiD.msh mesh but it is not installed.
3 - Normal
5 - Normal
1286641153
Missing file in the scilab-getfem++
Public
0
None
1581
Closed
Unlocked
1286467848
Original_Submission
Is there any ETA of a new release of getfem with the files ?
sylvestre
1286545441
Original_Submission
This file is in the 4.1 release with two instances :
interface/tests/meshes/tripod.GiD.msh
interface/src/scilab/demos/data/tripod.GiD.msh
renard
1286545915
Original_Submission
Well, looks like a critical bug happened.
When the initial release of getfem 4.1 has been done, I submitted several bugs :
https://gna.org/bugs/?group=getfem
and it has been uploaded into Debian:
http://packages.qa.debian.org/g/getfem++/news/20100728T083245Z.html
However, it seems that the archive getfem-4.1.tar.gz into Debian is different from the one of the getfem++.
It is a nightmare on the distribution point of view. That means that there is two different releases of the same version...
A new release called 4.1.1 including the missing files should have been done...
sylvestre1
1286637240
Original_Submission
This bug can be closed
sylvestre1
1286641153
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
-
bugs
None
16321
1280473724
sylvestre1
Fixed
In the release 4.1, most of the file of the scilab-getfem module are missing.
5 - Blocker
5 - Normal
1286641203
Many Scilab files are missing from the tarball
Public
0
None
1581
Closed
Unlocked
1286621945
Original_Submission
Most of the file are now available except a few:
interface/src/scilab/makefile_builder.sce
interface/src/scilab/sci_getfem.iss
sylvestre1
1286634468
Original_Submission
Can you control that all the files necessary for scilab are present in the release 4.1.1 I just make available for download ?
renard
1286637220
Original_Submission
Indeed, they are now available.
Thanks.
sylvestre1
1286641203
Open/Closed
Open
Closed
renard
Status
None
Fixed
renard
-
bugs
None
16322
1280473815
sylvestre1
None
Play with the demo and then end Scilab:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000000, pid=20024, tid=3027695840
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK Server VM (14.0-b16 mixed mode linux-x86 )
# Derivative: IcedTea6 1.8
# Distribution: Debian GNU/Linux unstable (sid), package 6b18-1.8-1
# Problematic frame:
# C 0x00000000
#
# An error report file with more information is saved as:
# /home/sylvestre/dev/debian/debian-science/packages/getfem++/build-area/hs_err_pid20024.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
3 - Normal
5 - Normal
1321253592
Closing Scilab after using scilab-getfem causing a segfault
Public
0
None
1581
Closed
Unlocked
1280473815
-
Added hs_err_pid20024.log, #9632
sylvestre1
1321253591
Open/Closed
Open
Closed
ycollet
1321253592
Original_Submission
Seems to be fixed.
I was not able to reproduce this on Scilab-5.3.3 64 bits + latest version of getfem on trunk.
I close the bug.
YC
ycollet
-
bugs
None
16323
1280473892
sylvestre1
None
The summary says all.
I have to do:
link("/usr/lib/libgetfem.so.4")
before loading the module.
3 - Normal
5 - Normal
0
Scilab-getfem++ loader is not loading getfem library
Public
0
None
1581
Open
Unlocked
1286637275
Original_Submission
This bug still occurs in getfem 4.1.1
sylvestre1
1291072807
Original_Submission
Actually, if the load is missing, it is because scilab-getfem is built against a static library...
cf:
ldflags = sci_getfem_path + '/../../../.libs/libgetfemint.a ' + sci_getfem_path + '/../../../../../src/.libs/libgetfem.a';
in interface/src/scilab/sci_gateway/c/loader.sce
This should not be done.
sylvestre
1321253725
Original_Submission
The main advantage of a static link is that a user can build and compile the toolbox without admin rights.
You just have a scilab dynamic library which contains everything.
Maybe I should add an option to ask to perform a dynamic link against getfem ...
ycollet
-
bugs
None
16324
1280473994
sylvestre1
None
It should be redirected into the Scilab console.
For example, the demo "fictitious domains" is displaying the following into the terminal:
Level 1 Warning in getfem_mesh_level_set.cc, line 137: Pure multi has failed in interpolate_face !!
Level 1 Warning in getfem_mesh_level_set.cc, line 137: Pure multi has failed in interpolate_face !!
Trace 2 in getfem_models.cc, line 1627: Mass term assembly for Dirichlet condition
Trace 2 in getfem_models.cc, line 2524: Stiffness matrix assembly for isotropic linearized elasticity
3 - Normal
5 - Normal
0
Scilab-getfem++ is displaying feedbacks in the console
Public
0
None
1581
Open
Unlocked
1321253764
Original_Submission
I will try to see how to redirect all the messages in the scilab console ...
YC
ycollet
1321881959
Original_Submission
Done for linux. Now all the messages are redirected to the scilab console.
For Windows, there is a problem. Since getfem is compiled in its own library, the cout and cerr are not overridable.
We need to find another solution for Windows.
In the mean time, you can activate the windows dos console:
consolebox('on')
ycollet
-
bugs
putanowr
16608
1283294170
putanowr
Fixed
The bug was in methods:
asm_real_tangent_terms
asm_complex_tangent_terms
and it resulted is segmentation fault after accessing null pointer. The null pointer was the pointer of the mesh_fem for the H matrix when using getfem::add_generalized_Dirichlet_condition_with_multipliers
with constant H matrix (no mesh_fem in that case).
4 - Important
5 - Normal
1283866111
Fixed bug in Dirichlet_condition_brick
Public
0
None
1581
Closed
Unlocked
1283866111
Open/Closed
Open
Closed
renard
-
bugs
None
16658
1283864411
sigurds
Fixed
When compiling getfem using MINGW32 I get the following error:
getfem_mesh.cc:586: error: 'GETFEM_VERSION' was not declared in this scope
I have googled the problem and found it mentioned elsewhere, but no resolution.
The getfem_arch_config.h file only contains:
#undef GETFEM_VERSION
I have attached my config.log file in case that gives you some useful information.
4 - Important
5 - Normal
1283928689
GETFEM_VERSION was not declared in this scope
Public
0
None
1581
Closed
Unlocked
1283864411
-
Added config.h, #10223
sigurds
-
Added sigurd.saue@ntnu.no
sigurds
-
Added getfem_arch_config.h, #10225
sigurds
-
Added config.log, #10224
sigurds
1283866071
Original_Submission
I already done some compilations with MINGW32 without having this problem. GETFEM_VERSION is defined in getfem/getfem_arch_config.h which is produced by the configure script.
For instance, line 3192 of Sigurd Saue config.log is
| #define VERSION "4.1"
which indicates that the config.h should be ok ...
Is there a line
#define VERSION "4.1"
in the file config.h ?
renard
1283866638
Original_Submission
I did attach both config.h and getfem_arch_config.h to the original bug report as I understood those were involved. There is no version definition in either of those files (only #undef).
sigurds
1283868064
Original_Submission
The attached config.h is not valid at all of course, it is identical to config.h.in. The config.status script did not its job !
This corresponds to the two macros
AC_CONFIG_HEADER(config.h)
AX_PREFIX_CONFIG_H(src/getfem/getfem_arch_config.h,GETFEM)
of configure.in.
Can you execute
./config.status config.h
and check the result ?
renard
1283868545
Original_Submission
I ran config.status with no effect on config.h. This is the extra output to the config.log:
## ---------------------- ##
## Running config.status. ##
## ---------------------- ##
This file was extended by getfem config.status 4.1, which was
generated by GNU Autoconf 2.65. Invocation command line was
CONFIG_FILES =
CONFIG_HEADERS =
CONFIG_LINKS =
CONFIG_COMMANDS =
$ ./config.status config.h
on HFF30396
config.status:1344: creating config.h
config.status:1516: config.h is unchanged
sigurds
1283869187
Original_Submission
So the problem is why config.status produces a wrong config.h. Can you look into config.status and find VERSION in it (or post config.status).
renard
1283869398
-
Added config.status, #10227
sigurds
Original_Submission
I have attached config.status. Seems to be correct versions there.
(file #10227)
sigurds
1283870453
Original_Submission
I do not see the problem ... sorry !
If there is a problem with awk, an error should appear in the config.log ...
It produces a file $tmp/subs.awk ... which should be correct ...
renard
1283876997
Original_Submission
It seems to work now. The trouble had nothing to do with getfem, so you are free to close the issue.
I was using Winzip to unzip the downloaded tar archive, and it seems that it by default converts line endings. So after unzipping again, I ran dos2unix on the *.in files. Now the config.h file looks fine.
Thanks for your assistance and quick response.
sigurds
1283928689
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
-
bugs
None
18083
1304062809
baudoly
Fixed
Description:
with 'make check', nonlinear_elastostatic fails with message:
MESH_TYPE=GT_PK(3,1)
FEM_TYPE=FEM_PK(3,2)
INTEGRATION=IM_TETRAHEDRON(6)
Selecting Neumann and Dirichlet boundaries
Test 74 wrong derivative of sigma, i=0, j=0, dsigma=-733.283, var sigma = -733.431
Test 90 wrong derivative of strain_energy, d=1.47731e+07, d2=1.47716e+07
Test 90 wrong derivative of sigma, i=0, j=0, dsigma=-7.06813e+11, var sigma = -7.06932e+11
<...>
Error in /Users/basile/Desktop/XCode-getfem-4.1.1/XCode/../src/getfem_nonlinear_elasticity.cc, line 337 :
Derivative test has failed
Diagnostic:
Derivatives of strain energy and stress sigma are computed by finite differences and checked against symbolic derivative. Test is done 100 times near randomly chosen strain states E. Each E is computed as E=(F^T.T-Id)/2, where F is a random 3*3 matrix. Among the 100 samples, it happens once in a while that the value of (det F) is significantly less than 1. For the samples such that (det F) is 10^-3 or less (2% of samples in my cases), the computed matrix sigma is numerically large, typically of order 1.e+7. Round-off errors become larger, and the tests
if (gmm::abs(d-d2)/(gmm::abs(d)+1e-40) > 1e-4) { /* error */ }
and/or
if (gmm::abs(dsigma(i,j) - sigma2(i,j))
/(gmm::abs(dsigma(i,j)) + 1e-40) > 1e-4) { /* error */ }
fail (by very little actually).
Suggested fix:
In random_E, initialize matrix Phi(=F) in a way that warrants (det F)>1.e-2.
Environment:
GetFEM 4.1.1
./configure uses default options
MacOS X 10.6.7 (Snow Leopard)
3 - Normal
5 - Normal
1314717641
derivative check fails in nonlinear_elastostatic test
Public
0
None
1581
Closed
Unlocked
1304062810
-
Added Derivative check in nonlinear_elastostatic diagnose.pdf, #12926
baudoly
1304105348
Original_Submission
Thank you very much for your analysis and suggestion !
I add
do {
gmm::fill_random(Phi);
d = gmm::lu_det(Phi);
} while (d < scalar_type(0.01));
in the method abstract_hyperelastic_law::random_E
renard
1314717641
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
-
bugs
None
18417
1311545272
johny
None
Lastly I have a bug in a level set procedure. It seems to me that it is very important bug because the results of xfem analysis sometimes may be totally erroneous. It took me few days to identify the bug and to get to the source of the bug.
The source of the bug lays in the static void add_sub_zones_no_zero function in getfem__mesh__level__set.cc file.
Ive prepared the test program to see what is happening in the function:
#include <iostream>
#include <set>
typedef std::string subzone;
typedef std::set<const subzone *> zone;
typedef std::set<const zone *> zoneset;
int main ()
{
int i, j;
subzone s;
std::set<subzone> allsubzones;
for(i =0; i<4; i++)
{
zone z;
zone::iterator it_z;
s = '+' ; z.insert(&(*(allsubzones.insert(s).first)));
s = '-' ; z.insert(&(*(allsubzones.insert(s).first)));
for(it_z=z.begin(), j=1;it_z!=z.end();it_z++,j++)
{ std::cout<<**it_z<<" "; } std::cout<<std::endl;
allsubzones.clear();
}
}
One would expect that the result of the program should be:
+ -
+ -
+ -
+ -
While on one machine I got:
+ -
- +
+ -
- +
On other machine I got:
+ -
- +
- +
+ -
The same is happening in the getfem every time when a mesh_level_set::adapt() function is started. It is enough to start the function few times. In a consequence, for example, the a function fem_level_set::interpolation gives quite different results (depends on the sequence + - or - +).
And by the way one more thing. In the function fem_level_set::find_zone_id the variable z is initiated from the common_ls_zones (line 101) while few lines beneath z is set by the other procedure (line 107). Eventually which one is correct?
I hope for correcting the bug.
I'm open for helping to correct the bug if You need.
With best regards
Jan Jaskowiec
3 - Normal
5 - Normal
0
mesh_level_set::update need to be corrected
Public
0
None
1581
Open
Unlocked
1311545272
-
Added johny@l5.pk.edu
johny
-
Added putanowr@l5.pk.edu.pl
johny
-
Added pl
johny
1314717825
Original_Submission
The order of the different objects in a set is not garanteed, so it seems to me that the result is not incoherent.
Normally, it should have no impact in the computation of the differente XFEM zones. Do you think it really has ?
Yves.
renard
-
bugs
None
19013
1321549416
rfiato
Fixed
In attempting to incorporate Gmm++ into my code, I ran into the fact that, in gmm_matrix.h, csc_matrix<T, shift>::init_with_identity(size_type n) doesn't compile because it tries to delete[] members that are std:vector<>s; this appears to be a vestige left over from a previous version when these data members were T* instead. Although I don't directly use csc_matrix<>, one of my C++ compilers (HP C++ on OpenVMS IA64) refuses to compile the code because it sees that invalid operations are attempted on std::vector<> objects.
The simple patch below placates my compiler and should fix the problem.
--- [.orig]gmm_matrix.h Fri Jul 9 02:42:45 2010
+++ gmm_matrix.h Fri Nov 11 18:37:48 2011
@@ -557,7 +557,6 @@
template <typename T, int shift>
void csc_matrix<T, shift>::init_with_identity(size_type n) {
- if (pr) { delete[] pr; delete[] ir; delete[] jc; }
nc = nr = n;
pr.resize(nc); ir.resize(nc); jc.resize(nc+1);
for (size_type j = 0; j < nc; ++j)
3 - Normal
5 - Normal
1321606988
In gmm_matrix.h, delete[] is attempted on std::vector<>
Public
0
None
1581
Closed
Unlocked
1321550044
-
Added gmm_matrix.h.patch, #14568
rfiato
1321606988
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Original_Submission
Thank you for your bug report. I incorporated your patch.
Yves.
renard
-
bugs
None
19040
1321881730
ycollet
None
add a function:
- getfem_set_stream
- gf_set_stream
which overload the cout and cerr and allow the user to send his own stream.
getfem use a gf_cout and gf_cerr instead of cout and cerr.
static ostream gf_cout = std::cout;
static ostream gf_cerr = std::cerr;
with such a function, it will be easier for interfaces to redirect cout and cerr into their own console (matlab, scilab, python).
1 - Wish
5 - Normal
0
add a function to overload cout and cerr
Public
0
None
1581
Open
Unlocked
-
bugs
None
19075
1322541413
rfiato
Fixed
In a couple places in gmm_interface.h, code tries to do "end+nbc*nbl", where "begin_" was intended instead of "end" (which actually doesn't compile because "end" is a member function).
I've attached a patch to fix the issue.
3 - Normal
5 - Normal
1322671623
Typos in gmm_interface.h
Public
0
None
1581
Closed
Unlocked
1322541413
-
Added gmm_interface.h.patch, #14615
rfiato
1322671623
Open/Closed
Open
Closed
renard
Status
None
Fixed
renard
Original_Submission
Dear Randy,
thank you for your patch! I included it in the current release.
Yves.
renard
-
bugs
None
19479
1329750983
rla48
None
I have downloaded the 4.1.1 GET FEM package and I believe I have properly compiled everything. I have a Mac OSX and compiled gmm then getfem-4.1.1 following the instructions. Everything went fine without any errors until I try to import getfem.
See below:
------------------------------
In [5]: import getfem
-------------------------------
ImportError Traceback (most recent call last)
/Users/rla48/Desktop/Source/getfem-4.1.1/interface/src/python/<ipython console> in <module>()
/Users/rla48/Desktop/Source/getfem-4.1.1/interface/src/python/getfem.py in <module>()
38 from numpy import *
39
---> 40 from _getfem import *
41 obj_count = {}
42 getfem('workspace', 'clear all')
ImportError: dynamic module does not define init function (init_getfem)
----------------------
Please let me know what the possible cause of this error may be.
Thanks,
Rick
3 - Normal
5 - Normal
0
Import Error for GET FEM
Public
0
None
1581
Open
Unlocked
1329750983
-
Added rla48@case.edu
rla48
-
bugs
None
19941
1342348268
tmac
Fixed
Hi!
It is my impression that it is considered bad practice to put statements like
using std::cout;
in header files, like is done in gmm_std.h, since it imports symbols inte the global scope, and there is no may of knowing if someone will have a problem due to a naming conflict.
I noticed this because my getfem-program didn't need the std:: in front of cout, which I otherwise always use.
I think I tracked down the reason to lines 133-144 in gmm_std.h:
133 using std::endl; using std::cout; using std::cerr;
134 using std::ends; using std::cin;
although I'm not sure if such lines are present or not in other header files.
So I wonder if it would be a good idea to eliminate those lines from that file, and instead do a search/replace to inserts std:: throughout it and possibly other header files that currently depend on them?
Best regards,
Torquil Sørensen
3 - Normal
5 - Normal
1356076920
gmm_std.h and std::cout + friends
Public
0
None
1581
Closed
Unlocked
1342449886
Original_Submission
Dear Torquil,
You are perfectly right. I don't remember why these declarations are outside the namespace gmm. I think I shall translate them just after the line "namespace gmm {".
Yves.
renard
1342508636
Status
None
Fixed
renard
1356076920
Open/Closed
Open
Closed
renard
-
bugs
None
19958
1342719151
laubry
Fixed
The gauss lobatto elements (FEM_PK_GAUSSLOBATTO1D(K)) seem broken with getfem 4.1.2 and latest svn trunk.
The problem seems to come from the ordering of the nodes with
respect to the ordering of the basis functions in getfem_fem.cc
(attached is a test program to demonstrate the problem)
This simple patch seems to fix the problem :
@@ -1463,8 +1463,14 @@ namespace getfem {
init_cvs_node();
std::stringstream sstr; sstr << "IM_GAUSSLOBATTO1D(" << k*2-1 << ")";
pintegration_method gl_im = int_method_descriptor(sstr.str());
+ std::vector<base_node> points(k+1);
for (size_type i = 0; i < k+1; ++i) {
- add_node(lagrange_dof(1), gl_im->approx_method()->point(i));
+ points[i] = gl_im->approx_method()->point(i);
+ }
+ std::sort(points.begin(),points.end());
+ for (size_type i = 0; i < k+1; ++i) {
+ cout << points[i][0] << endl;
+ add_node(lagrange_dof(1), points[i]);
}
base_.resize(k+1);
const double *coefs = fem_coeff_gausslob[k];
3 - Normal
5 - Normal
1356076933
problem with GAUSSLOBATTO1D elements
Public
0
None
1581
Closed
Unlocked
1342719151
-
Added test_sem.param, #16135
laubry
-
Added test_gll.cc, #16134
laubry
1342784364
Status
None
Fixed
renard
Original_Submission
You are right, the order of Gauss-Lobatto points has changed in the quadrature formula and GAUSSLOBATTO1D elements was broken. Thank you very much for your bug fix.
renard
1356076933
Open/Closed
Open
Closed
renard
-
bugs
None
20091
1345753257
tmac
Works For Me
After having quite a lot of problems trying to use the reduction feature of GetFEM++, I have decided to create what I think is a test case program that shows a bug in the reduction functionality. The manifestation of the bug is in this case an incorrect mass matrix for the reduced system.
The program creates a simple mesh on the segment [0,1], consisting only of the two endpoints and one convex, which is the segment between. On this mesh I have defined the mesh_fem FEM_PK(1,2), so there are three evenly spaced DOFs. I use the integration method IM_EXACT_SIMPLEX(1).
Then I define the following reduction:
psi_0 := phi_0 + 0.5*phi_1
psi_1 := 0.5*phi_1 + phi_2
where (phi_0, phi_1, phi_2) is the old unreduced basis, and (psi_0, psi_1) is the new reduced basis.
Using what we know about FEM_PK(1,2), we find that the new basis functions are:
psi_0 = 1-x
psi_1 = x
Therefore, the mass matrix in the reduced case should be the 2x2 matrix
[1/3 1/6]
[1/6 1/3]
However, this is not what GetFEM++ calculates in my test case program. Instead it gives
[0.133333 -0.0333333]
[-0.033333 0.133333]
and this result depends on the choice of extension matrix. Strangely, some elements are negative, while the basis functions are all positive.
I have attached the program source code. If more information is needed, I will be very pleased to provide it.
3 - Normal
5 - Normal
1351796954
Reduction gives incorrect mass matrix
Public
0
None
1581
Closed
Unlocked
1345753258
-
Added reduction_bug.cpp, #16423
tmac
-
Added tmac
tmac
1346077453
Original_Submission
You have to swap your matrix E and R and transpose them. The most important is the extension matrix.
See the documentation page
http://download.gna.org/getfem/html/homepage/userdoc/bfem.html#third-level-the-optional-linear-transformation-or-reduction
in particular, the extension matrix should be such that given a vector U of reduced dof, V=EU should correspond to a vector of basic dof. This is not the case with your extension matrix.
renard
Status
None
Works For Me
renard
1351763527
Original_Submission
Thank you! It works nicely now.
tmac
1351796954
Open/Closed
Open
Closed
renard
-
bugs
None
20284
1352103385
tmac
None
I hereby note that it would be nice to have export of mesh and solution data to the Gmsh MSH format (ASCII and/or BINARY versions), since the Gmsh POS format, to which Getfem can currently export, is described as a "legacy format" in the Gmsh 2.6.1 documentation.
Ref:
http://geuz.org/gmsh/doc/texinfo/gmsh.html#File-formats
1 - Wish
5 - Normal
0
Gmsh MSH format export
Public
0
None
1581
Open
Unlocked
-
bugs
None
20379
1356006714
tmac
Fixed
Hi!
When using std::cout, a printed row_matrix does not look exactly the same as the output of a col_matrix, for some reason. There are extra spaces in the printed col_vector, as seen here:
+verbatim+
matrix(4, 4)
( )
( (r0,1) (r1,1) (r2,1) (r3,1) )
( (r0,2) (r1,2) (r2,2) (r3,2) )
( (r0,3) (r1,3) (r2,3) (r3,3) )
matrix(4, 4)
( )
( (r0, 1) (r1, 1) (r2, 1) (r3, 1) )
( (r0, 2) (r1, 2) (r2, 2) (r3, 2) )
( (r0, 3) (r1, 3) (r2, 3) (r3, 3) )
-verbatim-
This was the output from:
+verbatim+
// Row matrix
gmm::row_matrix<gmm::wsvector<int>> Mr;
gmm::resize(Mr, 4, 4);
gmm::clear(Mr);
for(int i = 0; i != 4; ++i) {
for(int j = 0; j != 4; ++j) {
Mr(i,j) = i;
}
}
std::cout << Mr << std::endl;
// Column matrix
gmm::col_matrix<gmm::wsvector<int>> Mc;
gmm::resize(Mc, 4, 4);
gmm::clear(Mc);
for(int i = 0; i != 4; ++i) {
for(int j = 0; j != 4; ++j) {
Mc(i,j) = i;
}
}
std::cout << Mc << std::endl;
-verbatim-
It is unimportant, but perhaps you would like to change it.
Best regards
Torquil Sørensen
2 - Minor
5 - Normal
1356076879
Unimportant esthetic detail in printed output of col_matrix
Public
0
None
1581
Closed
Unlocked
1356076879
Open/Closed
Open
Closed
renard
Original_Submission
Ok, this is fixed. Thank you for the report.
renard
Status
None
Fixed
renard
-
bugs
None
20502
1360709901
mahdihaddad
Works For Me
Hello every buddy,
I intend to install GetFEM++ on CentOS operating system. However, the GetFEM++ documentation asks to install "package libqhull-dev in debian distribution". I have the following errors while configuring GetFEM++:
checking for qh_new_qhull in -lqhull... no
checking qhull/qhull.h usability... no
checking qhull/qhull.h presence... no
checking for qhull/qhull.h... no
configure: error: header files qhull/qhull.h not found. Use
--enable-qhull=no flag
Are the qhull packages in
"http://rpmfind.net/linux/rpm2html/search.php?query=qhull" appropriate options for my case?
How can I configure GetFEM using a qhull package compatible to CentOS operating system? Is it possible to do that?
Thanks a lot in advance,
Mahdi
4 - Important
5 - Normal
1360742341
A problem in using qhull
Public
0
None
1581
Closed
Unlocked
1360709901
-
Added mahdihaddad
mahdihaddad
1360742341
Original_Submission
Consider
http://pkgs.org/centos-6-rhel-6/naulinux-school-x86_64/qhull-devel-2010.1-1.el6.x86_64.rpm.html
renard
Open/Closed
Open
Closed
renard
Status
None
Works For Me
renard
-
bugs
renard
20857
1370008186
tmac
Fixed
Compiling with GCC 4.8.1 gives the following warnings:
1)
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_fem.h: In member function void getfem::virtual_fem::interpolation_grad(const getfem::fem_interpolation_context&, const CVEC&, VMAT&, bgeot::dim_type) const:
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_fem.h:766:59: warning: typedef T locally defined but not used [-Wunused-local-typedefs]
typedef typename gmm::linalg_traits<CVEC>::value_type T;
2)
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_interpolation.h: In function void getfem::interpolation_function__(const getfem::mesh_fem&, VECT&, F&, const dal::bit_vector&, const M&, gmm::abstract_matrix):
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_interpolation.h:122:59: warning: typedef T locally defined but not used [-Wunused-local-typedefs]
typedef typename gmm::linalg_traits<VECT>::value_type T;
3)
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_export.h: At global scope:
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_export.h:296:29: warning: auto_ptr is deprecated (declared at /mn/anatu/cma-u3/tmac/usr/stow/gcc/include/c++/4.8.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
std::auto_ptr<mesh_fem> pmf;
4)
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_assembling.h: In function void getfem::asm_dirichlet_constraints(MAT&, VECT1&, const getfem::mesh_im&, const getfem::mesh_fem&, const getfem::mesh_fem&, const getfem::mesh_fem&, const VECT2&, const getfem::mesh_region&, int):
/mn/anatu/cma-u3/tmac/usr/include/getfem/getfem_assembling.h:1137:69: warning: typedef magn_type locally defined but not used [-Wunused-local-typedefs]
typedef typename gmm::number_traits<value_type>::magnitude_type magn_type;
And two about GMM:
5)
In file included from /mn/anatu/cma-u3/tmac/usr/include/gmm/gmm_iter_solvers.h:85:0,
from /mn/anatu/cma-u3/tmac/usr/include/gmm/gmm.h:44,
from /mn/anatu/cma-u3/tmac/research/upwinding/source/upwind_custom_fem_bc.cpp:47:
/mn/anatu/cma-u3/tmac/usr/include/gmm/gmm_precond_diagonal.h: In function void gmm::right_mult(const gmm::diagonal_precond<Matrix>&, const V1&, V2&):
/mn/anatu/cma-u3/tmac/usr/include/gmm/gmm_precond_diagonal.h:116:56: warning: typedef T locally defined but not used [-Wunused-local-typedefs]
typedef typename linalg_traits<Matrix>::value_type T;
6)
In file included from /mn/anatu/cma-u3/tmac/usr/include/gmm/gmm.h:46:0,
from /mn/anatu/cma-u3/tmac/research/upwinding/source/upwind_custom_fem_bc.cpp:47:
/mn/anatu/cma-u3/tmac/usr/include/gmm/gmm_inoutput.h: In member function void gmm::HarwellBoeing_IO::read(gmm::csc_matrix<T, shift>&):
/mn/anatu/cma-u3/tmac/usr/include/gmm/gmm_inoutput.h:330:53: warning: typedef IND_TYPE locally defined but not used [-Wunused-local-typedefs]
typedef typename csc_matrix<T, shift>::IND_TYPE IND_TYPE;
2 - Minor
5 - Normal
1377512867
Warnings from GCC 4.8.1
Public
0
None
1581
Closed
Unlocked
1370276972
Original_Submission
I corrected the items corresponding to a unused type declaration.
Concerning auto-ptr, it is deprecated in C++11 only and the class which can be used instead (unique_ptr) is only available in C++11. So that, for the moment, we are obliged to keep the use of auto-ptr.
Yves.
renard
1377512867
Status
None
Fixed
renard
Assigned_to
100
4654
renard
Open/Closed
Open
Closed
renard
-
bugs
renard
21054
1377254974
tmac
Fixed
Hi!
With gcc (GCC) 4.8.2 20130815 (prerelease), I get the following warning from getfem_fem.h in the newest GetFEM SVN source code:
getfem_fem.h:791:59: warning: typedef T locally defined but not used [-Wunused-local-typedefs]
typedef typename gmm::linalg_traits<CVEC>::value_type T;
Best regards,
Torquil Sørensen
2 - Minor
5 - Normal
1377512756
Warning in getfem_fem.h
Public
0
None
1581
Closed
Locked
1377512756
Assigned_to
100
4654
renard
Open/Closed
Open
Closed
renard
Status
None
Fixed
renard
Discussion_Lock
Unlocked
Locked
renard
-
bugs
renard
21176
1380794853
mgregor
Fixed
In gmm++ 4.2, header gmm_except.h GMM_WARNING2, GMM_WARNING3 and GMM_WARNING4 remain undefined if GMM_WARNING_LEVEL is set to 0.
This is due to a typo in the corresponding else branches of preprocessor code, where instead of GMM_WARNING2, GMM_WARNING3, and GMM_WARNING4, GMM_WARNING1 is defined in every case.
I am attaching a diff with the corrected version.
3 - Normal
5 - Normal
1381219921
GMM_WARNING2, 3, and 4 undefined with GMM_WARNING_LEVEL 0
Public
0
None
1581
Closed
Unlocked
1380794853
-
Added gmm_except.patch, #19128
mgregor
-
Added mgregor
mgregor
1381219921
Open/Closed
Open
Closed
renard
Original_Submission
Thank you for this bug report.
It has already been corrected in the svn repository. So it will be incorporated to the next 4.3 release.
renard
Assigned_to
100
4654
renard
Status
None
Fixed
renard
-
bugs
None
21273
1384364616
tmac
None
The GetFEM build (current SVN) fails with an error related to MUMPS, despite having specified --disable-mumps --disable-par-mumps configure options:
Configure invokation:
$ LDFLAGS="-L$HOME/usr/lib -L$HOME/usr/lib64" CFLAGS=-I$HOME/usr/include CXXFLAGS=-I$HOME/usr/include BLAS_LIBS="-L$HOME/usr/lib -lsatlas" ./configure --prefix=$HOME/usr/stow/getfem --enable-shared --disablestatic --with-pic --disable-python --disable-scilab --disable-experimental --disable-superlu --enable-paralevel=2 --disable-mumps --disable-par-mumps
Configure summary output:
------------------------------------------------------------------------------
Libraries Used:
---------------
- QD library not found (don't worry, this library is only recommended for very specific uses).
- Qhull not found. Mesh generation will be disabled.
- MuParser found. Used for parsing mathematical expressions.
- Mumps not found. Not using the MUMPS library for large sparse linear systems.
- Lapack library found: -llapack
- BLAS library found. Link options: -L/mn/anatu/cma-u3/tmac/usr/lib -lsatlas
You can give the location of your prefered blas library with either
the --with-blas=<lib> option, or the BLAS_LIBS environment variable
for example: ./configure BLAS_LIBS="-L/usr/lib/sse2/atlas/ -lblas"
Lastly, the build error:
/bin/sh ../libtool --tag=CXX --mode=compile mpic++ -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I.. -I/mn/anatu/cma-u3/tmac/usr/include -DGETFEM_PARA_LEVEL=2 -DGMM_USES_MPI -DGMM_USES_BLAS -I/mn/anatu/cma-u3/tmac/usr/stow/getfem/include -I/mn/anatu/cma-u3/tmac/usr/stow/getfem/include -DGMM_USES_LAPACK -I/mn/anatu/cma-u3/tmac/usr/include -O3 -MT getfem_model_solvers.lo -MD -MP -MF .deps/getfem_model_solvers.Tpo -c -o getfem_model_solvers.lo getfem_model_solvers.cc
libtool: compile: mpic++ -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I.. -I/mn/anatu/cma-u3/tmac/usr/include -DGETFEM_PARA_LEVEL=2 -DGMM_USES_MPI -DGMM_USES_BLAS -I/mn/anatu/cma-u3/tmac/usr/stow/getfem/include -I/mn/anatu/cma-u3/tmac/usr/stow/getfem/include -DGMM_USES_LAPACK -I/mn/anatu/cma-u3/tmac/usr/include -O3 -MT getfem_model_solvers.lo -MD -MP -MF .deps/getfem_model_solvers.Tpo -c getfem_model_solvers.cc -fPIC -DPIC -o .libs/getfem_model_solvers.o
In file included from getfem/getfem_model_solvers.h:43:0,
from getfem_model_solvers.cc:22:
./gmm/gmm_MUMPS_interface.h:48:22: fatal error: smumps_c.h: No such file or directory
#include <smumps_c.h>
^
compilation terminated.
make[2]: *** [getfem_model_solvers.lo] Error 1
make[2]: Leaving directory `/tmp/getfem/getfem/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/getfem/getfem'
make: *** [all] Error 2
The build was attempted with the latest snapshot of GCC-4.8.2.
3 - Normal
5 - Normal
0
Mumps-related build failure
Public
0
None
1581
Open
Unlocked
1384528654
Original_Submission
This is normal because the option --enable-paralevel=2 means MPI version of Getfem which, for the moment, only works with the parallel version of Mumps for the solving of linear systems. So this option enforces the search of Mumps.
Do you want to use the parallel version of Getfem without Mumps ?
In that case, you have to interface a parallelized linear solver which accept distributed matrices.
Anyway, Mumps is a standard package which is normally easy to install.
renard
1384625550
Original_Submission
I'm using GetFEM to create a mesh and assemble matrices, but I transfer the data to PETSc, where I solve. So I was hoping to install a parallel-enabled GetFEM, and avoid MUMPS since I don't solve in GetFEM.
However, I have now managed to install MUMPS and subsequently GetFEM.
tmac
1384778766
Original_Submission
You are right, we could let the possibility not to link mumps for the paralellized version. I will consider it in the future.
renard
-
bugs
renard
21377
1388045595
paolog
Fixed
in gmm_std.h version 4.2 there is a new line:
#include <omp.h>
can you please put that inside the
#ifdef _OPENMP
section ? this would prevent conflicts for people who do not use OPENMP and wish to compile with dummy implementations for omp_init_lock & co.
Thanks
3 - Normal
5 - Normal
1388059617
solve openmp conflict
Public
0
None
1581
Closed
Unlocked
1388059617
Status
None
Fixed
renard
Original_Submission
Ok, the change is done. Thank you for the fix.
Yves.
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
23380
1426176716
tmac
Fixed
Hi!
I suspect that there is a parsing error in the high-level assembly code. In the attached test program, the two lines indicated by "Case A" and "Case B" should be equivalent, right?
But the program output is positive for Case A, and negative for Case B. I would expect a negative value to be correct for this expression. If so, Case A is incorrectly interpreted.
I'm using a very recent Getfem SVN version, compiled with a recent GCC 4.9.3 snapshot.
Best regards
Torquil Sørensen
3 - Normal
5 - Normal
1426230280
High-level assembly parser error
Public
0
None
1581
Closed
Unlocked
1426176716
-
Added high_level_bug.cpp, #24064
tmac
1426189447
Original_Submission
Dear Torquil,
Thank you for your bug report. There were indeed a problem in the simplification of 0 - expr which was wrongly simplified in expr instead of -expr. This is corrected.
Best regards,
Yves
renard
1426230280
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
23479
1429017022
tmac
Fixed
If at least one of the arguments to FEM_PRODUCT is not a polynomial fem, the resulting error message is not very instructive:
"Error in getfem_fem.cc, line 669 : Bad parameters"
Something like the following would be better:
"Error in getfem_fem.cc, line 669 : Both arguments to FEM_PRODUCT must be polynomial FEM."
Best regards
Torquil Sørensen
1 - Wish
5 - Normal
1429037383
Improve FEM_PRODUCT error message
Public
0
None
1581
Closed
Unlocked
1429037383
Original_Submission
Ok, this is done. Thank you for the suggestion.
Best regards,
Yves.
renard
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
renard
23553
1430322275
tmac
Fixed
When using nb_basic_dof_of_face_of_element(), the attached test program segfaults, unless ind_basic_dof_of_face_of_element() has been used before. The test program bug.cpp is attached.
Newest Getfem from the subversion repository, and
$ gcc --version
gcc (GCC) 4.9.3 20150422 (prerelease)
3 - Normal
5 - Normal
1430329589
Segfault with nb_basic_dof_of_face_of_element
Public
0
None
1581
Closed
Unlocked
1430322276
-
Added bug.cpp, #24399
tmac
1430329589
Assigned_to
100
4654
renard
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Original_Submission
Dear Torquil,
The line
context_check(); if (!dof_enumeration_made) enumerate_dof();
was missing at the begining of the method
nb_basic_dof_of_face_of_element(...)
It is fixed. Thank you for the bug report.
renard
-
bugs
renard
23567
1430814408
tmac
Fixed
Hi!
There seems to be an error in the description of
base_small_vector compute_normal(const geotrans_interpolation_context& c, size_type face)
around line 565 in bgeot_geometric_trans.cc.
The description indicates that the norm is realFaceArea/refFaceArea. But according to my tests, I think the correct statement should be the opposite: refFaceArea/realFaceArea.
On a 2x2 element square mesh on the domain [0,1]x[0,1] the norm is 2, and on a 3x3 the norm is 3, so it gets larger as the real face area gets smaller.
Best regards
Torquil Sørensen
2 - Minor
5 - Normal
1430846320
Documentation of compute_normal()
Public
0
None
1581
Closed
Unlocked
1430846320
Original_Submission
You are right, since B is a generalized inverse of the gradient between the reference element and the real element, and the applied formula is B*ref_elt_normal.
renard
Status
None
Fixed
renard
Open/Closed
Open
Closed
renard
Assigned_to
100
4654
renard
-
bugs
None
23925
1444228521
tmac
Fixed
When building the latest GetFEM++ revision, I get an error because the file src/getfem/getfem_copyable_ptr.h uses std::make_unique, and the build options include -std=c++11.
But std::make_unique is first introduced in C++14, so either the build options should change to -std=c++14, or std::make_unique should not be used.
I'm using the newest GCC 5 snapshot. Here is the error:
getfem/src/getfem/getfem_copyable_ptr.h:52:54: error: 'make_unique' is not a member of 'std'
If I change from c++11 to c++14 in configure.ac and rerun autogen.sh, this error dissapears. It still does not build, but that is a different matter.
Best regards
Torquil Macdonald Sørensen
3 - Normal
5 - Normal
1447699981
std::make_unique is not in C++11
Public
0
None
1581
Closed
Unlocked
1444302175
Original_Submission
This has been fixed by Andriy Andreykiv. Thanks for the report.
renard
Status
None
Fixed
renard
1447699981
Open/Closed
Open
Closed
renard
-
bugs
None
24090
1447670943
tmac
Works For Me
I have built the newest Subversion GetFEM with the configure option --enable-paralevel=2. I cannot get any GetFEM program to compile if I use -DGETFEM_PARA_LEVEL=2, because I get this error:
In file included from /home/tmac/programming/getfem/getfem_parallel.cpp:1:0:
/home/tmac/usr/include/getfem/getfem_config.h: In function T getfem::MPI_SUM_SCALAR(T):
/home/tmac/usr/include/getfem/getfem_config.h:225:32: error: mpi_type is not a member of gmm
T b; MPI_Allreduce(&a,&b,1,gmm::mpi_type(a), MPI_SUM, MPI_COMM_WORLD);
To trigger this, it is enough to try to compile a file that just has the following line:
#include "getfem/getfem_config.h"
Best regards,
Torquil Sørensen
3 - Normal
5 - Normal
1447746079
mpi_type is not a member of gmm
Public
0
None
1581
Closed
Unlocked
1447699791
Original_Submission
Dear Torquil,
I do not have this problem. Are you sure that mpi is installed properly on your system ? The gmm::mpi_type function is defined in gmm/gmm_matrix.h (when mpi is detected) and included by getfem/getfem_config.h.
Best regards,
Yves.
renard
1447714405
Original_Submission
Hi!
I found the problem: I was setting compiler flags manually, not using getfem-config. So I was not using -DGMM_USES_MPI=1. After rewriting my CMakeLists.txt file query getfem-config for compiler flags, everything is compiling correctly again. So can can just be closed (user error...).
tmac
1447746079
Open/Closed
Open
Closed
renard
Status
None
Works For Me
renard
-
bugs
renard
24865
1469024166
gilles
Fixed
I am postdoc at IMT in Toulouse and I am using GETFEM-5.0 for stabilizing the flow over a flate plate.
I have tried to use the function MPI_SPARSE_SUM for making one process collecting from the other process the contributions of the linearized system before performing an eigenvalue decomposition.
I realized that MPI_SPARSE_SUM makes the code crash, and not necessarily in the function itself, but sometimes later when we try to access to other variables. I assume that MPI_SPARSE_SUM writes in wrong places in the memory.
I have written my own function, that is not optimized and does not have the required genericity, but has the advantage to communicate safely. Indeed, I copy the non-empty values of the sparse matrix in a vector, I communicate, then I build again the matrix.
You will find attached a minimal code where MPI_SPARSE_SUM crash and MPI_SPARSE_SUM2 (my function in MPI_functions.cc) works.
My feeling is that there is something wrong with sizeof(gmm::elt_rsvector_<T>) in the MPI size specification. I used simply sizeof(T). I am unsure of that.
Best regards,
Gilles TISSOT
3 - Normal
5 - Normal
1469710029
Problem in MPI_SPARSE_SUM
Public
0
None
1581
Closed
Unlocked
1469024166
-
Added flat_plate.cc, #27959
gilles
1469024167
-
Added yves.renard@insa-lyon.fr
gilles
-
Added test.cc, #27962
gilles
-
Added michel.fournie@iut-tlse3.fr
gilles
-
Added flat_plate.h, #27960
gilles
-
Added MPI_functions.cc, #27961
gilles
1469557418
Original_Submission
I found a list an error in MPI_SPARSE_SUM. I corrected and comited it but I did not test it. Can you test the new version ?
A priori, this is indeed sizeof(gmm::elt_rsvector_<T>) (which means the element of type T and the index) not sizeof(T)
renard
1469605854
Original_Submission
Great! Where can I find the new version? I will test it.
Gilles
gilles
1469616226
Original_Submission
You can find it here : (revision 5354)
http://svn.gna.org/viewcvs/getfem/trunk/getfem/src/getfem/getfem_config.h?view=log
renard
1469696010
Original_Submission
Dear Yves,
I have tested it on the minimal code and on my complete code. It seems to work fine.
I have seen the changes you have made and it makes sense.
Thank you,
Best regards,
Gilles
gilles
1469710029
Status
None
Fixed
renard
Assigned_to
100
4654
renard
Open/Closed
Open
Closed
renard
-
bugs
None
25501
1486614295
paolog
Fixed
The Debian project is currently testing all packages in advance for the transition to g++-7, with -Werror turned on.
Turns out getfem++ fails to build, this is an extract of the log:
[...]
if (i) dists.push_back(i); if (j) dists.push_back(j);
^~
../src/getfem/getfem_mesher.h:631:7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (k) dists.push_back(k); if (l) dists.push_back(l);
^~
../src/getfem/getfem_mesher.h:631:34: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (k) dists.push_back(k); if (l) dists.push_back(l);
^~
../src/getfem/getfem_mesher.h:632:7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (m) dists.push_back(m); if (n) dists.push_back(n);
^~
../src/getfem/getfem_mesher.h:632:34: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (m) dists.push_back(m); if (n) dists.push_back(n);
^~
../src/getfem/getfem_mesher.h:633:7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (o) dists.push_back(o); if (p) dists.push_back(p);
^~
../src/getfem/getfem_mesher.h:633:34: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (o) dists.push_back(o); if (p) dists.push_back(p);
^~
../src/getfem/getfem_mesher.h:634:7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (q) dists.push_back(q); if (r) dists.push_back(r);
^~
../src/getfem/getfem_mesher.h:634:34: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (q) dists.push_back(q); if (r) dists.push_back(r);
^~
../src/getfem/getfem_mesher.h:635:7: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (s) dists.push_back(s); if (t) dists.push_back(t);
^~
../src/getfem/getfem_mesher.h:635:34: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (s) dists.push_back(s); if (t) dists.push_back(t);
^~
test_mesh_generation.cc: In function 'int main(int, char**)':
test_mesh_generation.cc:144:23: warning: this statement may fall through [-Wimplicit-fallthrough=]
fixed.push_back(base_node(0,-z));
^~~~~~~~~~~~~~~
test_mesh_generation.cc:146:5: note: here
case 2: dist = D2; break; /* union of 2 disks */
^~~~
make[3]: Leaving directory '/build/getfem++-DZRk9N/getfem++-5.1+dfsg1/tests'
Makefile:1553: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
If you want more information including the full build log, please refer to the Debian BTS: https://bugs.debian.org/853416
Also consider that the g++-7 transition is in a very early phase: https://wiki.debian.org/GCC7
Thanks,
Paolo
3 - Normal
5 - Normal
0
build failure on g++-7 with -Werror turned on
Public
0
None
1581
Open
Unlocked
1486827806
Original_Submission
Thank you for this
I made the modifictions (however, it is not strictly speaking some errors : two "if" on a line and a ces without break but for a good reason.
renard
1486827836
Status
None
Fixed
renard
-
bugs
renard
25503
1486754443
paolog
Fixed
Hi, the getfem testsuite fails in about 5% of the cases.
For more details please see: https://bugs.debian.org/848859
We encountered different failures:
- test_continuation.pl - Wrong number of bifurcation points
- make_gmm_test.pl - Error too large in auto_gmm_torture15_sub.cc
- make_gmm_test.pl - QR algorithm failed in gmm_torture01_lusolve.cc
- make_gmm_test.pl - QR algorithm failed in gmm_torture05_mult.cc
- make_gmm_test.pl - QR algorithm failed in gmm_torture20_iterative_solvers.cc
Unfortunately I don't have the artifacts for all those, ATM I have them only for the last one (see attchments).
Thanks,
Paolo
3 - Normal
5 - Normal
1486829220
test failures
Public
0
None
1581
Closed
Unlocked
1486754443
-
Added 848859@bugs.debian.org
paolog
-
Added auto_gmm_torture20_iterative_solvers.cc, #29816
paolog
-
Added test-suite.log, #29815
paolog
1486804246
-
Added test-suite.log, #29818
paolog
-
Added auto_gmm_torture01_lusolve.cc, #29819
paolog
1486829220
Open/Closed
Open
Closed
renard
Original_Submission
Thank you for these bug report. I improved the robustness of the condition_number function. It is ok, now.
New tarball :
math.univ-lyon1.fr/homes-www/renard/temp/getfem-5.1.1.tar.gz
renard
Status
None
Fixed
renard
Assigned_to
100
4654
renard