I am also having some similar issues, and pressing the Open in Coot, grays out the button, but does nothing. I have phenix installed with ./install on a Mac. I have coot 0.6.2-pre-1 (revision 2965) [with guile 1.8.6 embedded] [with python 2.6.5 embedded] and I have tried this in phenix 357. Even clicking the Coot button on Phenix Home window does nothing. The coot log window shows nothing. Sidenote: Open in Pymol does not work when opening from phenix, It gives some kind of error in phenix. I think "Open in Coot" was working previously, but I haven't found the problem. Daniel On Thu, May 27, 2010 at 1:50 PM, Nathaniel Echols wrote:

On Thu, May 27, 2010 at 11:32 AM, Ben Eisenbraun

...

wrote:

...

On Thu, May 27, 2010 at 12:31:41AM -0400, Ben Eisenbraun wrote:

...

I can't seem to get the "Open in Coot" option to work in PHENIX. I tested version 1.6.1-357 on 32 and 64-bit linux as well as the OS X Intel version, and while Coot will open, it won't display the working data.

Could this be a gtk issue of some sort?

The first thing to check is whether Coot has Python embedded ("coot --version"). If you downloaded the package(s) from Paul's website, they need to have "python" in the package name, otherwise they won't work. The only time I've seen GTK-related issues is (inconsistently) in the standalone packages on Bill Scott's webpage, and the result was that even the buttons wouldn't appear.

Does PHENIX produce some sort of log of GUI events, stderr, whatnot? Is

...

there a debugging mode that would output more information?

Yes: Utilities menu->Coot console log. Also, if you start the GUI with "--debug", all of the Coot output will be dumped to the console (and some other Phenix-specific debugging messages, but you can ignore those). This should indicate what is going wrong on the Mac version. (Which program are you running, by the way? Because the programs in Phenix all generate slightly different output, I have to write a separate function for each one for Coot, and PyMOL. . . not fun to maintain.) One other thing to try on Mac: open any program, load a PDB file, right-click on the magnifying glass icon next to the file, and select "Open in Coot". If this doesn't work, something weird is going on.

-Nat

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

-- Stop the ACTA. Row, row; fight the power! http://www.eff.org/

Hi Nat,

The first thing to check is whether Coot has Python embedded ("coot --version").

I knew about this one: /programs/l/coot/0.6.2-pre-1-r2969/bin/coot-real --version 0.6.2-pre-1 (revision 2969) [with guile 1.8.7 embedded] [with python 2.6.0 embedded]

Yes: Utilities menu->Coot console log. Also, if you start the GUI with "--debug", all of the Coot output will be dumped to the console

Ah, that's handy. So first off I see that I somehow got an older version of Coot lodged in my ~/.phenix/prefs.params file. It was pointing to a linux Coot 0.6.1 32-bit installation. I assume that will override the phenix.find_coot_command? Once I removed that, I can get our 64-bit installations of PHENIX and Coot to cooperate. On the 64-bit version I see: Coot: Running python script /programs/i386-linux/phenix/1.6.2-432/phenix-1.6.2-432/phenix/wxGUI2/Coot.py Coot: Loading PHENIX Coot extensions. . . Coot: xml-rpc server running on port 46712 And then the coot output as it reads the data files. On the 32-bit version I see: Coot: Running python script /programs/i386-linux/phenix/1.6.2-432/phenix-1.6.2-432/phenix/wxGUI2/Coot.py Coot: (use-graphics-interface-state) And the buttons and molecule are not loaded. I built the 32-bit Coot on CentOS 4 and the 64-bit Coot on CentOS 5. They're both using the autobuilder script with identical arguments, but using Paul's 32-bit CentOS build works fine, so there's definitely something gone amuck in our 32-bit build. The Mac problems appear to have cleared up when I removed the hard-coded path to the linux version of Coot in my preferences file. So everything's working as expected now. Thanks for your assistance. -ben -- | Ben Eisenbraun | Software Sysadmin | | Structural Biology Grid | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |

I have tried clicking the 'Open in Coot' and 'Open in Pymol' buttons I saw a small window saying "The .pdb file "$s" does not exist." I have not been able to get that small window to appear again. However, when clicking Open in Pymol... The Pymol window spits this. ExecutiveProcessPDBFile-Error: Unable to open file '/Volumes/RAID1/...../coot-povray.pdb'. Phenix shows this in the window. A Python error was detected. This is probably a bug; click "OK" to send a bug report to the PHENIX developers. Exception : XMLRPC error: '> Method: load_refinement Params: /Volumes/RAID1/Jeong/Phenix/PKG_CBDA/APO/Refine_1/coot-povray, False Traceback (most recent call last): File "/usr/local/phenix-1.6.1-357/phenix/wxGUI2/App.py", line 569, in OnTimer self.pymol_server.flush_requests() File "/usr/local/phenix-1.6.1-357/cctbx_project/libtbx/xmlrpc_utils.py", line 208, in flush_requests return self._server.flush_requests() File "/usr/local/phenix-1.6.1-357/cctbx_project/libtbx/xmlrpc_utils.py", line 126, in flush_requests (str(e), str(methodname), ", ".join([ str(p) for p in params ]))) Exception: XMLRPC error: '> Method: load_refinement Params: /Volumes/RAID1/Jeong/Phenix/PKG_CBDA/APO/Refine_1/coot-povray, False On Mon, Jun 14, 2010 at 4:32 PM, Nathaniel Echols wrote:

On Mon, Jun 14, 2010 at 12:20 PM, Ben Eisenbraun

...

wrote:

...

So first off I see that I somehow got an older version of Coot lodged in my ~/.phenix/prefs.params file. It was pointing to a linux Coot 0.6.1 32-bit installation. I assume that will override the phenix.find_coot_command?

Yes, there has to be some way to override automatic behavior. (For instance, I'm using this right now to prevent Phenix from using the Coot installed by Fink, because Fink has broken on my computer, yet again.)

The Mac problems appear to have cleared up when I removed the hard-coded

...

path to the linux version of Coot in my preferences file.

Sorry, I hadn't thought about cross-platform issues when I set this up; not sure if there's a good way to deal with this. I don't think there are too many people running Linux+Mac environments with shared home directories, but I've been worried about 32- vs. 64-bit compatibility.

-Nat

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

-- Stop the ACTA. Row, row; fight the power! http://www.eff.org/ Choel Kim Structural Biology Laboratory Department of Pharmacology, Baylor College of Medicine, Alkek N510, One Baylor Plaza, Houston, TX 77030 713-798-8687 (Lab) 713-798-3145 (Fax)

I have setup the Full Path to Coot in preferences setup as /sw64/bin/coot On Fri, Jun 18, 2010 at 5:45 PM, RaDaniel Christian 성준 < [email protected]> wrote:

Open In Coot opens the splash window, but nothing else happens. 'which coot' returns /sw64/bin/coot

I was mistaken about Pymol. Open In Pymol works. I just had to re-run the refinement, and Pymol opened the file ok.

Daniel

On Fri, Jun 18, 2010 at 4:49 PM, RaDaniel Christian 성준 < [email protected]> wrote:

...

I have tried clicking the 'Open in Coot' and 'Open in Pymol' buttons I saw a small window saying "The .pdb file "$s" does not exist." I have not been able to get that small window to appear again. However, when clicking Open in Pymol... The Pymol window spits this. ExecutiveProcessPDBFile-Error: Unable to open file '/Volumes/RAID1/...../coot-povray.pdb'.

Phenix shows this in the window. A Python error was detected. This is probably a bug; click "OK" to send a bug report to the PHENIX developers.

Exception : XMLRPC error: '> Method: load_refinement Params: /Volumes/RAID1/Jeong/Phenix/PKG_CBDA/APO/Refine_1/coot-povray, False

Traceback (most recent call last): File "/usr/local/phenix-1.6.1-357/phenix/wxGUI2/App.py", line 569, in OnTimer self.pymol_server.flush_requests() File "/usr/local/phenix-1.6.1-357/cctbx_project/libtbx/xmlrpc_utils.py", line 208, in flush_requests return self._server.flush_requests() File "/usr/local/phenix-1.6.1-357/cctbx_project/libtbx/xmlrpc_utils.py", line 126, in flush_requests (str(e), str(methodname), ", ".join([ str(p) for p in params ]))) Exception: XMLRPC error: '> Method: load_refinement Params: /Volumes/RAID1/Jeong/Phenix/PKG_CBDA/APO/Refine_1/coot-povray, False

On Mon, Jun 14, 2010 at 4:32 PM, Nathaniel Echols wrote:

...

On Mon, Jun 14, 2010 at 12:20 PM, Ben Eisenbraun < [email protected]> wrote:

...

So first off I see that I somehow got an older version of Coot lodged in my ~/.phenix/prefs.params file. It was pointing to a linux Coot 0.6.1 32-bit installation. I assume that will override the phenix.find_coot_command?

Yes, there has to be some way to override automatic behavior. (For instance, I'm using this right now to prevent Phenix from using the Coot installed by Fink, because Fink has broken on my computer, yet again.)

The Mac problems appear to have cleared up when I removed the hard-coded

...

path to the linux version of Coot in my preferences file.

Sorry, I hadn't thought about cross-platform issues when I set this up; not sure if there's a good way to deal with this. I don't think there are too many people running Linux+Mac environments with shared home directories, but I've been worried about 32- vs. 64-bit compatibility.

-Nat

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

-- Stop the ACTA. Row, row; fight the power! http://www.eff.org/

Choel Kim Structural Biology Laboratory Department of Pharmacology, Baylor College of Medicine, Alkek N510, One Baylor Plaza, Houston, TX 77030 713-798-8687 (Lab) 713-798-3145 (Fax)

-- Stop the ACTA. Row, row; fight the power! http://www.eff.org/

Choel Kim Structural Biology Laboratory Department of Pharmacology, Baylor College of Medicine, Alkek N510, One Baylor Plaza, Houston, TX 77030 713-798-8687 (Lab) 713-798-3145 (Fax)

-- Stop the ACTA. Row, row; fight the power! http://www.eff.org/ Choel Kim Structural Biology Laboratory Department of Pharmacology, Baylor College of Medicine, Alkek N510, One Baylor Plaza, Houston, TX 77030 713-798-8687 (Lab) 713-798-3145 (Fax)

The splash screen pops up and then goes away.

On Fri, Jun 18, 2010 at 3:45 PM, RaDaniel Christian 성준 < [email protected]> wrote:

Open In Coot opens the splash window, but nothing else happens. 'which coot' returns /sw64/bin/coot

Please try launching the Phenix GUI with "--debug", then start Coot, and send me the console output. Does typing "/sw64/bin/coot" at the command line successfully launch the program, or does it also stall at the splash window? thanks, Nat

On Fri, Jun 18, 2010 at 5:05 PM, jp d wrote:

hi, using supplied phenix examples 1rxf.mtz and 1rxf_randomise.pdb i can run the following command and it fails in phenix1.6.2 but not in phenix1.5-2

the error is: RuntimeError: Bond distance > max_reasonable_bond_distance: 52.1931 > 50

This is telling you that one of the bonds in the model is longer than the limit we've set - a simple sanity check that warns you there is something seriously wrong with the PDB file. This parameter appears to have been added since 1.5-2. It's possible that it's really a bug in the restraints generation, but usually these types of errors indicate corrupted coordinates. (For instance, in certain circumstances CNS sometimes outputs atoms at 999.99,999.99,999.99, which would probably trigger this error.) You should still use 1.6.2. You can, if you'd like, add the parameter max_reasonable_bond_distance=None to force it to accept absurd bond lengths, but this is probably just going to mask a problem with either your PDB file or our code. We need to see the PDB file to tell for sure. -Nat

On Sat, Jun 19, 2010 at 9:29 AM, jp d wrote:

i thought that also and checked everything with pdbtools. but now i can get the error using one of your example pdb files (1rxf_randomise.pdb ). so i dont think it is the pdb file.

As I said before, I can't find that PDB file anywhere in the PHENIX distribution - please send it to me or point me to a web page where I can get it. thanks, Nat

hi, pdb and mtz is posted at http://rna.ucsc.edu/pub/1rxf.tgz thanks jpd --- On Sat, 6/19/10, jp d wrote: From: jp d Subject: Re: [phenixbb] simulated annealing To: "PHENIX user mailing list" Date: Saturday, June 19, 2010, 9:41 AM sorry it was included with ccp4, (not phenix, my mistake) i tried to send it but hit the size limit with the attachment i dont think there is anything special about it. thanks jpd --- On Sat, 6/19/10, Nathaniel Echols wrote: From: Nathaniel Echols Subject: Re: [phenixbb] simulated annealing To: "PHENIX user mailing list" Date: Saturday, June 19, 2010, 9:34 AM On Sat, Jun 19, 2010 at 9:29 AM, jp d wrote: i thought that also and checked everything with pdbtools. but now i can get the error using one of your example pdb files (1rxf_randomise.pdb ). so i dont think it is the pdb file. As I said before, I can't find that PDB file anywhere in the PHENIX distribution - please send it to me or point me to a web page where I can get it.  thanks,Nat -----Inline Attachment Follows----- _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb -----Inline Attachment Follows----- _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

simulated_annealing.start_temperature=550000 \

This temperature is extremely large. It leads to chaotic trajectories, i.e. small changes in the program can lead to very different outcomes. I think it is just by chance that one phenix version crashes and the other doesn't. My recommendation is to lower the start temperature and to use the latest phenix version, which has many new features to help improve the model in different ways, e.g. fix_rotamers=True or the secondary structure restraints. Ralf

yes that temp is huge. my original error takes several hours to get. so this test case is a much smaller pdb and mtz file.

The small reproducer doesn't help in this case, although it is a good idea in general. Simulated Annealing inherently carries the risk of "exploding". We use tricks to achieve stability in most cases. This would have to be revisited and we'd need the actual problem case to be sure the additional tricks help. However, I doubt it will make it to the top of the priority list anytime soon. Practically the best response is to use a lower start temperature or to apply some quick manual fixes before the SA run. Another thing you could try is interleaved_minimization.number_of_iterations=1 which will make the trajectories more stable. Ralf

Hi All, from what I see on this conversation for the last couple of days: - I'm almost certain that there is something weird about the PDB file; - I don't think that the high start SA temperature causes the problem. For some (unknown to me) reasons the SA code in PHENIX is very tolerant to super high start temperatures. At some point I tried 100000K or so and nothing bad happened. If you really want us to debug this issue then the only way to do so is to send us enough of the inputs so we can reproduce this problems, explain what's happening and fix it. Necessary inputs include: - PDB file; - data file; - parameter file (if any); - the command you used (and that results in problem). Don't send these files to the whole phenixbb, but you can send them to my email directly and I will take care of it. Also, it would be helpful if you explain what you are trying to achieve by running SA with such as hight start temperature. Just in case I might be able to suggest a better way of doing that... Thanks! Pavel. On 6/19/10 10:38 AM, Nathaniel Echols wrote:

On Sat, Jun 19, 2010 at 9:32 AM, jp d mailto:[email protected]> wrote:

yes that temp is huge. my original error takes several hours to get. so this test case is a much smaller pdb and mtz file. at normal temp the error doesn't happen. but at high temp it is the same behaviour as my large original data set.

That doesn't tell us anything - the error could be caused by any number of problems with the coordinates, and unless you're using unrealistic high temperatures for the original data set too, there is probably something else wrong with it. In general you need to send us the original data, parameter file, and log file if you want us to debug problems like this (please use [email protected] mailto:[email protected] or [email protected] mailto:[email protected] for this, especially if it's unpublished data). However, after reading Ralf's reply, I'm not sure if there is anything we can do if the problem is specific to simulated annealing.

and at high temp it doesn't crash in 1.5 but does crash in 1.6

This is a problem with version 1.5, not 1.6 - it should certainly not continue to run if the protein bonds have been exploded.

-Nat ------------------------------------------------------------------------

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb