Re: show mesh in mayavi2, segfault

On Mon, Jul 21, 2008 at 2:38 PM, Prabhu Ramachandran
<prabhu@...> wrote:
> Ondrej Certik wrote:
>>>> $ mayavi2 -x show_grid.py
>>>> bug-buddy: symbol lookup error: /usr/lib/libxml2.so.2: undefined
>>>> symbol: gzopen64
> [...]
>> I got the same error when I was exporting LD_LIBRARY_PATH to Sage, so
>> libxml2.so was using Sage's libz and that broke stuff. So I removed
>> that LD_LIBRARY_PATH and all is ok.
>
> Sorry, am confused.  Are you saying the issue is solved when you unset
> the LD_LIBRARY_PATH env var?

That solved the problem in the Sage case, but in mayavi2 case I
already had this LD_LIBRARY_PATH unset. So one can really
only use this trick once.

>
>>> I am not too sure that the problem is in the Mayavi2 or TVTK code base.
>>
>> Do you (or anyone) have time to fix it? If so, I'll create you an
>
> I think this is really an issue with sfepy and what it links to and what
> vtk is linking to.  For some reason they are stepping on each other.  I
> can't see how mayavi and tvtk come into the picture.  My guess is if you
> take a simple VTK example and stick an import sfepy up front, you'll get
> the same error.  VTK uses libxml and libz (among various other things).
>  You can either build VTK with the ones on the system or have it use
> its own internal copies of the library.  I have no idea how your system
> is setup or how the debian build is setup for this.  Doing an ldd on the
> vtk libs and on sfepy may help.

Here is what sfepy links to:

ondra <at> fuji:~/sfepy$ ldd ./sfepy/physics/extmods/dft.so
	linux-gate.so.1 =>  (0xb7ef2000)
	libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7e19000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7df3000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7de5000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c8a000)
	/lib/ld-linux.so.2 (0xb7ef3000)
ondra <at> fuji:~/sfepy$ ldd ./sfepy/terms/extmods/_terms.so
	linux-gate.so.1 =>  (0xb7f70000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7dd2000)
	/lib/ld-linux.so.2 (0xb7f71000)
ondra <at> fuji:~/sfepy$ ldd ./sfepy/fem/extmods/_fem.so
	linux-gate.so.1 =>  (0xb7fde000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e52000)
	/lib/ld-linux.so.2 (0xb7fdf000)
ondra <at> fuji:~/sfepy$ ldd ./sfepy/fem/extmods/_geometry.so
	linux-gate.so.1 =>  (0xb7f27000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d92000)
	/lib/ld-linux.so.2 (0xb7f28000)
ondra <at> fuji:~/sfepy$ ldd ./sfepy/fem/extmods/_meshutils.so
	linux-gate.so.1 =>  (0xb7f08000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d7e000)
	/lib/ld-linux.so.2 (0xb7f09000)

apart from that it imports scipy + numpy + matplotlib. But importing
scipy, numpy or matplotlib works. So I'll try to investigate
and reduce the problem further.

CCing Robert, maybe he knows where the problem is.

On Mon, Jul 21, 2008 at 2:50 PM, Prabhu Ramachandran
<prabhu@...> wrote:
> Ondrej Certik wrote:
>>> Double-click on Surface module in the tree, then in Property,
>>> select Representation: wireframe.
>>>
>>> It does what you want.
>>
>> Yes! Thanks a lot, that's exactly what I wanted. Is there a way to see
>> the Representation popup in the mayavi2 window directly, without
>> having to call double click on the Surface module?
>
> It should!  There should be a pane for mayavi object editor below the
> tree view that allows you to set the objects properties.  Don't you get
> that?  I'll admit that the UI For that can be a bit painful with funky
> scrollbars etc. but the pane should be there below the tree view.
> single clicking on a node should bring up the UI for that node there.
>
>
>> Yes, it does exactly what I wanted. Thanks again. Is there a way to
>> script mayavi from ipython? If I do the following, it breaks:
>>
>> In [1]: from enthought.mayavi.scripts import mayavi2
>>
>> In [2]: mayavi2.standalone(globals())
>
> *NEVER* use that standalone line.  As the comment on the example states,
> this is only a hack to allow users to run the script as python script.py.
>
> Fred has the right idea for scripting but even easier might be the mlab
> interface like this:
>
> $ ipython -wthread
>
> In [1]: from enthought.mayavi import mlab
> In [2]: mlab.figure()
> In [3]: mlab.show_engine()
> In [4]: e = mlab.get_engine()
>
> With trunk you could do this:
>
> e.open('mesh.vtk')
>
> but with 2.2.0 you will have to do as Fred says,
>
> from enthought.mayavi.sources.api import VTKFileReader
> r = VTKFileReader()
> r.initialize('mesh.vtk')
> e.add_source(r)
> from enthought.mayavi.modules.api import Surface
> s = Surface()
> e.add_module(s)
> s.actor.property.representation = 'w'
>
> and so on.
>
>
> With trunk you can right click on the source, add new objects or click
> on the adder nodes etc. but with 2.2.0 this would again need explicit
> scripting.

Thanks Fred and Prabhu for the tips, it works nice. This is much
better, the mlab interface is what I wanted.

I think this brings a lot of new possibilities for 3D plots in SymPy.
We should hook it in, so that one can use either pyglet or mayavi2.

And for the mesh it's what I was looking for as well. Thanks again.

Ondrej