August 2008 - Chimera-dev - RBVI Mailing Lists

add h
by Virginie Lafont 01 May '09

01 May '09

Hi, I am a new user of chimera and I already have a question. I have an protonated aspartic acid in my protein and I was wondering, is it possible to add hydrogen atom to aspartic acid with chimera? Thanks Virginie

4 4

chimera import from unmodified python 2.5
by Ondrej Marsalek 12 Sep '08

12 Sep '08

hello everyone, first of all, i would like to say thank you for using vanilla python 2.5, i think this could be quite useful. unfortunately, there is one problem that keeps me from using chimera from a session of my regular python 2.5 installation (on ubuntu 8.04). after setting paths properly, an attempt to import chimera (or the binary module _chimera) produces the following exception: In [1]: import chimera --------------------------------------------------------------------------- <type 'exceptions.ImportError'> Traceback (most recent call last) /home/andy/<ipython console> in <module>() /home/andy/CHIMERA/share/chimera/__init__.py in <module>() <type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String In [2]: import _chimera --------------------------------------------------------------------------- <type 'exceptions.ImportError'> Traceback (most recent call last) /home/andy/<ipython console> in <module>() <type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String it seems that the python 2.5 provided with chimera is compiled with different unicode settings than the one in ubuntu. the shared chimera objects are compiled against that version of python and therefore can't be used from my normal python. the only way i see around this at the moment is to recompile chimera, but i wanted to leave that as the very last option. i would appreciate any suggestions, as a straightforward way to use chimera from my normal python would be really neat. i'll be glad to provide details if anyone is interested. regards, ondrej marsalek

3 6

Re: [chimera-dev] headless chimera issues
by Eric Pettersen 20 Aug '08

20 Aug '08

Hi James, Yes, undoubtedly in nogui mode there is no Reply Log dialog for you to access. If you are using Python, there are far more direct ways to get an atom's coordinates than using getcrd and trying to parse the reply log anyway. Such as: from chimera.selection import OSLSelection sel = OSLSelection("#0:%s.%s@CA" % (snpPos, chain)) a = sel.atoms()[0] crd = a.coord() # or a.xformCoord() for transformed coordinates I've attached a PDF of a handout from a Chimera development class we just taught here at UCSF. It covers a bunch of handy resources and tips. The first resource it lists, the Programmer's Examples, is something you should look over. They cover how Chimera's molecular data is laid out, how to deal with selections, and so forth. --Eric On Aug 20, 2008, at 9:37 AM, James A. Cleland wrote: > Ok, I ran this in chimera (gui) and I see how it is working now, the > reply contains space-separated coordinates at the end of the string > and get_coords picks these off from the end (-1, -2, -3). Perhaps > this is another “headless” issue as there is no dialog? If so, maybe > there’s somewhere else I can pick off the reply information for > getcrd? > > Thanks! > > From: James A. Cleland [mailto:jcleland@jamescleland.com] > Sent: Wednesday, August 20, 2008 12:32 PM > To: 'Eric Pettersen' > Subject: RE: headless chimera issues > > This worked like a charm, thank you! I have run into another issue > that I thought you may be able to help with. > > We are attempting to draw a pointer indicating the alpha carbon for > a particular residue. This has been done in the past, but no longer > works. This may have been something that you helped with. > > The function that is currently failing is called “get_coords()”. > Here’s what I have: > > def _get_coords(): > from chimera import dialogs, Vector > coords = Vector(0,0,0) > r = dialogs.find('reply') > text = r.text.get('1.0', 'end') > coordString = text.splitlines()[-2] > coordString = coordString.split(' ') > print coordString > coords[2] = float(coordString[-1]) > coords[1] = float(coordString[-2]) > coords[0] = float(coordString[-3]) > return cords > > Prior to calling get_coords(), there is a command executed that > seems to provide the dialog information, if I’m understanding > correctly: > > runCommand("getcrd #0:%s.%s@CA" % (snpPos, chain)) > > The line that appears to be failing in get_coords() is the fourth in > the function, r.text.get(). It looks like dialogs.find() returned > None. > > Do you have any suggestions as to how I might get these coordinates > or what we might be doing wrong? > > Thanks! > James > From: Eric Pettersen [mailto:pett@cgl.ucsf.edu] > Sent: Tuesday, August 19, 2008 7:41 PM > To: James A. Cleland > Cc: Tom Goddard > Subject: Re: headless chimera issues > > That's right -- the patch just prevents the error. It doesn't do > the coloring. Hopefully Tom Goddard will be able to help you with > that. > > --Eric > > On Aug 19, 2008, at 4:21 PM, James A. Cleland wrote: > > Thank you for the quick reply! I applied this patch manually by just > adding the import and the condition. I had commented the conditional > statements prior to writing you and this worked fine, but the > surface model didn’t appear to be colored according to the Delphi > output. Is it correct for me to assume that, after this patch is > applied, I’m still not seeing the electrostatic potential in the > surface coloring? > > Thanks again, > James > > From: Eric Pettersen [mailto:pett@cgl.ucsf.edu] > Sent: Tuesday, August 19, 2008 6:56 PM > To: James A. Cleland > Cc: Tom Goddard > Subject: Re: headless chimera issues > > Hi James, > That exception would be a bug -- SurfaceColor should not > be trying to bring up a dialog if Chimera is running in nogui mode. > I've committed a fix for this and it will be in tomorrow's daily > build. Here's the diff if you want to correct your version: > > *** ChimeraExtension.py 6 May 2008 04:20:05 -0000 1.12 > --- ChimeraExtension.py 19 Aug 2008 22:51:36 -0000 > *************** > *** 50,56 **** > from VolumeViewer import open_volume_file > vlist = open_volume_file(path, ftype, open_models = False, > show_data = False, > show_dialog = False) > ! if len(vlist) > 0: > from SurfaceColor.gui import show_surface_color_dialog > d = show_surface_color_dialog() > d.use_electrostatics_colormap() > --- 50,57 ---- > from VolumeViewer import open_volume_file > vlist = open_volume_file(path, ftype, open_models = False, > show_data = False, > show_dialog = False) > ! import chimera > ! if len(vlist) > 0 and not chimera.nogui: > from SurfaceColor.gui import show_surface_color_dialog > d = show_surface_color_dialog() > d.use_electrostatics_colormap() > > I've cc'ed Tom Goddard on this mail since he is the > expert on Chimera's volumetric API and can hopefully provide advice > on coloring your map programmatically. > > --Eric > > Eric Pettersen > UCSF Computer Graphics Lab > http://www.cgl.ucsf.edu > > > On Aug 19, 2008, at 1:32 PM, James A. Cleland wrote: > > > Hi Eric, > > My name is James Cleland and I am currently working with Dr. Rachel > Karchin at JHU. I had corresponded with Greg Couch over running > Chimera without an X server and he had directed me toward a build > designed to run headless. I have been using this for a couple of > weeks without problems, but I encountered an issue the other day. > > I am trying to import a surface for electrostatic potential that was > generated using Delphi. The trouble is, this is causing an error > (see below). > > Executing test.py...Opening pdb1a01.ent... > 1 model opened > > Traceback (most recent call last): > File "/home/pipeline/chimera/share/__main__.py", line 65, in > <module> > value = chimeraInit.init(sys.argv) > File "CHIMERA/share/chimeraInit.py", line 384, in init > chimera.openModels.open(a, prefixableType=1) > File "CHIMERA/share/chimera/__init__.py", line 1345, in open > File "CHIMERA/share/chimera/__init__.py", line 787, in _openPython > File "test.py", line 15, in <module> > runCommand("open 1a01.phi") > File "CHIMERA/share/chimera/__init__.py", line 2026, in runCommand > File "CHIMERA/share/Midas/midas_text.py", line 62, in makeCommand > File "CHIMERA/share/Midas/midas_text.py", line 918, in doOpen > File "<string>", line 1, in <module> > File "CHIMERA/share/Midas/__init__.py", line 1352, in open > File "CHIMERA/share/chimera/__init__.py", line 1345, in open > File "CHIMERA/share/SurfaceColor/ChimeraExtension.py", line 55, in > open_cb > File "CHIMERA/share/SurfaceColor/gui.py", line 613, in > show_surface_color_dialog > File "CHIMERA/share/chimera/dialogs.py", line 77, in display > File "CHIMERA/share/chimera/dialogs.py", line 62, in find > File "CHIMERA/share/chimera/baseDialog.py", line 435, in __init__ > File "CHIMERA/share/chimera/baseDialog.py", line 121, in __init__ > File "CHIMERA/share/chimera/tkgui.py", line 63, in <module> > ImportError: No module named Togl > Error while processing test.py: > ImportError: No module named Togl > (see reply log for Python traceback info) > > From what I can gather, the call to open is trying to present a > dialog for choosing surface colors and limits. I’ve seen this when > running Chimera with an X server. The trouble is, I need to skip > this dialog and, possibly, specify volume in some other fashion. > > We used to use the following python code in our Chimera script: > > from chimera import openModels, MSMSModel > runCommand("set bg_color black") > surf = openModels.list(modelTypes=[MSMSModel])[0] > from VolumeViewer.volume import Volume > vol = openModels.list(modelTypes=[Volume])[0] > from SurfaceColor import color_by_volume > color_by_volume(surf, vol, (-30, 0, 30), ((1,0,0,1.0), (1,1,1,1.0), > (0,0,1,1.0))) > > This was run using an older version of Chimera and used an X server. > We ran into problems using this version with –nogui, which is what > led me to the headless version. > > I have been playing around with SurfaceColor/ChimeraExtensions.py, > specifically line 55-56, trying to figure out how to at least get > color on the surface using the default volume. It appears that, by > commenting the aforementioned lines, I get no surface coloring at all. > > Can you provide some direction for me on this? Any help is > appreciated! > > Thanks, > > James A. Cleland > (w) 1(703)392-1357 > (c) 1(703)402-5447 > jcleland(a)jamescleland.com > > >

1 0

Re: [chimera-dev] making a python package
by Eric Pettersen 14 Aug '08

14 Aug '08

Hi Bill, Greg is the real expert here, but he's at SIGGRAPH right now so I'll put out what little I know and let Greg correct anything I get wrong when he has time. Yeah, compiling/linking can be a nightmare when you are trying to use libs you have no control over and that may have been compiled with options you didn't anticipate or from modified sources. That's why we cheat and include everything we depend on (which is one reason Chimera is such a huge download). In particular, we include Tk and Tcl libraries. If you look in Chimera's "foreign" source directory, there is a TclTk subdirectory there. So no worries about out-of-date/incompatible versions and all that. We have another layer of control in that we're not (currently) trying to provide a package that other people can easily compile on their own system. So therefore we don't need a configure step. Our makefiles have conditionals based on the OS to get the right flags for linking and compiling and whatnot for the systems that we ourselves compile on. A lot of that makefile logic is concentrated in the "includable" makefiles found in the mk directory, so that individual makefiles only have to include the appropriate mk makefile and then customize a few variables themselves. We try to use "foreign" source with as little patching as possible so that we can easily incorporate updated versions, so many of the foreign packages (e.g. Tcl/Tk) do have their "native" configure step. Nonetheless, the Chimera makefile that initiates the foreign package build may supply arguments to the configure so that the final build uses the right compiler flags, uses the right build/install location, and so forth. I don't know how much help this has been, but feel free to ask more questions and maybe I'll know the answers. :-) --Eric Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu On Aug 14, 2008, at 11:54 AM, William Baxter wrote: > Hello Eric, > > I'm trying to make an installation package like Chimera's, in which > our > software installs its own Python. Can you explain how your > installation > package is set up? I have a script that goes through the usual > configure, make, and make install commands, but it encounters > different > problems on each platform (for us, Linux and Irix). How does the > Chimera > install make sure everything is linked together properly? > > Any help is greatly appreciated. > > Thanks, > Bill Baxter > > -- > William T. Baxter, Ph.D. > Wadsworth Center > Empire State Plaza, PO Box 509 > Albany, NY 12201-0509 > > > Subject: Re:[chimera-dev] making a python package > From: William Baxter > Date: 02:42 PM > To: Greg Couch > > > Greg, > thanks for your description. I have another couple of questions. > > My script goes through the usual configure, make, make install > commands, > but Chimera seems to go straight to compilation. How do you set it > up to > be so fast? > > Also, finding Tcl/Tk for Tkinter is a headache that seems to be > different on each platform. How do you ensure that Python finds that > right Tcl libs? > > The Chimera installation is really admirable and efficient. I'd like > to > emulate it as far as possible. > > Any advice you can give is greatly appreciated. > > Thanks, > Bill B. > > Greg Couch wrote: >>> On Wed, 30 Jul 2008, William Baxter wrote: >>> >>>>> Hello, >>>>> >>>>> we would like to package our software, Spire >>>>> (www.wadsworth.org/spider_doc/spider/docs/spire/) the way >>>>> Chimera is >>>>> packaged, with its own Python, Tcl/Tk, and other libraries. Do >>>>> you have >>>>> some documentation, or can you point me toward some resources that >>>>> explain how to go about creating such an installation package? >>>>> >>>>> Thanks, >>>>> Bill Baxter >>> >>> We don't have any documentation, but here's a quick description of >>> what we do binary distributions for chimera: >>> >>> On Windows, we use the Inno Setup program, >>> <http://www.jrsoftware.org/isinfo.php>. >>> >>> For Mac OS X, we build a disk image using the hdiutil program. >>> And we >>> modify the name all of the shared libraries with something like: >>> install_name_tool -id @executable_path/$(LIBNAME) >>> >>> On Linux and other Unix systems, we use a modified self-extracting >>> zip >>> archive where an installation program is run after the files have >>> been >>> extracted. >>> >>> In all cases, when chimera starts up, we set up the environment to >>> get >>> our shared libraries (and clear the environment of things that would >>> hurt us, like PYTHONHOME). >>> >>> Hope this helps, >>> >>> Greg Couch >>> UCSF Computer Graphics Lab > > > -- > William T. Baxter, Ph.D. > Wadsworth Center Empire State Plaza, > PO Box 509 Albany, NY 12201-0509

1 0

making a python package
by William Baxter 01 Aug '08

01 Aug '08

Hello, we would like to package our software, Spire (www.wadsworth.org/spider_doc/spider/docs/spire/) the way Chimera is packaged, with its own Python, Tcl/Tk, and other libraries. Do you have some documentation, or can you point me toward some resources that explain how to go about creating such an installation package? Thanks, Bill Baxter -- William T. Baxter, Ph.D. Wadsworth Center Empire State Plaza, PO Box 509 Albany, NY 12201-0509 IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation.

2 1

Chimera-dev August 2008