complex problems

[GoogleCodeExporter]

We need to be able to solve problems in complex numbers, as found, for
example, in acoustics.

Currently, all numerical data are typed as numpy.float64 - this will be
made configurable.

It is a high-priority issue for the team at our lab now.

Original issue reported on code.google.com by robert.c...@gmail.com on 22 Jul 2008 at 9:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

complex numbers: test problem implemented, see 
http://hg.sympy.org/sfepy/rev/b646769ce501

Verification is needed, but Newton converges for:

ebcs = {
    'p_out' : ('Gamma_Right', {'p.0' : -2.0 + 1j}),
}
"""1.0 * dw_mass_scalar.i1.Omega( q, p ) - dw_laplace.i1.Omega( ac.one, q, p )
    = 1550j * dw_surface_integrate.isurf.Gamma_Left( ac.v_n, q )"""

see 'input/complex.py'.

Several spots in code could be optimized. I will think how to re-design 
hierarchy of
*Term classes to make it easier.

Original comment by robert.c...@gmail.com on 30 Jul 2008 at 6:02

[GoogleCodeExporter]

Already done and tested.

Original comment by vlukes@kme.zcu.cz on 4 Feb 2009 at 1:02

• Changed state: Fixed

[GoogleCodeExporter]

Great job. So you don't have to recompile sfepy just to use complex numbers? 
Many
other libraries need to be recompiled for complex numbers.

Original comment by ondrej.c...@gmail.com on 4 Feb 2009 at 4:03

[GoogleCodeExporter]

We use a trick here - for linear terms, you just have to call the same (real) C
function for the real and imaginary parts, and then assemble correctly. Anyway, 
there
is no native complex type and operator overloading in C, so for other terms you 
just
need to implement another function with different name.

Also only the terms we actually needed to work with complex numbers were 
modified.
But the "framework" is there.

Original comment by robert.c...@gmail.com on 4 Feb 2009 at 4:11

[GoogleCodeExporter]

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

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

• Changed state: Migrated