Export to GitHub

sfepy - issue #96

Segfault when assembling matrices


Posted on Aug 14, 2009 by Quick Hippo

Hi again, I would want to compute the resonance frequencies of a cylindre with some boundary conditions. Looks at Schroedinger, I tried to assembly each of the lhs/rhs, but I get a segfault with the following code. I assume it may come from the lhs/rhs I provide to the eval_term_op function. With debugger, the segfault happens while eval_term_op calls assemble_matrix for the lhs term.

May you have a look at the script, and possibly explain why it is wrong ? Thanks

Attachments

Comment #1

Posted on Aug 14, 2009 by Massive Hippo

I made some corrections to the test_fem.py (see test_fem_ok.py) and it works.

BTW. why do you declare the variables complex? The problem seems real-valued as it is, and the imaginary part of the results is zero.

Attachments

Comment #2

Posted on Aug 14, 2009 by Quick Hippo

Thanks for the great improvement of the computation of eigenvectors. It seems that the complex declaration is in fact the problem. With fields = {'pression' : ((1,1), 'real', 'Omega', {'Omega' : '3_4_P1'})} the call to assemble_matrix (C coded function) works, but with fields = {'pression' : ((1,1), 'complex', 'Omega', {'Omega' : '3_4_P1'})} calling assemble_matrix_complex segfaults.

While debugging, I saved the following data (in each case) in the evaluate.assemble_matrix (l175 - sfepy/fem/evaluate.py) tmd[0], tmd[1], tmd[2], mtx_in_els, iels, sign, rdc and cdc The files are 1Mb, if it can help debug, tell me, i would attach them

Comment #3

Posted on Aug 14, 2009 by Massive Hippo

I cannot reproduce the segfault, the script test_fem_ok.py works for me both for the real and complex variables - you are on your own in determining the offending line. maybe some print-outs in sfepy/fem/extmods/fem.c (assemble_matrix_complex()) might help - do not forget to 'make' after changing the C file.

What versions of sfepy, swig, numpy, scipy, etc. do you have? What is your OS, distribution, architecture?

In past some versions of swig generated a bad code. I have swig-1.3.36.

Comment #4

Posted on Aug 14, 2009 by Quick Hippo

I am working on debian (unstable) with sfepy 2009.3-release, numpy 1.2.1 and scipy 0.7.0 (official debian packages). Kernel is 2.6.30-1-686. Swig is 1.3.39-2 I've installed sfepy system-wide with # python setup.py install as root Should I remove this installation, or is there a way to work with a user modified copy ? And I see print commented calls in fem.c, are they usable?

Comment #5

Posted on Aug 14, 2009 by Massive Hippo

You need not to install sfepy at all - try typing:

$ make

or

$ python setup.py build_ext --inplace

in the main sfepy directory. Then you can just run all the stuff from there.

The commented print calls might be useful, yes.

I have just tried 2009.3-release (with the VTK reading patch) and still it works with complex.

I use numpy 1.3.0 and scipy 0.7.1.

BTW. I am now on the #sfepy irc channel at freenode.

Comment #6

Posted on Aug 14, 2009 by Massive Hippo

Also,

do all the tests pass, or specifically:

./runTests.py tests/test_input_acoustics.py --debug

  • this one is complex.

Comment #7

Posted on Aug 14, 2009 by Quick Hippo

The results of your mindbreaking friday's leisure.

Attachments

Comment #8

Posted on Aug 14, 2009 by Massive Hippo

Nice conclusion :) Let us close this issue, then.

Comment #9

Posted on Jan 30, 2012 by Massive Hippo

Migrated to http://github.com/sfepy/sfepy/issues/98

Status: Migrated