Problems with opening Coot and Firefox from gui under RHEL 6.2
Hi, I've installed Phenix 1.7.3-928 on a linux workstation by downloading the binary phenix-installer-1.7.3-928-intel-linux-2.6-x86_64-fc3.tar I'm running Red Hat Enterprise Linux Workstation release 6.2. (Mainly 64 bit libraries but some additional 32 bit libraries that are necessary to run Alwyn Jones' 32 bit version of O.) *Help and Firefox* When I click on the Help icon in the Phenix GUI I get the message: [pbrick@pb1 ~/test]$ phenix phenix_gui.htm Using browser /usr/bin/firefox phenix_gui.htm Using browser /usr/bin/firefox /usr/lib64/firefox-3.6/firefox: symbol lookup error: /usr/lib64/libgnome-2.so.0: undefined symbol: g_dgettext But if firefox is already running it opens a new tab and I receive no error message. Firefox is the version shipped with RHEL 6.2: firefox 3.6.24 (I notice that the mozilla website is offering version 9.0.1 for i686 processors.) *Starting Coot* When I click on the Coot icon in the Phenix gui no window opens but I can see the processes: coot, coot_build_phenix_coot.csh and coot-real running. In fact coot-real consumes 100% of the cpu of one of the cores. What I find really weird is if I look at the processes with the system monitor gui and right click and 'kill' coot-real then instead of killing the process the coot window opens. At the same time coot_build_phenix_coot.csh disappears and the cpu usage drops to zero. (Note: I've also tried the fc12 version. I found that the version of pymol distributed with phenix uses 32 bit libraries and I needed to install libXmu.so.6) Any suggestions as to what I might be doing wrong? Peter
*Starting Coot*
When I click on the Coot icon in the Phenix gui no window opens but I can see the processes: coot, coot_build_phenix_coot.csh and coot-real running. In fact coot-real consumes 100% of the cpu of one of the cores. What I find really weird is if I look at the processes with the system monitor gui and right click and 'kill' coot-real then instead of killing the process the coot window opens. At the same time coot_build_phenix_coot.csh disappears and the cpu usage drops to zero.
(Note: I've also tried the fc12 version. I found that the version of pymol distributed with phenix uses 32 bit libraries and I needed to install libXmu.so.6)
Any suggestions as to what I might be doing wrong?
That sounds like a startup-script problem (race condition?). When you send coot the TERM signal, it stops waiting for communication and gets on with starting up - presumably as it would if you started it without Phenix (if one can contemplate such a thing). Another option might be that it is somehow picking up an old coot - and the communication dependences are not in place - however, I thought the Phenix gui guards against this possibility. Paul.
On Thu, Jan 26, 2012 at 7:27 AM, Paul Emsley
Another option might be that it is somehow picking up an old coot - and the communication dependences are not in place - however, I thought the Phenix gui guards against this possibility.
Not really - the rules are: 1. If the path to coot is defined in Preferences, it uses that; 2. Otherwise, if "coot" is a valid command in the shell's search path, use that; 3. Finally, look for various common places where Coot might be expected (this is usually only necessary on Mac) for a "coot" executable. I may have some idea what is breaking here; will check again in a few hours (first I need coffee). Peter: what is the terminal output when you click the Coot icon? -Nat
Many thanks for the pointers
Coot problem - mea culpa:
Instead of having the directory containing the coot script in my PATH I has defined coot as an alias. I don't understand why this caused the problem.
When compiling a 64 bit version of the ccp4 suite I found that having the coot binary folder in my path caused confusion (I think with python) and had therefore swapped to using the alias.
Firefox?
Cheers
Peter
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Nathaniel Echols
Sent: 26 January 2012 15:34
To: PHENIX user mailing list
Subject: Re: [phenixbb] Problems with opening Coot and Firefox from gui under RHEL 6.2
On Thu, Jan 26, 2012 at 7:27 AM, Paul Emsley
Another option might be that it is somehow picking up an old coot - and the communication dependences are not in place - however, I thought the Phenix gui guards against this possibility.
Not really - the rules are: 1. If the path to coot is defined in Preferences, it uses that; 2. Otherwise, if "coot" is a valid command in the shell's search path, use that; 3. Finally, look for various common places where Coot might be expected (this is usually only necessary on Mac) for a "coot" executable. I may have some idea what is breaking here; will check again in a few hours (first I need coffee). Peter: what is the terminal output when you click the Coot icon? -Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On Thu, Jan 26, 2012 at 8:13 AM, Brick, Peter
Instead of having the directory containing the coot script in my PATH I has defined coot as an alias. I don't understand why this caused the problem.
I'm not sure either, but I'll see if I can reproduce the problem. (Although I thought we could handle aliases...)
Firefox?
Right, forgot about this. In Phenix, try setting Preferences->File handling->Reset LD_LIBRARY_PATH for external apps. This sometimes fixes the problem, but if not let me know. -Nat
Dear All, What it means if the Rwork or Rfree increase slightly during refinement? Best regards. Dialing
Hi Dialing, for example, it may mean the following: we typically refine macromolecular structures using maximum-likelihood (ML) target function and not the R-factor. Maximizing the ML target does not necessarily mean minimizing the R-factor (although free R is correlated with the phase error and the latter should improve with the optimization of ML). So what you observe is slightly odd but not too unexpected. This is discussed to some extent here (for example): http://www.ccp4.ac.uk/newsletters/newsletter37/08_ml.html The other 10+ potential reasons include: - suboptimal refinement strategy; - target weights may need adjustment; - ... Pavel
Dear All,
What it means if the Rwork or Rfree increase slightly during refinement?
Best regards.
Dialing
participants (5)
-
Brick, Peter -
Dialing Pretty -
Nathaniel Echols -
Paul Emsley -
Pavel Afonine