From riccardodesantis at fastwebnet.it Tue May 4 23:19:24 2004 From: riccardodesantis at fastwebnet.it (riccardodesantis at fastwebnet.it) Date: Wed, 5 May 2004 08:19:24 +0200 Subject: [Chimera-users] Message-ID: <4096D87D00002199@ms003msg.mail.fw> Hallo, my name is Riccardo De Santis, and I'm a new user of CHIMERA. I'd like to know how to use the program in command line mode. I noticed that there is a NOGUI option, I tryed it but unsuccessfully. Cuold you help me , please? Thank you in advance, Riccardo De Santis. From riccardodesantis at fastwebnet.it Tue May 4 23:38:36 2004 From: riccardodesantis at fastwebnet.it (riccardodesantis at fastwebnet.it) Date: Wed, 5 May 2004 08:38:36 +0200 Subject: [Chimera-users] Message-ID: <4096D87D000021CE@ms003msg.mail.fw> Hallo, my name is Riccardo De Santis and I'm a new user of CHIMERA. I'd like to know how run the program from the command line. I've tryed with the command NOGUI but the program doesn't start. Another question is: how can I use matchmaker (in the graphic menu) to match the molecules from the command line? Which is the istruction to type? Thank you in advance, Riccardo De Santis. From pett at cgl.ucsf.edu Wed May 5 15:18:24 2004 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Wed, 5 May 2004 15:18:24 -0700 Subject: [Chimera-users] In-Reply-To: <4096D87D000021CE@ms003msg.mail.fw> Message-ID: <1FE42B86-9EE2-11D8-A7D2-000393CD9B40@cgl.ucsf.edu> On Tuesday, May 4, 2004, at 11:38 PM, riccardodesantis at fastwebnet.it wrote: > Hallo, > my name is Riccardo De Santis and I'm a new user of CHIMERA. > I'd like to know how run the program from the command line. > I've tryed with the command NOGUI but the program doesn't start. > Another question is: how can I use matchmaker (in the graphic menu) to > match > the molecules from the command line? Which is the istruction to type? > Thank you in advance, > Riccardo De Santis. Hi Riccardo, Unlike Chimera's predecessor Midas, running Chimera in nogui mode ("chimera --nogui") doesn't expect or allow commands on standard input (e.g. typing in the shell window). Instead, you use one or more file name arguments on the "chimera --nogui" command line to have Chimera execute the commands you want. When you say that "the program doesn't start ", I'm guessing you ran "chimera --nogui" with no file name arguments, which resulted in Chimera exiting since it had no files to process. You can put normal Chimera commands in a file and have Chimera execute those. Such files should either end in ".cmd" or ".com" or be prefixed with "cmd:" or "com:" on the Chimera startup command line. So if you have such a file named "make_alignment" with Chimera commands you want executed then "chimera --nogui cmd:make_alignment" would execute it. You can do the same with files of Python code, ending such files in ".py" or prefixing them with "python:". As for MatchMaker, right now it is too closely tied to the GUI dialog to be called from nogui mode. I will work on disassociating the underlying computation from the graphical interface so that it can become a command-line command. The hydrogen-bond finder has recently been given this kind of treatment and is callable from the command line in the release we will be making later this week. I'll send mail when the same is true for MatchMaker. It is possible to "remote control" MatchMaker in GUI mode, so that as long as a window system is available, you could write scripts that automate MatchMaker functions. They just can't be run in nogui mode. But they can be run in an analogous manner to the above (e.g. "chimera python:make_alignment") -- it's just that windows and so forth will pop up until Chimera finishes. If you would want to do this, let me know and I can send more details. Eric Pettersen UCSF Computer Graphics Lab pett at cgl.ucsf.edu http://www.cgl.ucsf.edu From jsmith at structbio.vanderbilt.edu Wed May 12 15:26:29 2004 From: jsmith at structbio.vanderbilt.edu (Jarrod Smith) Date: Wed, 12 May 2004 17:26:29 -0500 (CDT) Subject: [Chimera-users] rainbow command with sub-models Message-ID: Hello all, Is it possible to add a new "level" to the rainbow command such that each submodel of a multi-model PDB file (MODEL/ENDMDL records) can be visited separately by the rainbow command? I have some pdb files with several tens to hundreds of submodels in them. Separating them by chain ID (so I can use the rainbow chains command) has proven to be impractical for other reasons, so this would be useful in such a case. Thanks for the great software. Jarrod Smith -- Jarrod A. Smith, Ph.D. Asst. Director, Center for Structural Biology Research Asst. Professor, Biochemistry Vanderbilt University 203 processes: 140 sleeping, 63 running From pett at cgl.ucsf.edu Wed May 12 16:17:31 2004 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Wed, 12 May 2004 16:17:31 -0700 Subject: [Chimera-users] rainbow command with sub-models In-Reply-To: Message-ID: <8B2E8058-A46A-11D8-9379-000393CD9B40@cgl.ucsf.edu> Hi Jarrod, So that I'm sure I'm understanding your request, let me rephrase it: you want each submodel to have a single color, with the submodel colors composing a rainbow from first submodel to last. Is this correct? If so, I don't think it will be too hard to implement. Eric Pettersen UCSF Computer Graphics Lab pett at cgl.ucsf.edu http://www.cgl.ucsf.edu On Wednesday, May 12, 2004, at 03:26 PM, Jarrod Smith wrote: > Hello all, > > Is it possible to add a new "level" to the rainbow command such that > each > submodel of a multi-model PDB file (MODEL/ENDMDL records) can be > visited > separately by the rainbow command? I have some pdb files with several > tens to hundreds of submodels in them. Separating them by chain ID > (so I > can use the rainbow chains command) has proven to be impractical for > other > reasons, so this would be useful in such a case. > > Thanks for the great software. > > Jarrod Smith > > -- > Jarrod A. Smith, Ph.D. > Asst. Director, Center for Structural Biology > Research Asst. Professor, Biochemistry > Vanderbilt University > > 203 processes: 140 sleeping, 63 running > _______________________________________________ > Chimera-users mailing list > Chimera-users at cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > From jsmith at structbio.vanderbilt.edu Wed May 12 17:29:56 2004 From: jsmith at structbio.vanderbilt.edu (Jarrod Smith) Date: Wed, 12 May 2004 19:29:56 -0500 (CDT) Subject: [Chimera-users] rainbow command with sub-models In-Reply-To: <8B2E8058-A46A-11D8-9379-000393CD9B40@cgl.ucsf.edu> References: <8B2E8058-A46A-11D8-9379-000393CD9B40@cgl.ucsf.edu> Message-ID: On Wed, 12 May 2004, Eric Pettersen wrote: > Hi Jarrod, > So that I'm sure I'm understanding your request, let me rephrase it: > you want each submodel to have a single color, with the submodel colors > composing a rainbow from first submodel to last. Is this correct? > If so, I don't think it will be too hard to implement. Yes, that is what I was asking. Thanks for considering this feature request. Jarrod From pett at cgl.ucsf.edu Fri May 14 11:37:04 2004 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Fri, 14 May 2004 11:37:04 -0700 Subject: [Chimera-users] new Chimera production release Message-ID: Hi all, A new Chimera production release (version 1.1951) is now available for download. I've summarized the major additions since the last snapshot (1.1917) below. A list of all the changes since the last production release (1.1872) is in the release notes: http://www.cgl.ucsf.edu/chimera/docs/relnotes/1.1951.html Eric Pettersen UCSF Computer Graphics Lab pett at cgl.ucsf.edu http://www.cgl.ucsf.edu Changes since 1.1917: General changes --------------- Newly opened models are shown larger (as well as models after a 'window' or 'focus' command) Selections can be written out as parsable text files (Actions->Write... or from the Selection Inspector) New residue attributes: kdHydrophobicity (Kyte-Doolittle hydropathy, amino acids only) mavPercentConserved (% conserved in a sequence alignment open in Multalign Viewer) above for use with Render/Select by attribute tools Double-picking a bond brings up a menu with Rotate Bond and Select Bonded (the latter is new and selects the atoms); double-picking a pseudobond bring up a menu with just Select Bonded; "select bonded" also now in Pseudobond Panel As much as possible, can handle PDB files with 100000+ atoms (e.g. AMBER output). Some PDB records (e.g. CONECT records) have no room for 6-digit atom serial numbers, so only can be used for the first 99,999 atoms. A new tutorial describing preparing images for publication Select by Attribute Value... in Selection menu and Model Panel New Tools --------- Lighting (Viewing Parameters): change and save lighting parameters Color Secondary Structure (Graphics): color peptides/proteins by secondary structure Render Attributes (Graphics): color or otherwise change atom, residue, or model displays based on attribute values; was in 1.1917 release but several changes have been made and documentation added Demo (its own category; entries are individual demos): create/replay demos in Chimera; example demo included (Cyclooxygenase) Tool Changes ------------ Adjust Torsions now allows a bond to be rotated with mouse motions in the graphics window Movie has File->Save PDB for writing out either the current frame or all frames that have been viewed Multalign Viewer: ClustalX-style residue letter coloring added and made the default; can save alignment depiction as an EPS file; can hide Consensus and/or Conservation lines RibbonStyleEditor now has two panels in which scalings and cross-sections can be defined and named; named cross-section are analogous to the built-in cross-sections (flat, edged, round) and can be accessed from the Actions menu or with ribrepr; nucleic acids are now treated separately in the scalings panel New "Graphics" category; Per-Model Clipping, PipesAndPlanks, ResProp, and Ribbon Style Editor moved into it SimpleSession saves lighting, ribbon scaling and cross-section(s), B-factor and occupancy values Web Data asks for confirmation before accepting certain files; associated option in Preferences Command Changes --------------- alias: $1, $2, $3, ... may be used to indicate the first, second, third... arguments of the alias conic: works on Windows, and the -s flag now works on Linux (besides Mac, SGI) write: has "trajectory" keyword to write all frames that have been viewed (loaded) [analogous option added to Model Panel's "write PDB" dialog] ribbackbone: now applies to nucleic acids also From pett at cgl.ucsf.edu Wed May 19 13:41:44 2004 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Wed, 19 May 2004 13:41:44 -0700 Subject: [Chimera-users] rainbow command with sub-models In-Reply-To: Message-ID: Hi again, I have implemented the rainbow-across-models feature and could send you the modified Python files to drop into your 1.1951 installation if you wanted it right away. Otherwise, they will be included in our next release, which we're guesstimating to be in about a month. --Eric On Wednesday, May 12, 2004, at 05:29 PM, Jarrod Smith wrote: > On Wed, 12 May 2004, Eric Pettersen wrote: > >> Hi Jarrod, >> So that I'm sure I'm understanding your request, let me rephrase it: >> you want each submodel to have a single color, with the submodel >> colors >> composing a rainbow from first submodel to last. Is this correct? >> If so, I don't think it will be too hard to implement. > > Yes, that is what I was asking. Thanks for considering this feature > request. > > Jarrod > _______________________________________________ > Chimera-users mailing list > Chimera-users at cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users From jsmith at structbio.vanderbilt.edu Wed May 19 15:03:13 2004 From: jsmith at structbio.vanderbilt.edu (Jarrod Smith) Date: Wed, 19 May 2004 17:03:13 -0500 (CDT) Subject: [Chimera-users] rainbow command with sub-models In-Reply-To: References: Message-ID: Hi Eric, I could use this right away if it is not too much trouble to send the files. Thanks! Jarrod Smith On Wed, 19 May 2004, Eric Pettersen wrote: > Hi again, > I have implemented the rainbow-across-models feature and could send > you the modified Python files to drop into your 1.1951 installation if > you wanted it right away. Otherwise, they will be included in our next > release, which we're guesstimating to be in about a month. From emma at compbio.berkeley.edu Thu May 20 09:01:08 2004 From: emma at compbio.berkeley.edu (Emma Hill) Date: Thu, 20 May 2004 09:01:08 -0700 Subject: [Chimera-users] Color blending on ribbons Message-ID: <40ACD644.90702@compbio.berkeley.edu> Hi, I wondered if there is any easy way to blend colors from one residue to the next on a ribbon chain (as in the rainbow facility.) I want to be able to precisely define where this takes place (ie whenever I switch from one color to another) - more specifically I am coloring different regions of a superimposed pair to show where is aligned and where is not, and the drastic switch from one color to the next would definitely look better more blended. Thanks in advance Emma -- Emma Hill Brenner Research Lab U.C. Berkeley From heiland at indiana.edu Thu May 20 10:31:48 2004 From: heiland at indiana.edu (Randy Heiland) Date: Thu, 20 May 2004 12:31:48 -0500 Subject: [Chimera-users] non-GUI use of Chimera Message-ID: <003801c43e90$54a4b670$0728fea9@escher> I am evaluating Chimera as a tool for providing (pseudo-interactive) vis functionality from a web server and therefore would like to use it in a non-gui mode. I saw the earlier post/reply to this list (May 4) on this topic, and Eric indicated that one way to do this was to put all your cmds in a file then run "chimera --nogui ". Obviously this isn't ideal for my purposes. So, I'm wondering what the alternatives are? I'm a newbie to Chimera, but I've read how it was based on Midas, and so I decided to see how far I could get in reading in a pdb file and... I didn't get very far: (after install Chimera (Linux, beta 1 build 1951), plus dependent Python pkgs) %python >>> import chimera >>> import Midas >>> f=Midas.open('foo.pdb') and I get an error about 'missing default material' and realize I'm doing the wrong thing anyway. Basic question: can I, from the Python interpreter, use Chimera/Midas to read in a pdb file and do basic Chimera functionality? For now, I don't even care if it assumes X is running and pops up windows. Thanks, Randy From dan at cgl.ucsf.edu Thu May 20 11:58:34 2004 From: dan at cgl.ucsf.edu (Daniel Greenblatt) Date: Thu, 20 May 2004 11:58:34 -0700 (PDT) Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <003801c43e90$54a4b670$0728fea9@escher> References: <003801c43e90$54a4b670$0728fea9@escher> Message-ID: Hi Randy, > I am evaluating Chimera as a tool for providing (pseudo-interactive) vis > functionality from a web server and therefore would like to use it in a > non-gui mode. I'm not completely clear on what you mean by this. Exactly what type of functionality do you want to provide? Do you plan on using Chimera on the server-side, or client-side? There are several different [potential] solutions here, depending on what it is you want to do: (1) Chimera as a web-browser client A locally installed copy of Chimera can be used as a web browser 'helper application', responding to certain links clicked on in a web browser. These links contatin information about files to open, and commands or python code to execute in Chimera (Chimera runs in its own window -- not embedded in the browser). See http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/webdata/webdata.html for more information. (2) The IDLE interpreter Currently, the only way to access Chimera's Python API in an interactive fashion is through the IDLE window (Tools->Programming->IDLE) from within Chimera. This, of course, requires having Chimera running in normal (i.e. not 'nogui') mode. If there is sufficient demand, we may include an 'interactive nogui' mode, that gives you access from the shell. (3) chimera --nogui As you already know, Chimera can be started with the '--nogui' flag, which doesn't bring up any graphics windows, and is used mainly for carrying out molecular calculations. Since there is no graphics window, it is not possible to do any visualization (including saving images). This sounds like an interesting problem - please let us know if any of these solutions are appropriate, or require further explanation. --Dan Greenblatt ---------------------------- Daniel Greenblatt UCSF Computer Graphics Lab dan at cgl.ucsf.edu From heiland at indiana.edu Thu May 20 12:21:56 2004 From: heiland at indiana.edu (Randy Heiland) Date: Thu, 20 May 2004 14:21:56 -0500 Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: Message-ID: <004801c43e9f$b77692a0$0728fea9@escher> Thanks for the reply Dan. Yes, I was familiar with the 3 options you describe and none of them really do what I want, although, I guess, the 'interactive nogui' mode you hinted at would be closest. In short, I'd like server-side Chimera functionality; I don't want users to have to download/install Chimera. --Randy > -----Original Message----- > From: Daniel Greenblatt [mailto:dan at cgl.ucsf.edu] > Sent: Thursday, May 20, 2004 1:59 PM > To: Randy Heiland > Cc: chimera-users at cgl.ucsf.edu > Subject: Re: [Chimera-users] non-GUI use of Chimera > > Hi Randy, > > > I am evaluating Chimera as a tool for providing (pseudo-interactive) vis > > functionality from a web server and therefore would like to use it in a > > non-gui mode. > > I'm not completely clear on what you mean by this. > Exactly what type of functionality do you want to provide? > Do you plan on using Chimera on the server-side, or client-side? > > There are several different [potential] solutions here, depending on > what it is you want to do: > > (1) Chimera as a web-browser client > A locally installed copy of Chimera can be used as a > web browser 'helper application', responding to certain > links clicked on in a web browser. These links contatin information > about files to open, and commands or python code to execute in > Chimera (Chimera runs in its own window -- not embedded in the > browser). > See > > http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/webdata/webdata .h > tml > for more information. > > (2) The IDLE interpreter > Currently, the only way to access Chimera's Python API in an > interactive fashion is through the IDLE window > (Tools->Programming->IDLE) from within Chimera. This, of > course, requires having Chimera running in normal (i.e. not 'nogui') > mode. If there is sufficient demand, we may include an 'interactive > nogui' mode, that gives you access from the shell. > > (3) chimera --nogui > As you already know, Chimera can be started with the '--nogui' flag, > which doesn't bring up any graphics windows, and is used mainly for > carrying out molecular calculations. Since there is no graphics window, > it is not possible to do any visualization (including saving images). > > This sounds like an interesting problem - please let us know if any of > these solutions are appropriate, or require further explanation. > > > --Dan Greenblatt > > > ---------------------------- > Daniel Greenblatt > UCSF Computer Graphics Lab > dan at cgl.ucsf.edu > From dan at cgl.ucsf.edu Thu May 20 12:58:23 2004 From: dan at cgl.ucsf.edu (Daniel Greenblatt) Date: Thu, 20 May 2004 12:58:23 -0700 (PDT) Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <004801c43e9f$b77692a0$0728fea9@escher> References: <004801c43e9f$b77692a0$0728fea9@escher> Message-ID: Do you need access to graphics, or just the data ? What are some intended scenarios ? It would take some work, but would certainly be possible to provide the kind of access you need from a shell. This is an idea we have considered before, and it is good to know that there is a demand for it. --Dan ---------------------------- Daniel Greenblatt UCSF Computer Graphics Lab dan at cgl.ucsf.edu On Thu, 20 May 2004, Randy Heiland wrote: > Date: Thu, 20 May 2004 14:21:56 -0500 > From: Randy Heiland > To: 'Daniel Greenblatt' > Cc: chimera-users at cgl.ucsf.edu > Subject: RE: [Chimera-users] non-GUI use of Chimera > > Thanks for the reply Dan. Yes, I was familiar with the 3 options you > describe and none of them really do what I want, although, I guess, the > 'interactive nogui' mode you hinted at would be closest. In short, I'd > like server-side Chimera functionality; I don't want users to have to > download/install Chimera. > > --Randy > >> -----Original Message----- >> From: Daniel Greenblatt [mailto:dan at cgl.ucsf.edu] >> Sent: Thursday, May 20, 2004 1:59 PM >> To: Randy Heiland >> Cc: chimera-users at cgl.ucsf.edu >> Subject: Re: [Chimera-users] non-GUI use of Chimera >> >> Hi Randy, >> >>> I am evaluating Chimera as a tool for providing (pseudo-interactive) > vis >>> functionality from a web server and therefore would like to use it > in a >>> non-gui mode. >> >> I'm not completely clear on what you mean by this. >> Exactly what type of functionality do you want to provide? >> Do you plan on using Chimera on the server-side, or client-side? >> >> There are several different [potential] solutions here, depending on >> what it is you want to do: >> >> (1) Chimera as a web-browser client >> A locally installed copy of Chimera can be used as a >> web browser 'helper application', responding to certain >> links clicked on in a web browser. These links contatin information >> about files to open, and commands or python code to execute in >> Chimera (Chimera runs in its own window -- not embedded in the >> browser). >> See >> >> > http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/webdata/webdata > .h >> tml >> for more information. >> >> (2) The IDLE interpreter >> Currently, the only way to access Chimera's Python API in an >> interactive fashion is through the IDLE window >> (Tools->Programming->IDLE) from within Chimera. This, of >> course, requires having Chimera running in normal (i.e. not > 'nogui') >> mode. If there is sufficient demand, we may include an 'interactive >> nogui' mode, that gives you access from the shell. >> >> (3) chimera --nogui >> As you already know, Chimera can be started with the '--nogui' > flag, >> which doesn't bring up any graphics windows, and is used mainly for >> carrying out molecular calculations. Since there is no graphics > window, >> it is not possible to do any visualization (including saving > images). >> >> This sounds like an interesting problem - please let us know if any of >> these solutions are appropriate, or require further explanation. >> >> >> --Dan Greenblatt >> >> >> ---------------------------- >> Daniel Greenblatt >> UCSF Computer Graphics Lab >> dan at cgl.ucsf.edu >> > > > From gregc at cgl.ucsf.edu Thu May 20 16:13:13 2004 From: gregc at cgl.ucsf.edu (Greg Couch) Date: Thu, 20 May 2004 16:13:13 -0700 (PDT) Subject: [Chimera-users] Color blending on ribbons In-Reply-To: <40ACD644.90702@compbio.berkeley.edu> References: <40ACD644.90702@compbio.berkeley.edu> Message-ID: On Thu, 20 May 2004, Emma Hill wrote: > I wondered if there is any easy way to blend colors from one residue to the > next on a ribbon chain (as in the rainbow facility.) I want to be able to > precisely define where this takes place (ie whenever I switch from one color > to another) - more specifically I am coloring different regions of a > superimposed pair to show where is aligned and where is not, and the drastic > switch from one color to the next would definitely look better more blended. Hi Emma, Although the answer is no, you can't do it with the current version of chimera, it would be possible. There are issues of how to do the color blending (i.e., which color space) and how big the transition area should be. I'll file it as a bug and you'll get email when we fix it (may be a long while though). - Greg From sabuj.pattanayek at Vanderbilt.Edu Fri May 21 16:07:30 2004 From: sabuj.pattanayek at Vanderbilt.Edu (Pattanayek, Sabuj) Date: Fri, 21 May 2004 18:07:30 -0500 Subject: [Chimera-users] vrml 2.0 export of pdb representation Message-ID: <1085180850.40ae8bb2c6904@vuwebmail.vanderbilt.edu> Hi, Is there anyway to export a pdb model into vrml once I have it just the way I want it (ribbon & atom sizes, colors, etc)? I tried a pdb2vrml converter from http://www.pc.chemie.tu-darmstadt.de/research/vrml/pdb2vrml_right.shtml but freewrl crashes when loading the output (I think pdb2vrml might be outputting vrml 1.0), it's also not very versatile as far as what I want to display into vrml from the pdb. Thanks From gregc at cgl.ucsf.edu Fri May 21 17:03:01 2004 From: gregc at cgl.ucsf.edu (Greg Couch) Date: Fri, 21 May 2004 17:03:01 -0700 (PDT) Subject: [Chimera-users] vrml 2.0 export of pdb representation In-Reply-To: <1085180850.40ae8bb2c6904@vuwebmail.vanderbilt.edu> References: <1085180850.40ae8bb2c6904@vuwebmail.vanderbilt.edu> Message-ID: We currently only support VRML export of volume isosurfaces and multiscale surfaces. So the answer is no, not yet. Exporting to a 3D graphics file format is definately something we would like to do. However, it is unclear what format would be best to generate. VRML 2.0 will never support transparency like chimera does. VRML's successor, X3D, looks promising, but there aren't many users yet. Other possiblities include the Renderman format, popular with animation studios; the .3DS format, popular on PCs; and many others. So, a question for everyone reading this, if you had to pick one format, would it be VRML97? And if so, why? And if not, why not? We are leaning torwards outputing X3D, but would appreciate comments from people who would actually be using the output. Greg Couch UCSF Computer Graphics Lab gregc at cgl.ucsf.edu On Fri, 21 May 2004, Pattanayek, Sabuj wrote: > Is there anyway to export a pdb model into vrml once I have it just the way I > want it (ribbon & atom sizes, colors, etc)? I tried a pdb2vrml converter from > http://www.pc.chemie.tu-darmstadt.de/research/vrml/pdb2vrml_right.shtml but > freewrl crashes when loading the output (I think pdb2vrml might be outputting > vrml 1.0), it's also not very versatile as far as what I want to display into > vrml from the pdb. From sabuj.pattanayek at Vanderbilt.Edu Sat May 22 09:35:49 2004 From: sabuj.pattanayek at Vanderbilt.Edu (Pattanayek, Sabuj) Date: Sat, 22 May 2004 11:35:49 -0500 Subject: [Chimera-users] vrml 2.0 export of pdb representation Message-ID: <1085243748.40af8165017da@vuwebmail.vanderbilt.edu> imho, 3DS is currently more widely supported than X3D by expensive, cheap, and free 3d modellers. Most 3D format translators can convert from 3DS to other types (DXF, iv, etc). However it looks like from web3d.org that X3D is much more versatile and feature rich than old 3ds... Quoting Greg Couch : > We currently only support VRML export of volume isosurfaces and multiscale > surfaces. So the answer is no, not yet. > > Exporting to a 3D graphics file format is definately something we would > like to do. However, it is unclear what format would be best to generate. > VRML 2.0 will never support transparency like chimera does. VRML's > successor, X3D, looks promising, but there aren't many users yet. Other > possiblities include the Renderman format, popular with animation studios; > the .3DS format, popular on PCs; and many others. > > So, a question for everyone reading this, if you had to pick one format, > would it be VRML97? And if so, why? And if not, why not? We are leaning > torwards outputing X3D, but would appreciate comments from people who > would actually be using the output. > > Greg Couch > UCSF Computer Graphics Lab > gregc at cgl.ucsf.edu > > > On Fri, 21 May 2004, Pattanayek, Sabuj wrote: > > > Is there anyway to export a pdb model into vrml once I have it just the way > I > > want it (ribbon & atom sizes, colors, etc)? I tried a pdb2vrml converter > from > > http://www.pc.chemie.tu-darmstadt.de/research/vrml/pdb2vrml_right.shtml > but > > freewrl crashes when loading the output (I think pdb2vrml might be > outputting > > vrml 1.0), it's also not very versatile as far as what I want to display > into > > vrml from the pdb. > From goddard at cgl.ucsf.edu Mon May 24 16:19:55 2004 From: goddard at cgl.ucsf.edu (Thomas Goddard) Date: Mon, 24 May 2004 16:19:55 -0700 (PDT) Subject: [Chimera-users] non-GUI use of Chimera Message-ID: <200405242319.i4ONJt221965010@guanine.cgl.ucsf.edu> Hi Randy, If I understand correctly you want to be able to type some Chimera Python code or Chimera commands to a web browser, those get sent to the web server which sends them to Chimera running on the web server machine. Then you capture the Chimera image and send it back to the web browser. I believe this can be done using the Chimera "Web Data" facility. This allows programs to send commands to Chimera. The intended use is for displaying models in Chimera when the user clicks a link in a web browser. It works by having the *.chimerax file associated with the link lauch helper application /bin/chimera_send. The same mechanism allows any program to send commands to Chimera. The Chimera User's Guide describes this under Tools/Web Browser Configuration. Here's a URL: http://www.cgl.ucsf.edu/chimera/1.1951/docs/ContributedSoftware/webdata/chimerax.html What you might do is have your web server create an appropriate *.chimerax that executes the user's commands and then prints the Chimera graphics window to a file. The web server than sends the image (jpg) to the web client. There is a bunch of somewhat tricky glue to make this work. As previous posts mentioned, Chimera will need to pop up windows on some screen to render an image. For the web server to know when Chimera has finished making an image, the *.chimerax file might end in a command that writes to some secondary status file after the image file is written. That will tell the web server that the image is ready. We haven't tried this. And there are other pitfalls, like you are likely to run into trouble if the web server starts 2 instances of Chimera and then tries to dispatch commands with the chimera_send program. Please let me know if you get this to work. Feel free to send additional questions. Tom From procter at zbh.uni-hamburg.de Tue May 25 01:27:53 2004 From: procter at zbh.uni-hamburg.de (J B Procter) Date: Tue, 25 May 2004 10:27:53 +0200 Subject: [Chimera-users] vrml 2.0 export of pdb representation In-Reply-To: References: <1085180850.40ae8bb2c6904@vuwebmail.vanderbilt.edu> Message-ID: <20040525102753.4b8aa741.procter@zbh.uni-hamburg.de> I just thought I'd add my two-cents worth to the VRML issue: > We currently only support VRML export of volume isosurfaces and > multiscale surfaces. So the answer is no, not yet. Bizarrely, (and irrelevantly) from my experience chimera actually provides one of the faster VRML rendering solutions for Linux. Whilst it does not have all of the interaction models available to VRML2/97 or X3D, it might be a good basis for them. But this is a digression, only relevant because of the serious lack of a high-performance 3d world browser on that platform. > Exporting to a 3D graphics file format is definately something we > would like to do. However, it is unclear what format would be best to > generate. VRML 2.0 will never support transparency like chimera does. > VRML's successor, X3D, looks promising, but there aren't many users > yet. Other possiblities include the Renderman format, popular with > animation studios; the .3DS format, popular on PCs; and many others. Format issues are difficult - 3DS is popular because it's one of the older modelling systems. As such, there are a whole heap of conversion programs between it and other formats (afair). Another point against 3DS is that of the limitations with a geometry/scene description form like it (iirc) is that it does *not* support the so-called 'rich media' interaction forms that VRML2/97 was devised for (although proteins probably don't call for immersive world properties like mpeg-movie nodes and proximal sound effects). > So, a question for everyone reading this, if you had to pick one > format, would it be VRML97? And if so, why? And if not, why not? We > are leaning torwards outputing X3D, but would appreciate comments from > people who would actually be using the output. My answer in short is to go for X3D output - but make sure that at least one 3D-browser on each platform actually supports all the bells and whistles that chimera's X3D flavour contains, and that at least one script exists to translate the XML into a generic VRML97 form. Producing X3D should be easier than generating VRML97, not least because of the use of standard XML tools. Secondly, dumbing-down the X3D form to read like VRML shouldn't be too hard (except perhaps when it comes to annoying things like complex NURB surfaces, but I've never got those to work right in every browser anyhow :-( ). The downside of using X3D is that it still exists as a 'reference implementation' for the generic successor to VRML97 (which is basically not developed anymore). There was precious little observable progress in the last two years, however, although the x3d website is now looking rather smarter than it did a year ago. I've had good experiences with using the java3D implementation of x3d, but freeWRL and a few others which claimed support tended not to work anywhere near as well. This has hopefully changed in the last 6 months, but the various coding projects may suffer from the same lack of progress that the 3D modelling scene suffers from (perhaps because all the workers became serious 3D-animator/developers for film-studios ;-). Finally, some more concrete points : . Static 3D scene files require lots of effort to get right This is why 3ds still makes money - the user interface for 'denovo' modelling is very important. Arguably the most straightforward approach to static scene generation is WYSIWYG, which is easily achievable given the underlying object engine used in chimera. * This is exactly what the first post asked for. . The power of 3D environments is that they are spatial This is a double edged sword - 'flythroughs' were great for coorporate demos (apparently) but quite useless when you actually want to look at specific parts of a model. Generally, users need some guidance information in the scenes - particularly for collaborative apps. The standard ways of doing this is by having multiple viewpoints built in to the scenegraph, and providing annotation, that can also be hidden. Essentially, its possible to write books about the kind of features necessary for effective stand-alone 3D visualizations - and people have. Static scene generation should be a first goal - and chimera's scene model doesn't need much modification. But, if the X3d (or even vrml 1's) form is to be used seriously, the chimera viewing model needs to be made 'stateful'. That is, there can be many independent instances of a particular view (position,scale,focal-length, rendering styles, etc) onto the same set of coordinates, and these can be switched between, stored and browsed at will. I hope all the extraneous discussion makes sense - obviously it will make me really happy if chimera's 3d exporting is improved in any way, x3d support seems the most obvious because there are no other open formats which come close and still have an active development community. cheers :-) j. _______________________________________________________________________ Dr JB Procter:Biomolecular Modelling at ZBH - Center for Bioinformatics Hamburg http://www.zbh.uni-hamburg.de/staff.php From cmoad at indiana.edu Tue May 25 11:59:57 2004 From: cmoad at indiana.edu (Charles Moad) Date: Tue, 25 May 2004 13:59:57 -0500 Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <000301c44252$f92ca2a0$0300a8c0@escher> References: <000301c44252$f92ca2a0$0300a8c0@escher> Message-ID: <40B397AD.9040007@indiana.edu> Hi, I am working with Randy on this, and I think we have a web service type solution that will work using your suggestions. The one problem that remains is killing chimera after a request. The webdata facility is targeted to run on a client's machine where a user quits chimera, but we will be running it on the server. I tried adding the 'stop' command at the end of the chimerax file, but I received an error from chimera and it continued to run. Same story for 'sys.exit()' Running the chimera_send script a second time only opens a new instance of chimera which also remains open. Is there a way to attach chimera_send to an existing process of chimera, or have chimera quit at the end of a chimera_send call? Thanks, Charlie > -----Original Message----- > From: chimera-users-bounces at cgl.ucsf.edu > [mailto:chimera-users-bounces at cgl.ucsf.edu] On Behalf Of Thomas Goddard > Sent: Monday, May 24, 2004 6:20 PM > To: heiland at indiana.edju > Cc: chimera-users at cgl.ucsf.edu > Subject: [Chimera-users] non-GUI use of Chimera > > Hi Randy, > > If I understand correctly you want to be able to type some Chimera > Python > code or Chimera commands to a web browser, those get sent to the web > server > which sends them to Chimera running on the web server machine. Then you > capture the Chimera image and send it back to the web browser. > > I believe this can be done using the Chimera "Web Data" facility. > This > allows programs to send commands to Chimera. The intended use is for > displaying models in Chimera when the user clicks a link in a web > browser. > It works by having the *.chimerax file associated with the link lauch > helper application /bin/chimera_send. > The same mechanism allows any program to send commands to Chimera. > The Chimera User's Guide describes this under Tools/Web Browser > Configuration. > Here's a URL: > > > http://www.cgl.ucsf.edu/chimera/1.1951/docs/ContributedSoftware/webdata/ > chimerax.html > > What you might do is have your web server create an appropriate > *.chimerax that executes the user's commands and then prints the > Chimera graphics window to a file. The web server than sends the > image (jpg) to the web client. There is a bunch of somewhat tricky > glue to make this work. As previous posts mentioned, Chimera will > need to pop up windows on some screen to render an image. For the web > server to know when Chimera has finished making an image, the > *.chimerax file might end in a command that writes to some secondary > status file after the image file is written. That will tell the web > server that the image is ready. > > We haven't tried this. And there are other pitfalls, like you are > likely to run into trouble if the web server starts 2 instances of > Chimera > and then tries to dispatch commands with the chimera_send program. > > Please let me know if you get this to work. Feel free to send > additional > questions. > > Tom > _______________________________________________ > Chimera-users mailing list > Chimera-users at cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > > > > From goddard at cgl.ucsf.edu Tue May 25 13:12:34 2004 From: goddard at cgl.ucsf.edu (Thomas Goddard) Date: Tue, 25 May 2004 13:12:34 -0700 (PDT) Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <40B397AD.9040007@indiana.edu> (message from Charles Moad on Tue, 25 May 2004 13:59:57 -0500) References: <000301c44252$f92ca2a0$0300a8c0@escher> <40B397AD.9040007@indiana.edu> Message-ID: <200405252012.i4PKCYpK1771058@guanine.cgl.ucsf.edu> Hi Charlie, You should be able to use sys.exit() in a *.chimerax script to quit Chimera. The sys.exit() call raises SystemExit. Unfortunately the code that runs the *.chimerax file is catching the SystemExit. This is a bug in Chimera 1951 that we will fix. For now you can use "import os" and "os._exit(0)". The chimera_send script will start a new Chimera if it does not find one already running that is accepting connections. By default Chimera does not accept connections. The easiest way to change this is to start Chimera by hand and use Favorites/Preferences/Web Data to turn on "Accept Web Data". Then press the Preferences Save button to save this setting in the user's Chimera preferences file (~/.chimera/preferences). (Note you'll need to do this as the user that Chimera runs with from the web server.) You can also change the "Confirm open of commands or code" preference to "never". This will prevent the Chimera warning dialog asking whether you really want to execute the *.chimerax file. You can also save this setting. Making these settings may pose a serious security risk. There are mechanisms to allow only the same user that is running Chimera to run *.chimerax files but I do not know how strong the security is. Dan Greenblatt (dan at cgl.ucsf.edu) wrote the code and would know. As it works now, if you wish to send commands to an already running Chimera, you cannot specify which instance of Chimera. So it is not possible to communicate with multiple instances of Chimera as you might want to support multiple web sessions. Dan Greenblatt may have ideas for addressing this. Tom From cmoad at indiana.edu Tue May 25 13:43:58 2004 From: cmoad at indiana.edu (Charles Moad) Date: Tue, 25 May 2004 15:43:58 -0500 Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <200405252012.i4PKCYpK1771058@guanine.cgl.ucsf.edu> References: <000301c44252$f92ca2a0$0300a8c0@escher> <40B397AD.9040007@indiana.edu> <200405252012.i4PKCYpK1771058@guanine.cgl.ucsf.edu> Message-ID: <40B3B00E.6050307@indiana.edu> We do not need the ability to issue requests to a specific instance of chimera. I changed the preferences and I was having new instances of chimera appear for each request, but that changed after restarting chimera. The current solution we are using involves the following. You open a web page which is a python/cgi script that prompts for input. Using SOAPpy, we issue a call to a web service function to do the rendering. The SOAP response is a pointer to the image url. The SOAP server just generates a chimerax file based on the request and spawns a chimera_send process. Other than the fact that we must have chimera attached to an Xserver everything works really well. Thanks, Charlie Thomas Goddard wrote: > Hi Charlie, > > You should be able to use sys.exit() in a *.chimerax script to quit Chimera. > The sys.exit() call raises SystemExit. Unfortunately the code that runs the > *.chimerax file is catching the SystemExit. This is a bug in Chimera 1951 > that we will fix. For now you can use "import os" and "os._exit(0)". > > The chimera_send script will start a new Chimera if it does not find > one already running that is accepting connections. By default Chimera > does not accept connections. The easiest way to change this is to > start Chimera by hand and use Favorites/Preferences/Web Data to turn > on "Accept Web Data". Then press the Preferences Save button to save > this setting in the user's Chimera preferences file > (~/.chimera/preferences). (Note you'll need to do this as the user > that Chimera runs with from the web server.) You can also change the > "Confirm open of commands or code" preference to "never". This will > prevent the Chimera warning dialog asking whether you really want to > execute the *.chimerax file. You can also save this setting. > Making these settings may pose a serious security risk. There are > mechanisms to allow only the same user that is running Chimera to > run *.chimerax files but I do not know how strong the security is. > Dan Greenblatt (dan at cgl.ucsf.edu) wrote the code and would know. > > As it works now, if you wish to send commands to an already running > Chimera, you cannot specify which instance of Chimera. So it is not > possible to communicate with multiple instances of Chimera as you might > want to support multiple web sessions. Dan Greenblatt may have ideas > for addressing this. > > Tom > > From goddard at cgl.ucsf.edu Tue May 25 13:58:00 2004 From: goddard at cgl.ucsf.edu (Thomas Goddard) Date: Tue, 25 May 2004 13:58:00 -0700 (PDT) Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <40B3B00E.6050307@indiana.edu> (message from Charles Moad on Tue, 25 May 2004 15:43:58 -0500) References: <000301c44252$f92ca2a0$0300a8c0@escher> <40B397AD.9040007@indiana.edu> <200405252012.i4PKCYpK1771058@guanine.cgl.ucsf.edu> <40B3B00E.6050307@indiana.edu> Message-ID: <200405252058.i4PKw0ax1786633@guanine.cgl.ucsf.edu> Hi Charlie, Can I try your Chimera web interface? It's a neat idea that we may have other uses for. I don't understand how your web server can handle multiple simultaneous requests that require Chimera rendering. If you send the requests to one instance of Chimera that you keep running it is possible that a request will get received in the middle of processing some earlier request causing havoc. Tom From dan at cgl.ucsf.edu Tue May 25 14:34:03 2004 From: dan at cgl.ucsf.edu (Daniel Greenblatt) Date: Tue, 25 May 2004 14:34:03 -0700 Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <200405252058.i4PKw0ax1786633@guanine.cgl.ucsf.edu> Message-ID: <3E674D8C-AE93-11D8-8C5A-000393AEA5E8@cgl.ucsf.edu> Hi Charles, If you do want to support multiple users and simultaneously running instances of Chimera, you'd need to control who gets the request coming from the chimera_send script. To do this, you'd need to dynamically rewrite the 'rendezvous' file where chimera_send looks to see who's listening. This is located usually in /tmp/chim_webinfo- where is the name of the user running Chimera (from the USER environment variable). This file is only in existence while there is an instance of Chimera running on the machine, and it is listening for data. Multiple users on the same system can be running Chimera, each user would have their own corresponding file. The file is user-read-write only. The first line contains three keys that are used for security purposes (each client attempting to send information to Chimera must correctly identify these keys), and each of the following lines contains information in the format port,pid where pid is the process id of a running Chimera, and port is the port number that that instance of Chimera is listening on. chimera_send will send the request to the most recently registered instance of Chimera, i.e. the one at the bottom of the list. So if the /tmp/chim_webinfo-cmoad file looks like: 43245,787727,838545 4576,98543 2567,98550 3879,98556 chimera_send will send the request to the instance of Chimera with pid 98556, listening on port 3879 . Note, the original intent here is for a user to have multiple instances of Chimera running on their desktop, and for them to be able to determine which Chimera will receive the file from a web browser, by raising a particular Chimera window above the others. Each time you raise a Chimera window by giving it the focus, that instance rewrites the rendezvous file to put itself first (i.e. last in the list). You could mimic this behavior programmatically by rewriting this file from the server-side CGI script depending on where the request came from. Hope this helps! -Dan On Tuesday, May 25, 2004, at 01:58 PM, Thomas Goddard wrote: > Hi Charlie, > > Can I try your Chimera web interface? It's a neat idea that we may > have other uses for. > > I don't understand how your web server can handle multiple > simultaneous > requests that require Chimera rendering. If you send the requests to > one > instance of Chimera that you keep running it is possible that a > request will > get received in the middle of processing some earlier request causing > havoc. > > Tom > _______________________________________________ > Chimera-users mailing list > Chimera-users at cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > From cmoad at indiana.edu Tue May 25 14:49:14 2004 From: cmoad at indiana.edu (Charles Moad) Date: Tue, 25 May 2004 16:49:14 -0500 Subject: [Chimera-users] non-GUI use of Chimera In-Reply-To: <200405252058.i4PKw0ax1786633@guanine.cgl.ucsf.edu> References: <000301c44252$f92ca2a0$0300a8c0@escher> <40B397AD.9040007@indiana.edu> <200405252012.i4PKCYpK1771058@guanine.cgl.ucsf.edu> <40B3B00E.6050307@indiana.edu> <200405252058.i4PKw0ax1786633@guanine.cgl.ucsf.edu> Message-ID: <5D3C354A-AE95-11D8-82A5-000393CE2FF6@indiana.edu> If I start it remotely it cannot do the on screen rendering, so I will start it in the morning and send you a link. The SOAPpy.SOAPServer that I use to handle requests only handles one at a time. I could have it spawn new processes/threads. I would think that spawning threads to handle simultaneous requests would work if you have the preferences set to not listen for web data. This would spawn new independent instances of chimera for each request. One may ask why not have the python/cgi script spawn the process directly and cut out the web service. I tried this and found out from others who have tried similar things, apache does not like to spawn new processes from the cgi-bin. They usually just return an error code. Also allowing the apache user access to the Xserver and chimera is difficult. The SOAP code is VERY simple however. - Charlie On May 25, 2004, at 3:58 PM, Thomas Goddard wrote: > Hi Charlie, > > Can I try your Chimera web interface? It's a neat idea that we may > have other uses for. > > I don't understand how your web server can handle multiple > simultaneous > requests that require Chimera rendering. If you send the requests to > one > instance of Chimera that you keep running it is possible that a > request will > get received in the middle of processing some earlier request causing > havoc. > > Tom > >