On Mar 9, 2010, at 6:03 PM, Stuart Endo-Streeter wrote:
> Problem is, column labels are selected. "i_obs sigma" is showing in the
> label field for each dataset. Clicking on the field to try to re-select
> makes no difference, I still get the same error message. If I load just a
> single anomalous dataset in addition to the native dataset, usually autosol
> will run, sometimes not. It does not matter which anomalous dataset I am
> using. If I load the native and only one of the anomalous datasets it
> usually works. If I then repeat the process of adding a single anomalous
> dataset, running autosol, aborting the run, then adding the next dataset,
> eventually I can add all the datasets and start autosol.
I'm not sure what to suggest, because I can't reproduce this (with 1.6 or the latest code), nor could I find anything in the code that indicates how it happens. Could you please send me a screenshot of the GUI before you click Run?
> After this repetitive route got autosol running, I ran into some kind of
> selinux security warning that blocked autosol and caused it to crash. I
> seem to have fixed that issue by switching temporarily to permissive mode,
> but disabling security to run phenix hardly seems the appropriate solution.
> I didn't manage to catch the autosol error message, I will try to recreate
> it later tonight if needed.
SELinux breaks the Fortran binaries we distribute. There are two things to try:
1. If you installed to /usr/local, try installing to your home directory instead (if this is your computer rather than a shared system). For example:
computer:~> ./install --prefix=/home/nat/software
I don't know if this will help or not, but it's worth a try.
2. Install from source. This will take several hours, so if you have multiple cores we recommend adding the flag "--nproc=8" (or whatever) when you run the install script. If you have access to the Intel Fortran compiler we recommend installing and configuring that (I think the build script will switch to using it automatically), since g77/gfortran produce binaries that are *much* slower.
This problem should go away in a few months when we purge the last FORTRAN code from PHENIX.
--------------------
Nathaniel Echols
Lawrence Berkeley Lab
510-486-5136
NEchols(a)lbl.gov
