Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
On Mon, Jan 21, 2013 at 6:21 AM, Clemens Vonrhein wrote: > Just for the record: the map-coefficients written by BUSTER > (amplitudes 2FOFCWT and FOFCWT in the final 'refine.mtz' file) are on > the same scale as the model (amplitude FC) ie. on approximate absolute > scale. For what it's worth: Pavel says the same is true of maps output by Phenix, "in theory", and in the several cases that I checked this appears to be true. We still have no idea what's going on in this particular case, but it does appear to be specific to these data (and another user's). > As far as we can tell, Coot uses the actual map-values (e/A^3) as a > 'score' in those 'density fit' graphs - is that right? So it is not > something with a known range (like a real-space correlation value from > -1 to +1) - especially not if the maps are sometimes on roughly > absolute scale and sometimes they aren't. This is consistent with what I saw too; multiplying the 2FOFCWT amplitudes by an arbitrary scale factor gave very different results in the density fit graph (but the mesh, of course, remains the same). -Nat
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
On 21/01/13 14:21, Clemens Vonrhein wrote: Dear all, On Thu, Jan 17, 2013 at 07:48:34AM -0800, Nat Echols wrote: If I had to guess, I'd say that the output from Refmac is on an approximately absolute scale, i.e. the volume-scaled density values resemble the actual electron densities expected for the model. (I say "approximately" because the absence of F(0,0,0) and various FFT artifacts pretty much guarantee that the values are not actually accurate, just on the same order of magnitude.) This is presumably done by scaling F(obs) to F(calc). Maps from Phenix are definitely *not* on an absolute scale, however, and I guess the same must be true for BUSTER. Just for the record: the map-coefficients written by BUSTER (amplitudes 2FOFCWT and FOFCWT in the final 'refine.mtz' file) are on the same scale as the model (amplitude FC) ie. on approximate absolute scale. As far as we can tell, Coot uses the actual map-values (e/A^3) as a 'score' in those 'density fit' graphs - is that right? Yes - for the moment at least. If I can make it fast enough, it will not be the case for 0.8. So it is not something with a known range (like a real-space correlation value from -1 to +1) - especially not if the maps are sometimes on roughly absolute scale and sometimes they aren't. Yes. It seems as if the determination of apropriate range for drawing those bars within coot is affecting if one sees only red (false negative) or only green (false positive) bars. Yes. Maybe Paul/Kevin/Bernhard can comment on how this is done? How does one avoid getting frustrated by too many red bars and (equally important) over-excited by bogus greenery? No good answer at the moment. The graph is only relative :-( I can only refer you to Bernhard's answer (above). Paul.
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
Dear all, On Thu, Jan 17, 2013 at 07:48:34AM -0800, Nat Echols wrote: > If I had to guess, I'd say that the output from Refmac is on an > approximately absolute scale, i.e. the volume-scaled density values > resemble the actual electron densities expected for the model. (I say > "approximately" because the absence of F(0,0,0) and various FFT > artifacts pretty much guarantee that the values are not actually > accurate, just on the same order of magnitude.) This is presumably > done by scaling F(obs) to F(calc). Maps from Phenix are definitely > *not* on an absolute scale, however, and I guess the same must be true > for BUSTER. Just for the record: the map-coefficients written by BUSTER (amplitudes 2FOFCWT and FOFCWT in the final 'refine.mtz' file) are on the same scale as the model (amplitude FC) ie. on approximate absolute scale. As far as we can tell, Coot uses the actual map-values (e/A^3) as a 'score' in those 'density fit' graphs - is that right? So it is not something with a known range (like a real-space correlation value from -1 to +1) - especially not if the maps are sometimes on roughly absolute scale and sometimes they aren't. It seems as if the determination of apropriate range for drawing those bars within coot is affecting if one sees only red (false negative) or only green (false positive) bars. Maybe Paul/Kevin/Bernhard can comment on how this is done? How does one avoid getting frustrated by too many red bars and (equally important) over-excited by bogus greenery? Cheers Clemens -- *** * Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com * * Global Phasing Ltd. * Sheraton House, Castle Park * Cambridge CB3 0AX, UK *-- * BUSTER Development Group (http://www.globalphasing.com) ***
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
Well, the problem seems to occur when Intensities are input to PHENIX instead of structure factors. I repeated a run using Fobs, SigFobs as input instead of IMEAN, SIGIMEAN and the Density Fit Analysis graph looks "normal". At 16:57 17-01-2013, Nathaniel Echols wrote: Actually, after some experimenting, I have just discovered that the map coefficients produced by the very latest code are actually on the same scale now, regardless of the scale of the input F(obs). This was not what I expected at all. However, I should add that I still don't know whether this scale will be what Coot expects. It is very difficult for me to tell what is happening internally, but when the "isotropize" option is selected (it's on by default) the map coefficient amplitudes are being multiplied by the overall anisotropic scale matrix. I'm not sure how this is calculated. On Thu, Jan 17, 2013 at 8:29 AM, Nathaniel Echols wrote: > On Thu, Jan 17, 2013 at 8:21 AM, Pedro M. Matias wrote: >> The funny thing is that I also have MTZ files from PHENIX that work >> perfectly in COOT. > > I think it will be dependent on having F(obs) already on an > approximately absolute scale. This can be accomplished by scaling > them during conversion from intensities, based on the Wilson plot (I > think). I should note that while the CCP4 conversion tools usually > take care of this, if you supply Phenix with intensities it will > simply take the square root (the French-Wilson correction doesn't > affect the overall scale). It would probably be useful to do the same > thing in our code; I think it's pretty straightforward but I'm not > sure about the math. > > My guess would be that some of the MTZ files you used were either a) > already on an absolute scale, or b) accidentally ended up being > approximately correct. However, if you're willing to send me the > inputs and outputs for Phenix and Refmac for the structures you've had > a problem with, I can confirm my guesses. > >> And although I cannot be 100% sure, since the run was in >> Dec-2012 I believe the PHENIX version is the same in both cases (it would be >> nice if PHENIX wrote the version number in the PDB header). > > It should already do this - but you need to look further down in the > remarks, where you will see something like this: > > REMARK 3 PROGRAM : PHENIX (phenix.refine: 1.7.3_928) > > Probably not a bad idea to display it at the very top too, however. > >> Bernhard has suggested tweaking some parameter in COOT >> >> Extensions->Refinement->Set Density Fit Graph Weight >> >> But the question is: which value should be used ? > > I suspect that this will also be completely arbitrary - btw, the fact > that this option even exists seems to be confirmation that the graphs > are not displaying a CC. I think the way Coot is doing this is > completely broken, for what it's worth - but I also think it would be > helpful if the maps from Phenix were at least on approximately the > correct scale, instead of being (potentially) orders of magnitude off. > > -Nat Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
On Thu, Jan 17, 2013 at 8:27 AM, Pedro M. Matias wrote: > Excuse me if I'm wrong but should't the correlation coefficient between Fo > and Fc (which is what the Density Fit analysis is looking at) be independent > of this issue, provided Fo and Fc are on the same scale ? And since the map > is calculated from weighted 2Fo-Fc amplitudes and phases the scaling problem > should not occur. Cross-posting again (sorry, I use different accounts for mailing lists and Phenix stuff): """I think it will be dependent on having F(obs) already on an approximately absolute scale. This can be accomplished by scaling them during conversion from intensities, based on the Wilson plot (I think). I should note that while the CCP4 conversion tools usually take care of this, if you supply Phenix with intensities it will simply take the square root (the French-Wilson correction doesn't affect the overall scale). It would probably be useful to do the same thing in our code; I think it's pretty straightforward but I'm not sure about the math. My guess would be that some of the MTZ files you used were either a) already on an absolute scale, or b) accidentally ended up being approximately correct. However, if you're willing to send me the inputs and outputs for Phenix and Refmac for the structures you've had a problem with, I can confirm my guesses.""" Note that what happens internally in Phenix is actually that Fc is scaled to Fo, not the other way around! (No, I don't know why this is done; ask Pavel.) So the Fc values from Coot are on a different scale. -Nat
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
Excuse me if I'm wrong but should't the correlation coefficient between Fo and Fc (which is what the Density Fit analysis is looking at) be independent of this issue, provided Fo and Fc are on the same scale ? And since the map is calculated from weighted 2Fo-Fc amplitudes and phases the scaling problem should not occur. What seems to happen is that Coot doesn't even "look" at the map - it immediately displays a collection of red bars. And to confuse the issue even more, I have data from another structure refined with PHENIX that works fine! At 16:10 17-01-2013, Phil Evans wrote: (hesitating to restart an old flame war) There has been a long-standing argument about scaling of electron density maps, with many people deprecating "sigma-scaling", for two reasons 1) in 2Fo-Fc type maps, "sigma" = RMS density is a function among other things of the solvent content (smaller with high solvent content) 2) in difference maps Fo-Fc type, as the model improves, sigma gets smaller (ideally = 0). Sigma contouring is useful to pick out the largest features though. Scaling even approximately to e/A^3 (i.e. scaling Fobs to Fcalc) is consistent across solvent content and model quality, though still affected by resolution and other things, and generally should be preferred in my opinion. Sharpening map coefficients may also affect the scale Phil On 17 Jan 2013, at 15:48, Nat Echols wrote: > On Thu, Jan 17, 2013 at 3:16 AM, Pedro M. Matias wrote: >> To clarify my previous e-mail, in both cases the maps are being calculated >> from weighted coefficients from an MTZ file output by the program. >> I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file >> and the end-result (red bars) was the same. > > If I had to guess, I'd say that the output from Refmac is on an > approximately absolute scale, i.e. the volume-scaled density values > resemble the actual electron densities expected for the model. (I say > "approximately" because the absence of F(0,0,0) and various FFT > artifacts pretty much guarantee that the values are not actually > accurate, just on the same order of magnitude.) This is presumably > done by scaling F(obs) to F(calc). Maps from Phenix are definitely > *not* on an absolute scale, however, and I guess the same must be true > for BUSTER. Since everyone is used to looking at sigma-scaled maps > this has not been a problem in the past; I don't think older versions > of Coot had this problem either. > > You are not the first person to complain about this, for what it's worth. > > -Nat Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
On Thu, Jan 17, 2013 at 8:10 AM, Phil Evans wrote: > There has been a long-standing argument about scaling of electron density > maps, with many people deprecating "sigma-scaling", for two reasons > > 1) in 2Fo-Fc type maps, "sigma" = RMS density is a function among other > things of the solvent content (smaller with high solvent content) > 2) in difference maps Fo-Fc type, as the model improves, sigma gets smaller > (ideally = 0). Sigma contouring is useful to pick out the largest features > though. > > Scaling even approximately to e/A^3 (i.e. scaling Fobs to Fcalc) is > consistent across solvent content and model quality, though still affected by > resolution and other things, and generally should be preferred in my opinion. > Sharpening map coefficients may also affect the scale I completely agree with this, although I still think the density fit graphs in Coot should work independently of scale. The main objection I've heard to attempting to put maps on an absolute scale is that it would (inaccurately) imply that the values really are accurate electron levels, which they are not, for the reasons I already mentioned. (The phrase "letting the perfect be the enemy of the good" comes to mind here...) Unfortunately this is not something I personally can fix, but I will bring it up at group meeting. (I should add that my hypothesis is only a guess, and I haven't actually tested it yet - however, it is consistent with the facts presented. I would need to look at the Coot source code to be sure, but I'm hoping Paul/Kevin/Bernhard will comment.) -Nat
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
(hesitating to restart an old flame war) There has been a long-standing argument about scaling of electron density maps, with many people deprecating "sigma-scaling", for two reasons 1) in 2Fo-Fc type maps, "sigma" = RMS density is a function among other things of the solvent content (smaller with high solvent content) 2) in difference maps Fo-Fc type, as the model improves, sigma gets smaller (ideally = 0). Sigma contouring is useful to pick out the largest features though. Scaling even approximately to e/A^3 (i.e. scaling Fobs to Fcalc) is consistent across solvent content and model quality, though still affected by resolution and other things, and generally should be preferred in my opinion. Sharpening map coefficients may also affect the scale Phil On 17 Jan 2013, at 15:48, Nat Echols wrote: > On Thu, Jan 17, 2013 at 3:16 AM, Pedro M. Matias wrote: >> To clarify my previous e-mail, in both cases the maps are being calculated >> from weighted coefficients from an MTZ file output by the program. >> I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file >> and the end-result (red bars) was the same. > > If I had to guess, I'd say that the output from Refmac is on an > approximately absolute scale, i.e. the volume-scaled density values > resemble the actual electron densities expected for the model. (I say > "approximately" because the absence of F(0,0,0) and various FFT > artifacts pretty much guarantee that the values are not actually > accurate, just on the same order of magnitude.) This is presumably > done by scaling F(obs) to F(calc). Maps from Phenix are definitely > *not* on an absolute scale, however, and I guess the same must be true > for BUSTER. Since everyone is used to looking at sigma-scaled maps > this has not been a problem in the past; I don't think older versions > of Coot had this problem either. > > You are not the first person to complain about this, for what it's worth. > > -Nat
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
On Thu, Jan 17, 2013 at 3:16 AM, Pedro M. Matias wrote: > To clarify my previous e-mail, in both cases the maps are being calculated > from weighted coefficients from an MTZ file output by the program. > I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file > and the end-result (red bars) was the same. If I had to guess, I'd say that the output from Refmac is on an approximately absolute scale, i.e. the volume-scaled density values resemble the actual electron densities expected for the model. (I say "approximately" because the absence of F(0,0,0) and various FFT artifacts pretty much guarantee that the values are not actually accurate, just on the same order of magnitude.) This is presumably done by scaling F(obs) to F(calc). Maps from Phenix are definitely *not* on an absolute scale, however, and I guess the same must be true for BUSTER. Since everyone is used to looking at sigma-scaled maps this has not been a problem in the past; I don't think older versions of Coot had this problem either. You are not the first person to complain about this, for what it's worth. -Nat
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
I see the same thing with Autobuster structures. -Original Message- From: Mailing list for users of COOT Crystallographic Software [mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Pedro M. Matias Sent: Thursday, January 17, 2013 6:16 AM To: COOT@JISCMAIL.AC.UK Subject: Re: Problem with Coot Density Fit Analysis with PHENIX map coefficients Hi, Bernhard, To clarify my previous e-mail, in both cases the maps are being calculated from weighted coefficients from an MTZ file output by the program. I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file and the end-result (red bars) was the same. Pedro. At 09:23 17-01-2013, Bernhard Lohkamp wrote: >Hi Pedro, > >this is due to the map sampling (which seems different between the >two programs). Anyway, for now you can change the weighting manually: > >Extensions->Refinement->Set Density Fit Graph Weight > >B > >On 17/01/2013 10:11, Pedro M. Matias wrote: >>Hi, >> >>I encountered a strange problem while running the "Density Fit Analysis" >>widget on a structure refined with PHENIX. All residues are represented >>with a red bar (see picture) with low CC. >> >>Using the same input coordinate and MTZ file in REFMAC produces normal >>"Density Fit Analysis" graphs (see picture). >> >>I am at a loss to understand why this is happening... >> >>This happens with both 0.6.2 and 0.7 versions of Coot. >> >>Best regards, >> >>Pedro. >> >> >>Industry and Medicine Applied Crystallography >>Macromolecular Crystallography Unit >>___ >>Phones : (351-21) 446-9100 Ext. 1669 >>(351-21) 446-9669 (direct) >> Fax : (351-21) 441-1277 or 443-3644 >> >>email : mat...@itqb.unl.pt >> >>http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography >> >>http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit >> >>Mailing address : >>Instituto de Tecnologia Quimica e Biologica >>Apartado 127 >>2781-901 OEIRAS >>Portugal > >-- >*** > >Dr. Bernhard Lohkamp >Assistant Professor >Div. Molecular Structural Biology >Dept. of Medical Biochemistry and Biophysics (MBB) >Karolinska Institutet >S-17177 Stockholm >Sweden > >phone: (+46) 08-52487651 >fax: (+46) 08-327626 >email: bernhard.lohk...@ki.se Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates Direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system.
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
Hi, Bernhard, To clarify my previous e-mail, in both cases the maps are being calculated from weighted coefficients from an MTZ file output by the program. I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file and the end-result (red bars) was the same. Pedro. At 09:23 17-01-2013, Bernhard Lohkamp wrote: Hi Pedro, this is due to the map sampling (which seems different between the two programs). Anyway, for now you can change the weighting manually: Extensions->Refinement->Set Density Fit Graph Weight B On 17/01/2013 10:11, Pedro M. Matias wrote: Hi, I encountered a strange problem while running the "Density Fit Analysis" widget on a structure refined with PHENIX. All residues are represented with a red bar (see picture) with low CC. Using the same input coordinate and MTZ file in REFMAC produces normal "Density Fit Analysis" graphs (see picture). I am at a loss to understand why this is happening... This happens with both 0.6.2 and 0.7 versions of Coot. Best regards, Pedro. Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal -- *** Dr. Bernhard Lohkamp Assistant Professor Div. Molecular Structural Biology Dept. of Medical Biochemistry and Biophysics (MBB) Karolinska Institutet S-17177 Stockholm Sweden phone: (+46) 08-52487651 fax: (+46) 08-327626 email: bernhard.lohk...@ki.se Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Bernhard, this sounds odd - wouldn't both maps be calculated from F/PHI by coot itself? Why would Paul (Kevin?) make a difference there between phenix and refmac5? Curiously, Tim On 01/17/2013 10:23 AM, Bernhard Lohkamp wrote: > Hi Pedro, > > this is due to the map sampling (which seems different between the > two programs). Anyway, for now you can change the weighting > manually: > > Extensions->Refinement->Set Density Fit Graph Weight > > B > > On 17/01/2013 10:11, Pedro M. Matias wrote: >> Hi, >> >> I encountered a strange problem while running the "Density Fit >> Analysis" widget on a structure refined with PHENIX. All residues >> are represented with a red bar (see picture) with low CC. >> >> Using the same input coordinate and MTZ file in REFMAC produces >> normal "Density Fit Analysis" graphs (see picture). >> >> I am at a loss to understand why this is happening... >> >> This happens with both 0.6.2 and 0.7 versions of Coot. >> >> Best regards, >> >> Pedro. >> >> >> Industry and Medicine Applied Crystallography Macromolecular >> Crystallography Unit ___ Phones : >> (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : >> (351-21) 441-1277 or 443-3644 >> >> email : mat...@itqb.unl.pt >> >> http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography >> >> >> >> http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit >> >> Mailing address : Instituto de Tecnologia Quimica e Biologica >> Apartado 127 2781-901 OEIRAS Portugal > - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQ98yxUxlJ7aRr7hoRAk6dAJ40C/NnDzSq5qwUge8smqs12jvolACeJzP+ x8dEGDrJzHvkVekddgcvPgs= =aZ9b -END PGP SIGNATURE-
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
Hi Pedro, this is due to the map sampling (which seems different between the two programs). Anyway, for now you can change the weighting manually: Extensions->Refinement->Set Density Fit Graph Weight B On 17/01/2013 10:11, Pedro M. Matias wrote: Hi, I encountered a strange problem while running the "Density Fit Analysis" widget on a structure refined with PHENIX. All residues are represented with a red bar (see picture) with low CC. Using the same input coordinate and MTZ file in REFMAC produces normal "Density Fit Analysis" graphs (see picture). I am at a loss to understand why this is happening... This happens with both 0.6.2 and 0.7 versions of Coot. Best regards, Pedro. Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal -- *** Dr. Bernhard Lohkamp Assistant Professor Div. Molecular Structural Biology Dept. of Medical Biochemistry and Biophysics (MBB) Karolinska Institutet S-17177 Stockholm Sweden phone: (+46) 08-52487651 fax: (+46) 08-327626 email: bernhard.lohk...@ki.se
Re: [COOT] Problem with coot
setenv LC_ALL C helped in my case. Thanks much, Paul! On Tue, 26 May 2009 00:21:53 +0100, Paul Emsley wrote: >Oliv Eidam wrote: >> Hi, >> >> I have the same problem like Robert. >> And although I updated to coot-0.6-pre-1-1941-intel-10.4-10.5.tgz like Bill >> suggested, the problem (displaying no or wrong bonds) persists. >> >> Has this problem been resolved by now? I am using OSX 10.4.11. > > >And > >source /sw/bin/init.sh > >was not the answer? > > >Check the settings of LANG, LANGUAGE LC_NUMERIC is what I suggest. > >Paul
Re: [COOT] Problem with coot
Oliv Eidam wrote: Hi, I have the same problem like Robert. And although I updated to coot-0.6-pre-1-1941-intel-10.4-10.5.tgz like Bill suggested, the problem (displaying no or wrong bonds) persists. Has this problem been resolved by now? I am using OSX 10.4.11. And source /sw/bin/init.sh was not the answer? Check the settings of LANG, LANGUAGE LC_NUMERIC is what I suggest. Paul
Re: [COOT] Problem with coot
Hi, I have the same problem like Robert. And although I updated to coot-0.6-pre-1-1941-intel-10.4-10.5.tgz like Bill suggested, the problem (displaying no or wrong bonds) persists. Has this problem been resolved by now? I am using OSX 10.4.11. Many thanks, Oliv
Re: [COOT] Problem with coot
The problem with my coot is fixed. I removed all the all installations of coot and the .coot file, installed it again and used the source /sw/bin/init.csh command. then It worked agian :) Thank you for all your help. Robert 2009/3/28 William G. Scott > > On Mar 28, 2009, at 10:14 AM, Robert wrote: > > Recently I updated to coot-0.6-pre-1-1876 using fink >> apparently something went wrong >> > > robertfloor% /usr/local/xtal/coot/bin/coot >> > > That is likely the origin of the problem, as this doesn't call fink's coot, > but rather the one I made as a stand-alone. > > Try this: > > source /sw/bin/init.sh > > coot > > >> >
Re: [COOT] Problem with coot
On Mar 28, 2009, at 10:14 AM, Robert wrote: Recently I updated to coot-0.6-pre-1-1876 using fink apparently something went wrong robertfloor% /usr/local/xtal/coot/bin/coot That is likely the origin of the problem, as this doesn't call fink's coot, but rather the one I made as a stand-alone. Try this: source /sw/bin/init.sh coot
Re: [COOT] Problem with coot
Try updating to 1941. I just put that in cvs an hour ago and it seems to behave ok, at least for me Bill On Sat, Mar 28, 2009 at 10:14 AM, Robert wrote: > Dear all, > > I am using coot on Mac OS X 10.5.6 and have a problem. I used coot for a > year without a problem. Recently I updated to coot-0.6-pre-1-1876 using fink > apparently something went wrong during the update. Now I can startup coot > but it behaves very badly, displaying no or wrong bonds and it had problems > opening every file. I tried to install an other version of coot but I still > have the problems. It seems there are muliple versions of some files or > something like that. This is what is when when I start coot: > > Kind regards and thank you in advance for your help > > Robert Floor > > robertfloor% /usr/local/xtal/coot/bin/coot > Acquiring application resources from /usr/local/xtal/coot/share/coot/cootrc > INFO:: splash_screen_pixmap_dir /usr/local/xtal/coot/share/coot/pixmaps > INFO:: Colours file: /usr/local/xtal/coot/share/coot/colours.def loaded > There are 117 data in > /usr/local/xtal/coot/share/coot/lib/data/monomers/list/mon_lib_list.cif > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading link plane mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading bond mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading bond mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link torsion mmCIFLoop > problem reading link t
[COOT] Problem with coot
Dear all, I am using coot on Mac OS X 10.5.6 and have a problem. I used coot for a year without a problem. Recently I updated to coot-0.6-pre-1-1876 using fink apparently something went wrong during the update. Now I can startup coot but it behaves very badly, displaying no or wrong bonds and it had problems opening every file. I tried to install an other version of coot but I still have the problems. It seems there are muliple versions of some files or something like that. This is what is when when I start coot: Kind regards and thank you in advance for your help Robert Floor robertfloor% /usr/local/xtal/coot/bin/coot Acquiring application resources from /usr/local/xtal/coot/share/coot/cootrc INFO:: splash_screen_pixmap_dir /usr/local/xtal/coot/share/coot/pixmaps INFO:: Colours file: /usr/local/xtal/coot/share/coot/colours.def loaded There are 117 data in /usr/local/xtal/coot/share/coot/lib/data/monomers/list/mon_lib_list.cif problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading link plane mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading link torsion mmCIFLoop problem reading bond mmCIFLoop problem reading link torsion mmC
Re: [COOT] Problem with Coot validation after Phenix twinned refinement
brr at the moment, the maps are indeed not on absolute scale, will change that. P 2008/10/10 Paul Emsley <[EMAIL PROTECTED]>: > Lieven Buts wrote: >> >> Hello all, >> >> I have just been experimenting with the refinement options for twinned >> data >> in phenix.refine (final 1.3 version), and I ran into a strange problem >> with >> the density fit validation function in Coot 0.4 and 0.5. When I >> "auto-open" >> the MTZ file with map coefficients produced by phenix.refine, I get a >> normal-looking map, but every single residue in the density fit plot is >> squarely in the red. When I open the 2Fo-Fc CNS format file also produced >> by phenix.refine, I get a map that looks identical to the first one, and >> when I validate the same model against the new map, I get the normal >> density fit pattern, with most residues in the green, and the occasional >> orange one. So it seems that the density fit calculation goes wrong for >> MTZ files from twinned refinement. Does anyone know what might be >> causing this? I can send the data files if required. > > > Randy Read told me about this issue the other day. > > The density fit graphs work assuming that the map is on the absolute scale - > I suspect that your maps have a different scale (test by looking at the > absolute level given the same number of sigma). It would be better if Coot > used correlation vs a calculated map, but today it does not. > > You can adjust the scale using Extensions -> Refine -> Set Density Fit Graph > Weight [1] > > [1] I may move this soon - Settings would seem a better submenu. > > Paul. > -- - P.H. Zwart Beamline Scientist Berkeley Center for Structural Biology Lawrence Berkeley National Laboratories 1 Cyclotron Road, Berkeley, CA-94703, USA Cell: 510 289 9246 BCSB: http://bcsb.als.lbl.gov PHENIX: http://www.phenix-online.org CCTBX: http://cctbx.sf.net -
Re: [COOT] Problem with Coot validation after Phenix twinned refinement
Lieven Buts wrote: Hello all, I have just been experimenting with the refinement options for twinned data in phenix.refine (final 1.3 version), and I ran into a strange problem with the density fit validation function in Coot 0.4 and 0.5. When I "auto-open" the MTZ file with map coefficients produced by phenix.refine, I get a normal-looking map, but every single residue in the density fit plot is squarely in the red. When I open the 2Fo-Fc CNS format file also produced by phenix.refine, I get a map that looks identical to the first one, and when I validate the same model against the new map, I get the normal density fit pattern, with most residues in the green, and the occasional orange one. So it seems that the density fit calculation goes wrong for MTZ files from twinned refinement. Does anyone know what might be causing this? I can send the data files if required. Randy Read told me about this issue the other day. The density fit graphs work assuming that the map is on the absolute scale - I suspect that your maps have a different scale (test by looking at the absolute level given the same number of sigma). It would be better if Coot used correlation vs a calculated map, but today it does not. You can adjust the scale using Extensions -> Refine -> Set Density Fit Graph Weight [1] [1] I may move this soon - Settings would seem a better submenu. Paul.
[COOT] Problem with Coot validation after Phenix twinned refinement
Hello all, I have just been experimenting with the refinement options for twinned data in phenix.refine (final 1.3 version), and I ran into a strange problem with the density fit validation function in Coot 0.4 and 0.5. When I "auto-open" the MTZ file with map coefficients produced by phenix.refine, I get a normal-looking map, but every single residue in the density fit plot is squarely in the red. When I open the 2Fo-Fc CNS format file also produced by phenix.refine, I get a map that looks identical to the first one, and when I validate the same model against the new map, I get the normal density fit pattern, with most residues in the green, and the occasional orange one. So it seems that the density fit calculation goes wrong for MTZ files from twinned refinement. Does anyone know what might be causing this? I can send the data files if required. Cheers, -- Lieven Buts Ultrastructure Laboratory Vrije Universiteit Brussel
