Hi Osman,
below is a hack that might help you. In terms of sfepy's Viewer, it should read:
# Workaround for 'scene = gui.scene.mayavi_scene'
e = mlab.get_engine()
for scene in e.scenes:
if scene.scene.render_window is gui.scene.scene_editor.render_window:
print 'Yeah'
break
r.
PS: Thanks, Gael!
-------- Original Message --------
Subject: Re: [Fwd: Re: [SciPy-User] ANN: SfePy 2009.4]
Date: Wed, 25 Nov 2009 15:20:40 +0100
From: Gael Varoquaux
To: Robert Cimrman
On Wed, Nov 25, 2009 at 03:11:39PM +0100, Robert Cimrman wrote:
> is there a way to get a mayavi_scene from a MlabSceneModel instance in
> mayavi 3.1.0? I guess something like
> engine = mlab.get_engine()
> scene = engine.<get the scene that corresponds to the MlabSceneModel instance>
Not really something like that.
It's a really design flaw, that we realized a bit late.
Here is a hack (my_model.scene is the MlabSceneModel instance):
for scene in e.scenes:
if scene.scene.render_window is my_model.scene.scene_editor.render_window:
print 'Yeah'
HTH,
Gaël
I am pleased to announce release 2009.4 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
New documentation site: http://docs.sfepy.org/doc
Many thanks to Logan Sorenson for the new documentation contents, and Vladimir
Lukes for setting up the server.
Highlights of this release
--------------------------
- unified handling of user-defined functions (for defining subdomains,
heterogeneous material properties, boundary conditions etc.)
- greatly improved postprocessing and visualization capabilities, namely:
- support for file sequences (evolutionary simulations)
- animations (using ffmpeg)
- automatic scalar bars
- sfepy_gui.py: Mayavi2-based GUI to launch simulations
Major improvements
------------------
Apart from many bug-fixes, let us mention:
- quasistatic time stepping
- graphical logging:
- dynamic adding of data groups (new axes) to Log and ProcessPlotter
- linear algebra:
- reversed Cuthill-McKee permutation algorithm, graph in-place permutation
- setting of parameter variables by a user-defined function
- new tests and terms
For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2009.4_RELEASE_NOTES.txt
(full release notes, rather long).
Best regards,
Robert Cimrman
Hi,
the docs pages at [1] were update to version 2009.4.
Best,
Vladimir
[1] http://docs.sfepy.org/doc/
Logan Sorenson napsal(a):
> Hi Robert,
>
> On Tue, Nov 24, 2009 at 7:30 AM, Robert Cimrman <cimr...(a)ntc.zcu.cz
<mailto:cimr...@ntc.zcu.cz>> wrote:
>
> Hi,
>
> The docs at [1] need to be regenerated with the 2009.4 version. Can
> somebody
> with a working sphinx do that?
>
>
> Done! The html is available from [2] (gh-pages branch) and you can
check the result at [3]. Also, I disentangled the sphinx documentation
into a separate branch (sphinx_docs) from the master branch at [2].
Maybe this way is easier to maintain? (Still getting the hang of git :) )
>
>
>
> thanks,
> r.
>
>
> Best,
> Logan
>
>
>
> [1] docs.sfepy.org/do <http://docs.sfepy.org/doc>
>
> [2] git://github.com/logansorenson/sfepy_doc2.git
<http://github.com/logansorenson/sfepy_doc2.git>
> [3] http://logansorenson.github.com/sfepy_doc2/
>
> --
>
> You received this message because you are subscribed to the Google
Groups "sfepy-devel" group.
> To post to this group, send email to sfepy...(a)googlegroups.com.
> To unsubscribe from this group, send email to
sfepy-devel...(a)googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
Hi,
I just did a git pull from [1]. I was getting the following build error (see
(1) below) using the "distutils" method. It seems to be due to missing paths
to sfepy/fem/extmods/* in sfepy/linalg/extmods, so I followed the example of
sfepy/terms/extmods to put in the missing paths. This is available from [2]
(it's on the master branch, should I have made a new branch for this?). It's
a pretty quick fix to get the build to work, so I wouldn't be surprised if
I'm overlooking something. :)
After putting in the fix, I'm getting a test failure in
tests/test_permutations.py (see (2)). I figure I missed something else in
the distutils configuration. The "make" build method works before and after
the fix.
I know sfepy/linalg is new, so probably everything isn't in place for
distutils building yet, but I thought I could at least help get the build
working again. :)
Thanks!
Logan
[1] git://git.sympy.org/sfepy.git
[2] git://github.com/logansorenson/electrostatic_structural_test.git
(1)
logan@quantumdot:~/phoenix/projects/sfepy$ python setup.py build_ext
--inplace
['sfepy', '/home/logan/phoenix/projects/sfepy/sfepy',
'/home/logan/phoenix/projects/sfepy', '/home/logan/phoenix/projects/sfepy',
'/usr/lib/python2.5/site-packages/numpydoc-0.2-py2.5.egg',
'/usr/lib/python2.5/site-packages/scikits.umfpack-5.1.0-py2.5-linux-i686.egg',
'/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
'/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload',
'/usr/local/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages/Numeric',
'/usr/lib/python2.5/site-packages/PIL',
'/usr/lib/python2.5/site-packages/gst-0.10', '/usr/lib/pymodules/python2.5',
'/usr/lib/pymodules/python2.5/gtk-2.0',
'/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode']
non-existing path in 'sfepy/linalg/extmods':
'common_python.c'
non-existing path in 'sfepy/linalg/extmods':
'array.i'
non-existing path in 'sfepy/linalg/extmods':
'common.i'
<snip>
building extension "sfepy.linalg.extmods._rcm" sources
swig: sfepy/linalg/extmods/rcm.i
swig -python -Isfepy/linalg/extmods -o sfepy/linalg/extmods/rcm_wrap.c
-outdir sfepy/linalg/extmods sfepy/linalg/extmods/rcm.i
sfepy/linalg/extmods/rcm.i:9: Error: Unable to find 'types.h'
sfepy/linalg/extmods/rcm.i:11: Error: Unable to find 'common.i'
sfepy/linalg/extmods/rcm.i:12: Error: Unable to find 'array.i'
error: command 'swig' failed with exit status 1
(2)
tests/test_permutations.py
--- test_rcm: failed!
logan@quantumdot:~/phoenix/projects/sfepy$ ./runTests.py --debug
tests/test_permutations.py
<<< directory: tests, test files: 1
<<< tests/test_permutations.py
sfepy: left over: ['__builtins__', '_filename', '__file__', 'TestCommon',
'__name__', 'assert_', '__doc__', 'op']
>>> test instance prepared (1 test(s))
>>> <type 'exceptions.ImportError'>
Traceback (most recent call last):
File "./runTests.py", line 226, in <module>
main()
File "./runTests.py", line 217, in main
run_tests(stats, dirname, [filename])
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/logan/phoenix/projects/sfepy/sfepy/base/testing.py", line 38,
in run
ret = test_method()
File "tests/test_permutations.py", line 11, in test_rcm
from sfepy.linalg import rcm, permute_in_place, save_sparse_txt
File "/home/logan/phoenix/projects/sfepy/sfepy/linalg/__init__.py", line
1, in <module>
from extmods.rcm import rcm, permute_in_place
File "/home/logan/phoenix/projects/sfepy/sfepy/linalg/extmods/rcm.py",
line 28, in <module>
import _rcm
ImportError:
/home/logan/phoenix/projects/sfepy/sfepy/linalg/extmods/_rcm.so: undefined
symbol: g_error
Hi,
the sphinx docs, thanks to Logan, are covering now pretty much everything the
old documentation wikis did. They are at [1] now, but we should put them to a
more permanent(-looking) location.
Any suggestions how to proceed?
Just a few ideas:
We have the 'sfepy.org' domain, so it would be nice to have the docs somewhere
under it. Or we could create the 'sfepy' github user and put the docs to the
'doc' repo, resulting in http://sfepy.github.com/doc/. The latter can be done
immediately, for the former my web knowledge is too limited.
r.
[1] http://logansorenson.github.com/sfepy_doc2/
Hi,
I was wondering how to implement the electrostatic-elastic coupling in
SfePy. Basically, I think this coupling is described by the Maxwell
stress tensor [1] which gives the stress due to the electrostatic
field (setting the magnetic field to 0 in the quasistatic
approximation) on the surface of a conductor.
I think the coupling can be handled in a similar manner with the
piezoelectric coupling. For example, in input/piezo.py, the equations
are:
equations = {
'1' : """- %f * dw_mass_vector.i1.Y( inclusion.density, v, u )
+ dw_lin_elastic_iso.i1.Y( inclusion.lam, inclusion.mu, v, u )
- dw_piezo_coupling.i1.Y2( inclusion.coupling, v, phi )
= 0""" % omega_squared,
'2' : """dw_diffusion.i1.Y( inclusion.dielectric, psi, phi )
+ dw_piezo_coupling.i1.Y2( inclusion.coupling, u, psi )
= 0""",
}
I think there should be a similar set of equations for the
electrostatic-elastic coupling case, but the integration should be
done over the interface of the elastic material and the vacuum
regions. I think that can be handled by adding a 2D integral in the
problem definition. What I'm missing is how to define the coupling
term in SfePy. I think the form of the term is basically the same as
dw_surface_ltr in sfepy_manual.pdf. Also, it looks like the gradient
of the electric potential can be obtained from cachesBasic.
Is it possible to use the gradient of the electric potential
information to calculate the Maxwell stress tensor using appropriate
vector operations (divergence and dot product), along with the
dielectric tensor? Would this be doable through the dw_surface_ltr
term? Or is it better to implement a new coupling term (based off
dw_surface_ltr) to handle this (and how would one go about that :) )?
Hope everything is clear! Any advice is greatly appreciated!
Thanks,
Logan
[1] http://en.wikipedia.org/wiki/Maxwell_stress_tensor
Hi,
I finally got some time to update the sphinx documentation. The final
result is at [1] and the git repo can be cloned from [2]. Basically,
so far I've just pulled stuff from the google pages and converted into
sphinx format and did some polishing. I think it's a good start, but
definitely needs more work! For example, the tutorial right now is
more "theoretical", and may not be "practical" enough for a new user
to understand...probably this can be separated into a simpler tutorial
and then an advanced tutorial or reference section, especially the
problem description format.
Also, I haven't had time to look into genDocs.py yet...
Thanks!
Logan
[1] http://logansorenson.github.com/sfepy_doc2
[2] git://github.com/logansorenson/sfepy_doc2.git
