Issue with demo_laplacian.py

Questions and issues
1

Dear all, I am new to this group.

I tried to run “python demo_laplacian.py” just to test GetFEM 5.4.2 (installed on a cluster), but I get the following error message:

Error in L2 norm :  7.272926620326205e-08
Error in H1 norm :  3.9791226362755064e-05
logic_error exception caught
Traceback (most recent call last):
  File "/storage/simple/projects/lamps/getfem-5.4.2/interface/tests/python/demo_laplacian.py", line 144, in <module>
    sl4.export_to_vtk('laplacian.vtk', "ascii", mfu, Ue,'Exact_solution', mfu, U,'Computed_solution')
  File "/home/dumonts/work_lamps/lib/python3.9/site-packages/getfem/getfem.py", line 5419, in export_to_vtk
    return self.get("export_to_vtk", filename, *args)
  File "/home/dumonts/work_lamps/lib/python3.9/site-packages/getfem/getfem.py", line 5303, in get
    return getfem('slice_get',self.id, *args)
RuntimeError: (Getfem::InterfaceError) -- Error in getfem_export.cc, line 207 getfem::vtk_export::vtk_export(const string&, bool, bool): 
impossible to write to file 'laplacian.vtk'

Could you please help me figure out what is wrong.
Thanks.

2

can it be that you are running the script in a folder where you do not have write permissions?

you can try to change the line

sl4.export_to_vtk('laplacian.vtk', "ascii", mfu, Ue,'Exact_solution', mfu, U,'Computed_solution')

to

sl4.export_to_vtk('/tmp/laplacian.vtk', "ascii", mfu, Ue,'Exact_solution', mfu, U,'Computed_solution')

or

sl4.export_to_vtu('/tmp/laplacian.vtu', "ascii", mfu, Ue,'Exact_solution', mfu, U,'Computed_solution')

to see if it is possible to write the file under the /tmp/ folder (if you have access to this folder)

1 Like
3

Thank you very much, Konstantinos. It now works fine.

I should just figure out now how to get it to work locally, instead of remotely on the cluster.

4

So, I ran python demo_laplacian.py on my MacBook Intel after installing everything, without the option --disable-dependency-tracking, and the outcome was zsh: segmentation fault python demo_laplacian.py.

Then, after a make check for a verification, I obtained the following. I guess there is something wrong (and very bad) with Python, but no idea how to figure this out:

Making check in python
/Library/Developer/CommandLineTools/usr/bin/make  check-TESTS
../../../test-driver: line 107: 33178 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: check_export.py
PASS: check_export_vtu.py
../../../test-driver: line 107: 33190 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: check_global_functions.py
../../../test-driver: line 107: 33196 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: check_asm.py
../../../test-driver: line 107: 33203 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: check_secondary_domain.py
../../../test-driver: line 107: 33209 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: check_mixed_mesh.py
../../../test-driver: line 107: 33215 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_truss.py
../../../test-driver: line 107: 33221 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_wave.py
../../../test-driver: line 107: 33227 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_wave_equation.py
../../../test-driver: line 107: 33233 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_laplacian.py
../../../test-driver: line 107: 33239 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_laplacian_HHO.py
../../../test-driver: line 107: 33245 Segmentation fault: 11  "$@" > $log_file 2>&1
FAIL: demo_elasticity_HHO.py
============================================================================
Testsuite summary for getfem 5.4.2
============================================================================
# TOTAL: 12
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  11
# XPASS: 0
# ERROR: 0
============================================================================
See interface/tests/python/test-suite.log

Checking what is inside test-suite.log, I found things like

FAIL: check_export.py
=====================

FAIL check_export.py (exit status: 139)

FAIL: check_global_functions.py
===============================

FAIL check_global_functions.py (exit status: 139)

FAIL: check_asm.py
==================

FAIL check_asm.py (exit status: 139)

FAIL: check_secondary_domain.py
===============================

FAIL check_secondary_domain.py (exit status: 139)

FAIL: check_mixed_mesh.py
=========================

FAIL check_mixed_mesh.py (exit status: 139)

FAIL: demo_truss.py
===================

FAIL demo_truss.py (exit status: 139)

FAIL: demo_wave.py
==================

FAIL demo_wave.py (exit status: 139)

FAIL: demo_wave_equation.py
===========================

FAIL demo_wave_equation.py (exit status: 139)

FAIL: demo_laplacian.py
=======================

FAIL demo_laplacian.py (exit status: 139)

FAIL: demo_laplacian_HHO.py
===========================

FAIL demo_laplacian_HHO.py (exit status: 139)

FAIL: demo_elasticity_HHO.py
============================

FAIL demo_elasticity_HHO.py (exit status: 139)
5

just run
python
in your terminal to start an interactive session and try
import getfem as gf
if it does not crash on import, then try
m = gf.Mesh('empty')
just to see when exactly it crashes.

This behavior typically happens when the libraries loaded at runtime do not match those used at compile time.

One way to reduce this kind of issues is to statically link the dependencies inside the _getfem…so file. This is done with adding the
--with-pic
option to the configure command. Maybe worth trying.

6

Thanks, I tried and it returns

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/site-packages/getfem/getfem.py", line 1164, in __init__
    generic_constructor(self,'mesh',*args)
  File "/usr/local/lib/python3.11/site-packages/getfem/getfem.py", line 65, in generic_constructor
    self.id = getfem_from_constructor(clname,*args)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: (Getfem::InterfaceError) -- Not enough input arguments for command 'EMPTY' (got 1, expected at least 2)

I will try adding the option you mentioned to the configure command.

7

Unfortunately, same outcome: even with the --with-pic option I get the segmentation fault error.

8

oh sorry this was my mistake, it should be
m = gf.Mesh('empty',2)

if this works you can try to define some more objects, e.g.

mf = gf.MeshFem(m,1)

9

Yes, this seems to work, I added also other stuff as follows:

>>> import getfem as gf
>>> m = gf.Mesh('empty',2)
>>> mf = gf.MeshFem(m,1)
>>> mfu   = gf.MeshFem(m, 1)
>>> mfrhs = gf.MeshFem(m, 1)
>>> md = gf.Model('real')
>>>

and so far everything works.

10

I found out the “culprit” in demo_laplacian.py: it is line 50, i.e.

m = gf.Mesh('regular_simplices', np.arange(0,1+1./NX,1./NX),
            np.arange(0,1+1./NX,1./NX))

Until this line, everything seems to work fine.

11

try to get a backtrace with gdb

$ LD_LIBRARY_PATH=..... PYTHONPATH=...../lib/python3.12/site-packages/getfem gdb python3
GNU gdb (Debian 15.2-1) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
(No debugging symbols found in python3)
(gdb) r
Starting program: /usr/bin/python3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.12.7 (main, Nov  8 2024, 17:55:36) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import getfem as gf
>>> m = gf.Mesh('regular_simplices',[0,0.5,1],[0,0.25,0.5])

after it will crash, run “bt” or “bt full” in the gdb command line

12

Thank you for your feedback.

Actually, I was finally able to install GetFEM on both machines (Apple Silicon and Intel MacBook, without the qhull library on the Intel machine), thanks to the right prefix, but unfortunately, on both machines, I get this segmentation fault error as I type something like, as you posted,

m = gf.Mesh('regular_simplices',[0,0.5,1],[0,0.25,0.5])

This does not occur with m = gf.Mesh('empty',2).

The problem is that gdb is not supported at all on Apple Silicon machines: I tried to install it by Homebrew, i.e., by

brew install gdb

but the outcome was

gdb: The x86_64 architecture is required for this software,

so, no way to use it on Apple Silicon computers.

On the other hand, even on my Intel machine (where I was able to install it successfully), gdb does not work properly: it hangs upon typing run after gdb python. I saw this is a well-known bug, but apparently not yet fixed.

Do you have an idea of any other debugger that I could use? I tried lldb but with Python it does not seem to work.

In any case, on both my MacBook Intel and Apple Silicon machines, I get this segmentation fault which is quite curious…

13

hmm interesting, I have never used a mac in my life, so no idea.

But why don’t you build GetFEM with clang which is more apple-native, if the g++ toolchain is not that well supported?

In any case it would be interested to see where the segfaults happen in the g+±compiled version. It is not normal. As far as I know, @yves.renard, who is the founder of the project uses Mac and g++.

14

But why don’t you build GetFEM with clang which is more apple-native, if the g++ toolchain is not that well supported?

Because with clang I get the following error:

configure: error: g++ do not support option -std=c++14. Update g++ to at least release 4.9

15

to compile with clang you should invoke the configure script with

./configure CC=clang CXX=clang++ ....

I also recommend you to download the current development version, e.g. with

curl "https://git.savannah.nongnu.org/gitweb/?p=getfem.git;a=snapshot;h=HEAD;sf=tgz" --output getfem-HEAD.tar.gz
mkdir -p getfem-HEAD
tar -zxf getfem-HEAD.tar.gz -C getfem-HEAD --strip 1
cd getfem-HEAD

then, you create the (corrected) configure script with
./autogen.sh

and then you configure your build with
./configure CC=clang CXX=clang++ ....

16

I know, but it seems that “clang” is interpreted as “g++”, that is the reason why I get that error.

When configuring the development version, “configure” does not find SuperLU… I think I will give up and use GetFEM directly on the HPC server!

Thank you for your precious assistance!

17

I changed my Intel Mac with an Apple Silicon Mac with Sequoia 15.2 installed.

The first thing I did is installing GetFEM using configure with the following options:

./configure CXX=g++-13 CC='gcc-13 -arch arm64 -ld_classic' CXXFLAGS='-arch arm64 -ld_classic -no-pie' FC='gfortran-13 -arch arm64 -ld_classic' CXXCPP='g++-13 -E -arch arm64 -ld_classic' CPP='g++-13 -E -arch arm64 -ld_classic'  --enable-metis --enable-python --enable-matlab=no --enable-shared --disable-dependency-tracking --prefix=/opt/homebrew/

Everything worked fine, no error message, until I tried to run demo_laplacian.py or whatever other test Python code. The outcome is always a segmentation fault, but unlike the previous operating system (I still cannot use gdb here), I have been able to obtain a report following the error (that actually caused Python to crash).

You can download the file containing the report here.

I think there is something wrong with the library files, but I am not sure that the report can help in any way…

18

Thanks, it looks like a memory corruption issue on our side, but it is strange if it only happens for python examples. Do C++ tests run? What do you get when you run make check ?

By the way this is the build log for arm64 on debian, where all test pass
https://buildd.debian.org/status/fetch.php?pkg=getfem&arch=arm64&ver=5.4.2%2Bdfsg1-5.1&stamp=1731202194&raw=0

so arm64 has in general been tested, but let’s see what is going wrong in your case.

19

Here is the output of make check.

Making check in m4
make[1]: Nothing to be done for `check'.
Making check in cubature
make[1]: Nothing to be done for `check'.
Making check in superlu
make[1]: Nothing to be done for `check'.
Making check in src
make[1]: Nothing to be done for `check'.
Making check in tests
/Library/Developer/CommandLineTools/usr/bin/make  dynamic_array dynamic_tas test_int_set test_tree_sorted poly test_small_vector test_kdtree test_rtree test_mesh test_slice integration geo_trans_inv test_mat_elem test_interpolation test_assembly test_assembly_assignment test_interpolated_fem test_internal_variables test_condensation test_range_basis laplacian laplacian_with_bricks elastostatic stokes helmholtz plate nonlinear_elastostatic nonlinear_membrane schwarz_additive  plasticity bilaplacian heat_equation wave_equation cyl_slicer test_continuation test_gmm_matrix_functions
make[2]: `dynamic_array' is up to date.
make[2]: `dynamic_tas' is up to date.
make[2]: `test_int_set' is up to date.
make[2]: `test_tree_sorted' is up to date.
make[2]: `poly' is up to date.
make[2]: `test_small_vector' is up to date.
make[2]: `test_kdtree' is up to date.
make[2]: `test_rtree' is up to date.
make[2]: `test_mesh' is up to date.
make[2]: `test_slice' is up to date.
make[2]: `integration' is up to date.
make[2]: `geo_trans_inv' is up to date.
make[2]: `test_mat_elem' is up to date.
make[2]: `test_interpolation' is up to date.
make[2]: `test_assembly' is up to date.
make[2]: `test_assembly_assignment' is up to date.
make[2]: `test_interpolated_fem' is up to date.
make[2]: `test_internal_variables' is up to date.
make[2]: `test_condensation' is up to date.
make[2]: `test_range_basis' is up to date.
make[2]: `laplacian' is up to date.
make[2]: `laplacian_with_bricks' is up to date.
make[2]: `elastostatic' is up to date.
make[2]: `stokes' is up to date.
make[2]: `helmholtz' is up to date.
make[2]: `plate' is up to date.
make[2]: `nonlinear_elastostatic' is up to date.
make[2]: `nonlinear_membrane' is up to date.
make[2]: `schwarz_additive' is up to date.
make[2]: `plasticity' is up to date.
make[2]: `bilaplacian' is up to date.
make[2]: `heat_equation' is up to date.
make[2]: `wave_equation' is up to date.
make[2]: `cyl_slicer' is up to date.
make[2]: `test_continuation' is up to date.
make[2]: `test_gmm_matrix_functions' is up to date.
/Library/Developer/CommandLineTools/usr/bin/make  check-TESTS
PASS: dynamic_array.pl
PASS: dynamic_tas.pl
PASS: test_int_set.pl
PASS: test_tree_sorted.pl
PASS: poly.pl
PASS: test_small_vector.pl
PASS: test_kdtree.pl
PASS: test_rtree.pl
PASS: geo_trans_inv.pl
PASS: test_mesh.pl
PASS: test_interpolation.pl
PASS: test_mat_elem.pl
PASS: test_slice.pl
PASS: integration.pl
PASS: test_assembly.pl
PASS: test_assembly_assignment.pl
PASS: test_interpolated_fem.pl
PASS: test_internal_variables.pl
PASS: test_condensation.pl
PASS: test_range_basis.pl
PASS: laplacian.pl
PASS: laplacian_with_bricks.pl
PASS: elastostatic.pl
PASS: stokes.pl
PASS: plate.pl
PASS: nonlinear_elastostatic.pl
PASS: nonlinear_membrane.pl
PASS: test_continuation.pl
PASS: plasticity.pl
PASS: helmholtz.pl
PASS: schwarz_additive.pl
PASS: bilaplacian.pl
PASS: heat_equation.pl
PASS: wave_equation.pl
PASS: test_gmm_matrix_functions.pl
PASS: cyl_slicer.pl
PASS: make_gmm_test.pl
============================================================================
Testsuite summary for getfem 5.4.2
============================================================================
# TOTAL: 37
# PASS:  37
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
Making check in interface
Making check in src
Making check in .
make[3]: Nothing to be done for `check-am'.
Making check in python
make[3]: Nothing to be done for `check'.
Making check in tests
Making check in meshes
make[3]: Nothing to be done for `check'.
Making check in python
/Library/Developer/CommandLineTools/usr/bin/make  check-TESTS
FAIL: check_export.py
PASS: check_export_vtu.py
FAIL: check_global_functions.py
FAIL: check_asm.py
FAIL: check_secondary_domain.py
FAIL: check_mixed_mesh.py
FAIL: demo_truss.py
FAIL: demo_wave.py
FAIL: demo_wave_equation.py
FAIL: demo_laplacian.py
FAIL: demo_laplacian_HHO.py
FAIL: demo_elasticity_HHO.py
============================================================================
Testsuite summary for getfem 5.4.2
============================================================================
# TOTAL: 12
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  11
# XPASS: 0
# ERROR: 0
============================================================================
See interface/tests/python/test-suite.log
============================================================================
20

so the issue does really occur only with python. Could you add “-g” to your CXXFLAGS, recompile, and provide the new crash log after this?

you can also try to run the failing script with
valgrind --leak-check=yes
if you have valgrind on your system.