<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi all,<br>
<br>
Apologies for the message to both mailing lists, but perhaps someone on
either cctbxbb or pymol-users has had some recent experience with
this...<br>
<br>
The subject line more-or-less says it all: I'm wondering if anyone has
recently used Rob Campbell's draw_symops (or draw_symops_cctbx) Python
modules with a relatively recent (within past year) version of the
cctbx (particularly the Boost C++
parts) ? I succeeded in doing this a few years ago to generate images
such
as the ones near the top of <a class="moz-txt-link-freetext" href="http://muralab.org/~cmura/PyMOL/Sandbox/">http://muralab.org/~cmura/PyMOL/Sandbox/</a>,
but I can't get it to work on my present system (64-bit Fedora
10; Python 2.5.2 with Python 2.6 coexisting).<br>
<br>
Below is what happens when I...<br>
<br>
1) Initiate a new PyMOL session (using a PyMOL v1.1 that I built
in-place from source, so should be compatible with local python, system
libs, etc)<br>
<br>
2) load PDB files (tried with a few diff't files; verified that they
contain proper CRYST specifications)<br>
<br>
3) do the usual 'run draw_symops_cctbx.py'<br>
<br>
4) call draw_symops() -- either implicitly, or by explicit
specification of the u.c.
params (i.e., using
something like
"draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)")<br>
<br>
...which crashes the pymol session and yields the following trace:<br>
<blockquote type="cite"><tt>PyMOL>draw_symops_param((45.2,45.2,70.8,90.,90.,120.),'p3121',0.5,0.1)<br>
libc backtrace (48 frames, most recent call last):<br>
/usr/bin/python [0x400649]<br>
/lib64/libc.so.6(__libc_start_main+0xe6) [0x344081e576]<br>
/usr/lib64/libpython2.5.so.1.0(Py_Main+0xb11) [0x34584e7ef1]<br>
<b><snip><br>
...<br>
...<br>
</snip></b><br>
/usr/lib64/libpython2.5.so.1.0(PyObject_Call+0x13) [0x345843d493]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so
[0x7ff19691db16]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::handle_exception_impl(boost::function0<void>)+0x9f)
[0x7ff19692a2ef]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so
[0x7ff196920b08]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::objects::function::call(_object*,
_object*) const+0x125) [0x7ff196920635]<br>
/root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so(boost::python::detail::caller_arity<2u>::impl<cctbx::sgtbx::rt_mx
(*)(cctbx::sgtbx::space_group const&, unsigned long),
boost::python::default_call_policies,
boost::mpl::vector3<cctbx::sgtbx::rt_mx, cctbx::sgtbx::space_group
const&, unsigned long> >::operator()(_object*,
_object*)+0x12a) [0x7ff18f820a3a]<br>
/root/cctbx/working/v4/cctbx_build/lib/cctbx_sgtbx_ext.so
[0x7ff18f8034cc]<br>
/root/cctbx/working/v4/cctbx_build/lib/libboost_python.so(boost::python::throw_error_already_set()+0xe)
[0x7ff196929dde]<br>
/usr/lib64/libstdc++.so.6(__cxa_allocate_exception+0x2f)
[0x3444cc2cdf]<br>
/lib64/libc.so.6 [0x3440832f90]<br>
Segmentation fault (libc call stack above)<br>
This crash may be due to a problem in any imported<br>
Python module, including modules which are not part<br>
of the cctbx project. To disable the traps leading<br>
to this message, define these environment variables<br>
(e.g. assign the value 1):<br>
BOOST_ADAPTBX_FPE_DEFAULT<br>
BOOST_ADAPTBX_SIGNALS_DEFAULT<br>
This will NOT solve the problem, just mask it, but<br>
may allow you to proceed in case it is not critical.<br>
PyMOL: abrupt program termination.<br>
</tt></blockquote>
I tried the recommendation of setting the BOOST_ADAPTBX* env vars, but
this doesn't remedy the problem.<br>
<br>
Also, I tried accomplishing this with many combinations of workflows:<br>
1) old cctbx (e.g., 2005_04_29_1615), latest stable release of cctbx
(2009_02_15_2320), bleeding-edge cctbx (2009_07_04_0143)<br>
2) pre-built cctbx binaries versus building myself from src (for each
of the above), insuring, again, optimal match between local system
libs...<br>
3) cctbx alone, cctbx in the context of Phenix, cctbx +/- its own
bundled Python (2.5 and 2.6)<br>
<br>
Also, I tried this with different combinations of Rob's scripts --
e.g., the 'symop_axes.dat'-dependent "draw_symops.py", versus
the 'all_axes_new.py'-dependent "draw_symops_cctbx.py". Interestingly,
I found that get_all_axes() from 'all_axes_new.py' works fine for
different
PDB files.<br>
<br>
Investigating the above draw_symops stacktrace led me to this
post from Ralf Grosse-Kunstleve to python-dev:
<a class="moz-txt-link-freetext" href="http://mail.python.org/pipermail/python-dev/2008-September/082639.html">http://mail.python.org/pipermail/python-dev/2008-September/082639.html</a><br>
It looks like exactly the same problem that's causing the
pymol/draw_symops
scripts to choke. Also, I can verify that issuing commands such as in
Ralf's post (boost_adaptbx.segmentation_fault,
boost_adaptbx.divide_by_zero)
result in the same segfaults and errors as in his post, so... I believe
this is the crux of it. Before delving into Boost codebase, cctbx's
exception-handling in C++/Python Boost, etc., I'm wondering if anyone
else has seen anything like this...? or has advice on how best to
proceed? Any tips or suggestions would be most greatly appreciated.<br>
<br>
Thanks,<br>
Cam<br>
<pre class="moz-signature" cols="72">--
-------------------------------------------------------
Cameron Mura
Assistant Professor
University of Virginia
Department of Chemistry
McCormick Road, Box 400319
Charlottesville, VA 22904-4319
Email: <a class="moz-txt-link-abbreviated" href="mailto:cmura@virginia.edu">cmura@virginia.edu</a>
Web: <a class="moz-txt-link-freetext" href="http://muralab.org">http://muralab.org</a>
Tel: 434.924.7824
Fax: 434.924.3710
-------------------------------------------------------
</pre>
</body>
</html>