phenix GUI freezing during refinement and file naming issues
Dear all I've recently been having a few problems with the new phenix GUI freezing during refinement runs on several different systems, most often when I try and do something different on the computer which puts the GUI in the background or on a different desktop. I've seen this problem when running a local copy of phenix on a ubuntu 9.10 system or when running the GUI remotely on a mac connected to our Centos linux cluster. When I switch to a different desktop to get on with doing something else (refine jobs can take a long time) the GUI freezes - although the underlying task runs correctly. The only way out of this problem is to force quit the GUI and then restart it. However, this means that the task isn't recorded in my history and all settings used to run the job are lost from the GUI - the parameter file to run the job does exist though. This also means I lose all the nice molprobibity connections to coot which are really useful. Also if I try to run phenix on the Centos linux cluster when running a local windows system the GUI is so sllloooowwww whenever the GUI tries to open a new window that its unsuable. Has anyone else seen these problems and know a cure? If I run phenix locally on a mac I don't seem to have this problem, but it is nice to run the refine job on our linux cluster so that I can get on with doing something else without it slowing down my mac. On another note, when running phenix refine from the GUI it nicely puts all the files in a folder called "Refine_1" etc... with the number incrementing with each run. So, why are the pdb and mtz file always called "refine_1..." not "refine_2 etc... to match the folder name? This would help with keeping track of files during itterative refinement and model building. It would also stop the problem of having lots of files called "refine_1" loaded into coot when I try to compare models from different refine runs. It would also be useful to be able to be able to add a prefix to the file name / folder name / job name in the GUI so that I could distinguish between different refinement experiments. This is easy to do on the command line.... Thanks and merry christmas John -- John Berrisford Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
On Dec 22, 2009, at 3:55 AM, John Berrisford wrote:
I've seen this problem when running a local copy of phenix on a ubuntu 9.10 system or when running the GUI remotely on a mac connected to our Centos linux cluster. When I switch to a different desktop to get on with doing something else (refine jobs can take a long time) the GUI freezes - although the underlying task runs correctly. The only way out of this problem is to force quit the GUI and then restart it. However, this means that the task isn't recorded in my history and all settings used to run the job are lost from the GUI - the parameter file to run the job does exist though. This also means I lose all the nice molprobibity connections to coot which are really useful. Also if I try to run phenix on the Centos linux cluster when running a local windows system the GUI is so sllloooowwww whenever the GUI tries to open a new window that its unsuable. Has anyone else seen these problems and know a cure?
I have an Ubuntu 9.10 system at the lab, so I'll see if I can replicate this. I've heard one report of this before (on Fedora 11), but I suspect it's yet another Linux video driver issue. I'm not sure what to suggest for the remote display, because this kind of problem is even more difficult to debug. I just tried running the phenix.refine GUI remotely (from a Linux server to my Mac) over AT&T's atrocious DSL line, and the experience was unpleasant, to say the least. That said, I've done this over a LAN before without any major problems. (The exception: anything involving 3D graphics, e.g. the atom selection widget, Coot, or PyMOL.) A few suggestions: 1. Don't use X11. Apple's implementation is horribly buggy, and X11 is a very primitive protocol (22 years old) to start with, and a massive bandwidth hog. We recommend NoMachine's NX Server, for which there is a free edition for Linux, and a free Mac client. Unlike VNC or Remote Desktop, it isn't limited to displaying what's on the actual screen - but it can still maintain the desktop when you disconnect. Unlike X11, it actually compresses the network traffic. I just tried this with the same setup, and it worked reasonably well - far more responsive than X11. However, I'm not sure how well this works with firewalls or IP masquerading. I also tried running the GUI remotely over X11 and displaying it on the NX desktop (both machines running intel-linux-2.6-x86_64), and this also worked well, if a little less responsive than NX alone. This would appear to confirm that the problem is partially Apple's. (However, if anyone experiences similar problems with Linux-only setups, please let me know.) 2. If you must use X11, turn off the main GUI, e.g. "phenix.refine --no-launch-main" or uncheck Preferences->Phenix interface->Open main Phenix GUI on startup. I'll see if I can make this behave better on Apple's X11, but I'm not optimistic. 3. Don't bother trying to use OpenGL over X11. (For what it's worth, I've heard from someone who's had a similar problem running Coot remotely, although I don't think OpenGL was the problem - it may be a GTK issue.) Definitely turn off the graphics mirroring (Preferences->Show progress in graphics window). OpenGL over NX isn't very fast either, but it is certainly less buggy.
If I run phenix locally on a mac I don't seem to have this problem, but it is nice to run the refine job on our linux cluster so that I can get on with doing something else without it slowing down my mac.
A further suggestion: the optimal platform for the phenix GUI is a multicore workstation - as many cores as possible. (Rumor has it that the next generation of MacPro will have 12 - but the quad-core iMac would probably be an excellent choice too. Or a similar Linux machine, if you prefer.)
On another note, when running phenix refine from the GUI it nicely puts all the files in a folder called "Refine_1" etc... with the number incrementing with each run. So, why are the pdb and mtz file always called "refine_1..." not "refine_2 etc... to match the folder name? This would help with keeping track of files during itterative refinement and model building. It would also stop the problem of having lots of files called "refine_1" loaded into coot when I try to compare models from different refine runs.
The labeling of output files and directories by the different programs in Phenix is not at all consistent to begin with, and it's somewhat difficult to control from the GUI - and I didn't want to tinker too much with other people's code. However, I think in this case the limitation is unnecessary, and since I received the same request last week, fixing this is high on my priority list. Check back in a couple of weeks - there will probably be a new installer soon, and I'll try to incorporate this feature before then.
It would also be useful to be able to be able to add a prefix to the file name / folder name / job name in the GUI so that I could distinguish between different refinement experiments. This is easy to do on the command line....
Configuration tab->Refinement settings tab->Output files->Other options->File prefix - in the future, I'll make this default to something that includes the project name. -Nat -------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]
I have a similar problem on Ubuntu 8.04 (nVidia card with X-server 11.0). I only run as a local copy. I can switch desktops and applications mostly, but if the computer goes to screen saver then it definitely freezes the gui. It does happen on other occasions, but as near as I can tell seems random.
Is there a way to restore a properly completed job to the gui (or alternatively, maybe it hasn't completed properly, but it does create a pdb and mtz and other files)?
So far my fix is to stay near the box when running and jiggle the mouse from time to time. It's nice to still be needed in the refinement process. ;)
-Christina
________________________________
From: Nathaniel Echols
I've seen this problem when running a local copy of phenix on a ubuntu 9.10 system or when running the GUI remotely on a mac connected to our Centos linux cluster. When I switch to a different desktop to get on with doing something else (refine jobs can take a long time) the GUI freezes - although the underlying task runs correctly. The only way out of this problem is to force quit the GUI and then restart it. However, this means that the task isn't recorded in my history and all settings used to run the job are lost from the GUI - the parameter file to run the job does exist though. This also means I lose all the nice molprobibity connections to coot which are really useful. Also if I try to run phenix on the Centos linux cluster when running a local windows system the GUI is so sllloooowwww whenever the GUI tries to open a new window that its unsuable. Has anyone else seen these problems and know a cure?
I have an Ubuntu 9.10 system at the lab, so I'll see if I can replicate this. I've heard one report of this before (on Fedora 11), but I suspect it's yet another Linux video driver issue. I'm not sure what to suggest for the remote display, because this kind of problem is even more difficult to debug. I just tried running the phenix.refine GUI remotely (from a Linux server to my Mac) over AT&T's atrocious DSL line, and the experience was unpleasant, to say the least. That said, I've done this over a LAN before without any major problems. (The exception: anything involving 3D graphics, e.g. the atom selection widget, Coot, or PyMOL.) A few suggestions: 1. Don't use X11. Apple's implementation is horribly buggy, and X11 is a very primitive protocol (22 years old) to start with, and a massive bandwidth hog. We recommend NoMachine's NX Server, for which there is a free edition for Linux, and a free Mac client. Unlike VNC or Remote Desktop, it isn't limited to displaying what's on the actual screen - but it can still maintain the desktop when you disconnect. Unlike X11, it actually compresses the network traffic. I just tried this with the same setup, and it worked reasonably well - far more responsive than X11. However, I'm not sure how well this works with firewalls or IP masquerading. I also tried running the GUI remotely over X11 and displaying it on the NX desktop (both machines running intel-linux-2.6-x86_64), and this also worked well, if a little less responsive than NX alone. This would appear to confirm that the problem is partially Apple's. (However, if anyone experiences similar problems with Linux-only setups, please let me know.) 2. If you must use X11, turn off the main GUI, e.g. "phenix.refine --no-launch-main" or uncheck Preferences->Phenix interface->Open main Phenix GUI on startup. I'll see if I can make this behave better on Apple's X11, but I'm not optimistic. 3. Don't bother trying to use OpenGL over X11. (For what it's worth, I've heard from someone who's had a similar problem running Coot remotely, although I don't think OpenGL was the problem - it may be a GTK issue.) Definitely turn off the graphics mirroring (Preferences->Show progress in graphics window). OpenGL over NX isn't very fast either, but it is certainly less buggy.
If I run phenix locally on a mac I don't seem to have this problem, but it is nice to run the refine job on our linux cluster so that I can get on with doing something else without it slowing down my mac.
A further suggestion: the optimal platform for the phenix GUI is a multicore workstation - as many cores as possible. (Rumor has it that the next generation of MacPro will have 12 - but the quad-core iMac would probably be an excellent choice too. Or a similar Linux machine, if you prefer.)
On another note, when running phenix refine from the GUI it nicely puts all the files in a folder called "Refine_1" etc... with the number incrementing with each run. So, why are the pdb and mtz file always called "refine_1..." not "refine_2 etc... to match the folder name? This would help with keeping track of files during itterative refinement and model building. It would also stop the problem of having lots of files called "refine_1" loaded into coot when I try to compare models from different refine runs.
The labeling of output files and directories by the different programs in Phenix is not at all consistent to begin with, and it's somewhat difficult to control from the GUI - and I didn't want to tinker too much with other people's code. However, I think in this case the limitation is unnecessary, and since I received the same request last week, fixing this is high on my priority list. Check back in a couple of weeks - there will probably be a new installer soon, and I'll try to incorporate this feature before then.
It would also be useful to be able to be able to add a prefix to the file name / folder name / job name in the GUI so that I could distinguish between different refinement experiments. This is easy to do on the command line....
Configuration tab->Refinement settings tab->Output files->Other options->File prefix - in the future, I'll make this default to something that includes the project name. -Nat -------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected] _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On Dec 22, 2009, at 9:35 AM, Christina Bourne wrote:
I have a similar problem on Ubuntu 8.04 (nVidia card with X-server 11.0). I only run as a local copy. I can switch desktops and applications mostly, but if the computer goes to screen saver then it definitely freezes the gui. It does happen on other occasions, but as near as I can tell seems random.
Does this only freeze the GUI when it's running a process, or is it happening any time the screensaver goes on? I tried 1.5-2 on a similar system (Ubuntu 8.10, nvidia-glx-96) and the phenix.refine GUI was still working after exiting the screensaver, but I wasn't running anything at the time. (Although the laptop I bought for grad school is showing its age - there are probably a few more things I can do to make the GUI more responsive.) One other thought: as many of you have discovered, when an error occurs, a window pops up with a message containing the Python traceback. As long as one of these windows is open, the rest of the GUI will be inaccessible. If you're switching around desktops while this happens, it is easy to miss the error, and this has confused me several times while testing. This doesn't explain the screensaver problem, of course.
Is there a way to restore a properly completed job to the gui (or alternatively, maybe it hasn't completed properly, but it does create a pdb and mtz and other files)?
Yes, assuming the GUI is still running and the issue is entirely with the display or underlying libraries, it will save all of the result data (i.e. validation info, statistics, and assorted internal data) for re-use later. In the main GUI, click on "Job history", select a job, and click "Restore results". This should resurrect the window with both the configuration and result tabs more or less as you left them. Alternately, use the "restore last result" toolbar button. If the GUI is truly frozen, it won't save its result data, but phenix.refine is running in a separate process, so if it completes it will write out the PDB and MTZ files to the output directory anyway. You can get most of the same result information in the GUI relatively quickly by running the comprehensive validation. -------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]
It sounds like the latter- it is completely frozen and doesn't save any results data, so never appears in the history. It also does not give any popup with a traceback message. It does only happen when a job is running. As trade-offs go, I consider this a minor problem - the value of the software by far outweighs an occasional crash.
Thanks for all,
Christina
________________________________
From: Nathaniel Echols
I have a similar problem on Ubuntu 8.04 (nVidia card with X-server 11.0). I only run as a local copy. I can switch desktops and applications mostly, but if the computer goes to screen saver then it definitely freezes the gui. It does happen on other occasions, but as near as I can tell seems random.
Does this only freeze the GUI when it's running a process, or is it happening any time the screensaver goes on? I tried 1.5-2 on a similar system (Ubuntu 8.10, nvidia-glx-96) and the phenix.refine GUI was still working after exiting the screensaver, but I wasn't running anything at the time. (Although the laptop I bought for grad school is showing its age - there are probably a few more things I can do to make the GUI more responsive.) One other thought: as many of you have discovered, when an error occurs, a window pops up with a message containing the Python traceback. As long as one of these windows is open, the rest of the GUI will be inaccessible. If you're switching around desktops while this happens, it is easy to miss the error, and this has confused me several times while testing. This doesn't explain the screensaver problem, of course.
Is there a way to restore a properly completed job to the gui (or alternatively, maybe it hasn't completed properly, but it does create a pdb and mtz and other files)?
Yes, assuming the GUI is still running and the issue is entirely with the display or underlying libraries, it will save all of the result data (i.e. validation info, statistics, and assorted internal data) for re-use later. In the main GUI, click on "Job history", select a job, and click "Restore results". This should resurrect the window with both the configuration and result tabs more or less as you left them. Alternately, use the "restore last result" toolbar button. If the GUI is truly frozen, it won't save its result data, but phenix.refine is running in a separate process, so if it completes it will write out the PDB and MTZ files to the output directory anyway. You can get most of the same result information in the GUI relatively quickly by running the comprehensive validation. -------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected] _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
participants (3)
-
Christina Bourne -
John Berrisford -
Nathaniel Echols