Stepping in frequency rather than time
by Logan Sorenson
Hi,
I have been familiarizing myself with sfepy for the last week or so.
So far, I like what I see! :)
My question is regarding the time stepping solver. I would like to
step through the frequency domain instead of in time. My naive
understanding is to convert time derivatives to i*omega by assuming
the solution has the form exp(i*omega*t). I believe this is what is
done in input/piezo.py, where the mass term is multiplied by
omega_squared.
So based off that assumption, I added the time stepping solver to
input/piezo.py as shown in input/time_poisson.py. Then I tried a
couple ways to get the omega_squared value to depend on ts.time. The
current way I'm trying is to multiply the 'density' parameter by
ts.time**2 (assuming ts.time actually represents the frequency) in the
get_inclusion_pars function, and removed completely the omega_squared
string substitution in the equation definition (please see the
attached file). This seems to work ok, but I'm not sure this is the
best way to include the frequency in the equation definition. I.e.,
it's not very explicit. Is there a better way to do this? Also, is
using the time stepping solver in this manner okay, or is there
something I'm ignoring like the result becoming incorrect because it
depends on the previously "frequency"?
Thanks very much!
Best regards,
Logan
9 years, 8 months
Fwd: Re: Slow Sfepy on Fedoracore 8
by Robert Cimrman
Hi,
I did not send the reply to the list - correcting now.
Also try running
$ ./runTests.py tests/test_linear_solvers.py --filter-less
to see the performance of available solvers applied to a Laplace problem.
For the reference, on my slow old laptop I get:
... solution times (rezidual norms):
... 1.41 [s] (3.286e-12) : i20 ls.scipy_iterative cg
... 2.25 [s] (1.714e-12) : i21 ls.scipy_iterative bicgstab
... 5.37 [s] (3.575e-12) : i22 ls.scipy_iterative qmr
... 12.92 [s] (4.135e-15) : d00 ls.umfpack
... 10000000000.00 [s] (1.000e+10) : i00 ls.pyamg ruge_stuben_solver
... 10000000000.00 [s] (1.000e+10) : i01 ls.pyamg
smoothed_aggregation_solver
... 10000000000.00 [s] (1.000e+10) : i10 ls.petsc cg icc
The last three lines mean that pyamg and petsc are not installed. BTW.
I recommend you to install petsc and petsc4py, as the iterative
solvers and preconditioners in petsc are really good.
r.
----- Forwarded message from cimr...(a)ntc.zcu.cz -----
Date: Sat, 25 Jul 2009 11:42:23 +0200
From: Robert Cimrman <cimr...(a)ntc.zcu.cz>
Reply-To: Robert Cimrman <cimr...(a)ntc.zcu.cz>
Subject: Re: Slow Sfepy on Fedoracore 8
To: Antonino Ingargiola <trit...(a)gmail.com>
Quoting Antonino Ingargiola <trit...(a)gmail.com>:
>>> 2009/7/23 Robert Cimrman <cimr...(a)ntc.zcu.cz>:
>>> <snip>
>>> On my machine (a quad-core 64bit, gentoo), all tests
>>>>>> pass in:
>>>>>>
>>>>>> 32 test file(s) executed in 41.48 s, 0 failure(s) of 42 test(s)
>>>>>>
>>>>>> you should get similar results.
>>>>> In fact on a dual core ubuntu machine I run all the test in less
>>>>> then a minute.
>>>>>
>>>>> On fedoracore8 I don't know how slow is but surely more than 20min (I
>>>>> interrupted the tests) that is definitely too much.
>>>> It definitely looks like umfpack is not used.
>>>
>>> Is possible that is another library that is not used causing the long
>>> runtime? For example atlas/lapack?
>>
>> Maybe. I am really not sure what happens.
>
> How can I check if scipy is using atlas/lapack/umfpack? Maybe I should
> ask on the scipy mailing list....
Yes, I have seen the thread - so it seems ATLAS (blas+lapack) is ok.
But it looks like the umfpack itself might not use it - can you try to
compile it manually? Otherwise I cannot explain its poor performance.
r.
----- End forwarded message -----
9 years, 9 months
Slow Sfepy on Fedoracore 8
by Antonio
Hi,
I've compile sfepy un a fedoracore 8 64bit machine (8 cores) but some
tests run very slow. The debug output show the test stopping a long
time in lines like:
sfepy: nls: iter: 0, residual: 3.515775e-04 (rel: 1.000000e+00)
I've installed the latest numpy, scipy and umfpack scikits from
source. I've installed (among others) the following devel packages:
atlas.x86_64
lapack-devel.x86_64
suitesparse-devel.x86_64
and inserted the section
[umfpack]
library_dirs=/usr/lib64
include_dirs = /usr/include/suitesparse
both in numpy and in scipy site.cfg.
What may be the problem?
Thanks,
~ Antonio
9 years, 9 months
ANN: SfePy 2009.3
by Robert Cimrman
I am pleased to announce release 2009.3 of SfePy.
Description
-----------
SfePy (simple finite elements in Python) is a software, distributed
under the BSD license, for solving systems of coupled partial
differential equations by the finite element method. The code is based
on NumPy and SciPy packages.
Mailing lists, issue tracking, git repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz
Highlights of this release
--------------------------
Finally, SfePy has a basic support for Windows installation via numpy
distutils:
- still very experimental!
- the tests will not finish if umfpack is not installed, as the default
direct solver in scipy cannot handle some problems (see recent
sfepy-devel mailing list discussions).
Major improvements
------------------
- new scripts:
- cylindergen.py: cylindrical mesh generator
- updated scripts:
- postproc.py:
- quite usable now for fast first glance at the results
- plots point, cell data of all kinds (scalar, vector, tensor)
- Viewer is much more configurable
- probe.py:
- can probe selected quantities only
- isfepy:
- Viewer is much more configurable
- new tests and terms
Applications
------------
- phononic materials:
- plotting improved
- caching of eigen-problem solution and Christoffel acoustic tensor
- schroedinger.py:
- choose and call DFT solver via solver interface
People who contributed to this release: Vladimir Lukes.
For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2009.3_RELEASE_NOTES.txt
Best regards,
Robert Cimrman
9 years, 9 months
Sfepy on ubuntu 9.04: test failing
by Antonio
Hi to the list,
I've installed sfepy on Ubuntu Jaunty 9.04. Using the distro supplied
numpy and scipy (numpy 1.2.1 and scipy 0.7.0)
I get one test failed: test_input_acoustics.py. Here it is the debug
output:
$ ./runTests.py --debug tests/test_input_acoustics.py
<<< tests/test_input_acoustics.py
sfepy: left over: ['__builtins__', '_filename', '__file__',
'__package__', 'TestInput', 'input_name', '__name__', 'output_name',
'__doc__']
sfepy: left over: ['w', '__builtins__', 'rho', '__name__', 'v_n', 'c',
'__doc__', '__package__', '_filename', '__file__']
>>> test instance prepared (1 test(s))
/usr/lib/python2.6/dist-packages/scipy/linsolve/__init__.py:4:
DeprecationWarning: scipy.linsolve has moved to
scipy.sparse.linalg.dsolve
warn('scipy.linsolve has moved to scipy.sparse.linalg.dsolve',
DeprecationWarning)
... solving input/acoustics.py...
sfepy: reading mesh (database/acoustics.mesh)...
sfepy: ...done in 0.00 s
sfepy: setting up domain edges...
sfepy: ...done in 0.00 s
sfepy: creating regions...
sfepy: leaf Gamma_out region_Gamma_out__0
sfepy: leaf Omega region_Omega__1
sfepy: leaf Gamma_in region_Gamma_in__2
sfepy: ...done in 0.02 s
sfepy: equation "Acoustic pressure":
sfepy: 117649.0 * dw_laplace.ivol.Omega( one.one, q, p )
- 1000000.0 * dw_mass_scalar.ivol.Omega( q, p )
- 343000j * dw_surface_mass_scalar.isurf.Gamma_out( q, p )
= 182355950j * dw_surface_integrate.isurf.Gamma_in( q )
sfepy: setting up dof connectivities...
sfepy: ...done in 0.00 s
sfepy: describing geometries...
sfepy: ...done in 0.00 s
sfepy: using solvers:
nls: newton
ls: ls
sfepy: matrix shape: (61, 61)
sfepy: assembling matrix graph...
sfepy: ...done in 0.00 s
sfepy: matrix structural nonzeros: 445 (1.20e-01% fill)
sfepy: updating materials...
sfepy: one
sfepy: ...done in 0.00 s
sfepy: nls: iter: 0, residual: 1.116698e+07 (rel: 1.000000e+00)
warning: singular matrix
zeroing nan and inf entries...
warning: (almost) singular matrix! (estimated cond. number: inf)
sfepy: rezidual: 0.00 [s]
sfepy: solve: 0.00 [s]
sfepy: matrix: 0.00 [s]
sfepy: linear system not solved! (err = 1.116698e+07)
sfepy: nls: iter: 1, residual: 1.116698e+07 (rel: 1.000000e+00)
... input/acoustics.py solved
--- test_input: failed!
!!! 1 test failed
1 test file executed in 0.57 s, 1 failure(s) of 1 test(s)
I also installed numpy 1.3.0 and scipy 0.7.1 from sources in a local
dir and but using them I get 23 test failed out of 39.
The problem with the newer versions seems due to the lack of the
umfpack library which I don't find in ubuntu 9.04. For example the
first test failing is test_quadrature.py and the debug output is:
<<< tests/test_quadratures.py
sfepy: left over: ['__builtins__', 'ebc_sin', '__file__', '__name__',
'N', 'TestCommon', 'nm', '_filename', '__package__', '__doc__']
>>> test instance prepared (1 test(s))
sfepy: reading mesh (database/tests/triquad.mesh)...
sfepy: ...done in 0.01 s
sfepy: setting up domain edges...
sfepy: ...done in 0.00 s
sfepy: creating regions...
sfepy: leaf Omega_2 region_Omega_2
sfepy: leaf Omega_1 region_Omega_1
sfepy: leaf Omega region_Omega
sfepy: leaf Gamma_Top region_Gamma_Top
sfepy: leaf Gamma_Bottom region_Gamma_Bottom
sfepy: ...done in 0.02 s
sfepy: equation "Temperature":
sfepy: dw_laplace.i2.Omega( m.val, s, t )
= 0
sfepy: setting up dof connectivities...
sfepy: ...done in 0.00 s
sfepy: describing geometries...
sfepy: ...done in 0.01 s
sfepy: using solvers:
nls: newton
ls: ls
sfepy: matrix shape: (1125, 1125)
sfepy: assembling matrix graph...
sfepy: ...done in 0.00 s
sfepy: matrix structural nonzeros: 11843 (9.36e-03% fill)
sfepy: updating materials...
sfepy: m
sfepy: ...done in 0.00 s
sfepy: nls: iter: 0, residual: 9.531284e+01 (rel: 1.000000e+00)
>>> <type 'exceptions.NameError'>
Traceback (most recent call last):
File "./runTests.py", line 219, in <module>
main()
File "./runTests.py", line 214, in main
op.walk( options.test_dir, wrap_run_tests( options ), stats )
File "/usr/lib/python2.6/posixpath.py", line 224, in walk
func(arg, top, names)
File "./runTests.py", line 148, in run_tests
n_fail, n_total, test_time = run_test( conf_name, options )
File "./runTests.py", line 111, in run_test
ok, n_fail, n_total = test.run( options.debug )
File "/home/anto/src/sfepy-release-2009.2/sfepy/base/testing.py",
line 38, in run
ret = test_method()
File "tests/test_quadratures.py", line 152, in test_problem_creation
problem, vec, data = solve_stationary( self.conf )
File "/home/anto/src/sfepy-release-2009.2/sfepy/solvers/generic.py",
line 62, in solve_stationary
state = problem.solve( nls_status = nls_status )
File "/home/anto/src/sfepy-release-2009.2/sfepy/fem/problemDef.py",
line 580, in solve
vec = solvers.nls( vec0 )
File "/home/anto/src/sfepy-release-2009.2/sfepy/solvers/nls.py",
line 228, in __call__
vec_dx = lin_solver( vec_r, mtx = mtx_a )
File "/home/anto/src/sfepy-release-2009.2/sfepy/solvers/ls.py", line
44, in __call__
um.UmfpackContext( family = family ) )
File "/home/anto/src/python/lib/python2.6/site-packages/scipy/sparse/
linalg/dsolve/umfpack/umfpack.py", line 278, in __init__
self.control = np.zeros( (UMFPACK_CONTROL, ), dtype = np.double )
NameError: global name 'UMFPACK_CONTROL' is not defined
Any suggestion to solve this two issue would be appreciated.
Cheers,
~ Antonio
9 years, 9 months
sfepy windows installation
by Robert Cimrman
Hi again!
I have finally had some success with Windows installation of SfePy. It
would be great, if someone could go through the following steps
(assuming EPD [1] is installed) and report any problems (or an unlikely
success) on the way:
1. install
http://msysgit.googlecode.com/files/Git-1.6.3.2-preview20090608.exe
2. in a terminal, try typing 'git'
3. if git works, try in some directory:
git clone git://github.com/rc/sfepy.git
cd sfepy
git pull origin windows_install
python setup.py build_ext --inplace
4. if all is ok, try:
python simple.py input/poisson.py
5. if even this works, install paraview and look at the results in
simple.vtk, or try:
ipython -wthread
and in ipython window:
%run postproc.py simple.vtk
cheers,
r.
[1] http://www.enthought.com/products/epd.php
9 years, 9 months
surface terms
by Robert Cimrman
Hey, Vlada,
Could you, please push somewhere the surface integrals that you have
implemented for the acoustics? I need them! Or send them to me off-list.
I will add them to the master branch.
thanks,
r.
9 years, 9 months
pcolor() to VTK
by Ondrej Certik
Hi,
I just wanted to share a simple code that I wrote:
http://certik.github.com/visit_writer/
which uses Visit's VTK writer (written in C, wrapped in Python). I
wrote a pcolor() function, that works just like the one in matplotlib,
only it produces a vtk file (resp. data that you then pass to the vtk
writer). See the pictures and demos on the webpage above.
With this, it's very easy to write VTK files, no need to fiddle with
the ASCII format --- btw, the module can produces a binary VTK file
too, so it really saved me lots of troubles.
Ondrej
9 years, 9 months
writing to VTK
by Ondrej Certik
Hi,
it's very difficult for me to use the VTK writer, since it has no
documentation about the input format:
"""
def write( self, filename, mesh, out = None ):
fd = open( filename, 'w' )
fd.write( vtk_header % op.basename( sys.argv[0] ) )
"""
this is very difficult to use. Robert, what do you think about using a
similar scheme to document things like here:
http://certik.github.com/python-theora/
in particular, look for example here:
http://certik.github.com/python-theora/module_theora.html#theora.Theora.a...
how each method is documented. Basically the trick is that first you
need to execute one script, that downloads test video files. Then you
can access those files like:
>>> t = Theora(test_files[2])
see the doctest. So in sfepy the simple script would first calculate
some results and save it to probably vtk files (maybe others too).
Then you would test them in the doctests. Also I must say I quite like
to always import everything in the docstring explicitly, because you
can then just copy & paste it to a python session and it is guaranteed
to work. (as opposed to assume that the current file is imported by
default, because it's not clear to the user how to import it).
I plan to get a similar thing working for hermes2d too soon.
Ondrej
9 years, 9 months