Hi Nat, I'm using the command-line installer for Mac, as I have always done. I typically run it with: sudo ./install.sh --no-apps --prefix=/some/where It is not a problem with the pdb file or with the mtz: 1/ the same pdb and mtz files work perfectly in the same Mac computer providede I run phenix.refine from the command line 2/ they also work fine if I run phenix.refine in a linux computer (in this case they work from both GUI and command line) 3/ Any file downloaded from the PDB gives the same negative result So, it is clearly a GUI problem on the Macs, which is not the same than saying that the problem is *in* the Phenix GUI: it could be yet another side-effect of an Apple software update... To be complete, for a typical Mac here:

uname -a Darwin think.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64

xcodebuild -version Xcode 3.2.6 Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0 BuildVersion: 10M2518

Best, Miguel Le 02/05/11 16:45, Nathaniel Echols a écrit :

By the way, are you using the graphical or command-line installer for Mac?

thanks, Nat

On Mon, May 2, 2011 at 7:41 AM, Nathaniel Echols wrote:

...

2011/5/2 Miguel Ortiz Lombardía :

...

Last Friday (April 29) we upgraded phenix to its most recent version (1.7.1-743). Installation went smoothly on both Mac (10.6.7 64-bit) and Linux (Ubuntu 10.10 64-bit) machines. However, we observe that we cannot use phenix.refine (I don't know for the rest of the applications) from the GUI on the Macs. phenix.refine does work from the command line, though.

So, whenever we try to add a pdb in the GUI, we get this error message:

This application does not support the file type for /path/to/the/file.pdb (format: txt)

I just tried about a dozen different PDB files and a few MTZs and I couldn't reproduce this. However, I only have the 32-bit version installed on this computer; I will try the 64-bit version when I arrive at the lab (although I'm pretty certain I tried loading PDB files in the installed version sometime last week without issues). The error you're seeing usually indicates some kind of formatting problem with the PDB file that caused the PDB parser to fail (it will default to reading it as a text file instead - not very helpful, I know). Could you please send me the file that is having this problem?

I'm not sure what the MTZ-related error means - it looks like the CCP4 library is choking on the CCP4 symop.lib, which is bizarre. Those extra spaces certainly shouldn't be there in the original file. Could you please also send me the file $PHENIX/ccp4io/lib/data/symop.lib?

thanks, Nat

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

-- Miguel Architecture et Fonction des Macromolécules Biologiques (UMR6098) CNRS, Universités d'Aix-Marseille I & II Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France Tel: +33(0) 491 82 55 93 Fax: +33(0) 491 26 67 20 mailto:[email protected] http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Le 02/05/11 20:03, Nathaniel Echols a écrit :

2011/5/2 Miguel Ortiz Lombardía :

...

1/ the same pdb and mtz files work perfectly in the same Mac computer providede I run phenix.refine from the command line 2/ they also work fine if I run phenix.refine in a linux computer (in this case they work from both GUI and command line) 3/ Any file downloaded from the PDB gives the same negative result

So, it is clearly a GUI problem on the Macs, which is not the same than saying that the problem is *in* the Phenix GUI: it could be yet another side-effect of an Apple software update...

It turned out to be a side effect of using the newer version of wxPython in the 64-bit Mac builds. The problem is with the French language setting on your computer, which change some of the formatting conventions (including, I suspect, using ',' instead of '.' for decimal numbers). I was able to reproduce this on a test system, but only with the 64-bit installer - the 32-bit version works fine, presumably because it is using an earlier release of wxPython. (This also explains why the GUI in the Linux build on your systems works okay.)

The launchers force the language setting to be the same as far as the command-line code is concerned, but I can only assume that wxPython now overrides this, on Mac at least. The solution to this, fortunately, is very simple - I just need to set the language localization again when the GUI starts. The next nightly build will have the fix, but if you want to patch 1.7.1, I've attached the file you need. Use this command:

patch $PHENIX/phenix/wxGUI2/App.py App.patch

Thanks for catching this. I'm assuming the MTZ file issue has the same cause, but if the problem doesn't completely go away after patching or updating, please let us know. (Oh, and I suspect REEL will have the same problem if started from the command line rather than the main GUI - I'll fix that next.)

-Nat

Thank you, Nat. This appears to have been the problem since your patch fixes it. It is also consistent with the fact that I set these variables in the general bashrc file: # To avoid decimal separator problems # export LC_NUMERIC=C # To get files sorted by date in Coot # export LC_MESSAGES=C that explain why the jobs could run properly from the command line. Best regards, -- Miguel Architecture et Fonction des Macromolécules Biologiques (UMR6098) CNRS, Universités d'Aix-Marseille I & II Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France Tel: +33(0) 491 82 55 93 Fax: +33(0) 491 26 67 20 mailto:[email protected] http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

We are depositing a structure refined by phenix, and the final pdb for deposit has the line "min Fobs/sigma=1.34". ADIT interprets this to mean a sigma cutoff of 1.34 was used. The .eff file confirms that rejection criterion on Fobs (and on Iobs) is 0.0 . And when I think about it, I can't see how the min Fobs/sigma could be zero, if the Fobs go right to zero and sigma doesn't go below some background level. So could these be lowest average of F/sigma for a shell? But we found a pdb file from another project where min Fobs/sigma=0.0, and the average for a shell wouldn't be exactly zero. So 1)what does the "min Fobs/sigma=" line mean, and is it OK to correct ADIT with the sigma cutoff of zero? 2)Also, this is a structure containing heavy atoms (derivative was better than the native) and so refined against anomalous data. The final PDB file that was uploaded listed unique reflections with Bijvoet mates separate. Is that what we want to report? or the number after merging Bijvoet mates? =================== more The data.refine .mtz has I's and F's. The I's go from small negative to large positive, while the F's go from .2 or .4 (F+ and F-) to around 5000 French and Wilson truncate procedure is being used, so only about .2% reflections get rejected. However many more have negative I's. The .eff indicates a cutoff on Iobs/sigma=0. If this is applied to the I's in data.refine.mtz it will reject a lot of weak reflections and make (min F/sigma) larger- but clearly that is not happening, besides I saw min Fobs/sigma > 1 for another project in which phenix was given only F, all positive of course.

Oh, this is interesting. When I saw your value of 1.34, I went that's what I also see, too. By that I mean 1.34 or something very similar (once I saw a 1.36). And I do not impose any cut-offs to the I/sigma(I) or F/sigma(F) criteria, except that by default HKL2000 does a very reasonable I/s(I)>-3 cutoff, and I hope phenix.refine is not using an artificial cutoff for F/sigma(F). I have always thought that this could be a result of using truncate (French-Wilson), but was not sure. I just checked and my "truncate"d mtz's have much lower F/sigma(F)s in them, so that's not the problem. So, I have the same questions as Edward has... Engin On 2/5/12 2:02 PM, Edward A. Berry wrote:

We are depositing a structure refined by phenix, and the final pdb for deposit has the line "min Fobs/sigma=1.34".

ADIT interprets this to mean a sigma cutoff of 1.34 was used. The .eff file confirms that rejection criterion on Fobs (and on Iobs) is 0.0 .

And when I think about it, I can't see how the min Fobs/sigma could be 1.34, if the Fobs go right to zero and sigma doesn't go below some background level. So could these be lowest average of F/sigma for a shell? But we found a pdb file from another project where min Fobs/sigma=0.0, and the average for a shell wouldn't be exactly zero.

So 1)what does the "min Fobs/sigma=" line mean, and is it OK to correct ADIT with the sigma cutoff of zero?

2)Also, this is a structure containing heavy atoms (derivative was better than the native) and so refined against anomalous data. The final PDB file that was uploaded listed unique reflections with Bijvoet mates separate. Is that what we want to report? or the number after merging Bijvoet mates?

=================== more

The data.refine .mtz has I's and F's. The I's go from small negative to large positive, while the F's go from .2 or .4 (F+ and F-) to around 5000 French and Wilson truncate procedure is being used, so only about .2% reflections get rejected. However many more have negative I's. The .eff indicates a cutoff on Iobs/sigma=0. If this is applied to the I's in data.refine.mtz it will reject a lot of weak reflections and make (min F/sigma) larger- but clearly that is not happening, besides I saw min Fobs/sigma > 1 for another project in which phenix was given only F, all positive of course. _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

Thanks, Pavel. We'll put zero for cutoff of Fobs and "NULL" for cutoff on Iobs. And use the number ADIT already gleaned from the remark in the PDB for total number of reflections (measured and observed) used in refinement. Actually original input data was I's from scalepack, but it is clear that negative intensities were not rejected at that stage (or there would have been more rejections) and anyway I'm used to thinking of I->F as part of data reduction, not refinement. So taking F's as input to the actual refinement process, some were rejected as outliers, but none by sigma cutoff of zero. I find it odd that min(F/Fobs) is greater than 1 when the I's go clear through zero to negatives. Maybe part of the magic of French and Wilson? I'll check tomorrow if, as Engin reports, there are individual reflections with F/sigma lower than reported, and if so let you know. eab Pavel Afonine wrote:

Hi Ed,

...

We are depositing a structure refined by phenix, and the final pdb for deposit has the line "min Fobs/sigma=1.34".

this value is the result of taking all input Fobs, then dividing them by corresponding sigmas and taking the min. This is for reporting purposes only, no data was rejected using this criterion.

...

The .eff file confirms that rejection criterion on Fobs (and on Iobs) is 0.0 .

We need to make it clearer. When the input data are Fobs then this criterion is actually used; that is all reflections with Fobs<0 are rejected. If Iobs are the input data then phenix.refine uses French&Wilson method to convert the Iobs into Fobs.

Jeff: could clarify how sigma rejection criterion is used in this case?

Also, phenix.refine uses dynamic outliers rejection. So the amount of Fobs actually used in refinement may be slightly different. This is why phenix.refine always outputs one MTZ file that contains four sets of data: 1) original data (just copy of input data); 2) Fobs actually used in refinement; 3) Fmodel - total model structure factor that includes bulk-solvent contribution and all scales, so you can take Fobs from "3)" and Fmodel and reproduce the reported R-factors. 4) Fourier map coefficients.

For details see page 57 here: http://www.phenix-online.org/presentations/latest/pavel_phenix_refine.pdf

or simply to

phenix.mtz.dump file.mtz

...

2)Also, this is a structure containing heavy atoms (derivative was better than the native) and so refined against anomalous data. The final PDB file that was uploaded listed unique reflections with Bijvoet mates separate. Is that what we want to report? or the number after merging Bijvoet mates?

It reports unique reflections with Bijvoet mates separate because that what was actually used in refinement. I will add another line showing the number of merged reflections (I thought I did it a while ago).

...

=================== more

The data.refine .mtz has I's and F's. The I's go from small negative to large positive, while the F's go from .2 or .4 (F+ and F-) to around 5000 French and Wilson truncate procedure is being used, so only about .2% reflections get rejected. However many more have negative I's. The .eff indicates a cutoff on Iobs/sigma=0. If this is applied to the I's in data.refine.mtz it will reject a lot of weak reflections and make (min F/sigma) larger- but clearly that is not happening, besides I saw min Fobs/sigma > 1 for another project in which phenix was given only F, all positive of course.

I hope Jeff will comment on this.

Pavel

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