Mailman 3 July 2009 - SfePy

Stepping in frequency rather than time
by Logan Sorenson Aug. 11, 2009

Aug. 11, 2009

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

2 4

slides from euroscipy 2009
by Robert Cimrman July 27, 2009

July 27, 2009

Hi, I have uploaded the slides to [1]. They should appear at [2], too. cheers, r. [1] http://code.google.com/p/sfepy/wiki/Documentation [2] http://www.euroscipy.org/presentations/slides/index.html

1 0

Fwd: Re: Slow Sfepy on Fedoracore 8
by Robert Cimrman July 26, 2009

July 26, 2009

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 -----

1 0

Slow Sfepy on Fedoracore 8
by Antonio July 24, 2009

July 24, 2009

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

3 6

ANN: SfePy 2009.3
by Robert Cimrman July 21, 2009

July 21, 2009

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

1 0

Sfepy on ubuntu 9.04: test failing
by Antonio July 21, 2009

July 21, 2009

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

3 10

sfepy windows installation
by Robert Cimrman July 21, 2009

July 21, 2009

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

3 8

surface terms
by Robert Cimrman July 16, 2009

July 16, 2009

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.

1 0

pcolor() to VTK
by Ondrej Certik July 15, 2009

July 15, 2009

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

2 2

writing to VTK
by Ondrej Certik July 8, 2009

July 8, 2009

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.asp… 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

2 5