Segfault when assembling matrices

[GoogleCodeExporter]

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

Original issue reported on code.google.com by Fabrice....@gmail.com on 14 Aug 2009 at 12:27

Attachments:

• test_fem.py
• fem.log

[GoogleCodeExporter]

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.

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 8:29

Attachments:

• test_fem_ok.py

[GoogleCodeExporter]

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

Original comment by Fabrice....@gmail.com on 14 Aug 2009 at 12:19

[GoogleCodeExporter]

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.

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 12:31

[GoogleCodeExporter]

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?

Original comment by Fabrice....@gmail.com on 14 Aug 2009 at 12:54

[GoogleCodeExporter]

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.

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 1:03

[GoogleCodeExporter]

Also,

do all the tests pass, or specifically:

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

- this one is complex.

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 1:26

[GoogleCodeExporter]

The results of your mindbreaking friday's leisure.

Original comment by Fabrice....@gmail.com on 14 Aug 2009 at 5:50

Attachments:

• fake_imaginary.patch

[GoogleCodeExporter]

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

Original comment by robert.c...@gmail.com on 14 Aug 2009 at 6:00

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by robert.c...@gmail.com on 30 Jan 2012 at 10:26

• Changed state: Migrated