Re: [COOT] Disulphide sphere refinement fails in COOT when PDB file comes from BUSTER?

[Ian Tickle]

All, could this behaviour be due to different line terminators
(DOS/Linux/Mac)?  I've had that problem before, though not in this
particular context.

-- Ian


On Fri, 24 Mar 2023 at 10:00, Martin Moche <
9c00cd8c651b-dmarc-requ...@jiscmail.ac.uk> wrote:

> Dear Clemens and colleagues,
>
> I spot the issue in COOT logfile - see COOT-BUSTER-issue-captured.PNG -
> however why does COOT connect Cys31 with Cys223?
>
> The disulphide is between Cys31 and Cys52 as indicated correctly in the
> right-hand side COOT logfile using Refmac PDB
>
> I share the headers of the buster PDB (buster6_header.pdb) and refmac
> (cutc-x31-1-header.pdb)
>
> Cheers,
> Martin
>
> Head of Macromolecular X-ray Crystallography | Protein Science Facility
> Medical Biochemistry and Biophysics
> 171 65 Solna | Solnavägen 9
> +46 8 524 868 43 | +46 73 322 93 27
> martin.mo...@ki.se | ki.se
> __
> Karolinska Institutet – a medical university
>
> -Original Message-
> From: Clemens Vonrhein 
> Sent: den 24 mars 2023 10:26
> To: Martin Moche 
> Cc: COOT@jiscmail.ac.uk
> Subject: Re: Disulphide sphere refinement fails in COOT when PDB file
> comes from BUSTER?
>
> Dear all,
>
> just to avoid confusion: BUSTER version numbering is maybe a bit unusual
> and differs between academic and commercial users (for various historic
> reasons). The most relevant version information is the release data, ie
> 20230217 currently [1].
>
> Another short note: we also don't see that sphere refinement issue for
> typical PDB entries (with standard SSBOND records) from BUSTER.
>
> Cheers
>
> Clemens
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.globalphasing.com%2Fbuster%2Fnews.html&data=05%7C01%7Cmartin.moche%40ki.se%7C498f51ecbc4a4b41672008db2c49ce5b%7Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C0%7C638152467737316306%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iiAxj61VjYylobCvFJvf49Yd0kTLVgeDgVAJED369qk%3D&reserved=0
>
>
> När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI
> kommer att behandla dina personuppgifter. Här finns information om hur KI
> behandlar personuppgifter<
> https://ki.se/medarbetare/integritetsskyddspolicy>.
>
>
> Sending email to Karolinska Institutet (KI) will result in KI processing
> your personal data. You can read more about KI’s processing of personal
> data here.
>
> 
>
> To unsubscribe from the COOT list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1
>
> This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/
>



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [COOT] absolute map levels

[Ian Tickle]

Hi Tim

I would say that it's not the displayed map density value in whatever units
that's arbitrary: it's completely defined as the true density on an
absolute scale minus the F000 contribution ('b' below) and optionally
divided by the RMS.  It's just that we don't have a good estimate of F000
and as I said it's your choice of contour level that's arbitrary.

The Buster map is scaled to the model so is on an absolute scale.  We can
write the linear transformation:

rho[map] = a.(rho[true] - b)

where the scale factor a = 1 so that rho[map] is on the same absolute scale
as rho[true] (i.e. differences in rho[true] are equal to differences in
rho[map]), and b is the F000 contribution.

Cheers

-- Ian


On Mon, 2 May 2022 at 15:04, Tim Gruene  wrote:

> Hi Paul,
>
> I'd rather you comment on the unit "e/A^3" displayed at the top of my
> Coot canvas when I change the contour level of a map. Is this arbitrary?
>
> I noticed that the Buster Wiki states that their FWT is on an absolute
> scale. Would there be a paper or url to advance my rusty habits?
>
> Cheers,
> Tim
>
>
> On Mon, 2 May 2022 13:52:05 +0100 Paul Emsley
>  wrote:
>
> > On 02/05/2022 12:44, John R Helliwell wrote:
> > > I was intrigued by Paul’s 5sigma Fo-Fc default cut off, rather than
> > > 3.
> >
> >
> > It's 5.6 now :-)
> >
> > 
> >
> > To unsubscribe from the COOT list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/COOT, a
> > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > available at https://www.jiscmail.ac.uk/policyandsecurity/
>
>
>
> --
> --
> Tim Gruene
> Head of the Centre for X-ray Structure Analysis
> Faculty of Chemistry
> University of Vienna
>
> Phone: +43-1-4277-70202
>
> GPG Key ID = A46BEE1A
>
> 
>
> To unsubscribe from the COOT list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1
>
> This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/
>



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [COOT] absolute map levels

[Ian Tickle]

Hi Tim

The absolute peak height doesn't only depend on the element, it also
depends on a number of other things, most notably the resolution and the B
factor (i.e. peaks are broader and peak heights are lower at lower
resolution and higher B factor), and of course the occupancy factor in the
case of partial occupancy.  So I'm not clear how one would know what peak
height to expect just by looking at the map: one would have to do quite a
complicated calculation involving a Fourier transform of the scattering
curve.  It's the volume integral of the electron density under the peak
that's directly related to the element type, not the peak height.  The
range of resolution and B factor for small molecules is much less than for
macromolecules, so your method of element identification is likely to be
much more reliable in the former case.

Cheers

-- Ian


On Mon, 2 May 2022 at 12:15, Tim Gruene  wrote:

> Hi Ian,
>
> this is the custom I was educated with. However, small molecule people
> seem confused when a map contour level is described with an rsmd (which
> to me makes some sense). When refining a structure with shelxl, the
> peak height of the maxima of the difference map corresponds quite well
> to the element one is expecting, i.e. the absolute value of the peak
> height can be used to guess the missing atom type (e.g. '8' for a
> properly ordered oxygen from a water molecule).
>
> Also COOT has been displaying the map countour level with the unit
> e/A^3, and I seem to remember Paul's recommendation to use this unit,
> rather than the rmsd, which is displayed in brackets.
>
> Cheers,
> Tim
>
> On Mon, 2 May 2022 09:48:30 +0100 Ian Tickle  wrote:
>
> > Hi Tim
> >
> > F000 is customarily not included in MX electron density for the
> > reason you mention.  This doesn't matter because the contour levels
> > are completely arbitrary anyway, i.e. you choose a level that shows
> > the features you expect to see.  This can be misleading of course
> > since there may be significant features at lower density than you
> > expected due to thermal motion / disorder or maybe H atoms; however
> > including F000 would not change that.
> >
> > Cheers
> >
> > -- Ian
> >
> >
> > On Mon, 2 May 2022 at 07:45, Tim Gruene 
> > wrote:
> >
> > > Hello readers,
> > >
> > > how does Coot calculate the absolute map levels, i.e. the contour
> > > level given as [e/A^3]? i always thought (rather from hear-say)
> > > that F000 was necessary for the absolute level. With a small
> > > molecule structure, F000 can be calculated from a complete model,
> > > but with solvent channels, the number of disordered electron is not
> > > known, is it?
> > >
> > > Thanks a lot for a clarification!
> > >
> > > Best,
> > > Tim
> > >
> > >
> > > --
> > > --
> > > Tim Gruene
> > > Head of the Centre for X-ray Structure Analysis
> > > Faculty of Chemistry
> > > University of Vienna
> > >
> > > Phone: +43-1-4277-70202
> > >
> > > GPG Key ID = A46BEE1A
> > >
> > >
> 
> > >
> > > To unsubscribe from the COOT list, click the following link:
> > > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1
> > >
> > > This message was issued to members of www.jiscmail.ac.uk/COOT, a
> > > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > > available at https://www.jiscmail.ac.uk/policyandsecurity/
> > >
>
>
>
> --
> --
> Tim Gruene
> Head of the Centre for X-ray Structure Analysis
> Faculty of Chemistry
> University of Vienna
>
> Phone: +43-1-4277-70202
>
> GPG Key ID = A46BEE1A
>



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [COOT] absolute map levels

[Ian Tickle]

Hi Tim

F000 is customarily not included in MX electron density for the reason you
mention.  This doesn't matter because the contour levels are completely
arbitrary anyway, i.e. you choose a level that shows the features you
expect to see.  This can be misleading of course since there may be
significant features at lower density than you expected due to thermal
motion / disorder or maybe H atoms; however including F000 would not change
that.

Cheers

-- Ian


On Mon, 2 May 2022 at 07:45, Tim Gruene  wrote:

> Hello readers,
>
> how does Coot calculate the absolute map levels, i.e. the contour level
> given as [e/A^3]? i always thought (rather from hear-say) that F000 was
> necessary for the absolute level. With a small molecule structure, F000
> can be calculated from a complete model, but with solvent channels, the
> number of disordered electron is not known, is it?
>
> Thanks a lot for a clarification!
>
> Best,
> Tim
>
>
> --
> --
> Tim Gruene
> Head of the Centre for X-ray Structure Analysis
> Faculty of Chemistry
> University of Vienna
>
> Phone: +43-1-4277-70202
>
> GPG Key ID = A46BEE1A
>
> 
>
> To unsubscribe from the COOT list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1
>
> This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing
> list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/
>



To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT&A=1

This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [COOT] Calculating sigma value

[Ian Tickle]

Hi Edward

You are perfectly correct that the use of the term 'standard deviation' is
not limited to error distributions.  However I believe that my preferred
terminology, namely 'standard uncertainty', i.e. the experimental estimate
of the standard deviation in the error, related in the same way as the
experimental estimate of an intensity to its true value, is.  The use of
the Greek letter σ (sigma), or indeed any symbol, in equations is purely a
notational convention, since there are obviously not enough symbols in a
font set to go round for every possible entity - 'sigma' is used as an
algebraic symbol for probably at least 20 different entities in maths & the
sciences, as I would guess are most of the other Latin & Greek letters.
There cannot therefore be any permanent connection between a symbol and its
meaning, so that typically its meaning in an manuscript is given in a table
of notation: this is used locally in equations only in the context of that
manuscript (which therefore cannot necessarily be taken to apply in any
other context).

This means that if one is to avoid ambiguity, one cannot use 'sigma' to
mean both 'standard deviation of the error' (or 'standard deviation' /
'RMSD') and 'standard uncertainty' in the same context, and therefore that
we are forced to define symbols to mean whatever we want them to mean (with
a suitable explanation of the notation of course).  My thinking in the
context of the current thread was that sigma indeed meant 'standard
uncertainty', and I thought that that was implicit from what I wrote, but
if anyone misunderstood my meaning then I should certainly have been more
explicit.  I should perhaps have properly defined my notation and said
something like: "... it shouldn't be called sigma (where here I define
sigma as 'standard uncertainty'), because it's not an uncertainty ...".

My main argument, which I should perhaps have expanded further, is that we
need to avoid a clash of symbols when RMS deviation and standard
uncertainty appear in the same set of equations (I take it that there is no
argument that they are distinct quantities that require different
symbols).  Now since RMS deviation is in general a sample standard
deviation (one can and often does take only a sample of the map and
calculate the RMSD of that sample), the usual symbol for that is 's'.  In
contrast the standard uncertainty is an estimate of the population standard
deviation, for which I think we have agreed that the symbol is 'sigma'.  As
Steven Sheriff pointed out to me, this situation does arise with my own
program EDSTATS, which attempts to calculate the standard uncertainty of
the 2mFo-DFc map, based on the RMSD of the 2(mFo-DFc) map, so this is a
genuine issue.

You are right that the FFT in Coot is most likely performed by the FFTW
('Fastest Fourier Transform in the West') package and not by the CCP4 FFT
program as I originally stated.

Thanks for the correction!

Cheers

-- Ian


On 19 April 2018 at 17:44, Edward A. Berry  wrote:

>
>
> On 04/19/2018 08:57 AM, Ian Tickle wrote:
>
>>
>> Hi, first maps are produced by Refmac, not Coot, and second it shouldn't
>> be called sigma because it's not an uncertainty, it's a root-mean-square
>> deviation from the mean.  The equation for the RMSD can be found in any
>> basic text on statistics, e.g. just type 'RMSD' in Wikipedia.
>>
>> Cheers
>>
>> -- Ian
>>
>
>
> With all due respect, and I may be misunderstanding something here, but I
> think that that is an unnecessarily restrictive definition of sigma! I'm
> assuming sigma stands for the standard deviation. Although standard
> deviation is often associated with a probability distribution, it is
> defined for (any?) kind of distribution. From the Wikipedia page on
> standard deviation, "the standard deviation (SD, also represented by the
> Greek letter sigma σ or the Latin letter s, is a measure that is used to
> quantify the amount of variation or dispersion of a set of data values",
> and "There are also other measures of deviation from the norm . . .".  That
> together with the formula for population standard deviation suggests
> standard deviation is exactly the RMS Deviation from the mean.
>
> For an analogy, suppose a dietician weighs a dozen mice that have
> undergone the same regimen, and calculates a certain mean value with a
> standard deviation deviation of 1.2 g. Now he weighed the mice on a scale
> reading to the tenth of a gram, so the standard deviation of the
> measurement is around 0.1 g or less. Nonetheless he is going to report the
> deviation of his population, which is 1.2 g.  Likewise even if we knew
> precisely the electron dens

Re: [COOT] Calculating sigma value

[Ian Tickle]

On 19 April 2018 at 17:03, Marcin Wojdyr  wrote:

I think he means the numbers that coot displays, e.g.
> map 1 level = 1.56 e/A^3 (3.50 rmsd)
>
> So the answer to the question if the relation between the two numbers
> is linear is yes.
>

OK I see, Mohamed means the electron density value ('number of A^-3'), not
the unit of the electron density, and the multiplier of the RMSD ('number
of RMSDs'), not the RMSD itself.

So yes.


In Coot docs it's called sigma or sigma-level:
> https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/web/docs/coot.html
>

Hmmm needs to be updated to be consistent with the code!

Cheers

-- Ian

Re: [COOT] Calculating sigma value

[Ian Tickle]

Hi Mohamed

The RMSD of the electron density (or difference density) is calculated by
the FFT program using the standard equation that I referenced.  I would
guess that what you see in Coot is copied either from the map header or the
FFT log file.

I'm not clear what you mean when you refer to 'the e/A^3'.  The RMSD (as
does the electron density from which it's calculated) consists of a pure
number and a unit of measure, e.g. '1.234 A^-3' (why it's not '1.234 eA^-3'
we won't go into here: suffice it to say that 'e' is a unit of charge and
'electron density' is not the same as 'charge density', while an electron,
or 'e-',  is not a unit of measure at all, it's a sub-atomic particle: see
Wikipedia/Non-SI_units_mentioned_in_the_SI and Wikipedia/electron).  The
relation between 'RMSD' and 'A^-3' is simply that the latter is the unit of
the former, exactly analogous to the relation between 'distance' and
'metre'.

Yes '3 sigma' in this context is not correct: it's '3 RMSD', and indeed
COOT itself uses the latter terminology (which you see any time you change
the contour level), so I'm not clear where you got that from.  The
uncertainty ('sigma') of the density does have a value, though this is not
estimated by any of the standard programs AFAIK.  However one thing is
certain: it's unlikely to equal the RMSD!

Cheers

-- Ian


On 19 April 2018 at 15:25, Mohamed Ibrahim 
wrote:

> Hi Ian,
>
> Thanks a lot for your answers. They are very informative. I am afraid that
> I was looking in the wrong direction to figure out what I seek. So, I am
> reforming my question; I am trying to figure out whether the relation
> between the RMSD and the e/A^3 is linear or not. Therefore, I was looking
> for how does COOT calculate the RMSD, hoping to find the relation between
> RMSD and e/A^3. If you could refer to me a reference that is related to
> this, it will be great.
> One more question, you mentioned that " it shouldn't be called sigma
> because it's not an uncertainty ", so when we say, for example, this map
> is contoured at 3 sigma, this is a wrong statement?
>
> Cheers,
>
> On Thu, Apr 19, 2018 at 2:57 PM, Ian Tickle  wrote:
>
>>
>> Hi, first maps are produced by Refmac, not Coot, and second it shouldn't
>> be called sigma because it's not an uncertainty, it's a root-mean-square
>> deviation from the mean.  The equation for the RMSD can be found in any
>> basic text on statistics, e.g. just type 'RMSD' in Wikipedia.
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On 19 April 2018 at 13:20, Mohamed Ibrahim 
>> wrote:
>>
>>> Dear COOT users,
>>>
>>> Do you know how to extract the equations that COOT uses for generating
>>> the maps and calculating the sigma values?
>>>
>>> Best regards,
>>> Mohamed
>>>
>>> --
>>> ​
>>> --
>>> *​--*
>>> *Mohamed Ibrahim  *
>>>
>>> *Humboldt University   *
>>> *Berlin, Germany  *
>>>
>>> *Tel: +49 30 209347931  *
>>>
>>
>>
>
>
> --
> ​
> --
> *​--*
> *Mohamed Ibrahim  *
>
> *Humboldt University   *
> *Berlin, Germany  *
>
> *Tel: +49 30 209347931  *
>

Re: [COOT] Calculating sigma value

[Ian Tickle]

Historical note: the FFT algorithm was originally discovered by Carl
Friedrich Gauss in 1866 (though not published), not by Cooley & Tukey in
1965 as is often stated.  Cooley & Tukey rediscovered it independently,
unaware of Gauss's work.

Gauss, Carl Friedrich <https://en.wikipedia.org/wiki/Carl_Friedrich_Gauss>
(1866). "Theoria interpolationis methodo nova tractata" [Theory regarding a
new method of interpolation]. *Nachlass*
<https://babel.hathitrust.org/cgi/pt?id=uc1.c2857678;view=1up;seq=279>
(Unpublished manuscript). Werke (in Latin and German). *3*. Göttingen,
Germany: Königlichen Gesellschaft der Wissenschaften zu Göttingen.
pp. 265–303.

Cooley, James W. <https://en.wikipedia.org/wiki/James_Cooley>; Tukey, John
W. <https://en.wikipedia.org/wiki/John_Tukey> (1965). "An algorithm for the
machine calculation of complex Fourier series"
<http://www.ams.org/mcom/1965-19-090/S0025-5718-1965-0178586-1/>. *Mathematics
of Computation <https://en.wikipedia.org/wiki/Mathematics_of_Computation>*.
*19* (90): 297–301.

Cooley, James W. <https://en.wikipedia.org/wiki/James_W._Cooley> (1987). *The
Re-Discovery of the Fast Fourier Transform Algorithm*
<https://carma.newcastle.edu.au/jon/Preprints/Talks/CARMA-CE/FFT.pdf> (PDF).
*Mikrochimica Acta*. *III*. Vienna, Austria. pp. 33–45.

Cheers

-- Ian


On 19 April 2018 at 14:18, Ian Tickle  wrote:

>
> Correction: maps are produced by Refmac & FFT.  Original references are:
>
> Read, R.J.: Acta Cryst. A42 (1986) 140-149 for map coefficients, and type
> 'FFT' in Wikipedia for FFT algorithm & references.
>
> Cheers
>
> -- Ian
>
>
> On 19 April 2018 at 13:57, Ian Tickle  wrote:
>
>>
>> Hi, first maps are produced by Refmac, not Coot, and second it shouldn't
>> be called sigma because it's not an uncertainty, it's a root-mean-square
>> deviation from the mean.  The equation for the RMSD can be found in any
>> basic text on statistics, e.g. just type 'RMSD' in Wikipedia.
>>
>> Cheers
>>
>> -- Ian
>>
>>
>> On 19 April 2018 at 13:20, Mohamed Ibrahim 
>> wrote:
>>
>>> Dear COOT users,
>>>
>>> Do you know how to extract the equations that COOT uses for generating
>>> the maps and calculating the sigma values?
>>>
>>> Best regards,
>>> Mohamed
>>>
>>> --
>>> ​
>>> --
>>> *​--*
>>> *Mohamed Ibrahim  *
>>>
>>> *Humboldt University   *
>>> *Berlin, Germany  *
>>>
>>> *Tel: +49 30 209347931  *
>>>
>>
>>
>

Re: [COOT] Calculating sigma value

[Ian Tickle]

Correction: maps are produced by Refmac & FFT.  Original references are:

Read, R.J.: Acta Cryst. A42 (1986) 140-149 for map coefficients, and type
'FFT' in Wikipedia for FFT algorithm & references.

Cheers

-- Ian


On 19 April 2018 at 13:57, Ian Tickle  wrote:

>
> Hi, first maps are produced by Refmac, not Coot, and second it shouldn't
> be called sigma because it's not an uncertainty, it's a root-mean-square
> deviation from the mean.  The equation for the RMSD can be found in any
> basic text on statistics, e.g. just type 'RMSD' in Wikipedia.
>
> Cheers
>
> -- Ian
>
>
> On 19 April 2018 at 13:20, Mohamed Ibrahim 
> wrote:
>
>> Dear COOT users,
>>
>> Do you know how to extract the equations that COOT uses for generating
>> the maps and calculating the sigma values?
>>
>> Best regards,
>> Mohamed
>>
>> --
>> ​
>> --
>> *​--*
>> *Mohamed Ibrahim  *
>>
>> *Humboldt University   *
>> *Berlin, Germany  *
>>
>> *Tel: +49 30 209347931  *
>>
>
>

Re: [COOT] Calculating sigma value

[Ian Tickle]

Hi, first maps are produced by Refmac, not Coot, and second it shouldn't be
called sigma because it's not an uncertainty, it's a root-mean-square
deviation from the mean.  The equation for the RMSD can be found in any
basic text on statistics, e.g. just type 'RMSD' in Wikipedia.

Cheers

-- Ian


On 19 April 2018 at 13:20, Mohamed Ibrahim 
wrote:

> Dear COOT users,
>
> Do you know how to extract the equations that COOT uses for generating the
> maps and calculating the sigma values?
>
> Best regards,
> Mohamed
>
> --
> ​
> --
> *​--*
> *Mohamed Ibrahim  *
>
> *Humboldt University   *
> *Berlin, Germany  *
>
> *Tel: +49 30 209347931  *
>

Re: [COOT] CHO H-bonds.

[Ian Tickle]

Hi Jan

Thanks for the suggestion.  I checked & AFAICS the wavelength is correct.
I think in any case the difference you are talking about would be far too
small to explain the effect I'm seeing (the error in the wavelength is ~
0.01% whereas I'm seeing deviations from the ideal vdW contact of up to
15%!).

My conclusion is that this is not due to any kind of error, it is a real
effect.  CH...O bonds are well-documented (thanks to Patrick Loll and Scott
Horowitz for useful references), even though it appears that MP (and PDB
validation) takes absolutely no account of them!

Cheers

-- Ian


On 2 July 2015 at 08:27, Jan Stransky  wrote:

>  About the unit cell shrinkage:
>
> I have heard a lecture (I believe it was Andrea Thorn form G. Sheldrick
> group on one of CCP4 meetings), where she mentioned a mistake in X-ray
> wavelenght input (swaped 3rd and 4th digit), which no program from
> integration to structure solution did not recognised. It appeared in
> structure refinement in wrong bond distances.
>
> Worth of checking.
>
> Jan
>
>
> On 07/01/2015 10:58 AM, Ian Tickle wrote:
>
>
>  Paul, as an aside to this, would it be possible to have it so that if the
> relevant boxes in the "Environment Distances" menu are checked then H-bonds
> and.or bumps are automatically re-calculated on re-centering?  Currently
> it's necessary to check off & on one of the boxes every time the view is
> re-centered.  If I forget to do that it's very easy to miss bumps (and I
> don't have a great deal of faith in MP's concept of what constitutes a
> bump)!
>
>  Cheers
>
>  -- Ian
>
>
> On 30 June 2015 at 14:33, Ian Tickle  wrote:
>
>>
>>  Hello All
>>
>>  I guess this is really a question about MolProbity (and possibly about
>> autoBuster) but I assume that most Coot users will be using the MolProbity
>> validation tools.
>>
>>  I am in the process of depositing 4 structures of the same protein
>> (different ligands) and I noticed that MP seems to be reporting an
>> unusually large number of bumps in both the "small overlap" and "bad
>> overlap" classes.  In each case the resolution is 2 Ang., the structures
>> have been refined by autoBuster and the density seems to be unequivocal,
>> see e.g.:
>>
>>
>> https://drive.google.com/file/d/0B4H4H-DyO60-SEQwS1k5S3RIVG8/view?usp=sharing
>>
>>  A lot of the bumps are main-chain CHalpha to main-chain carbonyl O
>> H-bonds, but there are also some CH...O side-chain H-bonds, again with
>> clear density.  The C...O distances are in the range 3.0 to 3.2 Ang., so
>> too short for a vdW contact.  The H...O distances are ~ 2.2 Ang. which is
>> definitely shorter than the sum of the vdW radii ( H: 1.2 + O: 1.5 = 2.7).
>>
>>  I found this survey of CH...O H-bonds but it's restricted to CH...O
>> bonds at the end of helices and I see them mostly in sheets.
>>
>> http://www.mrc-lmb.cam.ac.uk/genomes/madanm/pdfs/chapter1.pdf
>>
>>  This reports 11 examples (i.e. H-bonds, not structures) in the 3.0-3.2
>> range for the whole of the PDB (admittedly as it was in 2001 when the
>> article appears to have been written).  I have about the same number in one
>> structure!
>>
>>  One possibility I considered was that the unit cells had all somehow
>> 'shrunk'.  This can be tested with WhatCheck: however it only reports a
>> very small shrinkage which translates to an error of ~ 0.02 Ang. in a 3
>> Ang. distance, which is nowhere near enough to explain a discrepancy of 0.5
>> Ang.
>>
>>  So I guess my question is has anyone else noticed this in their MP
>> dot-plots; also does anyone know what criteria does MP uses for testing
>> bumps and specifically what value is it using for CH...O H-bonds?  And of
>> course I'd like to know whether this will affect my percentile ranking in
>> the clashscore from the PDB validation!
>>
>>  Cheers
>>
>>  -- Ian
>>
>>
>
> --
> Jan Stransky, PhD student
> Institute of Biotechnology, CAS
> Laboratory of structure and function of biomolecules
> Nad Safinou II 366
> Vestec
> Czech Republic
>
> Tel.: +420226201570
>
>

Re: [COOT] CHO H-bonds.

[Ian Tickle]

Paul, as an aside to this, would it be possible to have it so that if the
relevant boxes in the "Environment Distances" menu are checked then H-bonds
and.or bumps are automatically re-calculated on re-centering?  Currently
it's necessary to check off & on one of the boxes every time the view is
re-centered.  If I forget to do that it's very easy to miss bumps (and I
don't have a great deal of faith in MP's concept of what constitutes a
bump)!

Cheers

-- Ian


On 30 June 2015 at 14:33, Ian Tickle  wrote:

>
> Hello All
>
> I guess this is really a question about MolProbity (and possibly about
> autoBuster) but I assume that most Coot users will be using the MolProbity
> validation tools.
>
> I am in the process of depositing 4 structures of the same protein
> (different ligands) and I noticed that MP seems to be reporting an
> unusually large number of bumps in both the "small overlap" and "bad
> overlap" classes.  In each case the resolution is 2 Ang., the structures
> have been refined by autoBuster and the density seems to be unequivocal,
> see e.g.:
>
>
> https://drive.google.com/file/d/0B4H4H-DyO60-SEQwS1k5S3RIVG8/view?usp=sharing
>
> A lot of the bumps are main-chain CHalpha to main-chain carbonyl O
> H-bonds, but there are also some CH...O side-chain H-bonds, again with
> clear density.  The C...O distances are in the range 3.0 to 3.2 Ang., so
> too short for a vdW contact.  The H...O distances are ~ 2.2 Ang. which is
> definitely shorter than the sum of the vdW radii ( H: 1.2 + O: 1.5 = 2.7).
>
> I found this survey of CH...O H-bonds but it's restricted to CH...O bonds
> at the end of helices and I see them mostly in sheets.
>
> http://www.mrc-lmb.cam.ac.uk/genomes/madanm/pdfs/chapter1.pdf
>
> This reports 11 examples (i.e. H-bonds, not structures) in the 3.0-3.2
> range for the whole of the PDB (admittedly as it was in 2001 when the
> article appears to have been written).  I have about the same number in one
> structure!
>
> One possibility I considered was that the unit cells had all somehow
> 'shrunk'.  This can be tested with WhatCheck: however it only reports a
> very small shrinkage which translates to an error of ~ 0.02 Ang. in a 3
> Ang. distance, which is nowhere near enough to explain a discrepancy of 0.5
> Ang.
>
> So I guess my question is has anyone else noticed this in their MP
> dot-plots; also does anyone know what criteria does MP uses for testing
> bumps and specifically what value is it using for CH...O H-bonds?  And of
> course I'd like to know whether this will affect my percentile ranking in
> the clashscore from the PDB validation!
>
> Cheers
>
> -- Ian
>
>

[COOT] CHO H-bonds.

[Ian Tickle]

Hello All

I guess this is really a question about MolProbity (and possibly about
autoBuster) but I assume that most Coot users will be using the MolProbity
validation tools.

I am in the process of depositing 4 structures of the same protein
(different ligands) and I noticed that MP seems to be reporting an
unusually large number of bumps in both the "small overlap" and "bad
overlap" classes.  In each case the resolution is 2 Ang., the structures
have been refined by autoBuster and the density seems to be unequivocal,
see e.g.:

https://drive.google.com/file/d/0B4H4H-DyO60-SEQwS1k5S3RIVG8/view?usp=sharing

A lot of the bumps are main-chain CHalpha to main-chain carbonyl O H-bonds,
but there are also some CH...O side-chain H-bonds, again with clear
density.  The C...O distances are in the range 3.0 to 3.2 Ang., so too
short for a vdW contact.  The H...O distances are ~ 2.2 Ang. which is
definitely shorter than the sum of the vdW radii ( H: 1.2 + O: 1.5 = 2.7).

I found this survey of CH...O H-bonds but it's restricted to CH...O bonds
at the end of helices and I see them mostly in sheets.

http://www.mrc-lmb.cam.ac.uk/genomes/madanm/pdfs/chapter1.pdf

This reports 11 examples (i.e. H-bonds, not structures) in the 3.0-3.2
range for the whole of the PDB (admittedly as it was in 2001 when the
article appears to have been written).  I have about the same number in one
structure!

One possibility I considered was that the unit cells had all somehow
'shrunk'.  This can be tested with WhatCheck: however it only reports a
very small shrinkage which translates to an error of ~ 0.02 Ang. in a 3
Ang. distance, which is nowhere near enough to explain a discrepancy of 0.5
Ang.

So I guess my question is has anyone else noticed this in their MP
dot-plots; also does anyone know what criteria does MP uses for testing
bumps and specifically what value is it using for CH...O H-bonds?  And of
course I'd like to know whether this will affect my percentile ranking in
the clashscore from the PDB validation!

Cheers

-- Ian

Re: [COOT] Negative & positive contours for neutron map.

[Ian Tickle]

Thanks Paul, (and for the swift response!).

-- Ian

On 24 May 2015 at 17:16, Paul Emsley  wrote:

>
>
> On 24/05/2015 16:57, Ian Tickle wrote:
>
>>
>> Hello, does anyone know how to simultaneously display negative & positive
>> contours for a neutron 2Fo-Fc map?
>>
>> For example, as in Fig. 2 here:
>>
>>
>> http://www.researchgate.net/profile/Toshiyuki_Chatake/publication/224014577_High_resolution_neutron_protein_crystallography._Hydrogen_and_hydration_in_proteins/links/004635165b7b2dbfcb00.pdf
>>
>
> (set-map-is-difference-map imol)
>
> or read in the map twice and contour it with a negative level, e.g.:
>
> (set-contour-level-absolute imol -0.5)
>
> Then you can have easier colouring.
>
> Paul.
>
>
>

[COOT] Negative & positive contours for neutron map.

[Ian Tickle]

Hello, does anyone know how to simultaneously display negative & positive
contours for a neutron 2Fo-Fc map?

For example, as in Fig. 2 here:

http://www.researchgate.net/profile/Toshiyuki_Chatake/publication/224014577_High_resolution_neutron_protein_crystallography._Hydrogen_and_hydration_in_proteins/links/004635165b7b2dbfcb00.pdf

Cheers

-- Ian

Re: [COOT] Reading multichart script into WInCoot.

[Ian Tickle]

On 27 March 2015 at 19:16, Paul Emsley  wrote:

>
> There might be a python version of these available from the Molprobity
> server.  It should be straightforward for them to make it if not.
>

OK after some digging in the MP distribution (i.e. find/xargs/grep) I found
that if you use 'multichart-cluster-coot' instead of 'multichart-coot'
(same usage) you get both Scheme and Python scripts and the Python one
works in WinCoot!

Not sure what the 'cluster' part refers to though (and Google throws no
light on it).

Cheers

-- Ian

[COOT] Reading multichart script into WInCoot.

[Ian Tickle]

Hello All

I'm trying to read the script from multichart into WinCoot.  I do:

> multichart-coot reduce.pdb > reduce.scm

but when I select Calculate -> Run Script absolutely nothing happens,
there's no error message on the console, nothing.

I'm assuming this is because WinCoot doesn't recognise Scheme scripts.  So
my question is: is there a way to generate the equivalent Python script, or
alternatively does someone has a jiffy script to do the conversion?  I'm
assuming one of these solutions exists because in the MolProbity tutorials
it mentions downloading Python versions of the Scheme scripts.

Cheers

-- Ian

Re: [COOT] Selecting columns from MTZ file

[Ian Tickle]

Paul, I'm having trouble accessing the md5sums on
http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/binaries/release/ ,
though the tar.gzs themselves seem to be OK.  I get "source file could not
be read." on all of them.  Could you check it out?

Cheers

-- Ian


On 10 December 2013 11:47, Paul Emsley  wrote:

> On 04/12/13 21:10, Robert Oeffner wrote:
>
>> Hi,
>>
>> I'm customising a small script for displaying the Patterson map from an
>> MTZ file. As the names of the columns is arbitrary I wonder if there is a
>> function available in Coot that lists the names of the columns in the MTZ
>> file. It should be similar to the drop down list you get when you open an
>> MTZ file through the menu "File | Open MTZ" that lets you select what
>> columns to use for drawing the electron density map.
>>
>>
> Hi Rob,
>
> This is now available (as of r4839). Example usage:
>
> import coot
> a = coot.get_mtz_columns("test.mtz")
> for i in range(a.f_cols.size()):
> print a.f_cols[i].column_label
> for i in range(a.phi_cols.size()):
> print a.phi_cols[i].column_label
>
> Paul.
>

Re: [COOT] --auto column labels

[Ian Tickle]

Hi Graeme

This has nothing to do with Randy's 1986 paper on minimally-biased map
coefficients from partial structures (which I assume is the one you're
referring to) since as you said yourself these are experimental, not
partial structure, phases.  Rather, this is Blow & Crick's (1959)
result where they showed that coefficients m*F with the centroid phase
give the electron density with the least mean-square error over the
unit cell.  But maybe the error in the density is not something you
need to worry about, since if the signal/noise ratio is sufficiently
high the peaks will stand out against the background anyway?

Paul's solution looks like the best one (once tested!).

Cheers

-- Ian

On 24 May 2012 10:38,   wrote:
> Hi Tim,
>
> Thanks, this seems like a good plan. As I don't get to do much refinement I 
> have never really spent much time worrying about FWT, FOM etc. I should read 
> Randy's papers more I guess.
>
> Best wishes,
>
> Graeme
>
> BTW - does everyone have to confirm every message to the mailing list?
>
>
> -Original Message-
> From: Mailing list for users of COOT Crystallographic Software 
> [mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Tim Gruene
> Sent: 24 May 2012 10:31
> To: COOT@JISCMAIL.AC.UK
> Subject: Re: --auto column labels
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Graeme,
>
> So far I never noticed any difference between using or not using FOM into 
> account from a phs-file, so if you only want to display the resulting map 
> from shelxe DM I would not bother about whether this is mathematically 
> correct.
>
> I DON'T think FWT=F*FOM: as far as I understand FWT are the sigmaA weighted 
> amplitudes and I don't think shelxe calculates sigmaA weighted coefficients.
>
> Regards,
> Tim
>
> On 05/24/12 10:47, graeme.win...@diamond.ac.uk wrote:
>> Hi Tim,
>>
>> A good answer, but I thought FWT = F * FOM? So this would not include
>> the FOM's for the reflections? If I have this wrong that would be
>> great.
>>
>> Thanks,
>>
>> Graeme
>>
>> -Original Message- From: Tim Gruene
>> [mailto:t...@shelx.uni-ac.gwdg.de] Sent: 24 May 2012 09:46 To:
>> Winter, Graeme (DLSLtd,RAL,DIA) Cc: COOT@JISCMAIL.AC.UK Subject:
>> Re: --auto column labels
>>
>> Hi Graeme, why don't you name the column types FWT and PHWT as you
>> convert the phs-file to mtz?
>>
>> You can also read in the phs-file directly given a cell, although I am
>> not aware of an automated way.
>>
>> Cheers, Tim
>>
>> On 05/24/12 10:27, graeme.win...@diamond.ac.uk wrote:
>>> Hi Folks,
>>
>>> I would like to load a phased mtz file from shelxe / convert2mtz
>>> automatically in coot:
>>
>>> (from mtzdmp)
>>
>>> * Column Labels :
>>
>>> H K L F FOM PHI SIGF FreeF_flag
>>
>>> * Column Types :
>>
>>> H H H F W P Q I
>>
>>> * Associated datasets :
>>
>>> 0 0 0 0 0 0 0 0
>>
>>> I see from the manual I need:
>>
>>> --auto filename for auto-reading mtz files (mtz file has the default
>>> labels FWT, PHWT)
>>
>>> Is there an easy way to join these up? I just want to be able to
>>> inspect the map. I use this already to automatically show results
>>> from refmac, which works very nicely indeed.
>>
>>> Many thanks,
>>
>>> Graeme
>>
>>
>>
>
> - --
> - --
> 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/
>
> iD8DBQFPvf/oUxlJ7aRr7hoRAnNbAKDbFMAUwqUGoijyV1JdjrS1xQDB/ACggTZ8
> UV1zCe/IdRwpeaeFhSydtxU=
> =RyGN
> -END PGP SIGNATURE-

Re: [COOT] --auto column labels

[Ian Tickle]

Hi Graeme

Sorry yes I failed to notice it's shelxe this is coming from, not
shelxl.  Can't you just use sftools to do the multiplication m*F ?

Cheers

Ian

On 24 May 2012 10:26,   wrote:
> Hi Ian,
>
> We do something similar for our difference map pipeline, however this is 
> experimental phasing so we don't (at this stage) have any coordinates beyond 
> the substructure. Including the shelxe chain tracing is on the cards, but 
> this takes a little while and we're trying to pack a lot into a short time.
>
> Many thanks,
>
> Graeme
>
> -Original Message-
> From: Ian Tickle [mailto:ianj...@gmail.com]
> Sent: 24 May 2012 10:20
> To: Winter, Graeme (DLSLtd,RAL,DIA)
> Cc: COOT@jiscmail.ac.uk
> Subject: Re: --auto column labels
>
> Hi Graeme
>
> The way I would do it would be to ignore the output MTZ and use the refined 
> co-ordinates with the original HKLF file converted to MTZ in a run of Refmac 
> with 0 cycles (and unrestrained to avoid having to worry about any ligand 
> dictionaries).  That way you get the correct coefficients with the correct 
> labels (and you get the difference map as a bonus!).
>
> Cheers
>
> -- Ian
>
>
> On 24 May 2012 09:27,   wrote:
>> Hi Folks,
>>
>>
>>
>> I would like to load a phased mtz file from shelxe / convert2mtz
>> automatically in coot:
>>
>>
>>
>> (from mtzdmp)
>>
>>
>>
>> * Column Labels :
>>
>>
>>
>> H K L F FOM PHI SIGF FreeF_flag
>>
>>
>>
>> * Column Types :
>>
>>
>>
>> H H H F W P Q I
>>
>>
>>
>> * Associated datasets :
>>
>>
>>
>> 0 0 0 0 0 0 0 0
>>
>>
>>
>> I see from the manual I need:
>>
>>
>>
>> --auto filename for auto-reading mtz files (mtz file has the default
>> labels FWT, PHWT)
>>
>>
>>
>> Is there an easy way to join these up? I just want to be able to
>> inspect the map. I use this already to automatically show results from
>> refmac, which works very nicely indeed.
>>
>>
>>
>> Many thanks,
>>
>>
>>
>> Graeme
>
> --
> This e-mail and any attachments may contain confidential, copyright and or 
> privileged material, and are for the use of the intended addressee only. If 
> you are not the intended addressee or an authorised recipient of the 
> addressee please notify us of receipt by returning the e-mail and do not use, 
> copy, retain, distribute or disclose the information in or attached to the 
> e-mail.
> Any opinions expressed within this e-mail are those of the individual and not 
> necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
> attachments are free from viruses and we cannot accept liability for any 
> damage which you may sustain as a result of software viruses which may be 
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and 
> Wales with its registered office at Diamond House, Harwell Science and 
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
>

Re: [COOT] --auto column labels

[Ian Tickle]

Hi Graeme

The way I would do it would be to ignore the output MTZ and use the
refined co-ordinates with the original HKLF file converted to MTZ in a
run of Refmac with 0 cycles (and unrestrained to avoid having to worry
about any ligand dictionaries).  That way you get the correct
coefficients with the correct labels (and you get the difference map
as a bonus!).

Cheers

-- Ian


On 24 May 2012 09:27,   wrote:
> Hi Folks,
>
>
>
> I would like to load a phased mtz file from shelxe / convert2mtz
> automatically in coot:
>
>
>
> (from mtzdmp)
>
>
>
> * Column Labels :
>
>
>
> H K L F FOM PHI SIGF FreeF_flag
>
>
>
> * Column Types :
>
>
>
> H H H F W P Q I
>
>
>
> * Associated datasets :
>
>
>
> 0 0 0 0 0 0 0 0
>
>
>
> I see from the manual I need:
>
>
>
> --auto filename for auto-reading mtz files (mtz file has the default labels
> FWT, PHWT)
>
>
>
> Is there an easy way to join these up? I just want to be able to inspect the
> map. I use this already to automatically show results from refmac, which
> works very nicely indeed.
>
>
>
> Many thanks,
>
>
>
> Graeme

Re: [COOT] Version 7 not repainting screen after initial load.

[Ian Tickle]

>> I just spotted one minor infelicity: when it starts it pops up a
>> window "Fix Nomenclature Errors" (which is very nice).  However if I
>> close this it still remains visible but inactive.  The same thing
>> happens if I open other dialogs, so eventually I can cover the screen
>> with inactive dialogs!  So it looks like it's not repainting the main
>> window when the dialog window is closed.  This didn't happen with v6.
>> I can however force a repaint by minimising and maximising the window,
>> and after that the dialog windows behave normally.
>
>
> Sounds like a driver bug.  Although why it should be different for different
> coot versions, I do not know.

Just for the record, and in case anyone else hits this problem, I
found a fix.  Upgrading the BIOS and graphics driver to the latest
versions had absolutely no effect.  However all I had to do to fix it
was increase the display resolution from 1024x768 to either 1152x864
or 1280x1024.  So it looks like a driver bug as you said, just at the
1024x768 setting.  This is no doubt hardware dependent (it's a Dell
OptiPlex 790 with i5-2400 CPU and Integrated Intel HD 2000 Graphics).

Cheers

-- Ian

[COOT] Version 7 not repainting screen after initial load.

[Ian Tickle]

Hello, I just installed WinCoot_0.7-pre-1-4040 (because I kept getting
the message "this is an old Coot" from version 0.6.2.1 !).

I just spotted one minor infelicity: when it starts it pops up a
window "Fix Nomenclature Errors" (which is very nice).  However if I
close this it still remains visible but inactive.  The same thing
happens if I open other dialogs, so eventually I can cover the screen
with inactive dialogs!  So it looks like it's not repainting the main
window when the dialog window is closed.  This didn't happen with v6.
I can however force a repaint by minimising and maximising the window,
and after that the dialog windows behave normally.  Also is there a
way to disable the initial "Fix Nomenclature Errors" pop-up (couldn't
see anything in the manual).  I don't want to fix them right away
(because it's not my structure), and it keeps reminding me every time!

Cheers

-- Ian

Re: [COOT] New restraints, same name

[Ian Tickle]

On 24 January 2012 17:53, Paul Emsley  wrote:
> Now that Coot uses the restraints dictionary to render ligands it has become
> apparent that the method of doing so is problematic for typical working
> situations.
>
> Say for example your read in
> complex-XYZ00123456.pdb in which the ligand is called LIG
> You read in the dictionary for XYZ00123456 and the ligand looks fine.
>
> Now read in
> complex-XYZ00123457.pdb in which the ligand is called LIG
> Different compound, same name, so same dictionary is used to render
> XYZ00123457.
> Result: tangled mess
>
> Read in dictionary for XYZ00123457 and now complex-XYZ00123457 looks fine
> but XYZ00123456 is a tangled mess because the restraints for LIG have been
> overwritten.
>
> So I am considering adding in a hack to Coot to make this situation less
> problematic.
>
> A potential hack is to specify that it is to be used for molecule number N
> (or a set of Ns) only.
>
> Doing this would make Coot internals messy so I have make this request for
> comments before I spend time reworking things and producing a solution that
> no-one will use.

Paul, the situation you describe never arises for us (Astex) simply
because we don't allow users to directly access to the filesystem
containing the data, so they simply cannot load arbitrary files from
refinements into WinCoot.  However I can see it might be a problem for
users who do load files from their filesystem.  We have a CGI script
running on the webserver which uses a unique refinement ID to identify
all the session files needed (MTZ + protein & ligand PDBs), does the
necessary security checks to ensure that the user is allowed to see
and modify the data, and if so fetches them from our Oracle DB.  The
script makes any changes to the ligand residue IDs necessary to make
them unique for the session (we use 'L01', 'L02', ... 'L99'),
generates a unique CIF for each ligand, then passes the whole lot
through to a Java linking applet ('CootLink') running in the browser,
which finally loads and fires up a Coot script on the user's PC.  At
the end of the session any changed PDBs are passed back through
CootLink and stored back in the DB as a new version ID under the same
refinement ID.  Of course the price of this automation is that someone
(i.e. me) has to maintain the scripts (such as if/when you change the
way Coot works!).  So far this has been relatively straightforward
because we only ever use Coot for building individual structures, we
never use it as a viewer, say for comparing different structures (we
only use AstexViewer for that).

So I would only ask that wherever possible changes are made in a
backwards-compatible manner, for example would it be possible that any
additional user input is optional and is only needed to resolve
ambiguities such as those you describe?  In that way the changes you
propose would be completely transparent as far as we are concerned.
Of course I appreciate that most other users do things differently and
it may not be possible to make the changes completely transparent.  If
that turns out to be the case then so be it.

Cheers

-- Ian

Re: [COOT] map level

[Ian Tickle]

On 17 January 2012 12:43, Paul Emsley  wrote:
> On 17/01/12 08:33, Dayana Nisbar wrote:
>>
>> How to change the map level from rmsd to sigma?
>
>
> You can't.  Electron density levels should not be expressed in terms of
> sigma.  Sigma refers to probability distributions - and an electron density
> map is not one of those.  I used to not understand this and there may be
> some references to "sigma" in the code/interface which I need to clean up.

But an electron density, being an experimentally determined quantity,
has an error and an error certainly does have a probability
distribution.  The standard deviation of that error distribution,
which is not the same as and should not be confused with the RMSD, is
what I assume is here being referred to as 'sigma'.  The RMSD would be
the s.d. if the electron density were to be treated as a probability
density function (which I agree it isn't); however this pseudo-PDF is
not in any case relevant to the discussion because what we are
concerned about here is the error distribution (characterised by
sigma), not the electron density distribution (characterised by the
RMSD).

When we are judging significance of the (difference) electron density
the relevant statistic is the signal/noise ratio (delta-)rho/sigma,
analogous to I/sigma for the diffraction data (no-one would think of
expressing I in terms of its RMSD!).  The s.d. (sigma) of the
difference density can be estimated from a Q-Q ('normal probability')
plot.  (Delta-)rho/RMSD has no meaning in terms of significance (it
has no meaning period), so electron densities should not expressed in
terms of RMSD, unless you can legitimately claim that the RMSD is a
good estimate of the s.d., which means that you are really expressing
it in terms of sigma.  Also it begs the question "how accurate an
estimate of the s.d. is the RMSD?" and "is a more accurate estimate
available?".

Cheers

-- Ian

Cheers

-- Ian

Re: [COOT] map level

[Ian Tickle]

On 17 January 2012 08:33, Dayana Nisbar  wrote:

> How to change the map level from rmsd to sigma?

I would guess that Coot just uses whatever value is in the map header
(as opposed to recalculating it), so you would need to arrange to put
sigma(rho) in the slot currently occupied by the RMSD.  AFAIK this can
currently only be done by the EXTENDS program, and only for difference
maps (AFAIK there's no way of doing it for 2mFo-DFc maps, even
assuming you have a reliable way of estimating sigma for 2mFo-DFc
maps).  This means you would need to read in your map (as opposed to
the MTZ file route, since that doesn't perform the sigma calculation
step).

HTH

-- Ian

Re: [COOT] reading chiral restraints from grade's cif files

[Ian Tickle]

> Just a moment, are those real tags and fields?
>
> Are you saying that a structure _chem_comp_tor (from whatever program
> produced that) doesn't have a comp_id?
> Without a comp_id coot will fail to parse both of the above.

Ooops yes, got left off when I pasted:

_chem_comp_tor.comp_id   XXX
_chem_comp_tor.idother-001
_chem_comp_tor.atom_id_1 CL
_chem_comp_tor.atom_id_2 C
_chem_comp_tor.atom_id_3 N
_chem_comp_tor.atom_id_4 H1
_chem_comp_tor.value_angle   0.0
_chem_comp_tor.value_angle_esd   100.0
_chem_comp_tor.period10

Cheers

-- Ian

Re: [COOT] reading chiral restraints from grade's cif files

[Ian Tickle]

My apologies, I just tested it without the comment & it works fine.
Maybe it was a bug once upon a time, and it was fixed.

Cheers

-- Ian

On 30 November 2011 16:16, Garib N Murshudov  wrote:
>
> If refmac requires comment after chem_comp it is a bug. It needs to be fixed. 
> I will try to fix it for next version - 5.7 series.
>
> Garib
>
>
>
> On 30 Nov 2011, at 16:08, Ian Tickle wrote:
>
>> Note that the _chem_comp and _chem_comp_tor blocks are formatted the
>> same way if there's only one compound/torsion resp. e.g.:
>>
>> _chem_comp.id                  XXX
>> _chem_comp.three_letter_code   XXX
>> _chem_comp.name                XXX
>> _chem_comp.group               .
>> _chem_comp.number_atoms_all    7
>> _chem_comp.number_atoms_nh     4
>> _chem_comp.desc_level          .
>> #
>>
>> _chem_comp_tor.id                other-001
>> _chem_comp_tor.atom_id_1         CL
>> _chem_comp_tor.atom_id_2         C
>> _chem_comp_tor.atom_id_3         N
>> _chem_comp_tor.atom_id_4         H1
>> _chem_comp_tor.value_angle       0.0
>> _chem_comp_tor.value_angle_esd   100.0
>> _chem_comp_tor.period            10
>>
>> Just as a matter of interest, I take it that Refmac, Libcheck,
>> Sketcher etc all accept this fprmat?  I agree that if it's using a
>> proper CIF reader it should be able to handle this without blinking.
>> I'm pretty sure Refmac doesn't (or didn't when I tested it some time
>> ago, maybe it's been fixed), because it requires that the _chem_comp
>> block (only) be terminated by a comment line (as in the example):
>> that's definitely not in the spec.
>>
>> Cheers
>>
>> -- Ian
>>
>> On 30 November 2011 15:34, Judit Debreczeni  
>> wrote:
>>> On 30 November 2011 15:06, Paul Emsley  wrote:
>>>> On 30/11/11 10:52, Judit Debreczeni wrote:
>>>>>
>>>>> Grade (from Global Phasing) produces cif files with non-loop_
>>>>> descriptions of chiral restraints, e.g.:
>>>>>
>>>>> _chem_comp_chir.comp_id          INH
>>>>> _chem_comp_chir.id               chir_01
>>>>> _chem_comp_chir.atom_id_centre   C1
>>>>> _chem_comp_chir.atom_id_1        C
>>>>> _chem_comp_chir.atom_id_2        C2
>>>>> _chem_comp_chir.atom_id_3        O
>>>>> _chem_comp_chir.volume_sign      negativ
>>>>>
>>>>>
>>>>> This format seems correct to me and actually makes a lot of sense if
>>>>> there is only one chiral centre in the molecule.
>>>>>
>>>>> Coot, however, ignores such records entirely, so the chirality remains
>>>>> unrestrained, cannot be edited in the restraints editor or flipped by
>>>>> a keystroke. Using 0.7-pre-1 (revision 3792)  [with guile 1.8.7
>>>>> embedded] [with python 2.7.0 embedded].
>>>>>
>>>>> Bug? Oversight? Feature?
>>>>>
>>>>>
>>>>
>>>> Oversight.  I didn't think that anyone would be so contrary as to format
>>>> their chirality in such a way (it seems to me that they must have gone out
>>>> of their way to do so - I wonder why...)
>>>>
>>>
>>>
>>> Contrary? -- We are talking about the genuine and vanilla RCSB cif
>>> parser which I thought should be the gold standard?
>>>
>>>
>>>> Anyway, it's something that I should fix.  I'll add it for 0.7.
>>>>
>>>
>>>
>>> Thanks.
>>>
>>> JED.
>>>
>
>

Re: [COOT] reading chiral restraints from grade's cif files

[Ian Tickle]

Note that the _chem_comp and _chem_comp_tor blocks are formatted the
same way if there's only one compound/torsion resp. e.g.:

_chem_comp.id  XXX
_chem_comp.three_letter_code   XXX
_chem_comp.nameXXX
_chem_comp.group   .
_chem_comp.number_atoms_all7
_chem_comp.number_atoms_nh 4
_chem_comp.desc_level  .
#

_chem_comp_tor.idother-001
_chem_comp_tor.atom_id_1 CL
_chem_comp_tor.atom_id_2 C
_chem_comp_tor.atom_id_3 N
_chem_comp_tor.atom_id_4 H1
_chem_comp_tor.value_angle   0.0
_chem_comp_tor.value_angle_esd   100.0
_chem_comp_tor.period10

Just as a matter of interest, I take it that Refmac, Libcheck,
Sketcher etc all accept this fprmat?  I agree that if it's using a
proper CIF reader it should be able to handle this without blinking.
I'm pretty sure Refmac doesn't (or didn't when I tested it some time
ago, maybe it's been fixed), because it requires that the _chem_comp
block (only) be terminated by a comment line (as in the example):
that's definitely not in the spec.

Cheers

-- Ian

On 30 November 2011 15:34, Judit Debreczeni  wrote:
> On 30 November 2011 15:06, Paul Emsley  wrote:
>> On 30/11/11 10:52, Judit Debreczeni wrote:
>>>
>>> Grade (from Global Phasing) produces cif files with non-loop_
>>> descriptions of chiral restraints, e.g.:
>>>
>>> _chem_comp_chir.comp_id          INH
>>> _chem_comp_chir.id               chir_01
>>> _chem_comp_chir.atom_id_centre   C1
>>> _chem_comp_chir.atom_id_1        C
>>> _chem_comp_chir.atom_id_2        C2
>>> _chem_comp_chir.atom_id_3        O
>>> _chem_comp_chir.volume_sign      negativ
>>>
>>>
>>> This format seems correct to me and actually makes a lot of sense if
>>> there is only one chiral centre in the molecule.
>>>
>>> Coot, however, ignores such records entirely, so the chirality remains
>>> unrestrained, cannot be edited in the restraints editor or flipped by
>>> a keystroke. Using 0.7-pre-1 (revision 3792)  [with guile 1.8.7
>>> embedded] [with python 2.7.0 embedded].
>>>
>>> Bug? Oversight? Feature?
>>>
>>>
>>
>> Oversight.  I didn't think that anyone would be so contrary as to format
>> their chirality in such a way (it seems to me that they must have gone out
>> of their way to do so - I wonder why...)
>>
>
>
> Contrary? -- We are talking about the genuine and vanilla RCSB cif
> parser which I thought should be the gold standard?
>
>
>> Anyway, it's something that I should fix.  I'll add it for 0.7.
>>
>
>
> Thanks.
>
> JED.
>

Re: [COOT] Environment variable for 'examples' directory?

[Ian Tickle]

Paul,

OK maybe I did a bit of loose interpretation of the documentation on
'Extensions -> Modelling -> Replace Residue...' and did a bit of
extrapolation to '... -> Monomer from dictionary' but whether you
intended it or not, it certainly works in the way I described and very
handy it is too!  It's great watching a programmer's face when you
tell him that his software has nice features that weren't intended -
almost like machine intelligence!  Anyway, we don't use ccp4i a great
deal (at least it's not linked with our LIMS), and a soft link would
require changes to be made to the Coot installation which is what I'm
trying to avoid, and anyway I've no idea if soft links work in the
same way in Windows (I believe they're called 'shortcuts') as in
Linux.  Specifically it would require the existing files in 'examples'
(which admittedly only consist of an Rnase MTZ & PDB file) to be moved
to my personal area each time I install a new Coot.  Somewhere in your
software you must either have set an environment variable or you have
the 'examples' directory hard-wired for the 'Replace Residue' and
'Monomer from dictionary' functions (and maybe others too), or maybe
you're even searching the whole installation tree for CIF files,
otherwise how does it know where to find my files?  I certainly
haven't told it anywhere that they're in the 'examples' directory.

If there isn't such an environment variable already defined, I can
live with that (for now ;-) ).

Cheers

-- Ian

On Thu, Mar 4, 2010 at 1:57 PM, Paul Emsley  wrote:
> Ian Tickle wrote:
>>
>> Quick question: is there an environment variable in WinCoot which
>> points to the directory where 'Extensions->Modelling->Monomer from
>> dictionary' gets its files?  This is the '%COOT_PREFIX%/examples'
>> directory by default.  I couldn't see anything relevant in the
>> documentation (e.g. section 1.5 'Environment variables').
>>
>> If I start runwincoot.bat from a link I can specify a 'Start in'
>> directory in Properties to be anywhere I like, but I'd like to do the
>> same from inside runwincoot.bat.  This will save me having to copy my
>> private collection of monomer dictionaries every time a new version of
>> Coot comes along.
>>
>>
>>
>
> I had to look up what this function actually does :)
>
> OK, so it presumes that you have read in a cif file that contains
> coordinates typically (a fragment of) the Chemical Component Library.
>  That's why there is no dictionary, because the data come from your file. So
> much I guess you know.
>
> Perhaps I am misunderstanding you, but it seems that you suggest that if you
> put cif files COOT_PREFIX/examples and use
>
> Extensions->Modelling->Monomer from dictionary...
>
> then coot will automatically load files from that directory?  That is
> suprising/cool/undocumented.
>
> I don't know about COOT_PREFIX/examples (perhaps that is Bernhard's
> addition).  Thus, I don't understand the need for copying cif files.  If I
> had a directory with a personal collection of cifs, I'd use a soft link or a
> ccp4i project.
>
> Paul.
>

[COOT] Environment variable for 'examples' directory?

[Ian Tickle]

Quick question: is there an environment variable in WinCoot which
points to the directory where 'Extensions->Modelling->Monomer from
dictionary' gets its files?  This is the '%COOT_PREFIX%/examples'
directory by default.  I couldn't see anything relevant in the
documentation (e.g. section 1.5 'Environment variables').

If I start runwincoot.bat from a link I can specify a 'Start in'
directory in Properties to be anywhere I like, but I'd like to do the
same from inside runwincoot.bat.  This will save me having to copy my
private collection of monomer dictionaries every time a new version of
Coot comes along.

If there isn't one can I put in a request ...

Cheers

-- Ian

Re: [COOT] Release 0.6.1

[Ian Tickle]

On Thu, Jan 28, 2010 at 1:13 PM, Paul Emsley  wrote:

> WinCoot:
>
> http://www.ysbl.york.ac.uk/~emsley/software/binaries/stable/
>
> (actually, now that I think about it, I am not sure that this feature is in
> the WinCoot version :-)
>
> Extensions -> Refine... -> Autoweight refinement
>
> Paul.

You're right, it doesn't seem to function in WinCoot, downloading
Centos 4 version right now!

I found the auto-weight function in 'scheme/coot-utils.scm': I see it
depends on 'chi-squares', but searching for this finds only:

xserver11:~/coot-0.6.1-1189> find * -type f | xargs grep chi-squares

greg-tests/01-pdb+mtz.scm:(chi-squares (map (lambda
(x) (list-ref x 2)) nnb-list))
greg-tests/01-pdb+mtz.scm:(n (length chi-squares))
greg-tests/01-pdb+mtz.scm:(sum (apply + chi-squares)))
scheme/coot-utils.scm: (chi-squares (map (lambda (x) (list-ref
x 2)) nnb-list))
scheme/coot-utils.scm: (n (length chi-squares))
scheme/coot-utils.scm: (sum (apply + chi-squares)))

i.e. not the source for the 'chi-squares' function: is it hidden
somewhere or am I not searching for it right?

I'm puzzled how it can calculate chi-squared at all since this will
depend on (1) the SD of the Engh & Huber library values, (2) the SD of
the calculated values (which can only be obtained by doing a
full-matrix refinement in Shel-X), and most importantly (3) the
correlation coefficient between these.  Since the library and
calculated values will be highly correlated except at ultra-high
resolution (i.e. particularly at resolutions lower than ~ 2.3 the
calculated values will be determined almost completely by the library
values since 2.3 or lower data tells you almost nothing about
individual bond lengths & angles), then any estimate of chi-squared
which ignores the correlation is likely to be in error by at least a
factor of 4, i.e. the correct target value for an improperly
calculated chi-squared is likely to be ~ 0.25, not 1.0.  This value is
that which is obtained consistently as the average of all refinements
in the PDB (even including the incorrectly weighted ones!).
Unfortunately there's no way of estimating the correlation coefficient
(at least no way that I can think of!), so AFAICS the only workable
method is to use data-mining of the PDB to come up with an average
chi-squared.

Robbie Joosten & I have come up with a more accurate estimate of
chi-squared (or to be more precise its sqrt, aka the RMSZ), based just
on his recent PDB-REDO refinements that do correct weighting by
maximising the free log-likelihood.  The results exhibit significant
resolution-dependence (as you would expect it to).  This is the same
result I submitted to the VTF a while back, but of course most COOTBB
subscribers will not have seen these results.  Even a blanket
resolution-independent value of 0.25 would be a huge improvement on
1.0!

Cheers

-- Ian

[COOT] How to turn off display of negative contour level?

[Ian Tickle]

Hi, is there an easy way to turn off the display of the negative contour
level for a difference map after it has been read in?

I found a function 'set_map_is_difference_map()' to effectively turn on the
negative level, but I couldn't see one to turn it off, maybe something like
'toggle_map_is_difference_map()' ?

Cheers

-- Ian

Re: [COOT] Cysteine rotamers not working

[Ian Tickle]

On Wed, Oct 7, 2009 at 4:34 PM, Paul Emsley wrote:

> Ian Tickle wrote:
>
>
>> On Tue, Oct 6, 2009 at 8:41 AM, Paul Emsley 
>> > paul.ems...@bioch.ox.ac.uk>> wrote:
>>
>>Ian Tickle wrote:
>>
>>
>>By coincidence we just noticed exactly the same bug, i.e.
>>after creating alternate conformation for CYS A525 rotamers
>>cannot be selected, but it works fine for CYS B525.  This is
>>with WinCoot v5 & v6.
>>
>>
>>Dear Ian,
>>
>>For the record which revision is that?  I cannot reproduce.
>>
>>Regards,
>>
>>Paul.
>>
>>  Hi Paul
>>
>> Sorry it was rev 2134, but I was not able to reproduce the problem myself,
>> one problem being that the user had forgotten exactly which PDB file
>> exhibited the problem.  Anyway I just installed rev 2400 and the problem has
>> gone away, at least with the PDB file we tested.
>>
>
> OK, good!  Ready to release then.
>
> Thanks.
>
> Paul.
>

Hi Paul

Sounds good to me!  One thing that did occur to me while watching a user
manipulating a protein with several ligands (note our CGI scripts call Coot
with the protein & possibly up to 8 ligands all in separate files) was that
it might be nice to have a 'Save changed' function, otherwise the user
either has to save each molecule in turn, or remember which molecules were
changed.  Or since the exit routine knows there are unsaved changes you
could offer to save only the changed files at that point.  Maybe one for
version 7!

Cheers

-- Ian

Re: [COOT] Cysteine rotamers not working

[Ian Tickle]

By coincidence we just noticed exactly the same bug, i.e. after creating
alternate conformation for CYS A525 rotamers cannot be selected, but it
works fine for CYS B525.  This is with WinCoot v5 & v6.

Cheers

-- Ian

On Wed, Sep 30, 2009 at 1:35 PM, Martin Moche  wrote:

> Dear all,
>
> I am running coot-Linux-i386-fedora-4-gtk2 on fedora 10 linux computer.
>
> For some cysteines in my structure there is not possible to choose
> between different rotamers since the options are not visible when
> pressing "Rotamers...click on atom"
>
> I have multiple conformations of Cys213 and in chain A I could select a
> second rotamer while in the B-chain there was no option.  Multiple
> rotamers work for some cysteines in my structure but not for all?
>
> Is this a known bug?
>
> Cheers,
>
> Martin
> __
>
> Martin Moche, Ph.D., M.Sc.
> Senior scientist
> Karolinska Institutet
> MBB/SGC
> Scheeles väg 2
> 171 77 Stockholm
> Sweden
> Phone: +46-8-524 868 43
> Mob:   +46-733-229327
> Fax:   +46-8-524 868 68
> martin.mo...@ki.se
>

[COOT] Fwd: rotating chi angles of an unnatural amino acid with structure

[Ian Tickle]

Hi Evan

When it asks you to click an atom, click the main-chain N (nothing else!).
I had this problem - took me a while to work it out!

Cheers

-- Ian


On Thu, Jul 30, 2009 at 7:44 PM, Evan Kantrowitz wrote:

> Hi All,
>
>I am having problems rotating about the chi angles of an unnatural amino
> acid that is in
> my structure.  I have modified the .cif file as indicated below
>
> _chem_comp_tor.period
>  HCE  chi1 N  CA CB CG   175.000   20.000   3
>  HCE  chi2 CA CB CG C4   175.000   20.000   3
>  HCE  chi3 CB CG C4 C9   175.000   20.000   2
>
> If I go into Edit Chi angles mode, Coot recognizes the chi1-3 no problem.
>  However, if I
> rotate the chi1, or chi2  the section towards the backbone rotates and
> separates (eg the
> peptide bonds on either side break).  Is there somewhere else I need to do
> in order to
> indicate to Coot that this is a amino acid linked into the structure and
> not a ligand?  Any
> help would be appreciated.
>

[COOT] Syntax of mutate_by_overlap.

[Ian Tickle]

All - can anyone help me with the syntax of the 'mutate_by_overlap'
scripting command.  I need to mutate a CYS to a chemically-modified entity
that I've called CYD.  I made a Refmac dictionary entry for this which I
read in & it's accepted.  I'm using WinCoot so I understand I must use
Python syntax.

I've tried the following:

mutate_by_overlap(0,"A",17,"CYD")

and also every variation of adding & deleting apostrophes & quotes I can
think of: everything I try is rejected, typically with this message:

coot >> mutate_by_overlap(0,"A",17,"CYD")
BL WARNING:: Python error!
(Or you attempted to use an invalid guile command...)
Python error:
an integer is required


and in the text window:

get_monomer ("CYD")
This is not a guile command!

What does it mean by "an integer is required"?

I've got to the point where I'm tearing my hair out with this, I hope
someone has some good ideas!

Cheers

-- Ian

PS I'm using a Gmail account because the JISCmail server wouldn't send a
joining confirmation e-mail to my Astex address (I tried several times & I
think 12 hrs is long enough to wait for the e-mail to arrive): does it have
something against Astex or is it just a glitch in the server?


Ian J. Tickle, DPhil.
Director of X-ray Technology
Astex Therapeutics Ltd
436 Cambridge Science Park
Milton Road, Cambridge
CB4 0QA, UK
Tel: +44(0)1223 226214
Fax: +44(0)1223 226201
www.astex-therapeutics.com