Chimera-dev November 2012

Download

chimera-dev@cgl.ucsf.edu

2 participants
2 discussions

Re: [chimera-dev] Chimera/Python sparse matrices
by Greg Couch 06 Dec '13

06 Dec '13

On 8/13/2010 12:06 PM, Forbes J. Burkowski wrote: > What are the steps that need to be taken if the Python used in Chimera is > to have the ability to import functions from SciPy or PySparse? > > Thanks for any advice that you can provide. > > Cheers, > Forbes Burkowski If you want to use prebuilt SciPy binaries with chimera, you need one that is compatible with the version of chimera that chimera is using. Chimera 1.4.x uses Python 2.5, and the daily builds use Python 2.7. You would add those packages to chimera by either (1) given the '--pypath dir' command line option, (2) setting your CHIMERAPTH environment variable (instead of PYTHONPATH, PYTHONPATH is ignored so chimera won't be accidentally broken by other installed Pythons), or (3) add the installation directory to sys.path in Python. If you're not using a daily build on Linux, then you should edit CHIMERA/share/chimeraInit.py and comment out or remove the part that sets the RTLD_GLOBAL flag -- it appears to be no longer needed and its presence breaks SciPy. If you're going to compile from source, which you'll need to do if you're using a daily build, I'd recommend trying PySparse first, since it is a smaller package. Python packages that incorporate C (or C++ or Fortran) code are more difficult than prebuilt binaries because (a) you need a compiler, and (b) if the code calls the Python C API, you need a compatible compiler, ideally the same one as what the rest of Chimera was build with. PySparse needs BLAS and LAPACK libraries and optionally wants UMFPACK and/or SuperLU. On on Redhat and Fedora Linux, you can get the first three libraries by installing the blas-devel, lapack-devel, and suitesparse-devel packages. Chances are you'll be able to install PySparse into chimera's python by running "CHIMERA/bin/pythonXXX setup.py install" in the pysparse source tree (where CHIMERA is the path to where chimera was installed). On Linux, you might have to set the LD_LIBRARY_PATH environment variable to CHIMERA/lib. On Mac OS X, the path to the chimera binary is CHIMERA/Contents/Resources/bin/pythonXXX and the environment variable is DYLD_LIBRARY_PATH. Or you could install PySparse into another Python and use the --pypath/CHIMERAPATH/sys.path approach as given above. Hope this helps, Greg

4 3

atom.anisoU does update as expected for MD trajectories
by Ryan Harrison 26 Nov '12

26 Nov '12

Dear Chimera team, I've encountered a problem with atom.anisoU. Since class Atom is implemented in C++, and I don't have the technical sophistication or nerve to build chimera from scratch after the dire warning, [1<http://www.cgl.ucsf.edu/chimera/sourcecode.html>] I seek council. I'm using PDB ANISOU to store orientation information from a coarse grained model. Using PDB MODEL and PDB ENDMDL I output trajectory information. PDB atom coordinates and aniso change with each frame in the trajectory. When visualizing a coordSet in the trajectory, atom.coord() updates as expected... # m1 is a model with ANISO information >>> m1.activeCoordSet = m1.coordSets[2] >>> m1.atoms[1].coord() chimera.Point(-0.268, 0.002, 0.08) *# <~~~ As expected from PDB file* >>> m1.activeCoordSet = m1.coordSets[10] >>> m1.atoms[1].coord() chimera.Point(0.012, -0.276, -0.043) *# <~~~ Changes as expected from PDB file* However, atom.anisoU does not update as expected [2<http://www.cgl.ucsf.edu/pipermail/chimera-users/2012-February/007246.html>, 3<http://plato.cgl.ucsf.edu/pipermail/chimera-users/2008-December/003377.html>]. It is always the PDB ANISO information from the last model (last MD trajectory) in the file... >>> m1.activeCoordSet = m1.coordSets[2] >>> m1.atoms[1].anisoU *# <~~~ ANISO for last model in PDB file, not model 2 * array([[ 0.0296, 0.0182, 0.0201], [ 0.0182, 0.0844, -0.0055], [ 0.0201, -0.0055, 0.1258]], dtype=float32) >>> m1.activeCoordSet = m1.coordSets[10] >>> m1.atoms[1].anisoU *# <~~~ Again, ANISO for last model in PDB file, not model 10* array([[ 0.0296, 0.0182, 0.0201], [ 0.0182, 0.0844, -0.0055], [ 0.0201, -0.0055, 0.1258]], dtype=float32) The result is visualizations with proper coordinates (update properly for each frame in trajectory) but inaccurate ellipsoids (ANISO does not update; fixed as last frame / last model). *Work around 1 (Failed):* Since *aniso* takes spec atom-spec as an input, I tried specifying a model and position in trajectory. Unfortunately, this doesn't seem to be possible [4<http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/frameatom_spec.html> ]. *Work around 2 (Tedious):* Since *aniso* can take submodels, I import (cannot use nifty MD Movie tool) as sub-models instead of as a trajectory. I can then apply aniso to each submodel, which works as expected, and switch submodels on/off sequentially to make a movie (5<http://www.cgl.ucsf.edu/pipermail/chimera-users/2009-April/003800.html>). This is not ideal since I'm missing out on the ease of use of the MD Movie tool, and it's very cumbersome to move through a stack of submodels to emulate a trajectory. Thank you for your time and please help! Best, Ryan -- Ryan M Harrison Wolfson College University of Oxford NIH-Oxford Graduate Partnership Program http://graylab.jhu.edu/~ryan/ http://www.linkedin.com/in/rmharri

2 1