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