- Chimera-dev - RBVI Mailing Lists

Material science feature requests
by Thomas Goddard 23 Oct '04

23 Oct '04

Here is email I exchanged with Chris Greenwell about using Chimera for a material science / molecular dynamics study. Tom --------- Date: Thu, 21 Oct 2004 09:14:55 +0100 Subject: Re: Material visualization with Chimera From: "H. Chris Greenwell" <h.greenwell(a)ucl.ac.uk> To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Hi Tom, First of all, Chimera is fantastic! Congratulations! Yes, I noticed the problem with large numbers of atoms. We run systems getting on for 500,000 atoms., but most are less than 100,000 atoms. I still use the Atom Eye software, which is more efficient at using memory (http://164.107.79.177/Archive/Graphics/A/) for large models. However, it is less intuitive to use and doesn't have much of the functionality that we would like. The type of work we do at the moment involves simulating the interlayer region of layered clay type structures with organic molecules, such as long monomers, between the crystalline clay sheets. We do this to gain insight into the interlayer arrangement and dynamics not attainable by experimental means. We have to present data which is both meaningful and interesting to the experimental community. We use the LAMMPS code as our large-scale MD engine, from Sandia. We have our own data analysis tools to generate RDFs, diffusion coefficients and atom density plots. However, in order to make sense of the features, and to spot unusual features that get averaged in the data of these numerical data sets it is necessary to visualize the model through the simulation. As an ex-experimental chemist I have a strong bias to the visual! I have looked at many types of software, and essentially we have two considerations: 1) A visualizer for looking at each frame, and movies of the atom positions. Data analysis as described above. 2) A builder for loading crystalline unit cells, generating organic monomers, translating, rotating and deleting atoms/molecules. Critically, we tend to use periodic boundary conditions in all our simulation so an ability to replicate unit cells and visualize the boundary markers when desired. Functionality to place forcefield atom types on the system is also needed. I have come across only two contenders to do this with: ECCE (http://ecce.emsl.pnl.gov/) looks promising and is free to academia, however, as with many freeware builders/visualizers, it is only for bio-systems and has no concept of periodic unit cells. I also am unaware of the atom number capability. Materials Studio/Cerius 2. These are the commercial options from Accelrys and work very well. Unfortunately, these are also incapable of building models greater then approx. 30,000 atoms for materials science. Materials Studio has a bug, which stops it doing this, and Cerius 2 (a) gets very slow, and (b) has a purely numeric atom numbering, which has a 5 digit capacity and relies on the molecules being made up of residues. We are starting to use the latest LAMMPS2003 software from Sandia, and may well look at steering it in the future, so any developments in Chimera to aid us in looking at materials would be much appreciated. Many thanks Chris On Thursday, October 21, 2004, at 12:02 AM, Thomas Goddard wrote: > Hi Chris, > > Dave Konerding told me you tried using Chimera to visualize materials > with large numbers of atoms. Unfortunately Chimera uses alot of memory > per atom (~2 Kbytes) and gets pretty slow for systems of 100,000 atoms > or more. > > I'm curious about what you are looking for with Chimera and whether > there are new features you would need. We primarily focus on proteins > and nucleic acids but would consider adding features to help in > materials > science. > > Tom Goddard > Chimera developer > UC San Francisco > > H. C. Greenwell EPSRC Fellow Centre for Computational Science Christopher Ingold Laboratories University College London 20 Gordon Street London WC1H 0AJ United Kingdom --------- Date: Thu, 21 Oct 2004 10:54:31 +0100 Subject: Chimera materials visualization wish list From: "H. Chris Greenwell" <h.greenwell(a)ucl.ac.uk> To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Hi Tom, I realise that in my earlier e-mail I have only outlined general points, and therefore have only addressed part of your email. Therefore, if I could compile an initial wish-list of new features (apologies if some of this is already in the code, as I am still getting to know it) it might look something like: 1) To be able to import the common file types we use in our simulations. These are: (a) the LAMMPS 2001 output files (.pos), which are largely XYZ files with a time step and an atom type number related to, (b) the LAMMPS 2001 data file (.dat/.lmp), which contains the atom information (masses), coordinates and bonding. (c) the LAMMPS 2003 data/position files, which I think are a little different but will be used by us in the near future. (d) the Accelrys Biosym coordinate (.car) file, topology (.mdf) file and trajectory (.arc/.trj) files. Dave kindly put together a little utility for the .car/.mdf file. 2) To be able to remap any atoms that have moved outside the cell, within the cell boundaries when visualized. 3) To be able to view the cell boundaries as a dashed/solid/no line. 4) To be able to replicate the viewed model in XYZ directions so that motion across cell boundaries can be followed. 5) To be able to turn the replicated unitcells into one supercell (we have an utility to do this with .car/.mdf) . 6) To be able to display and select atoms on the basis of forcefield atom types. 7) To be able to render crystalline structures as polyhedra. 8) After visualizing, or performing molecule/atom translations/deletions/insertions etc, to be able to export as the file types listed in (1) and also the Atom Eye (.cfg) format. Many thanks Chris H. C. Greenwell EPSRC Fellow Centre for Computational Science Christopher Ingold Laboratories University College London 20 Gordon Street London WC1H 0AJ United Kingdom

1 0

[chimera-dev] API change in next release: no more selection.selectionModels()
by Eric Pettersen 03 Oct '04

03 Oct '04

If you based any code off the "Selections" programmer's example, you may be using the selection.selectionModels() function to get a list of models to restrict selections to. That function is going away with the next release. You should use the chimera.openModels.list() function instead as explained in the revised example now on the Chimera web site. Using the openModels.list() function will work in 1.1951 and prior releases as well as our next release which should be out next week. At one point, it had been our intent to allow users to designate a set of models to restrict selections to, which was the raison d'etre for the selectionModels() function. The implementation of an interface designating such models never materialized and over time the whole mechanism just seemed to be unnecessary, so we are dropping the idea and the corresponding API baggage. I apologize for any inconvenience. Eric Pettersen UCSF Computer Grpahics Lab pett(a)cgl.ucsf.edu

1 0

proxy support
by Eric Pettersen 23 Sep '04

23 Sep '04

The development version of Chimera now has support for proxy web servers (controlled in the "Web Access" preferences category). Developers should try to use urllib.urlopen or urllib2.urlopen whenever possible rather than using httplib directly so that proxying will work without having to explicitly provide for it in your code. Eric Pettersen UCSF Computer Graphics Lab pett(a)cgl.ucsf.edu http://www.cgl.ucsf.edu

1 0

Re: [Chimera-users] chimera in fink
by Eric Pettersen 15 Sep '04

15 Sep '04

On Sep 14, 2004, at 4:42 PM, Grant Jacobs wrote: > > FWIW, I prefer the .dmg style installer, or at least single package, > one click installers. Its also useful to have the application > relocatable to any folder within /Applications. Certainly if you're _not_ using fink, the .dmg is almost certainly what you want. I find it highly convenient too. If you're using fink, perhaps you'd like to be able to do everything through that mechanism, but as you point out sometimes even fink users prefer the .dmg install. And given the work we would need to do before we could even try to have Chimera available via fink, it won't be happening soon. >> We haven't really seriously considered it, no. One stumbling block >> is that Chimera really isn't completely open source yet. We >> distribute the source to the Python part of Chimera but not the C++ >> part. We plan on distributing the C++ part once we have organized it >> enough that outside developers would have a prayer of compiling it, > > :-) > > For my money I'd be more concerned about good documentation of the > APIs (etc) so that people can build on what already exists without > having to decipher someone else's code base. Just my 2c - my pet peeve > about open source is that poor or non-existant documentation forces > everyone up the same time-wasting learning curves. > >> but we haven't put in the work to do that yet -- always so many >> things to do! Yes, better documentation would be part of "organizing" the C++ part. Right now, the only comprehensive API documentation we have is the programmer's reference guide, which amounts to simply a dump of all APIs with some doc strings thrown in -- barely more useful that using 'dir' on Python objects of interest. The best documentation we have is the programmer's examples, which do a good job of explaining how to do various commonly-desired tasks in Chimera, such as getting your extension into the menus, using molecular data, and saving into sessions. Once you want to go beyond the realm of the examples, we trust that people will look at other Chimera extensions that do similar things to what they want to do and figure things out. It's the best we have until we get that "organizing" done. Of course, we do answer any development-related questions we get on chimera-dev(a)cgl.ucsf.edu. The other thing about a documented API is that you can expect that it won't disappear from one release to the next -- at least not without a migration path being provided. Eric Pettersen UCSF Computer Graphics Lab pett(a)cgl.ucsf.edu http://www.cgl.ucsf.edu

1 0

Chimera programming in Solaris
by Hongbo Zhu 03 Sep '04

03 Sep '04

Hi, I want to include Chimera python packages in my program under Solaris. Concretely, I want to use the UnitCell-related packages to construct the crystal unit cell from PDB files. I read through the mailing list and I know it's not possible to get chimera for solaris now. But is there any other method I can use to invoke related packages, e.g. import chimera, in my python program in solaris? Thanks in advance! -- Macro Zhu macrozhu(a)gmail.com

2 1

by Sheetal Patil 03 Sep '04

03 Sep '04

Hello, Iam trying to configure Phantom desktop with Chimera. I get the following error: "Couldnot load Chimers_phantomcursor library.Can you please tell me where I can find this piece of software? Thanks, Sheetal +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ " The future belongs to those, who believe in the beauty of their dreams "

1 0

adding commands
by Eric Pettersen 28 Aug '04

28 Aug '04

I added an example ("Adding Command-line Commands") to Chimera's programmer examples describing how to add your own commands to Chimera's command-line interpreter. The functionality described in the example will not be available until the next Chimera release, in 2-6 weeks. The programming examples are at http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/Examples/ index.html Eric Pettersen UCSF Computer Graphics Lab pett(a)cgl.ucsf.edu http://www.cgl.ucsf.edu

1 0

emulating the command line change
by Eric Pettersen 13 Jul '04

13 Jul '04

Hi, Just wanted to note that Midas.midas_text.makeCommand() is changing (it is used to emulate typed commands). It now immediately executes the relevant functionality instead of returning a string that can be exec'ed. So when this change becomes available in the next release, alter your code that uses makeCommand() to just call it directly instead of exec'ing what it returns. Eric Pettersen UCSF Computer Graphics Lab pett(a)cgl.ucsf.edu http://www.cgl.ucsf.edu

1 0

regd error when opening a .mrc file
by Sandeep N Seshadri 01 Jul '04

01 Jul '04

i am getting the following error when i try to open a .mrc file . i generated a .pdb file and use a pdb2mrc to generate a .mrc file . i tried opening the .pdb file it works fine but when i try to open the .mrc file it gives the error. if anyone has any idea on why this error occurs please let me know thanks sandeep Error while processing test-helix.mrc: ZeroDivisionError: float division (see reply log for Python traceback info) Traceback (most recent call last): File "/home/sandeep/chimera/share/__main__.py", line 56, in ? value = chimeraInit.init(sys.argv) File "/home/sandeep/chimera/share/chimeraInit.py", line 275, in init prefixableType=1) File "/home/sandeep/chimera/share/chimera/__init__.py", line 886, in open models = func(filename, *args, **kw) File "/home/sandeep/chimera/share/VolumeViewer/ChimeraExtension.py", line 30, in open_cb d.add_data_sets([g]) File "/home/sandeep/chimera/share/VolumeViewer/__init__.py", line 175, in add_data_sets self.redisplay_cb() File "/home/sandeep/chimera/share/VolumeViewer/__init__.py", line 459, in redisplay_cb self.show_using_dialog_settings(self.focus_region) File "/home/sandeep/chimera/share/VolumeViewer/__init__.py", line 380, in show_using_dialog_settings tp.update_histograms(data_region) File "/home/sandeep/chimera/share/VolumeViewer/__init__.py", line 1142, in update_histograms cw.update_histogram(data_region, read_matrix, self.dialog.message) File "/home/sandeep/chimera/share/VolumeViewer/__init__.py", line 1465, in update_histogram h.show_data(Numeric.log(s.counts + 1)) File "/home/sandeep/chimera/share/VolumeViewer/histogram.py", line 26, in show_data hscale = float(cheight) / max_height ZeroDivisionError: float division

1 0

JPEG image format
by Greg Couch 24 Apr '04

24 Apr '04

I hate to suggest this, but we should consider dropping support for the JPEG image format to avoid liability due to possible patent infringement. We can reinstate JPEG support in 2007 after the patent expires. See <http://www.eweek.com/article2/0,1759,1572333,00.asp>. I agree that it is not likely that we will be sued, but the patent is now owned by a IP company (read lawyer owned and operated), so why take the risk. - Greg

3 2