Re: [ccp4bb] why does Coot ignore CONECT?

[Robbie Joosten]

Hi Paul,

I think this is a very good call as CONECT records are notoriously unreliable. 
Many PDB files don't have them and many programs don't update them when you 
change atom numbers. Even in annotated PDB entries there are many problems with 
those. It's better to forget about them altogether and focus on the mmCIF 
format.

Cheers,
Robbie

On 2 Nov 2019 02:15, Paul Emsley  wrote:

On 01/11/2019 20:17, Pavel Mader wrote:
> Hello,

Hello.

>
> I have a question, can anyone explain, why does Coot not display a covalent 
> bond manually specified by
> CONECT line in a pdb file?

Because I have never thought them necessary. Using SSBOND, LINK and residue 
dictionaries seemed to me to
cover the bases for which CONECT would be used.

Paul.



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




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

Re: [ccp4bb] TLS parameters

[Robbie Joosten]

Hi Eleanor,

The blocks are reliably recorded in PDB entries but in some cases the 
renumbering of residues was not pushed through to TLS groups. Certain 
selections cannot be captured in the PDB format, for instance the split in main 
chain and side chain that Refmac allows. Fortunately that feature is hardly 
used.
Parsing TLS records is not straightforward, particularly the sets from Buster 
suffered a lot from inconsistent manual editing in the early days of TLS 
refinement. PDB-REDO's extractor does a decent job in getting selections and 
changing those into Refmac format, but there are definitely cases that it 
cannot do. We also have a tool that does this for mmCIF files which is not 
written by me and (therefore) much more sophisticated in handling more 
complicated cases. 

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Eleanor
> Dodson
> Sent: Tuesday, November 19, 2019 3:59 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] TLS parameters
> 
> Does anyone know how reliably the different programs record and use these
> blocks from the PDB file?
> 
> Eleanor
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1




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

Re: [ccp4bb] technical question

[Robbie Joosten]

Or use the residue name MHO if SME has the wrong hand around the sulfur.

Cheers,
Robbie

On 29 Nov 2019 21:47, Paul Emsley  wrote:

On 29/11/2019 18:06, amit gaur wrote:

> I want to replace a particular methionine in a pdbwith methionine sulfoxide( 
> an oxidized form of
> methionine). Can body please tell me how to do this? I am familiar with 
> pymol, chimera and coot software.

In Coot:

Extensions -> Modelling -> Replace Residue -> SME -> Mutate



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




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

Re: [ccp4bb] Remember the turkey?

[Robbie Joosten]

If there is a better term because the current one is incorrect or unsuitable, 
I'm all for changing it. We changed GRID to AIDS (the name was factually wrong) 
and the names of quarks were also changed in the history of particle physics 
(because we found better terms). At the same time we still use somewhat 
derogatory terms in astrophysics (e.g. MACHO and WIMP) and in the olden days 
IDE drives still had masters and slaves and we still have loads of silly names 
(remember TWAIN?).

However, quantum advantage and quantum supremacy mean different things and 
should not be mixed. In this context it is a good term as it describes the 
state at which quantum computing can do something regular computing cannot. 
This is in stark contrast with the (anti)social use of supremacy which is 
AFAICT always factually wrong. Here, the authors make an issue (I believe out 
of virtue signaling) without coming with an adequate solution. I do not find 
that constructive at all.

Cheers,
Robbie

On 2 Jan 2020 08:29, Frank Von Delft  wrote:

Those authors raise a fair point though, don't they:  if nothing else,
"suppremacy" is an utterly daft word to use in any scientific context,
since it brings nothing technical to the table.

Before geek triumphalism became the rage (or maybe before the need for
grant-gaining hyperbole?), we might have selected adjectival phrases by
referring to style guides like Strunk and White, which consistently
emphasise informative simplicity.  But when companies get to call
themselves "Uber" without being pilloried for it I guess we know those
days are long gone.

phx.



On 26/12/2019 18:46, Bernhard Rupp wrote:
> Hi Fellows - here some light Holiday entertainment (and puzzle) for you:
>
> Remember my thanksgiving posting below?  Meant as  a hoax or satire, it 
> follows the
> classical pattern of throwing postmodern Critical Theory gibberish and Social 
> Justice key words
>   (successfully deployed by Alan Sokal)
> https://en.wikipedia.org/wiki/Sokal_affair
> onto an out-of-context situation with the purpose of virtue signaling and 
> posturing on moral high ground.
>
>   Well, we just got outdone by a letter in our favorite vanity magazine, 
> Nature:
> https://www.nature.com/articles/d41586-019-03781-0
>
> The parallels are fascinating and it exactly follows the recipe developed 
> above:
> " throwing postmodern Critical Theory gibberish and Social Justice key words 
> onto an out-of-context situation
> with the purpose to signal virtue and to opportunity for posturing on moral 
> high ground"
>
> Now - is this comment (a) meant serious or (b) another successful 
> Sokal-Turkey-type hoax?
>
> Cheers, BR
>
> --
> It has come to our attention that on this bulletin board insensitive and 
> hurtful comments have
> been made towards animals with disability. Particularly concerning is the 
> display of white privilege
> and racial bias towards a minority individual  given that the turkey is also 
> referred to in German as 'Indian'.
> In view of this non-inclusive and divisive display of unwokeness, the faculty 
> Bias Response Team
> will contact you shortly and allow you to present your self-critique.
>
> We want this board to remain a safe zone inclusive of all animals, complete 
> or not.
>
> Stuffed, BR
>
> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Jurgen Bosch
> Sent: Thursday, November 28, 2019 13:51
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Xray-dataset usable despite low completeness ?
>
> Think of completeness with an analogy to turkey.
> Say you happen to find a one-legged turkey (incomplete by conventional 
> standard) you could still stuff it and put it in the oven and enjoy 93% of 
> the turkey. The 7% missing, who cares? Other than I like both legs of the 
> turkey :-)
>
> Happy Thanksgiving everyone
>
> Jürgen
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1





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




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

Re: [ccp4bb] Refmac5 question

[Robbie Joosten]

Hi Joern,

The logic behind it this is that those are hydrogen position that are uncertain 
due to possible flips and free rotation (tyr, thr, ser). You should probably 
only set these occupancies to 1.00 after you have studies the local hydrogen 
bonding network.

Cheers,
Robbie 

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Joern
> Krausze
> Sent: Tuesday, February 4, 2020 10:24
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Refmac5 question
> 
> Dear all,
> 
> I've got a Refmac5 question. When I refine my protein structure in Refmac5
> with the options make hydrogen ALL and make hout yes, some of the
> hydrogen atoms in the output file have zero occupancies. At a first glance,
> only the the H-atoms attached to OG1 of Ser, ND2 of Asn, and NE2 of Gln are
> affected. These hydrogen atoms were present in the input file with their
> occupancies matching that of the residues they are attached to. Is there a
> reason for this behavior that I might be missing? I am currently running
> Refmac version 5.8.025.
> 
> 
> 
> 
> Best regards,
> 
> Joern
> 
> 
> --
> *
> Address:
> 
> Joern Krausze
> Department of Plant Biology
> Braunschweig University of Technology
> Spielmannstr. 7
> 38106 Braunschweig
> Germany
> 
> Email:  j.krau...@tu-braunschweig.de  braunschweig.de>
> Phone:  +49 (0)531 3915858
> *
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1




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

Re: [ccp4bb] disulfides in coot

[Robbie Joosten]

Hi Sam,

Once a disulfide bridge is made Coot will restrain the sulfur atoms to bind. 
The way out is deleting one of the side chains and adding it back while making 
sure the sulfurs do not get too close.

HTH,
Robbie

On 18 Feb 2020 11:24, Sam Tang  wrote:
Dear all

A very technical question which I believe a few simple mouse clicks would 
solve. Is there a way I can ask Coot not to build the disulfide linkage 
automatically (which lies within a strong red density)?

My WinCoot is version 0.8.9.2

Many thanks!

Regards

Sam



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




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

Re: [ccp4bb] What resolution - X-ray diffraction round this time

[Robbie Joosten]

Hi Dusan,

I don't know what the correct answer is but I think it is safe to see that your 
referee has outdated views (trying to stay polite here). I/sigI > 2.0 with 
decent completeness would be not be seen as to agressive by most (but as too 
conservative by others!). From that cut-off you could push the resolution to 
I/sigI > 1.0 by paired refinement and still be safe because you show there is 
useful information in the data.

One thing I do notice that there are still quite a lot of people overstressing 
the resolution in their manuscripts. This causes a lot of unnecessary 
discussion with referees. It is not a well established number, so don't make a 
big deal of it if the point of the paper is about biology rather than methods.

Cheers,
Robbie

On 28 Feb 2020 09:22, dusan turk  wrote:

Hi,

Browsing through the recent discussion on EM data resolution cutoff it occurred 
to me that the X-ray diffraction community isn’t that unanimous either.

My stand:

When the default resolution cutoff provided with the data processing software 
in electron density map calculation and refinement delivers quality maps 
noisier than expected and/or too high R-factors I start adjusting the 
resolution cutoff by lowering the resolution and trying alternative space 
group.   Hence, I allow the data processing programs to suggest where to draw 
the line (be it CC1/2, I/sigI, R merge, R sym, R p.i.m. and R r.i.m, …) , 
unless there are problems.

Doing so, I came into a dispute with a referee who shaped his request:

"It is well accepted that the criteria for resolution cutoff should consider 
both I/SigI and Rmerge for the outer most shell. For data sets collected at 
synchrotron sources, the criteria of I/SigI > 5 and Rmerge <50% can be taken as 
a good practical reference.”

So where do we stand? Which are the most objective criteria for resolution 
cutoff to be used in diffraction data processing? Which number of shells to use 
when calculating the statistics? Do we have a consensus?

best wishes,

dusan turk



Dr. Dusan Turk, Prof.
Head of Structural Biology Group http://stef.ijs.si/
Head of Centre for Protein  and Structure Production
Centre of excellence for Integrated Approaches in Chemistry and Biology of 
Proteins, Scientific Director
http://www.cipkebip.org/
e-mail: dusan.t...@ijs.si
phone: +386 1 477 3857   Dept. of Biochem.& Mol.& Struct. Biology
fax:  +386 1 477 3984   Jozef Stefan Institute
Jamova 39, 1 000 Ljubljana,Slovenia
Skype: dusan.turk (voice over internet: www.skype.com



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




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

Re: [ccp4bb] Hydrogens in PDB File

[Robbie Joosten]

Hi Dale,

You make very valid points and there are good reasons to keep the refined 
hydrogen positions (methyl twists an protonation of HIS are good examples). 
There is a way of distinguishing refined a modelled hydrogens in mmCIF and we 
should start using that.
About protonation of hustidines: WHAT IF does quite a decent job although there 
is room for improvement around ligands.
About maps from EDS: These were (and perhaps are) made by running 0 cycles of 
unrestrained refinement in Refmac. Unrestrained refinement takes away the need 
to sort out restraints which was an absolute nightmare at the time. A 
side-effect of unrestrained refinement is that Refmac cannot (could not) add 
hydrogens. PDB-REDO needs restraints anyway so this does 0 cycles restrained 
refinement to generate the first maps and adds hydrogens in the process. This 
addition is not that sophisticated, but it should make the maps better. Have a 
look https://pdb-redo.eu/db/3eoj.zip

Cheers,
Robbie

On 1 Mar 2020 09:26, Dale Tronrud  wrote:

Dear Ethan,

   To move away from an abstract discussion of hydrogen atoms I'd like
to describe a concrete example.  In 2008 I deposited a model of the FMO
(Bacteriochlorophyll containing) protein.  The ID code is 3EOJ.  The
model was refined to a data set cut off at 1.3 A resolution using the
criteria of the day.  I used shelxl for the final stage of refinement
and added riding hydrogen atoms to the mix.  When I deposited the model
I succumb to peer pressure and removed the hydrogen atoms.

   If you look at the map calculate by the Electron Density Server you
will see many peaks in the Fo-Fc map indicating the missing hydrogen
atoms.  (I have attached a screen-shot from Coot but I recommend that
you fire up Coot and explore the map yourself.)  In my picture you can
see the three peaks around a methyl group.  Above and to the left is the
peak for the hydrogen of a CH bridging atom in the Bacteriochlorophyll-a
ring.  To the right and in the distance is a peak for the hydrogen of a
CH2 group.  Not every hydrogen is represented by a positive peak, but
they exist throughout the map.  This Fo-Fc map is useless for the
purpose of assessing the quality of my model, since the true residuals
are hidden among all these hydrogen peaks.

   A critic might say that these peaks are simply the result of the
model being biased toward the presence of hydrogen atoms and therefore
an artifact.  A model refined to this data set w/o hydrogen atoms would
not likely show peaks indicating that hydrogen atoms need to be built.

   I would say that the map calculated from a Hydrogen-free model is the
biased one.  I am 99% confident in the location of most of the riding
hydrogen atoms and leaving them out results in a model that is
fantastically unlikely.  The absence of peaks in an apo map is a flaw in
that map.  I would describe it as "vacuum bias".  "Biasing" a model
toward reality is not a problem.

   This example shows that the current PDB is incompatible with models
whose Hydrogen atoms have been stripped.  To get proper maps and
validation reports one has to either preserve the Hydrogen atoms in the
model, or modify all the software that uses coordinate files to add the
hydrogen atoms back in.  That is a major programming task, which the
authors have, apparently, been unwilling to do.

   I will go further and disagree with you that even this is a solution.
It is very difficult to add the Hydrogen atoms back into 3EOJ, and I
expect this difficulty is the reason software has not been written that
successfully does it.

   There are two major problems to be overcome in 3EOJ.  shelxl has an
option to twirl the methyl groups and select the torsion angle with the
best fit to the map.  The hydrogen atoms in the pictured methyl group
weren't built as staggered -- All values for the torsion angle were
tested and it happens that the best fit placed them in a staggered
conformation.  That is a much more interesting result.  There are other
methyl groups around the edges of the Bchl-a molecules that are crowded
and the methyl groups are observed to have torsion angles that are not
standard for riding Hydrogen atoms.  The neighboring methyl groups avoid
H-H bumps by twisting and that twist can be detected by shelxl in the
1.3 A data.

   The second problem is the matter of Histidine residues.  There are
two Nitrogen atoms in the side chain.  A hydrogen atom could be on
either one, and sometimes both have hydrogens.  A very clever program
could work out from the hydrogen bonding pattern the most likely
placement, but I've not seen any program that is very good with hydrogen
bonding networks.  Worst still, I've often seen programs place the
hydrogen atom *between* the Nitrogen and Magnesium atoms of a Histidine
ligand to a Bacteriochlorophyll a.  This mistake will certainly lead to
very bad geometry!

   Until an hydrogenation program is written that can handle all
ligands, all hydrogen bonding networks (even overlapping partial

Re: [ccp4bb] Ligand discrimination

[Robbie Joosten]

Hi Nicolas,

VHELIBS does a good job at that. Keep in mind though that the distinction 
between additives and functional molecules is done based on a list of 
compounds. There are compounds that can serve both as crystallisation agent and 
ligand in different contexts.

Cheers,
Robbie 

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Nicolas
> Soler
> Sent: Friday, March 27, 2020 13:28
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Ligand discrimination
> 
> Dear all,
> 
> Could somebody point me to a good tool that providing a pdb id, could
> analyze its ligand(s) and distinguish between crystallographic agents and
> putative drugs.
> 
> Many thanks in advance,
> 
> Nicolas
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1



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

Re: [ccp4bb] modelling MET (methionine) and SME (met-sulfoxide)

[Robbie Joosten]

> On 26/04/2020 16:21, Abhishek Anan wrote:
> > Dear all,
> >
> > I have a peptide crystal structure at 0.97 Å that contains two surface
> > exposed Methionine. The CE atoms of both MET have a suspiciously high
> > b-factor >40 and a positive density. In addition, the sulfur atom SD
> > has a large negative density (b-factor ~23).
> >
> > I initially suspected that the MET may have oxidized to MET-sulfoxide
> > and tried to model only the MET-sulfoxide. This again resulted in
> > negative density.
> >
> > I think that the peptides might be partly oxidized which brings me to
> > my question. Is there a way to model both MET and MET-sulfoxide into
> > the density much like alternate conformation with options to refine
> > their respective occupancies.
> 
> 
> Yes. This is called micro-heterogeneity
> 
> And is documented here:
> 
> https://www.wwpdb.org/documentation/procedure
> 
> That should "just work" if you then give the model to refmac.
> 
> FWIW, Coot is, AFAIR, not 100% happy with such models.
Neither is Refmac ☹

Cheers,
Robbie


> 
> Paul.
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1



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

Re: [ccp4bb] Fwd: Refmac error

[Robbie Joosten]

Hi Eugene,

We recently had this with a student as well and at least in PDB format the 
files are salvageable by doing a simple search and replace from , to .

Rather than going completely American, you can also just change the number 
format. In Windows 10 this is 
Settings > Time & Language > Data, time, & regional formatting (hidden on the 
right) > Additional data, time, & regional settings > Change data, time, or 
number formats > Additional settings

Only "decimal symbol" and "Digit grouping symbol" need to be set to . and , 
respectively. 

Cheers,
Robbie
> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Eugene
> Krissinel
> Sent: Friday, May 29, 2020 12:47
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Fwd: Refmac error
> 
> Dear Nadine,
> 
> Many thanks for sharing your project with me on CCP4 Cloud. The reason for
> Refmac failure is absolutely clear: the previous Coot job exported PDB file,
> using commas (wie im besten Deutsch) instead of periods (as we would
> expect in best English) for all float-point numbers. You can see it if you go 
> to
> the previous Coot job report, scroll down to "Output Structure", press
> "Display" and scroll down a bit.
> 
> This effect is known to be peculiar to WinCoot -- have you used Windows
> machine to run Coot in job 179? And had you used a different machine to
> run Coot in job 169, which produced output file in correct format?
> 
> The only way to cope with the situation, known to me, is to ensure that your
> Windows machine uses US/English locale settings. This takes tweaking
> Language settings in Windows Control Panel and rebooting the machine.
> Regrettably, you will have to repeat job 179 in new locale. If it contains
> particularly valuable results that are difficult to reproduce, let me know 
> and I
> will advise you of the rescue procedure.
> 
> Admittedly, you are by far not the only one who encounters this problem,
> which appears in all locales with float point formats different from
> US/English. Therefore, I cc WinCoot developer on this email (they are aware
> anyway, and are working on the issue), as well as CCP4 BB list, where you
> placed your request initially, for other CCP4 users to be aware of this
> feature. And there is an obvious homework for us here at CCP4.
> 
> Once again, many thanks for your report. Please unshare this project now
> (simply remove my login name where you have put it for sharing before).
> 
> Kind regards,
> 
> Eugene
> 
> 
> On Fri, May 29, 2020 at 9:52 AM Nadine Gerlach   > wrote:
> 
> 
>   Hey Eugene,
> 
>   actually this happend not just for one project of mine, but I shared
> one project with you now. Scroll down to the last refmac run after model
> building with coot. I just tried it again but it is still the same result.
> 
>   Thanks for the help!!
> 
>   Nadine
> 
> 
> 
> 
> 
>   Am 28.05.2020 um 19:28 schrieb Eugene Krissinel:
> 
> 
>   Dear Nadine,
> 
>   We would need more information on what happens. You can
> share your project with me and I can have a look at it. To share the project,
> open it, then push Main Manu button in top-left corner, choose "Share" and
> set my login name (eugene), then confirm to me by e-mail. Your data and
> project will be treated as confidential.
> 
>   Many thanks for writing to us (use c...@ccp4.ac.uk
>   rather than BB list for this type of queries please)
> 
>   Eugene
> 
> 
>   -- Forwarded message -
>   From: Nadine Gerlach   >
>   Date: Thu, 28 May 2020 at 14:21
>   Subject: Refmac error
>   To: mailto:CCP4BB-
> requ...@jiscmail.ac.uk> >
> 
> 
> 
> 
>   Hey everybody,
> 
>   I am running refmac in CCP4 ccloud after Coot and I get this
> error message:
> 
>*** error running refmac5: Error in command.call
>   Return code: 512
> 
>   Any held is really appreaciated!
> 
>   Best wishes,
>   Nadine
>   --
>   Nadine Gerlach
>   PhD candidate
>   MPG MARUM Bridge Group Marine Glycobiology
>   MARUM, University Bremen & Max Planck Institute for
> Marine Microbiology
>   Tel: +49 421 218-65758
>   Email: nger­lach@mpi-bre­men.de  ,
> ngerl...@marum.de 
>   MARUM Pavillon room 1110
>   Leobener Straße
>   28359 Bremen, Germany
> 
>   This email and any attachments are intended solely for the
> use of the named recipients. If you are not the intended recipient you must
> not use, disclose, copy or distribute this email or any of its attachments and
> should notify the sender immediately and delete this email from your
> system. UK Research and Innovation (UKRI) has taken eve

Re: [ccp4bb] PDB file header lines...

[Robbie Joosten]

Hi Harry,

You need this: 
http://www.wwpdb.org/documentation/file-format-content/format33/sect9.html#MODEL

Essentially you have to make sure a MODEL has a number and a closing tag. It is 
read as a real PDB record so you have to make sure it is correct BIDEN is not 
PDB compliant and will be either ignored or a parser will throw an error.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Harry
> Powell - CCP4BB
> Sent: Friday, May 29, 2020 16:57
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] PDB file header lines...
> 
> Hi
> 
> Is there something about “MODEL ” lines (i.e. five characters followed by a
> space) in PDB files that is completely beyond the pale?
> 
> I’ve got some PDB files from a protein structure prediction server based in
> the US that Coot fails to read and that cause QTMG to crash on my Mac. I’ve
> tracked this down to “MODEL” lines in the file headers.
> 
> I’ve tested this most in QTMG, so the following may not be true for Coot. If I
> change this line so that it has “M ”, “MO ”, “MOD ”, MODE ”, “MODEL1 ”,
> “MODEL22 ”, “MODEL678 ” or even “MODEL^&* ” instead of “MODEL ” then
> all looks hunky-dory.
> 
> I thought - “aha - there’s something about 5 characters” - so I tried 
> replacing
> “MODEL ” with “TRUMP ” and “BIDEN ” and the files read okay, so it does
> look very specific.
> 
> I’m sure there’s a simple answer to this (is there a “FM” I could read?), but 
> I
> haven’t found one yet. Can anyone on the BB help out?
> 
> Harry
> 
> ###
> #
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

[ccp4bb] Completeness question

[Robbie Joosten]

Hi Everyone,

I've been looking at some recent PDB entries that have much lower spherical) 
completeness than reported in the coordinate file. One reason for this is that 
the data were anisotropicly truncated, another reason is some mess-up with the 
deposition of the reflection data. There is a lot of discussion about the 
former practice and I don't want to go in to that, but the second one is 
obviously an error. Now how do I distinguish these cases?

Sometimes, you can look at the reported number of reflections and compare that 
to the deposited reflection file and you will find that something has clearly 
gone wrong. However, the reported number of reflections is not entirely 
reliable because of other issues so I'd rather not use it. If you use PDBpeep 
(e.g. for 6rjy) you can see something is wrong, but that is completely visual. 
Is there a tool in CCP4 that reports both spherical and ellipsoidal 
completeness (on merged reflection data)? That would make it easy to 
distinguish such cases.

Cheers,
Robbie



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

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

Re: [ccp4bb] Completeness question

[Robbie Joosten]

Hi Ian,

> I don't see that anisotropic truncation has anything to do with the low
> spherical completeness as compared with the info in the co-ordinate file.
> Yes the spherical completeness after anisotropic truncation will be reduced,
> but why would it cause it to become inconsistent with that reported (unless
> of course the completeness calculations were performed on two different
> reflection files)?  Besides, the anisotropy is quite low (Delta-B eigenvalues:
> 3.42  -1.95 -1.47) so that couldn't explain it.
This is a general problem with anisotropic truncation. 6rjy is an example of 
something else going on. What happens is that people report the ellipsoidal 
completeness, but when you import the reflection data from the PDB and add the 
missing reflections (because those are typically not deposited) with the CCP4 
program complete you get a spherical dataset. If you now calculate the 
completeness it will be very low and inconsistent with the reported number. 
This is actually also a problem on the side of the PDB validation as EDS does a 
similar thing.

So what I want is a way to reproduce the reported completeness even when it is 
the ellipsoidal completeness. Not being able to do so would then be a clear 
indication that something else is going on like you see below. I suppose 
replacing complete with something that can add the missing ellipsoidal 
reflections would also solve the problem. If anything that would be even more 
elegant.

Cheers,
Robbie







> 
> I do agree that something has clearly gone wrong with the reflection
> deposition for 6RJY.  It could of course go right back to the collection or
> processing, but I think it unlikely anyone could solve the structure with data
> in this state!  Approximately alternate reflections are missing, but the
> pattern of absences does not correspond with any space group.  For example
> from MTZDUMP on the reflection file:
> 
>3   1   00.00 21.21  0.22
>3   1   20.00 23.83  0.19
>3   1   40.00 34.71  0.26
>3   1   60.00  9.06  0.11
>3   1   80.00 31.64  0.24
>3   1  100.00 31.22  0.25
>3   1  120.00  1.28  0.39
>3   1  140.00  6.59  0.12
>3   1  160.00 17.58  0.15
>3   1  180.00  3.94  0.18
>3   1  200.00 11.05  0.12
>3   1  220.00 34.24  0.24
>3   1  240.00 12.39  0.14
>3   1  260.00 12.76  0.15
>3   1  280.00 20.80  0.18
> 
>3   1  300.00 23.70  0.19
>3   1  320.00 23.47  0.20
>3   1  340.00 30.50  0.23
>3   1  360.00 10.93  0.22
>3   1  380.00 28.11  0.22
>3   1  400.00 24.41  0.21
>3   1  420.00 11.04  0.21
>3   1  440.00 12.58  0.28
>3   1  470.00 10.54  0.29
>3   1  490.00 10.54  0.23
>3   1  510.00  2.98  0.70
>3   1  530.00  5.84  0.39
>3   1  550.00  9.79  0.27
>3   1  570.00 11.33  0.26
>3   1  590.00  8.99  0.30
>3   1  610.00  1.84  0.76
>3   1  630.00  2.63  0.78
>3   1  650.00  4.91  0.46
>3   1  670.00  3.50  0.64
>3   1  690.00  1.93  0.76
>3   1  710.00  4.57  0.52
>3   1  730.00  1.71  0.73
> 
> 
> Note how the pattern switches between (3 1 44) and (3 1 47).
> 
> 
> So sometimes k+l = 2n are absent and sometimes k+l = 2n+1 are: this pattern
> pervades the whole dataset so the completeness (both spherical and
> ellipsoidal) is reduced by a factor of about two.  This makes no sense in
> terms of known systematic absences, and certainly not for the reported
> space group P212121.  This alternating pattern of absences is of course
> extremely unlikely in valid data: normally low completeness arises from
> whole missing wedges of data, or cusps, or to a smaller extent detector gaps,
> i.e. usually missing data are largely contiguous, not alternating as here.
> 
> 
> I think the only solution here is to get the authors to deposit the data
> correctly: is there any commonality of the authors for the structures where
> you have noted this problem?
> 
> 
> Cheers
> 
> 
> -- Ian
> 
> 
> 
> On Sat, 30 May 2020 at 09:36, Robbie Joosten
> mailto:robbie_joos...@hotmail.com> >
> wrote:
> 
> 
>   Hi Everyone,
> 
>   I've 

Re: [ccp4bb] Completeness question

[Robbie Joosten]

I fully agree. Unfortunately, not everyone does that so cases like I described will keep appearing. Cheers,RobbieOn 30 May 2020 16:40, Eleanor Dodson  wrote:My pennysworth. If you find your maps look better after the anisotroy correction use it, but it may be helpful to those wo want to mine your data if you deposit the whole sphere..eleanorOn Sat, 30 May 2020 at 09:36, Robbie Joosten <robbie_joos...@hotmail.com> wrote:Hi Everyone,

I've been looking at some recent PDB entries that have much lower spherical) completeness than reported in the coordinate file. One reason for this is that the data were anisotropicly truncated, another reason is some mess-up with the deposition of the reflection data. There is a lot of discussion about the former practice and I don't want to go in to that, but the second one is obviously an error. Now how do I distinguish these cases?

Sometimes, you can look at the reported number of reflections and compare that to the deposited reflection file and you will find that something has clearly gone wrong. However, the reported number of reflections is not entirely reliable because of other issues so I'd rather not use it. If you use PDBpeep (e.g. for 6rjy) you can see something is wrong, but that is completely visual. Is there a tool in CCP4 that reports both spherical and ellipsoidal completeness (on merged reflection data)? That would make it easy to distinguish such cases.

Cheers,
Robbie



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

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




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

Re: [ccp4bb] Completeness question

[Robbie Joosten]

Hi Clemens,

Thanks for pointing out the table in the PDBpeep log file. It has the data I 
need and since the issue only applies to deposited PDB entries it does the 
trick quite nicely.

Cheers,
Robbie

> -Original Message-
> From: Clemens Vonrhein 
> Sent: Wednesday, June 3, 2020 14:18
> To: Robbie Joosten 
> Cc: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Completeness question
> 
> Dear Robbie,
> 
> On Sat, May 30, 2020 at 08:36:06AM +, Robbie Joosten wrote:
> > I've been looking at some recent PDB entries that have much lower
> > spherical) completeness than reported in the coordinate file. One
> > reason for this is that the data were anisotropicly truncated, another
> > reason is some mess-up with the deposition of the reflection data.
> > There is a lot of discussion about the former practice and I don't
> > want to go in to that, but the second one is obviously an error. Now
> > how do I distinguish these cases?
> >
> > Sometimes, you can look at the reported number of reflections and
> > compare that to the deposited reflection file and you will find that
> > something has clearly gone wrong. However, the reported number of
> > reflections is not entirely reliable because of other issues so I'd
> > rather not use it. If you use PDBpeep (e.g. for 6rjy) you can see
> > something is wrong, but that is completely visual. Is there a tool in
> > CCP4 that reports both spherical and ellipsoidal completeness (on
> > merged reflection data)? That would make it easy to distinguish such
> > cases.
> 
> One needs a description of the anisotropy in a form that allows for a simple
> computation ("Is a reflection above a significance limit or
> not?") to relate this to the completeness of reflections above such a
> significance level. That model could e.g. be the ellipsoid fitted to the
> significance (local ) cutoff surface as done by STARANISO [1]. You can
> see that information e.g. at the PDBpeep server [2]:
> 
>   http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi?ID=6rjy
> 
> as
> 
>   Diffraction limits & principal axes of ellipsoid fitted to diffraction 
> cut-off
> surface:
> 
>   1.747 1.   0.   0.   a*
>   1.777 0.   1.   0.   b*
>   1.465 0.   0.   1.   c*
> 
> Of course, if this information is already present in deposited PDB entries of
> interest, no additional computation is required. We are currently working
> with our colleagues from the PDBx/mmCIF working group on definitions and
> items that would extend the current PDBx/mmCIF dictionary so that the
> above information could be deposited to and retrieved from the PDB
> database.
> 
> In any case, this information is then used for computation of the spherical
> and ellipsoidal completness e.g. within STARANISO - see link to the
> "complete log file" at the bottom of the page:
> http://staraniso.globalphasing.org/PDB/6rjy.log. It contains a table
> ("Statistics for isotropic, anisotropic & ellipsoidal diffraction
> cut-offs") where Cmeas_sph and Cmeas_ell should give the above
> information (showing clearly that for 6rjy something else went wrong during
> deposition).
> 
> If there is unmerged data deposited, one could give that ellipsoid description
> e.g. to MRFANA [3] via
> 
>   mrfana -ell 1.747 1.0 0.0 0.0 1.777 0.0 1.0 0.0 1.465 0.0 0.0 1.0
> unmerged.mtz
> 
> to get the same information (but maybe use different binning, limit
> resolution ranges etc).
> 
> Cheers
> 
> Clemens, Claus, Ian & Gerard
> 
> [1] http://staraniso.globalphasing.org/
> [2] http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi
> [3] https://github.com/githubgphl/MRFANA, a result of the Data Quality
> Metrics Workshop organised by Global Phasing at the ESRF in April
> 2019



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

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

[ccp4bb] B-factor distributions

[Robbie Joosten]

Posted on behalf of Gert Vriend:

This article didn't make it to Nature Methods (...), but might be of interest 
to theoreticians interested in B-factor distributions:
 https://journals.calstate.edu/pump/article/view/2409/2168 

Gert Vriend



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

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

Re: [ccp4bb] Quote source inquiry

[Robbie Joosten]

Hi Ian,

Errors in cell dimensions can have a large effect in MX with certain refinement 
doctrines. The school of "bond length rmsd must be $NUMBER" (which is still 
going strong unfortunately) will suffer from poor R-factors because the target 
cannot be satisfied without harming the fit to the data. At the same time if 
you have a a more relaxed approach to restraints than you might find systematic 
deviations in bond lengths. A test for that has been in WHAT_CHECK for decades 
and it actually works surprisingly well to detect cell dimension problems. That 
said, the problem is uncommon now.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Ian
> Tickle
> Sent: Wednesday, July 15, 2020 20:25
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Quote source inquiry
> 
> 
> Hi,
> 
> There's one big difference between macromolecular and small molecule
> refinement: except at ultra-high resolution the bond lengths in the former
> are almost always strongly restrained, whereas those in the latter are almost
> without exception completely unrestrained (except possibly bond lengths to
> H atoms in XRD).  In other words, MX accurately determines the orthogonal
> atomic co-ordinates, whereas XRD accurately determines their fractional co-
> ordinates (it's no accident that the different programs output co-ordinates in
> those formats).
> 
> This means that since the cell dimensions are then used to convert fractional
> to orthogonal in XRD, the final bond lengths will be much more sensitive to
> errors in the cell dimensions, so having accurate cell dimensions is more
> critical if you want accurate bond lengths (e.g. for use as restraints in 
> MX!).
> Obviously there's also a limit to the errors in the cell dimensions that can 
> be
> tolerated in MX: large errors will lead to errors in calculated d* values and
> hence the scattering factors, which is likely to have a significant effect, 
> and
> there may be issues with VdW repulsions if the cell is too small (though it's
> relatively easy for the structure to accommodate that).
> 
> As Philip pointed out, the bond lengths will be totally insensitive to errors 
> in
> the uncertainties of the cell dimensions, whether artificially introduced or
> poorly estimated from the data.  I don't know of any MX refinement
> program (other than Shel-X) that takes the uncertainties in the cell
> dimensions into account, even assuming that you have accurate values for
> them.
> 
> Also you should be careful not to confuse uncertainty (imprecision) with
> error (inaccuracy).  The 'standard uncertainty' (s.u.) is the experimental
> estimate of the 'standard deviation' (in the error)
> (https://physics.nist.gov/cgi-bin/cuu/Info/Constants/definitions.html), and
> the old term 'estimated standard deviation' (e.s.d.) was deprecated in 1993
> (http://scripts.iucr.org/cgi-bin/paper?S0108767395002340).  You can have
> an error in an uncertainty (which is what you were introducing in your test),
> but you can't have an uncertainty in an error, since errors are by their 
> nature
> unknown anyway!
> 
> It goes without saying that it's not a good idea to use bond lengths from a
> restrained refinement as restraints in other refinements!
> 
> Cheers
> 
> -- Ian
> 
> 
> On Wed, 15 Jul 2020 at 17:56, Jeffrey B Bonanno
>   > wrote:
> 
> 
>   Hi Phil,
> 
> 
> 
>   Being young and impressionable, I only changed ZERR, and you are
> quiet right the result is the rigorous and expected error propagation of
> shelxl. Of course the more fun experiment would be in systematically
> changing various values in UNIT to watch the molecule distort.
> 
> 
> 
>   Hope all is well,
> 
>   jbb
> 
> 
> 
>   Jeffrey B. Bonanno, Ph.D.
> 
>   Department of Biochemistry
> 
>   Albert Einstein College of Medicine
> 
>   1300 Morris Park Avenue
> 
>   Bronx, NY 10461
> 
>   off. 718-430-2452 fax. 718-430-8565
> 
>   email jeffrey.bona...@einsteinmed.org
> 
> 
> 
> 
>   From: Jeffrey, Philip D. 
>   Sent: Wednesday, July 15, 2020 12:47 PM
>   To: CCP4BB@JISCMAIL.AC.UK  ;
> Jeffrey B Bonanno   >
>   Subject: Re: [ccp4bb] Quote source inquiry
> 
> 
> 
> CAUTION: This email comes from an external source; the attachments and/or
> links may compromise our secure environment. Do not open or click on
> suspicious emails. Please click on the “Phish Alert” button on the top right 
> of
> the Outlook dashboard to report any suspicious emails.
> 
>   :: took a working dataset and increased (only) the error on unit cell
> dimensions in the instruction file for the final round of full matrix :: least
> squares refinement in shelxl. Sure enough, the errors on the bonds and
> angles shot up. I was more careful
> 
> 
> 
>   Question: did you change the unit cell dimensions (UNIT) o

Re: [ccp4bb] Quote source inquiry

[Robbie Joosten]

I don't know what the return on investment would be, but after establishing 
that there are cell dimension deviations one should actually try to find the 
source of the problem. If it is the reported geometry of the experiment than it 
is just a matter of changing the cell dimension, but if the wavelength come 
into play as Clemens pointed out (hooray for home sources) one should also 
correct the wavelength in order to get better scattering factors. If you don't 
have ice rings as a reference can you still do that? Perhaps refine f' and f''. 
Has anyone does that in a systematic way?

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Eleanor
> Dodson
> Sent: Thursday, July 16, 2020 12:57
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Quote source inquiry
> 
> Hmm - remember Gerard, the EU Validation initiative in the 1990s? We
> analysed these effects, or at least Victor Lamsin did, and we applauded him.
> Cheers Eleanor
> 
> On Thu, 16 Jul 2020 at 11:52, Clemens Vonrhein
> mailto:vonrh...@globalphasing.com> >
> wrote:
> 
> 
>   Hi Robbie,
> 
>   On Wed, Jul 15, 2020 at 07:23:15PM +, Robbie Joosten wrote:
>   > At the same time if you have a a more relaxed approach to
> restraints
>   > than you might find systematic deviations in bond lengths. A test
>   > for that has been in WHAT_CHECK for decades and it actually
> works
>   > surprisingly well to detect cell dimension problems.
> 
>   Indeed.
> 
>   > That said, the problem is uncommon now.
> 
>   Not so sure about that: we all rely on an accurate value of the
>   energy/wavelength from the instrument/beamline - and if that is off
>   (for whatever reasons) it will result in incorrect cell dimensions and
>   a systematic deviation from the various restraints.
> 
>   This would even affect the best experiment done on the best crystal
>   ... so fairly easy to spot at the refinement stage, especially if such
>   an energy/wavelength offset is constant over a long period of time
> on
>   a given instrument. To spot this at the data collection stage one
>   would hope that at some point a crystal with very pronounced ice-
> rings
>   will be looked at properly (and the fact these are not where we
> expect
>   them to should cause some head-scratching).
> 
>   Cheers
> 
>   Clemens
> 
>   
> 
> 
>   To unsubscribe from the CCP4BB list, click the following link:
>   https://www.jiscmail.ac.uk/cgi-bin/WA-
> JISC.exe?SUBED1=CCP4BB&A=1
> 
>   This message was issued to members of www.jiscmail.ac.uk/CCP4BB
> <http://www.jiscmail.ac.uk/CCP4BB> , a mailing list hosted by
> www.jiscmail.ac.uk <http://www.jiscmail.ac.uk> , terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1




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

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

Re: [ccp4bb] Quote source inquiry

[Robbie Joosten]

I suppose that this is where the phrase "Mind your own beeswax" comes from 😉
 

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Edward
> Snell
> Sent: Thursday, July 16, 2020 16:36
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Quote source inquiry
> 
> Not completely related to the question but at one particular European
> synchrotron there were a group of beamline scientists that also kept honey
> bees. The wax from each hive gave very beautiful powder diffraction
> patterns with the scattering being similar but distinctive to each hive. I was
> fortunate to observe this before my data collection - this was their
> calibration of the beam center.
> 
> In the US, many years before BluIce there was a 'jiffy' software routine that
> would take a powder pattern and accurately calculate the beam center. This
> saved one of our structures. Wax, silicon powder, and other test samples
> were used. If I remember correctly cryo-vials had a powder signature and a
> magnet with part of a vial glued to it became part of the tool kit when one
> would still routinely travel to the beamline.
> 
> I've been saved once with the powdered silicon. We had a hutch that was
> completely empty when we arrived due to an unanticipated emergency. A
> week of beamtime turned into an amazing educational opportunity to install
> and align the diffractometer. The powder data proved very useful in the
> energy calibration. After installation and alignment, unbelievably we were
> able to collect our data and get a publication from it.
> 
> Best,
> 
> Eddie
> 
> Edward Snell Ph.D.
> 
> Director of the NSF BioXFEL Science and Technology Center President and
> CEO Hauptman-Woodward Medical Research Institute BioInnovations
> Chaired Professorship, University at Buffalo, SUNY
> 700 Ellicott Street, Buffalo, NY 14203-1102 hwi.buffalo.edu
> Phone:   (716) 898 8631 Fax: (716) 898 8660
> Skype:eddie.snell Email: esn...@hwi.buffalo.edu
> Webpage: https://hwi.buffalo.edu/scientist-directory/snell/
> 
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Harry Powell - CCP4BB
> Sent: Thursday, July 16, 2020 7:26 AM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Quote source inquiry
> 
> Hi
> 
> Does anyone bother collecting a powder image (e.g. Si powder) these days
> so they actually have a reference that can be used to check both the
> wavelength and the beam centre? Or is this considered just something that
> old folk do?
> 
> Harry
> 
> > On 16 Jul 2020, at 12:19, Gerard DVD Kleywegt
>  wrote:
> >
> > There was a case a few years ago (not too many though) where a 1.6 Å
> structure had been solved using an incorrect value for the wavelength (~5%
> too low, leading to a cell that was slightly too small for its contents to be
> comfortable). It was later corrected so we could compare their validation
> statistics. Some interesting observations:
> >
> > - the geometry had been very tightly restrained so that didn't give a
> > clue  about the cell error (WhatCheck only suggested a very small
> > change)
> >
> > - somewhat surprisingly (I thought) the Ramachandran plot did not
> > improve in  the correct model (0.3% outliers in the wwPDB validation
> > report), and the  sidechain rotamer outliers even got worse (from 1.5
> > to 2.5 %)
> >
> > - the map looked surprisingly good for the incorrect cell
> >
> > - however, RSR-Z told clearly that the map was not good enough for the
> > claimed  resolution - the model had 24% outliers! (3% in the corrected
> > model which  still only put it at the ~50th percentile)
> >
> > - another good indicator was the clashscore (went from 44 to 7)
> >
> > - the original model did not include an Rfree, but the R-value (>0.3
> > at 1.6Å
> >  resolution) ought to have provided a clue to the crystallographers
> > and  reviewers one would think
> >
> > It would be interesting to see what would happen if the wavelength would
> be set 5% too high.
> >
> > --Gerard
> >
> >
> >
> > On Thu, 16 Jul 2020, Clemens Vonrhein wrote:
> >
> >> Hi Robbie,
> >>
> >> On Wed, Jul 15, 2020 at 07:23:15PM +, Robbie Joosten wrote:
> >>> At the same time if you have a a more relaxed approach to restraints
> >>> than you might find systematic deviations in bond lengths. A test
> >>> for that has been in WHAT_CHECK for decades and it actually works
> >>> surprisingly well to detect cell dimension problems.
> >&

[ccp4bb] PDB-REDO downtime

[Robbie Joosten]

Hi everyone,Due to major electrical work at our institute, PDB-REDO will be down from Sunday August 16th 20:00h CET to Tuesday August 18th 11:00h CET.Any calculations still running at the start of the downtime will be restarted once we are back online, but feel free to email me to remind me on Tuesday. On behalf of the PDB-REDO team, sorry for the inconvenience,Robbie


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

Re: [ccp4bb] Omega angles with molprobity

[Robbie Joosten]

Hi Joana,

molprobity.omegalyze seems to do what you want. Just run it on the command 
prompt.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Joana
> Pereira
> Sent: Friday, September 4, 2020 11:29
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Omega angles with molprobity
> 
> Dear all,
> 
> Does anyone know which molprobity tool in ccp4/bin lists the omega angles
> for each residue? I see Phenix provides a comprehensive validation based on
> Molprobity and, from what I understand, lists the omega angles for each
> residue. However, I am having troubles to find which molprobity tool
> provides that info. Any idea?
> 
> Many thanks!
> 
> Best wishes
> 
> Joana Pereira
> 
> --
> Postdoctoral Researcher
> Department of Protein Evolution
> 
> Max Planck Institute for Developmental Biology Max-Planck-Ring 5
> 72076 Tübingen
> GERMANY
> 
> ###
> #
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

Re: [ccp4bb] Omega angles with molprobity

[Robbie Joosten]

Hi Joana,

By default it only lists non-trans peptides. Theis command worked for me:
molprobity.omegalyze tempdir/3bwh/pdb3bwh.pdb nontrans_only=False

Cheers,
Robbie

> -Original Message-
> From: Joana Pereira 
> Sent: Friday, September 4, 2020 12:04
> To: Robbie Joosten ;
> CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Omega angles with molprobity
> 
> Hi Robbie,
> 
> Thanks for the quick response :) That was my first try but it does not list me
> the angles.. see the output below:
> 
> Starting molprobity.omegalyze
> on Fri Sep  4 12:00:35 2020 by jpereira
> ===
> 
> 
> Processing files:
> ---
> 
>   Found model, .pdb
> 
> Processing PHIL parameters:
> ---
> 
>   No PHIL parameters found
> 
> Final processed PHIL parameters:
> ---
>   data_manager {
> model {
>   file = ".pdb"
> }
> default_model = ".pdb"
>   }
> 
> 
> Starting job
> ===
> 
> residues:type:omega:conformation:mc_bmax
> SUMMARY: 0 cis prolines out of 5 PRO
> SUMMARY: 0 twisted prolines out of 5 PRO
> SUMMARY: 0 other cis residues out of 140 nonPRO
> SUMMARY: 0 other twisted residues out of 140 nonPRO
> 
> ===
> 
> 
> 
> What I would like to have is a per residue assignment of omega angles, as
> molprobity.ramanalyse does. Of course i could code it, but I was trying to
> avoid that ;)
> 
> 
> Cheers,
> 
> Joana
> 
> 
> 
> 
> On 04.09.20 11:45, Robbie Joosten wrote:
> 
> 
>   Hi Joana,
> 
>   molprobity.omegalyze seems to do what you want. Just run it on the
> command prompt.
> 
>   Cheers,
>   Robbie
> 
> 
>   -Original Message-
>   From: CCP4 bulletin board 
> <mailto:CCP4BB@JISCMAIL.AC.UK>  On Behalf Of Joana
>   Pereira
>   Sent: Friday, September 4, 2020 11:29
>   To: CCP4BB@JISCMAIL.AC.UK
> <mailto:CCP4BB@JISCMAIL.AC.UK>
>   Subject: [ccp4bb] Omega angles with molprobity
> 
>   Dear all,
> 
>   Does anyone know which molprobity tool in ccp4/bin lists
> the omega angles
>   for each residue? I see Phenix provides a comprehensive
> validation based on
>   Molprobity and, from what I understand, lists the omega
> angles for each
>   residue. However, I am having troubles to find which
> molprobity tool
>   provides that info. Any idea?
> 
>   Many thanks!
> 
>   Best wishes
> 
>   Joana Pereira
> 
>   --
>   Postdoctoral Researcher
>   Department of Protein Evolution
> 
>   Max Planck Institute for Developmental Biology Max-Planck-
> Ring 5
>   72076 Tübingen
>   GERMANY
> 
> 
>   
> ###
>   #
> 
>   To unsubscribe from the CCP4BB list, click the following link:
>   https://www.jiscmail.ac.uk/cgi-bin/WA-
> JISC.exe?SUBED1=CCP4BB&A=1
> 
>   This message was issued to members of
> www.jiscmail.ac.uk/CCP4BB <http://www.jiscmail.ac.uk/CCP4BB> , a
>   mailing list hosted by www.jiscmail.ac.uk
> <http://www.jiscmail.ac.uk> , terms & conditions are available at
>   https://www.jiscmail.ac.uk/policyandsecurity/
> 
> 
>   
> 
> 
>   To unsubscribe from the CCP4BB list, click the following link:
>   https://www.jiscmail.ac.uk/cgi-bin/WA-
> JISC.exe?SUBED1=CCP4BB&A=1
> 
>   This message was issued to members of www.jiscmail.ac.uk/CCP4BB
> <http://www.jiscmail.ac.uk/CCP4BB> , a mailing list hosted by
> www.jiscmail.ac.uk <http://www.jiscmail.ac.uk> , terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/
> 
> --
> Postdoctoral Researcher
> Department of Protein Evolution
> 
> Max Planck Institute for Developmental Biology Max-Planck-Ring 5
> 72076 Tübingen
> GERMANY



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

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

Re: [ccp4bb] metal coordination at low resolution - restraints

[Robbie Joosten]

Hi Anna,

Yes you can do this in Refmac by adding external restraints. If you have 
structural Zinc sites (Zn coordinated by 4 histidines or cysteines)  you can 
also use PDB-REDO to generate the restraints automatically. The restraints are 
written to the output so you can continue using them in Refmac.

HTH,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of anna
> anna
> Sent: Tuesday, September 8, 2020 11:28
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] metal coordination at low resolution - restraints
> 
> Dear all,
> 
> quickly: is there a way to restrain metal coordination geometry (even angles)
> in refmac?
> 
> I am refining a low resolution structure (3.3A) with 2 zinc binding sites.
> I am pretty sure about metal position (strong anomalous signal) and what
> are the residues involved in coordination since I solved the apo-structure at
> good resolution and Zn-binding does not induce huge structural variations.
> However, as you can imagine, electron density is poorly defined and Refmac
> gives a very distorted coordination geometry.
> I noticed that in phenix it is possible to generate restraints with readyset 
> but
> I'd like to work with refmac.
> 
> Many thanks for your suggestions.
> 
> Cheers,
> Anna
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1




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

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

Re: [ccp4bb] metal coordination at low resolution - restraints

[Robbie Joosten]

Hi Elanor,

The distances are in the dictionaries but the angles involve three different 
residues so these cannot be in the current dictionary. We could add the program 
that generates these restraints to CCP4 though.

Cheers,
Robbie

> -Original Message-
> From: Eleanor Dodson 
> Sent: Tuesday, September 8, 2020 11:38
> To: Robbie Joosten ; Garib N Murshudov
> 
> Cc: CCP4BB@JISCMAIL.AC.UK; Robert Nicholls  lmb.cam.ac.uk>
> Subject: Re: [ccp4bb] metal coordination at low resolution - restraints
> 
> Robbie - could that be added to the distributed dictionaries? Zn binding is
> common and at low resolution distance restraints are not enough..
> Eleanor
> 
> On Tue, 8 Sep 2020 at 10:33, Robbie Joosten  <mailto:robbie_joos...@hotmail.com> > wrote:
> 
> 
>   Hi Anna,
> 
>   Yes you can do this in Refmac by adding external restraints. If you
> have structural Zinc sites (Zn coordinated by 4 histidines or cysteines)  you
> can also use PDB-REDO to generate the restraints automatically. The
> restraints are written to the output so you can continue using them in
> Refmac.
> 
>   HTH,
>   Robbie
> 
>   > -Original Message-
>   > From: CCP4 bulletin board  <mailto:CCP4BB@JISCMAIL.AC.UK> > On Behalf Of anna
>   > anna
>   > Sent: Tuesday, September 8, 2020 11:28
>   > To: CCP4BB@JISCMAIL.AC.UK <mailto:CCP4BB@JISCMAIL.AC.UK>
>   > Subject: [ccp4bb] metal coordination at low resolution - restraints
>   >
>   > Dear all,
>   >
>   > quickly: is there a way to restrain metal coordination geometry
> (even angles)
>   > in refmac?
>   >
>   > I am refining a low resolution structure (3.3A) with 2 zinc binding
> sites.
>   > I am pretty sure about metal position (strong anomalous signal)
> and what
>   > are the residues involved in coordination since I solved the apo-
> structure at
>   > good resolution and Zn-binding does not induce huge structural
> variations.
>   > However, as you can imagine, electron density is poorly defined
> and Refmac
>   > gives a very distorted coordination geometry.
>   > I noticed that in phenix it is possible to generate restraints with
> readyset but
>   > I'd like to work with refmac.
>   >
>   > Many thanks for your suggestions.
>   >
>   > Cheers,
>   > Anna
>   >
>   > 
>   >
>   >
>   > To unsubscribe from the CCP4BB list, click the following link:
>   > https://www.jiscmail.ac.uk/cgi-bin/WA-
> JISC.exe?SUBED1=CCP4BB&A=1
> 
> 
>   
> 
> 
>   To unsubscribe from the CCP4BB list, click the following link:
>   https://www.jiscmail.ac.uk/cgi-bin/WA-
> JISC.exe?SUBED1=CCP4BB&A=1
> 
>   This message was issued to members of www.jiscmail.ac.uk/CCP4BB
> <http://www.jiscmail.ac.uk/CCP4BB> , a mailing list hosted by
> www.jiscmail.ac.uk <http://www.jiscmail.ac.uk> , terms & conditions are
> available at https://www.jiscmail.ac.uk/policyandsecurity/
> 




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

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

Re: [ccp4bb] metal coordination at low resolution - restraints

[Robbie Joosten]

  Z  402 ZN   B   H  135 NE2  B  2.024 X,Y,Z
> 1.009.22
>Z  402 ZN   B   D  139 OD2  B  2.032 X,Y,Z
> 1.009.70
>Z  402 ZN   B   Z  601 O3   B  1.973 X,Y,Z
> 0.709.58
> 
> 
>Z  403 ZN   B   H  145 NE2  B  2.027 X,Y,Z
> 1.00   10.80
>Z  403 ZN   B   H  168 NE2  B  2.029 X,Y,Z
> 1.00   10.65
>Z  403 ZN   B   D  172 OD2  B  2.089 X,Y,Z
> 1.00   13.12
>Z  403 ZN   B   Z  601 O4   B  1.938 X,Y,Z
> 0.70   14.10
>Z  403 ZN   B   O  825 OC  2.322 X,Y,Z
> 0.20   10.61
>   ~
> 
>   On Tue, 8 Sep 2020 at 10:47, Garib Murshudov
> mailto:ga...@mrc-lmb.cam.ac.uk> > wrote:
> 
> 
>   Hi Robbie and Eleanor
> 
>   There are links for Zn-His and Zn-Cys. They
> meant to be used automatically, obviously something is not entirely right.
> 
>   Link names are:
>   ZN-CYS
> 
> 
>   It has a bond between Zn and S as well as an
> angle:
>   ZN-CYS   1 ZN  2 SG  2 CB  109.000
> 3.000
> 
>   This also removes H of Cys to make covalent
> bond between Zn and Cys.
> 
>   Similar links are available for Zn and His ND1
> and Zn - HIS NE2
>   Link names are:
> 
>   ZN-HISND
>   ZN-HISNE
> 
> 
>   Again these links have angles between Zn and
> atoms of His.
> 
> 
>   Angle centred at Zn is missing. But these
> distances and angles defined in the link it should work fine.
> 
> 
>   Regards
>   Garib
> 
> 
> 
> 
>   On 8 Sep 2020, at 10:40, Robbie
> Joosten  <mailto:robbie_joos...@hotmail.com> > wrote:
> 
>       Hi Elanor,
> 
>   The distances are in the dictionaries
> but the angles involve three different residues so these cannot be in the
> current dictionary. We could add the program that generates these
> restraints to CCP4 though.
> 
>   Cheers,
>   Robbie
> 
> 
> 
>   -Original Message-
>   From: Eleanor Dodson
> mailto:eleanor.dod...@york.ac.uk> >
>   Sent: Tuesday, September 8, 2020
> 11:38
>   To: Robbie Joosten
> mailto:robbie_joos...@hotmail.com> >;
> Garib N Murshudov
>    <mailto:ga...@mrc-lmb.cam.ac.uk> >
>   Cc: CCP4BB@JISCMAIL.AC.UK
> <mailto:CCP4BB@JISCMAIL.AC.UK> ; Robert Nichollslmb.cam.ac.uk
> <http://lmb.cam.ac.uk/> >
>   Subject: Re: [ccp4bb] metal
> coordination at low resolution - restraints
> 
>   Robbie - could that be added to the
> distributed dictionaries? Zn binding is
>   common and at low resolution
> distance restraints are not enough..
>   Eleanor
> 
>   On Tue, 8 Sep 2020 at 10:33, Robbie
> Joosten  <mailto:robbie_joos...@hotmail.com>
> 
>   <mailto:robbie_joos...@hotmail.com> > wrote:
> 
> 
>   Hi Anna,
> 
>   Yes you can do this in Refmac by
> adding external restraints. If you
>   have structural Zinc sites (Zn
> coordinated by 4 histidines or cysteines)  you
>   can also use PDB-REDO to generate
> the restraints automatically. The
>   restraints are written to the output
> so you can continue using them in
>   Refmac.
> 
>   HTH,
>   Robbie
> 
>   > -Original Message-
>

Re: [ccp4bb] metal coordination at low resolution - restraints

[Robbie Joosten]

Yes, and the Zn is tetrahedral with a vacancy which makes then angles a bit 
more open. It's a good thing insulin makes nice crystals 😉

Cheers,
Robbie

> -Original Message-
> From: Eleanor Dodson 
> Sent: Tuesday, September 8, 2020 12:59
> To: Robbie Joosten 
> Cc: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] metal coordination at low resolution - restraints
> 
> I guess I have lived with Zn since I first learnt what a crystal was - ZN is 
> part
> of insulin secretion and whether it is or is not present is fundamental to the
> biochemistry..
> 
> I agree things have to be handled case by case - For insulin the three HIS are
> generated by symmetry and that causes horrible headaches for any restraint
> dictionary..
> And for Jan's case the resolution is excellent and the main links very clear. 
> (In
> fact they were not restrained but all distances finish up near to 2A as
> expected.) However maybe something can be learnt from this structure
> which would help the query which started us off!
> Eleanor
> 
> On Tue, 8 Sep 2020 at 11:49, Robbie Joosten  <mailto:robbie_joos...@hotmail.com> > wrote:
> 
> 
>   Hi Jan,
> 
>   If you want targets for your metal site you could have a look at
> MetalPDB (http://metalweb.cerm.unifi.it/). That has good tools to find
> similar sites and get some statistics you can use to generate case-specific
> restraints.
> 
>   Cheers,
>   Robbie
> 
>   > -Original Message-
>   > From: CCP4 bulletin board  <mailto:CCP4BB@JISCMAIL.AC.UK> > On Behalf Of Garib
>   > Murshudov
>   > Sent: Tuesday, September 8, 2020 12:44
>   > To: CCP4BB@JISCMAIL.AC.UK <mailto:CCP4BB@JISCMAIL.AC.UK>
>   > Subject: Re: [ccp4bb] metal coordination at low resolution -
> restraints
>   >
>   > Hi Jan,
>   >
>   >
>   >
>   >
>   >   On 8 Sep 2020, at 11:39, Jan Dohnalek
> mailto:dohnalek...@gmail.com>
>   > <mailto:dohnalek...@gmail.com
> <mailto:dohnalek...@gmail.com> > > wrote:
>   >
>   >   These are structural.
>   >
>   >
>   > Are they tetrahedral or octahedral? From the list of neighbours
> they do not
>   > look like tetrahedral. Some of them do look like octahedral.
>   >
>   >
>   >   They form the active site of our enzyme.
>   >
>   >
>   > So,are they  involved in reaction?
>   >
>   >
>   >   Normally there is no need to restrain these, they "behave".
>   >
>   >   But in general having such standard "restraint angles" available
>   > would be of use, I agree.
>   >
>   >
>   >
>   > For tetrahedral Zn we do have “bonds” and “angles” between Zn
> and
>   > coordinating residues. For general solution we need a bit different
> approach
>   > (e.g. coordination analysis).
>   >
>   >
>   >
>   > Regards
>   > Garib
>   >
>   >
>   >
>   >
>   >   Jan
>   >
>   >
>   >   On Tue, Sep 8, 2020 at 12:22 PM Garib Murshudov> lmb.cam.ac.uk <http://lmb.cam.ac.uk>  <mailto:garib@mrc-
> lmb.cam.ac.uk <mailto:ga...@mrc-lmb.cam.ac.uk> > > wrote:
>   >
>   >
>   >   What are these numbers?
>   >
>   >   If I understand these numbers correctly: none of your Zn
>   > atoms is structural (4 coordinated tetrahedral). If that is the case
> then you
>   > need specific links or restraints. If my reading of your numbers is
> correct
>   > then there could be some chemistry change of the surrounding
> residues.
>   >
>   >   If it is not structural Zn then it is likely that 
> coordination is
> 6.
>   > But without seeing coordinates and maps it is difficult to say what
> is there.
>   >
>   >   Regards
>   >   Garib
>   >
>   >
>   >
>   >   On 8 Sep 2020, at 11:11, Eleanor Dodson
>   >  <mailto:eleanor.dod...@york.ac.uk>  <mailto:eleanor.dod...@york.ac.uk
> <mailto:eleanor.dod...@york.ac.uk> > > wrote:
>   >
>   >   Hmm - here is my problem - a list of ZN 
> contacts for
>   > the two molecules..
>   >   residue 602 

Re: [ccp4bb] taking information from a deposited structure

[Robbie Joosten]

Dear Kahkashan,That is totally fine as long as you make it clear that you used this PDB entry. That's what the PDB is for.Just make sure you check the model with the electron density from EDS or pdb-redo. Cheers,RobbieOn 9 Sep 2020 07:41, Firdous Tarique  wrote:Dear CCP4 community members.I have solved  a crystal structure of a protein and am now trying to get a structure with a ligand bound to it, but so far unsuccessful. A homologous structure with the same ligand is present in the RCSB PDB (un published). Is it permissible to fetch structural information from that unpublished data and use it for docking and simulation studies with my protein? Will it be copyright infringement or it is just a normal thing.  I will be mentioning in my manuscript that I have used this unpublished structure (deposited by this author) for these studies. BestKahkashan


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




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

Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] AW: Going back to Coot 0.8

[Robbie Joosten]

Indeed, and that is why testing new developments in courses is so important 
because there you get naïve users. Obviously, this has been very difficult this 
year. It is also exactly the reason why you do need to have developers at 
courses, not just power users. 

For those struggling to get used to Coot 0.9 there are few tips:
1) Drag atoms where you want them to go, not beyond where you want them. I.e. 
don't "overdrag" like you used to do in Coot.
2) Try to get close to the right answer first by rigid body movement. This is 
particularly useful for ligands.
3) Practice*. The C-termini in PDB entry 1ggx are nice to practice resisting to 
overdrag.

Cheers,
Robbie

* Ling Ling practices 40 hours a day!

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Tim
> Gruene
> Sent: Wednesday, September 9, 2020 23:01
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] AW: Going back to Coot 0.8
> 
> Hi Eike,
> 
> one of the points is that, only because you got used to a certain operation
> (over many years after someone showed it to you), does not mean it is
> intuitive. This could be judged by e.g. showing an ignorant user both
> methods and let the person judge which one is easier to use...
> 
> Cheers,
> Tim
> 
> On Wed, 9 Sep 2020 20:27:55
> + "Schulz, Eike-Christian"  wrote:
> 
> > Hi Tim,
> >
> > I don't think that metaphor is quite correct. To me it seems that no
> > matter what button you pushed you got coffee. In my opinion intuitive
> > software is a blessing and should not easily be disregarded.
> >
> > But as I said before, I am happy to read into new stuff.
> >
> > Also there seem to be mixed experiences here. Might this be
> > map-resolution related ?
> >
> > Best,
> >
> > Eike
> >
> >
> >
> > -Original Message-
> > From: CCP4 bulletin board  on behalf of Georg
> > Zocher  Reply to: Georg Zocher 
> > Date: Wednesday, 9. September 2020 at 22:17
> > To: "CCP4BB@JISCMAIL.AC.UK" 
> > Subject: Re: [ccp4bb] [EXTERNAL] Re: [ccp4bb] AW: Going back to Coot
> > 0.8
> >
> > Dear Herman,
> >
> > Am 09.09.2020 um 17:46 schrieb Schreuder, Herman /DE:
> > > The old real-space refinement was intuitive and easy to use and
> > > did exactly what the user expected, without having to consult
> > > the manual!😊 The result might not have been perfect, but was
> > > good enough for subsequent Refmac, Buster, Phenix refinement.
> >
> > That fits perfectly to my user experience with RSR in coot 0.8.x.
> > and also explains why at least a number of people having some issues
> > with the new RSR.
> >
> > All the best,
> >
> > Georg
> >
> >
> >
> ###
> ###
> > ##
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> > mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
> > available at https://www.jiscmail.ac.uk/policyandsecurity/
> >
> >
> >
> ###
> ###
> > ##
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
> >
> > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, 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 CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1
> 
> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a
> mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at
> https://www.jiscmail.ac.uk/policyandsecurity/



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

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

[ccp4bb] PDB-REDO downtime on October 17th

[Robbie Joosten]

Dear BB'ers,

Due to electrical maintenance and testing at the Netherlands Cancer Institute, 
the PDB-REDO server and databank will be unavailable on Saturday October 17th 
from approximately 6:00h to 16:00h CEST (Amsterdam local time). 

Sorry for the inconvenience,
Robbie



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

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

Re: [ccp4bb] over-fitting? over-refinement?

[Robbie Joosten]

A related way of looking at things is saying that you model is over-fitted when 
you increase your model's precision without (noticeably) gaining accuracy.

Ethan describes the cases in which you add a lot of parameters in you model. 
The test he describes in his paper works great, I use it all the time in 
pdb-redo. Pavel sent a lot of references to R-free which is used to test how 
predictive the model is. If R-free deviates too much from R, then apparently 
your model is not predictive enough for additional data (so it's too precise or 
not accurate enough). If we relate accuracy to R-free and the predictiveness of 
the model, then where does the precision com from if you do not change the 
number of model parameters? We always give coordinates and B-factors with the 
same precision in our models, don't we? Well yes, but we change other aspects 
of the model's precision by adding restraints (effectively improving the 
degrees of freedom of the model: Occam's Razor). For instance we have 
restraints to reduce the range that bond lengths can have in our model with 
respect to their "known" standard deviation. Or we reduce the differences 
between things we expect to be very similar with NCS restraints. That is why we 
validate models by looking at scores like the bond length rmsZ: we check 
whether the model is not too precise overall. If one bond is much longer or 
shorter than expected, this can still be right. If most of them are, then 
something is going on and your model may be too precise. Same goes for your 
Ramachandran plot, a single outlier may not be a problem, but if all residues 
are off a lot you should worry. That is why we have been advocating the 
Ramachandran Z-score (also see the recent paper by the Phenix and PDB-REDO 
teams).

All of the things are related to the degrees of freedom of your system 
(obeservations - parameter + some_weight*restraints). Make sure you do not have 
too many parameters overall, improve the degrees of freedom by adding 
restraints. You can balance precision and accuracy by changing the weights on 
the restraints. And you check the accuracy by looking at the deviation of R and 
R-free.

HTH,
Robbie 

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Ethan A
> Merritt
> Sent: Tuesday, October 20, 2020 06:04
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] over-fitting? over-refinement?
> 
> On Monday, 19 October 2020 20:27:04 PDT Sam Tang wrote:
> > Hi, the question may be a bit weird, but how do you define 'over-fitting'
> > in the context of structure refinement? From users' perspective the
> > practical aspect is to 'fit' the model into the density. So there
> > comes this question from our juniors: fit is fit, how is a model over-fit?
> 
> That is a good question, not asked as many times as it should be.
> There are several validation techniques, tools, and indicators.
> You are probably at least familiar with Rfree as an indicator.
> But you are asking the deeper question "what is it that makes it over-fit".
> 
> I suggest that the best starting point for thinking about it is Occam's Razor,
> specifically the rephrasing by Albert Einstein:
>"Everything should be made as simple as possible,
> but no simpler."
> 
> In applying this to considering a crystallographic model, that can be
> translated as "the number of parameters used in the model should be as
> small as possible, but no smaller".
> 
> For example, if your structure is a homo-dimer you have a choice of
> modelling each monomer separately or modelling only one monomer and
> then describing how to generate the second by some symmetry operation.
> Modeling each monomer independently will obviously require twice as many
> parameters as modelling only one.
> The guidance from Occam + Einstein is that the simpler (== smaller) model is
> better, but only if it in fact adequately explains your observations.
> 
> Ah, but how do you know if the simpler description is "adequate"?
> That's where specific statistical tests and quality measures come in.
> From hundreds of thousands of previous crystal structures we have a good
> idea of what the R-factor for a good model is expected to be.
> Does your simple model have a good R-factor?   Good enough?
> If you refine the more complicated (twice as big) model does it have a better
> R-factor?  If not then clearly all those extra parameters are useless and the
> model is over-fit.
> More typically the R-factor for the more complicated model will be a little 
> bit
> better.  But "a little bit" is not very convincing.
> So we need some statistical test to ask if the model is
> _significantly_ better.   I won't delve into statistics here,
> but that's the philosophical approach.
> 
> I wrote a paper some years ago trying to lay this out as clearly as I could
> while focusing on a common choice made by crystallographers as to how to
> choose or refine B factors.  The logic and statistical approach is valid for
> many other choices in

Re: [ccp4bb] Kevin Denkmann lädt Sie zur Zusammenarbeit auf 'Rechnungen' ein.

[Robbie Joosten]

Working on your bills with the entire bulletin board. Is that crowdsourcing or 
what? 😉

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Kevin
> Denkmann
> Sent: Tuesday, October 20, 2020 15:27
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Kevin Denkmann lädt Sie zur Zusammenarbeit auf
> 'Rechnungen' ein.
> 
> 
> Kevin Denkmann shared a file with you
> 
> Here's the document that Kevin Denkmann shared with you.
> 
>  my.sharepoint.com:443/:b:/g/personal/kevin_denkmann_dunnlab_de/EZQT
> 7ED-bpdJtg5lG-H32GkByQoTQqzWyiKSIRel_DIrFA?e=4%3a9jNtyK&at=9>
>   Rechnungen
>   This link will work for anyone.
> Open  my.sharepoint.com:443/:b:/g/personal/kevin_denkmann_dunnlab_de/EZQT
> 7ED-bpdJtg5lG-H32GkByQoTQqzWyiKSIRel_DIrFA?e=4%3a9jNtyK&at=9>
> 
>   Privacy Statement  notifyp.svc.ms:443/api/v2/tracking/method/Click?mi=HgrSi7OfwUKiTn-
> 401hPpQ&tc=PrivacyStatement&cs=f97d4ae4336b3342c9a937ee3f36e84e&r
> u=https%3a%2f%2fprivacy.microsoft.com%2fprivacystatement%5c>
>   notifyp.svc.ms:443/api/v2/tracking/method/View?mi=HgrSi7OfwUKiTn-
> 401hPpQ>
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1




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

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

Re: [ccp4bb] phenix.refine with ligand with ambiguous electron density

[Robbie Joosten]

I’m with Dale on this, the scientifically prudent thing is to set the rules and 
then play by them. Not to change the rules as you go. Of course, in a teaching 
environment where you know the correct answer, it is good to be educational and 
learn how to dig a bit more.

However, in a scientific setting this digging is not to come to a strong 
conclusion, but only to see if you should pursue the project and do additional 
experiments (e.g. longer soaks or using a higher ligand concentration). In this 
case the topic starter has poor density and fitting the ligand and refining 
gives negative difference density. Surely that is not enough evidence to reject 
the null hypothesis “the ligand is not bound”. In other words, there is no 
strong evidence that the ligand is bound. Perhaps you can look at the occupancy 
, but that is probably as far as you should go. The polder map is useful to get 
rid of the effect of the solvent mask blurring actual ligand density. But after 
fitting the ligand you shouldn’t need the polder map. Blurring and sharpening 
is something to make sense of the density shape to better fit your ligand, not 
to conclude whether or not you ligand is there.

On a whole, for ligands we should try to stick to the so-called “bloody 
obvious” test: if the density is not bloody obvious, your ligand is not there. 
At least not all the time.

Cheers,
Robbie


From: CCP4 bulletin board  On Behalf Of Jon Cooper
Sent: Wednesday, November 25, 2020 05:20
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] phenix.refine with ligand with ambiguous electron density

Hello Dale, the statistical rigour you describe is, of course, excellent, but 
in a learning environment, if someone gets a negative result, you have to go 
into overdrive to check that everything has been done correctly, since there is 
a fair chance that human error is the cause. It may be a terrible practice, but 
it would seem to be an important part of the process? Even as a relative 
newcomer to the field (well, since the mid-80's ;-) I have seen many people 
getting nothing in their initial difference maps, even if the ligand is there. 
Frequently it was just the contour level being too high and, depending on how 
far back you go, the solution varied from showing someone how to roll the mouse 
wheel in Coot to having the map recontoured at a computer centre 200 miles away 
and posted back on a magnetic tape, which took about 10 days - a timescale on 
which some people just gave up and did something else! I can't help thinking it 
would be a shame to robotically accept every negative result at face value, not 
least if you're doing something important like curing a pandemic. However, back 
to the original question which I think was whether polder map coefficients 
could be used as refinement targets and I think the answer to that one is 
probably 'no', at least in the X-ray field ;-)

Best wishes, Jon Cooper



 Original Message 
On 24 Nov 2020, 16:02, Dale Tronrud < 
de...@daletronrud.com> wrote:


Hi,

To me, this sounds like a very dangerous way to use this tool decide
if a ligand has bound. I would be very reluctant to modify my map with
a range of arbitrary parameters until it looked like what I wanted to
see. The sharpening and blurring of this tool is not guided or limited
by theory or data.

As you describe it, your choice of map is driven by its agreement
with your ligand, and the proper way to make this decision is the other
way around.

The original poster has the problem that their density does not have
the appearance they desire. They have chosen to run around trying to
find some way to modify the map to get a variant that does. This is a
terrible practice, since the final choice of map is being made in a
fashion that is dominated by bias.

I have no idea what sort of "structural characteristics" have
convinced this poster of the presence of their ligand despite the
absence of clear electron density. What other evidence does a
diffraction pattern give? The map is your best and only source of
information about your structure that you can get from the diffraction
pattern. (Mass spec and other experimental techniques could, of course,
be applied.)

I think we, as a community, could learn a few things from the
vaccine trial studies that are so much in the news now. In a modern
clinical trial, to avoid bias in the interpretation of the results, all
of the statistical procedures are decided upon BEFORE the study is even
began. This protocol is written down and peer reviewed at the start.
Then the study is performed and the protocol is followed exactly. If
the results don't pass the test, the treatment is not supported. There
is no hunting around, after the fact, for a "better" statistical measure
until one is found that "works".

This way of handling data analysis in clinical trials was adopted
after the hard lesson was learned that many trails could be reproduced,
their results were not.

Re: [ccp4bb] Mean B factors and number of atoms (Refmac/baverage)

[Robbie Joosten]

Hi Julia,

For a table 1 you should make a sensible split of the atoms over which you 
calculate the mean. You might need to pool certain chains. There is not really 
convenient tool for that because the choice depends on the biology/biochemistry 
of your system. In practice, the easiest way is using the command line on just 
the ATOM/HETATM records (atom_site in mmCIF format) in which you are 
interested. Calculating the mean of a column of values is pretty 
straightforward in awk.
Example for all atoms in a PDB file:
grep ^[HA][TE][OT][MA] 100d_final.pdb  | cut -c 61-66 | awk '{sum = sum + $1} 
END {print sum/NR}'

Or mmCIF:
grep [HA][TE][OT][MA] /DATA/pdb_redo/00/100d/100d_final.cif |  awk '{sum = sum 
+ $16} END {print sum/NR}'

HTH,
Robbie

From: CCP4 bulletin board  On Behalf Of Julia Griese
Sent: Thursday, November 26, 2020 15:11
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Mean B factors and number of atoms (Refmac/baverage)

Hi all,

I’m writing a Table 1 and getting a bit confused when it comes to number of 
atoms and average B factors. Refmac has these in the table in the GUI, but the 
atom numbers in that table seem to include H, and I’m only interested in non-H 
atoms.
As an example, the PDB file says:

REMARK   3  NUMBER OF NON-HYDROGEN ATOMS USED IN REFINEMENT.
REMARK   3   ALL ATOMS: 8351

Which agrees with the total count minus TER cards, so that seems to be correct. 
However, the table in the GUI for this refinement run looks like this:

Chain mean B(No. atoms)
 AAA
41.4(   2193 )
BBB
57.7(   3499 )
CCC
57.7(   3499 )
DDD
41.7(   2212 )
EEE
60.3(923 )
FFF
60.6(920 )
aaa
55.4(   1323 )
ddd
56.0(   1346 )
GGG
34.3(  1 )
GaG
42.7(  1 )
GbG
34.3(  1 )
GcG
40.1(  1 )
GdG
40.6(  1 )
GeG
35.8(  1 )
GfG
34.2(  1 )
GgG
43.2(  1 )
HHH
40.6(136 )

You can easily see that this adds up to a lot more than 8351 atoms. The numbers 
for the G chain (metal ions) and the H chain (water) are correct, whereas the 
numbers for the macromolecule chains appear to include H. (If I run a 
refinement with H output to the final file, I get approximately the same number 
of atoms in total, though not quite.) But what I’m really interested in is of 
course the number of non-H atoms per chain. I don’t want to count all the atoms 
by hand…

I used to use baverage to calculate average B factors (and that would also give 
me the number of non-H atoms per chain), but can’t get that to work on the 
command line and can’t find it in the i2 GUI. I don’t have the old ccp4i 
anymore.

So if anyone could either tell me how to get baverage to work, or if there is 
another way to extract these numbers, I would much appreciate it!

Best,

Julia


--
Dr. Julia Griese
Assistant Professor
Department of Cell and Molecular Biology
Uppsala University
BMC, Box 596
SE-75124 Uppsala
Sweden

email: julia.gri...@icm.uu.se
phone: +46-(0)18-471 4043
http://www.icm.uu.se/structural-biology/griese-lab/








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/en/about-uu/data-protection-policy



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



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

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

Re: [ccp4bb] Refmac not handling microheterogeneity?

[Robbie Joosten]

Hi Ian,

AFAIK there is no clean solution for this and I imagine this problem goes very 
deep into the internal representation of the model in REFMAC. That said, 1 in 6 
missing PDB-REDO entries is caused by this problem, so a solution would be very 
welcome.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Ian
> Tickle
> Sent: Wednesday, December 2, 2020 15:02
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Refmac not handling microheterogeneity?
> 
> 
> Dear All
> 
> I just downloaded a PDB file (7A5V) from the EBI server, tried to run Refmac
> on it and got the error:
> 
> ERROR: in chain A residue: 279 different residues have the same number
> There is an error in the input coordinate file
> 
> At least one the chains has 2 residues with the same number ===> Error:
> Problem with coordinate file
> 
> 
> and indeed residue A279 has:
> 
> ATOM   2354  N  ATHR A 279 138.241 168.068 154.050  0.50 27.65   N
> 
> and
> ATOM   2361  N  BLYS A 279 138.238 168.081 154.020  0.50 32.20   N
> and the same for all the other atoms in the residues.
> 
> Searching the CCP4BB archives for "microheterogeneity" I see that this has
> been discussed before and apparently it should "just work" if there are alt
> atom indicators (check) and occupancies add up to <= 1 (check).  I must say I
> also was of the impression that it "just worked" so I'm a bit confused now
> why it doesn't.
> 
> Version info:
> DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
> ### CCP4 7.1.008: Refmac  version 5.8.0267 : 24/08/20##
> 
> Is there some other hack I need to do to get it to work?
> 
> Cheers
> 
> -- Ian
> 
> 
> 
> 
> 
> 
> 
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1




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

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

Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- N-glycans are now separate chains if more than one residue

[Robbie Joosten]

Dear Zhijie,

In generally I like the treatment of carbohydrates now as branched polymers. I 
didn't realise there was an exception. It makes sense for unlinked carbohydrate 
ligands, but not for N- or O-glycosylation sites as these might change during 
model building or, in my case, carbohydrate rebuilding in PDB-REDO powered by 
Coot. Thanks for pointing this out.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Zhijie Li
> Sent: Thursday, December 3, 2020 19:52
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the
> PDB -- N-glycans are now separate chains if more than one residue
> 
> Hi all,
> 
> I was confused when I saw mysterious new glycan chains emerging during
> PDB deposition and spent quite some time trying to find out what was
> wrong with my coordinates.  Then it occurred to me that a lot of recent
> structures also had tens of N-glycan chains.  Finally I realized that this
> phenomenon is a consequence of this PDB policy announced here in July.
> 
> 
> For future depositors who might also get puzzled, let's put it in a short
> sentence:  O- and N-glycans are now separate chains if it they contain more
> than one residue; single residues remain with the protein chain.
> 
> 
> https://www.wwpdb.org/documentation/carbohydrate-remediation
> 
> "Oligosaccharide molecules are classified as a new entity type, branched,
> assigned a unique chain ID (_atom_site.auth_asym_id) and a new mmCIF
> category introduced to define the type of branching
> (_pdbx_entity_branch.type) . "
> 
> 
> 
> 
> 
> I found the differential treatment of single-residue glycans and multi-residue
> glycans not only bit lack of aesthetics but also misleading.  When a structure
> contains both NAG-NAG... and single NAG on N-glycosylation sites, it might
> be because of lack of density for building more residues, or because that
> some of the glycosylation sites are now indeed single NAGs (endoH etc.)
> while some others are not cleaved due to accessibility issues.Leaving NAGs
> on the protein chain while assigning NAG-NAG... to a new chain, feels like
> suggesting something about their true oligomeric state.
> 
> 
> For example, for cryoEM structures, when one only builds a single NAG at a
> site does not necessarily mean that the protein was treated by endoH. In
> fact all sites are extended to at least tri-Man in most cases. Then why
> keeping some sites associated with the protein chain while others kicked
> out?
> 
> Zhijie
> 
> 
> 
> 
> 
> From: CCP4 bulletin board  on behalf of John
> Berrisford 
> Sent: Thursday, July 9, 2020 4:39 AM
> To: CCP4BB@JISCMAIL.AC.UK 
> Subject: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB
> 
> 
> Dear CCP4BB
> 
> PDB data will shortly incorporate a new data representation for
> carbohydrates in PDB entries and reference data that improves the
> Findability and Interoperability of these molecules in macromolecular
> structures. In order to remediate and improve the representation of
> carbohydrates across the archive, the wwPDB has:
> 
> * standardized Chemical Component Dictionary nomenclature
> following IUPAC-IUBMB recommendations
> * provided uniform representation for oligosaccharides
> * adopted Glycoscience-community commonly used linear descriptors
> using community tools
> * annotated glycosylation sites in PDB structures
> 
> Starting July 29, 2020, users will be able to access the improved data via FTP
> or wwPDB partner websites. Detailed information about this project is
> available at the wwPDB website
>  ; lists
> of impacted entries and chemical components will be published on this page
> after data release.
> 
> The wwPDB has created a new ‘branched’ entity representation for
> polysaccharides, describing all the individual monosaccharide components of
> these in the PDB entry. As part of this process, we have standardized atom
> nomenclature of >1,000 monosaccharides in the Chemical Component
> Dictionary (CCD) and applied a branched entity representation to
> oligosaccharides for >8000 PDB entries. To guarantee unambiguous chemical
> description of oligosaccharides in the affected PDB entries, an explicit
> description of covalent linkage information between their monosaccharide
> units is included. In addition, wwPDB validation reports provide consistent
> representation for these oligosaccharides and include 2D representations
> based on the Symbol Nomenclature for Glycans (SNFG).
> 
> To support the remediation of carbohydrate representation, software tools
> providing linear descriptors were developed in collaboration with the
> glycoscience community to enable easy translation of PDB data to other
> representations commonly used by glycobiologists. These include Condense
> IUPAC from GMML   at University
> of Georgia, W

Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- N-glycans are now separate chains if more than one residue

[Robbie Joosten]

Dear Dale,Yes, good point. Let's stop bending over backwards to come up with faux PDB compatibility and focus on making mmCIF better.There are struct_conn records that describe the linkages. This is enough to reconstruct the connectivity. There is an ongoing debate on how to capture the restraints for such linkages. But at least this can in principle be captured in mmCIF whereas this is pretty much undoable in PDB format.Cheers,RobbieOn 4 Dec 2020 18:01, Dale Tronrud  wrote:

    This suggestion violates a basic principle of data base theory.  A 

single data item cannot encode two pieces of information.  The whole 

structure of CIF falls apart if this is done.



    Does the new PDB convention contain a CIF record of the link that 

bridges between the protein chain and the, now separated, glycan chain? 

  If not, I think this is the principle failing of their new scheme.



Dale Tronrud



On 12/4/2020 12:06 AM, Tristan Croll wrote:

> To go one step further: in large, heavily glycosylated multi-chain complexes the assignment of a random new chain ID to each glycan will lead to headaches for people building visualisations using existing viewers, because it loses the easy name-based association of glycan to parent protein chain. A suggestion: why not take full advantage of the mmCIF capability for multi-character chain IDs, and name them by appending characters to the parent chain ID? Using chain A as an example, perhaps the glycans could become Ag1, Ag2, etc.?

> 

>> On 4 Dec 2020, at 07:48, Luca Jovine  wrote:

>>

>> CC: pdb-l

>>

>> Dear Zhijie and Robbie,

>>

>> I agree with both of you that the new carbohydrate chain assignment convention that has been recently adopted by PDB introduces confusion, not just for PDB-REDO but also - and especially - for end users.

>>

>> Could we kindly ask PDB to improve consistency by either assigning a separate chain to all covalently attached carbohydrates (regardless of whether one or more residues have been traced), or reverting to the old system (where N-/O-glycans inherited the same chain ID of the protein to which they are attached)? The current hybrid solution hardly seems optimal...

>>

>> Best regards,

>>

>> Luca

>>

>>> On 3 Dec 2020, at 20:17, Robbie Joosten  wrote:

>>>

>>> Dear Zhijie,

>>>

>>> In generally I like the treatment of carbohydrates now as branched polymers. I didn't realise there was an exception. It makes sense for unlinked carbohydrate ligands, but not for N- or O-glycosylation sites as these might change during model building or, in my case, carbohydrate rebuilding in PDB-REDO powered by Coot. Thanks for pointing this out.

>>>

>>> Cheers,

>>> Robbie

>>>

>>>> -Original Message-

>>>> From: CCP4 bulletin board  On Behalf Of Zhijie Li

>>>> Sent: Thursday, December 3, 2020 19:52

>>>> To: CCP4BB@JISCMAIL.AC.UK

>>>> Subject: Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the

>>>> PDB -- N-glycans are now separate chains if more than one residue

>>>>

>>>> Hi all,

>>>>

>>>> I was confused when I saw mysterious new glycan chains emerging during

>>>> PDB deposition and spent quite some time trying to find out what was

>>>> wrong with my coordinates.  Then it occurred to me that a lot of recent

>>>> structures also had tens of N-glycan chains.  Finally I realized that this

>>>> phenomenon is a consequence of this PDB policy announced here in July.

>>>>

>>>>

>>>> For future depositors who might also get puzzled, let's put it in a short

>>>> sentence:  O- and N-glycans are now separate chains if it they contain more

>>>> than one residue; single residues remain with the protein chain.

>>>>

>>>>

>>>> https://eur01.safelinks.protection.outlook.com/?url=""

>>>>

>>>> "Oligosaccharide molecules are classified as a new entity type, branched,

>>>> assigned a unique chain ID (_atom_site.auth_asym_id) and a new mmCIF

>>>> category introduced to define the type of branching

>>>> (_pdbx_entity_branch.type) . "

>>>>

>>>>

>>>>

>>>>

>>>>

>>>> I found the differential treatment of single-residue glycans and multi-residue

>>>> glycans not only bit lack of aesthetics but also misleading.  When a structure

>>>> contains both NAG-NAG... and single NAG on N-glycosylation sites, it might

>>>> be because of lack of density for building more residues, or because that

>&

Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- N-glycans are now separate chains if more than one residue

[Robbie Joosten]

Hi Luca,

Your point remains completely valid and I agree that residues that can belong 
to a longer chain should be treated as such. The same problem is with peptide 
ligands (at least in PDB times), if they consist of three residues they would 
their own chains, with 2 residues they would not. It's spectacular how much 
code beaks on that. 

At the same time you have to understand that the PDB makes design choices and 
that some experimentalist will find an exception. Yes, there are PDB entries 
where they add amino acids as crystallisation additives. As an interesting 
exception, this works better for nucleic acids: A loose nucleotide, say AMP, 
has a different name than a nucleotide that is part of a polymer. 

Anyway, we should appreciate the work that goes into setting up something as 
the PDB which is, by all means, a triumph in biological databases and an 
example to other fields.

Cheers,
Robbie



> -Original Message-
> From: CCP4 bulletin board  On Behalf Of Luca
> Jovine
> Sent: Friday, December 4, 2020 18:45
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the
> PDB -- N-glycans are now separate chains if more than one residue
> 
> Dear Dale and Robbie,
> 
> I agree with your comments! But may I stir back the discussion to the
> original issue, which is that one-residue N-glycans are now treated
> differently from multi-residue N-glycans (although they are both covalently
> linked to a protein chain)? This inconsistency is independent of the file
> format…
> 
> Best, Luca
> 
> 
>   On 4 Dec 2020, at 18:30, Robbie Joosten
> mailto:robbie_joos...@hotmail.com>
> > wrote:
> 
>   Dear Dale,
> 
>   Yes, good point. Let's stop bending over backwards to come up with
> faux PDB compatibility and focus on making mmCIF better.
> 
>   There are struct_conn records that describe the linkages. This is
> enough to reconstruct the connectivity. There is an ongoing debate on how
> to capture the restraints for such linkages. But at least this can in 
> principle be
> captured in mmCIF whereas this is pretty much undoable in PDB format.
> 
>   Cheers,
>   Robbie
> 
> 
>   On 4 Dec 2020 18:01, Dale Tronrud  <mailto:de...@daletronrud.com> > wrote:
> 
> 
> 
>   This suggestion violates a basic principle of data base
> theory.  A
>   single data item cannot encode two pieces of information.
> The whole
>   structure of CIF falls apart if this is done.
> 
>   Does the new PDB convention contain a CIF record of the
> link that
>   bridges between the protein chain and the, now separated,
> glycan chain?
> If not, I think this is the principle failing of their new
> scheme.
> 
>   Dale Tronrud
> 
>   On 12/4/2020 12:06 AM, Tristan Croll wrote:
>   > To go one step further: in large, heavily glycosylated multi-
> chain complexes the assignment of a random new chain ID to each glycan
> will lead to headaches for people building visualisations using existing
> viewers, because it loses the easy name-based association of glycan to
> parent protein chain. A suggestion: why not take full advantage of the
> mmCIF capability for multi-character chain IDs, and name them by
> appending characters to the parent chain ID? Using chain A as an example,
> perhaps the glycans could become Ag1, Ag2, etc.?
>   >
>   >> On 4 Dec 2020, at 07:48, Luca Jovine  <mailto:luca.jov...@ki.se> > wrote:
>   >>
>   >> CC: pdb-l
>   >>
>   >> Dear Zhijie and Robbie,
>   >>
>   >> I agree with both of you that the new carbohydrate chain
> assignment convention that has been recently adopted by PDB introduces
> confusion, not just for PDB-REDO but also - and especially - for end users.
>   >>
>   >> Could we kindly ask PDB to improve consistency by either
> assigning a separate chain to all covalently attached carbohydrates
> (regardless of whether one or more residues have been traced), or reverting
> to the old system (where N-/O-glycans inherited the same chain ID of the
> protein to which they are attached)? The current hybrid solution hardly
> seems optimal...
>   >>
>   >> Best regards,
>   >>
>   >> Luca
>   >>
>   >>> On 3 Dec 2020, at 20:17, Robbie Joosten
> mailto:robbie_joos...@hotmail.com>
> > wrote:
>   >>>
>  

Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- N-glycans are now separate chains if more than one residue

[Robbie Joosten]

.UK
> > 
> > *Subject:* Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at
> > the PDB -- N-glycans are now separate chains if more than one residue
> >
> >      This suggestion violates a basic principle of data base theory.
> > A single data item cannot encode two pieces of information.  The whole
> > structure of CIF falls apart if this is done.
> >
> >      Does the new PDB convention contain a CIF record of the link that
> > bridges between the protein chain and the, now separated, glycan chain?
> >    If not, I think this is the principle failing of their new scheme.
> >
> > Dale Tronrud
> >
> > On 12/4/2020 12:06 AM, Tristan Croll wrote:
> >> To go one step further: in large, heavily glycosylated multi-chain
> >> complexes the assignment of a random new chain ID to each glycan will
> >> lead to headaches for people building visualisations using existing
> >> viewers, because it loses the easy name-based association  of glycan
> >> to parent protein chain. A suggestion: why not take full
> > advantage of the mmCIF capability for multi-character chain IDs, and
> > name them by appending characters to the parent chain ID? Using chain
> > A as an example, perhaps the glycans could become Ag1, Ag2, etc.?
> >>
> >>> On 4 Dec 2020, at 07:48, Luca Jovine  wrote:
> >>>
> >>> CC: pdb-l
> >>>
> >>> Dear Zhijie and Robbie,
> >>>
> >>> I agree with both of you that the new carbohydrate chain assignment
> convention that has been recently adopted by PDB introduces confusion,
> not just for PDB-REDO but also - and especially - for end users.
> >>>
> >>> Could we kindly ask PDB to improve consistency by either assigning a
> >>> separate chain to all covalently attached carbohydrates (regardless
> >>> of whether one or more residues have been traced), or reverting to
> >>> the old system (where N-/O-glycans inherited the same  chain ID of
> >>> the protein to which they are attached)? The current
> > hybrid solution hardly seems optimal...
> >>>
> >>> Best regards,
> >>>
> >>> Luca
> >>>
> >>>> On 3 Dec 2020, at 20:17, Robbie Joosten
>  wrote:
> >>>>
> >>>> Dear Zhijie,
> >>>>
> >>>> In generally I like the treatment of carbohydrates now as branched
> polymers. I didn't realise there was an exception. It makes sense for unlinked
> carbohydrate ligands, but not for N- or O-glycosylation sites as these might
> change during model building or,  in my case, carbohydrate rebuilding in
> PDB-REDO powered by Coot.
> > Thanks for pointing this out.
> >>>>
> >>>> Cheers,
> >>>> Robbie
> >>>>
> >>>>> -Original Message-
> >>>>> From: CCP4 bulletin board  On Behalf Of
> >>>>> Zhijie Li
> >>>>> Sent: Thursday, December 3, 2020 19:52
> >>>>> To: CCP4BB@JISCMAIL.AC.UK
> >>>>> Subject: Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data
> >>>>> at the PDB -- N-glycans are now separate chains if more than one
> >>>>> residue
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I was confused when I saw mysterious new glycan chains emerging
> >>>>> during PDB deposition and spent quite some time trying to find out
> >>>>> what was wrong with my coordinates.  Then it occurred to me that a
> >>>>> lot of recent structures also had tens of N-glycan chains.
> >>>>> Finally I realized that this phenomenon is a consequence of this PDB
> policy announced here in July.
> >>>>>
> >>>>>
> >>>>> For future depositors who might also get puzzled, let's put it in
> >>>>> a short
> >>>>> sentence:  O- and N-glycans are now separate chains if it they
> >>>>> contain more than one residue; single residues remain with the
> protein chain.
> >>>>>
> >>>>>
> >>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> www.wwpdb.org%2Fdocumentation%2Fcarbohydrate-
> remediation&data=
> >>>>>
> 04%7C01%7Cluca.jovine%40KI.SE%7C1d790a0717ce4217c7a308d897c01b47
> %7
> >>>>>
> Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C1%7C637426199684263065%
> 7CU
> >>>&g

Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- N-glycans are now separate chains if more than one residue

[Robbie Joosten]

Dear Jasmine,

I have a few questions about this bit:
//
As some users pointed out, single NAG could be just a part of the glycan that 
the author chose to build, as most natural N-glycans must have stem of a common 
core of 5 monosaccharides or its fucosylated version, such as those modeled in 
the PDB ID 6WPS. However, the PDB is a 3D-atomic coordinate archive in which 
the model coordinates are built based on supporting experimental data. 
Therefore, carbohydrates are described as-is in the modeled structures without 
reference to missing components of the presumed oligosaccharide sequence. If 
the author only builds a monosaccharide, then this monosaccharide is described 
as a non-polymer ligand.
//
Is it technically allowed to have a single, covalently bound carbohydrate 
described as a branched entity of length 1?
If so, if an author does specify such a single modeled residue as branched 
entity, for instance because (s)he has a good reason to suspect that a second 
residue was there, but isn’t comfortable with building it, then is this 
specification kept in annotation?
If not, do you expect model building programs to switch from branched to 
non-poly entities when a second residue is removed when a model is written out? 
And back again when a residue is added? I find this rather unpractical from an 
implementation point of view. We change carbohydrate trees quite regularly.

Cheers,
Robbie


From: CCP4 bulletin board  On Behalf Of Jasmine Young
Sent: Tuesday, December 8, 2020 21:01
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Coming July 29: Improved Carbohydrate Data at the PDB -- 
N-glycans are now separate chains if more than one residue

Dear PDB Data Users:

Thank you for providing feedback on the results of an archival-level 
carbohydrate remediation project that led to the re-release of over 14,000 PDB 
structures in July 2020. This update includes diverse oligosaccharides: 
glycosylation; metabolites such as maltose, sucrose, cellulose fragments; 
glycosaminoglycans, such as fragments of heparin and heparan sulfate; epitope 
patterns such as A/B blood group antigens and the H-type or Lewis-type stems; 
and many artificial carbohydrates mimicking or counting natural products 
(https://www.wwpdb.org/documentation/carbohydrate-remediation).

Starting in 2017, this PDB remediation aimed to standardize the biochemical 
nomenclature of the carbohydrate components following the IUPAC-IUBMB 
recommendations established by the carbohydrate community 
(https://media.iupac.org/publications/pac/1996/pdf/6810x1919.pdf), and to 
provide uniform representation of oligosaccharides to improve the 
identification and searchability of oligosaccharides modeled in the PDB 
structures.  During the remediation planning, wwPDB consulted community users 
and the PDBx/mmCIF Working Group and made data files available on GitHub in 
early 2020 for community feedback. wwPDB has collaborated with Robert Woods at 
University of Georgia in US, researchers at The Noguchi Institute and Soka 
University in Japan, and Thomas Lutteke in Germany to generate uniform linear 
descriptors for the oligosaccharide sequences.

To achieve these community goals, each oligosaccharide is represented as a 
branched entity with complete biochemical description and each glycosidic 
linkage specified. The full representation of carbohydrates is provided in the 
mmCIF format file, but this is not possible in legacy PDB format files (as the 
format has been frozen since 2012 
(https://www.wwpdb.org/documentation/file-formats-and-the-pdb).

Proper indexing is necessary for branched entity representation and for 
generation of linear descriptors, hence the ordering (numbering) starts at the 
reducing end (#1), where the glycosylation occurs, to the non-reducing end in 
ascending order. Unique chain IDs are assigned to branched entities 
(oligosaccharides) to avoid residue numbering overlapped with protein residues 
and to enable consistent numbering for every oligosaccharide. For example, in 
PDB ID 6WPS, there are 5 oligosaccharides associated with the same protein 
chain A, the consistent ordering and numbering can only be retained with unique 
chain ID for each oligosaccharide in both PDBx/mmCIF and PDB format files

For archival consistency, a single-monosaccharide is defined as a non-polymer 
and treated consistently with other non-polymer ligands in the PDB. A 
single-monosaccharide occurring at a glycosylation site has a unique chain ID 
in the PDBx/mmCIF file (_atom_site.label_asym_id) but not in the PDB format 
file.

Using PDB ID 6WPS as an example, the PDBx/mmCIF data item 
_atom_site.label_asym_id corresponds to the column #7 in the atom_site 
coordinates section has an asym ID ‘Y’ for the 1st instance of 
single-monosaccharide, NAG bound to ASN 61 of protein chain ‘A’. The ‘Y’ value 
is unique for this monosaccharide. The additional chain ID 
(_atom_site.auth_asym_id) in the PDBx/mmCIF file that mapped to the PDB format 
file for 

Re: [ccp4bb] number of cycles in refmac

[Robbie Joosten]

Dear Protein Chemistry (?),

When R and R-free drift off you are probably refining with suboptimal weights. 
If anything, it proves you still have work to do. At convergence R and R-free 
do not really change anymore so neither does the difference. If you have 
already done a lot of rebuilding and refinement 20 cycles is usually enough 
(but more cycles shouldn't hurt).

Cheers,
Robbie

Date: Fri, 26 Aug 2011 20:29:59 +0530
From: proteinchemistr...@gmail.com
Subject: Re: [ccp4bb] number of cycles in refmac
To: CCP4BB@JISCMAIL.AC.UK



Dear Dr Ian



from your argument i could not understand how many cycles to refine 
before submitting the coordinates to the PDB. what is the upper limit 
100 or thousand or million according to my understanding, its more 
logical to stop the refinement when over refinement is  taking place 
(when R and Rfree are going in opposite directions and LLG is stabilized
 )

AR

  

Re: [ccp4bb] Superpose, SSM

[Robbie Joosten]

One would assume that Windows software would read DOS/Windows type text 
files... 
Open the file in Wordpad. Unlike Notepad, it is able to work with Windows and 
Unix type text files. If you edit something and save the file, it will be in 
Windows style. If Superpose stops on that, it should really be updated. I'm 
sure that there are Windows versions op the programs Unix2dos and Dos2unix 
which were the programs to use to convert one type to the other. You can also 
use Word to search and replace the linefeeds.

Good luck with this very retro problem. 
Cheers,
Robbie

> Date: Mon, 26 Sep 2011 17:07:50 -0600
> From: xtald...@gmail.com
> Subject: Re: [ccp4bb] Superpose, SSM
> To: CCP4BB@JISCMAIL.AC.UK
> 
> I think something in your workflow is inserting dos line feeds (\n\r or \r\n, 
> I can't remember which).
> 
> If I have guessed correctly, you want to remove those "\r"s before proceeding 
> (or never let them get in there in the first place).
> 
> You claim to open it with MS something, which would insert dos line feeds as 
> part of Operation Vendor Lock. Did you happen to save it, perhaps by habit? 
> That would do the trick.  It might even do something insidious and insert 
> those linefeeds without your purposefully saving the document. 
> 
> Your best bet to fix the file after corruption is vim (used to be that 
> "crystallographers" could use real text editors).
> 
> The command in vim is:
> 
>   :%s/\r//g
> 
> You might find some third party utility that fixes linefeeds for $30.00 
> somewhere, if vim is too "retro".
> 
> Otherwise, you may want to start over, skip checking it out in MS something, 
> and go straight to superpose.
> 
> James
> 
> 
> 
> On Sep 26, 2011, at 2:51 PM, Matthias Zebisch wrote:
> 
> > Hi again,
> > 
> > Thanks for your quick replies but I think I made myself not clear. here is 
> > what I'm doing:
> > 
> > 1) superpose proteinA.pdb onto proteinB.pdb  : works, but gives out 
> > proteinA_lsq1.pdb with extra empty lines (not the anisou lines ;o) )
> > 
> > 2) superpose proteinA_lsq1.pdb onto proteinC.pdb : doesnt work because 
> > proteinA_lsq1.pdb cannot be read
> > 
> > Any ideas?
> > Even if there is some compatibility issue between CCP4 and windows, I guess 
> > superpose should be able to read its own files, shouldnt it?
> > 
> > Thanks,
> > 
> > Matthias
> > 
> > 
> > On 9/26/2011 9:13 PM, Jacob Keller wrote:
> >> I vaguely recall notepad doing something wacky with files in certain
> >> cases...why don't you get the excellent text editor NoteTab Light
> >> [sic] (I use it all the time--free and works great), then take a look
> >> at your files and see whether MS notepad altered the files.
> >> 
> >> JPK
> >> 
> >> On Mon, Sep 26, 2011 at 2:42 PM, Matthias Zebisch
> >>   wrote:
> >>> Dear CCP4 users,
> >>> 
> >>> I am using the ccp4i version 6.2.0 under windows 7. I've come across a
> >>> problem with superpose.
> >>> The outputfile appears to have additional line feeds (see picture) which,
> >>> however are not seen in the windows notepad.
> >>> The structure can also be opened in coot and pymol. However, it is not
> >>> possible to use it within CCP4, eg. for a subsequent superposition.
> >>> 
> >>> Is this problem known to anybody and is there a simple workaround 
> >>> available?
> >>> I need to compare hell of a lot of relative domain orientations...
> >>> 
> >>> I did not have this problem on a second computer with ccp4 6.1.2. When I
> >>> updated to 6.2.0, the situation was as described above.
> >>> 
> >>> Any help will be highly appreciated,
> >>> 
> >>> Thanks, Matthias
> >>> 
> >> 
> >> 
  

Re: [ccp4bb] should the final model be refined against full datset

[Robbie Joosten]

Hi Ed,
 

> This is a follow up (or a digression) to James comparing test set to
> missing reflections. I also heard this issue mentioned before but was
> always too lazy to actually pursue it.
> 
> So.
> 
> The role of the test set is to prevent overfitting. Let's say I have
> the final model and I monitored the Rfree every step of the way and can
> conclude that there is no overfitting. Should I do the final refinement
> against complete dataset?
> 
> IMCO, I absolutely should. The test set reflections contain
> information, and the "final" model is actually biased towards the
> working set. Refining using all the data can only improve the accuracy
> of the model, if only slightly.
Hmm, if your R-free set is small the added value will also be small. If it is 
relatively big, then your previously established optimal weights may no longer 
be optimal. A more elegant thing to would be refine the model with, say, 20 
different 5% R-free sets, deposit the ensemble and report the average R(-free) 
plus a standard deviation. AFAIK, this is what the R-free set numbers that 
CCP4's FREERFLAG generates are for. Of course, in that case you should do 
enough refinement (and perhaps rebuilding) to make sure each R-free set is 
free. 

> The second question is practical. Let's say I want to deposit the
> results of the refinement against the full dataset as my final model.
> Should I not report the Rfree and instead insert a remark explaining the
> situation? If I report the Rfree prior to the test set removal, it is
> certain that every validation tool will report a mismatch. It does not
> seem that the PDB has a mechanism to deal with this.
The deposited R-free sets in the PDB are quite frequently 'unfree' or the wrong 
set was deposited (checking this is one of the recommendations in the VTF 
report in Structure). So at the moment you would probably get away with 
depositing an unfree R-free set ;)
 
Cheers,
Robbie
 
 
> 
> Cheers,
> 
> Ed.
> 
> 
> 
> -- 
> Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
> Julian, King of Lemurs
  

Re: [ccp4bb] refmac 5.6 ccp4 6.2.0

[Robbie Joosten]

Hi Kenneth,

This looks like an off-by-one bug in the restraint generation. Typical sources 
are weird LINKs, wrong atom names and bad luck. I suggest you make sure you 
have the very latest Refmac and dictionary and try setting up a new refinement 
instead of recycling an old job. If that doesn't work, we may need a closer 
look at your input model.

Cheers,
Robbie

> Date: Thu, 27 Oct 2011 20:48:49 -0500
> From: satys...@wisc.edu
> Subject: [ccp4bb] refmac 5.6 ccp4 6.2.0
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Has anyone had problems with Refmac 5.6? I tried refining our stucture at 
> 1.24 A,
> aniso with H in riding position and it just exploded! I get error in 
> distances such as
> 
> Standard  External   All
> Bonds:  3270 0  3270
>Angles:  4923 0  4923
>   Chirals:   214 0   214
>Planes:   368 0   368
>  Torsions:   957 0   957
> ---
> 
>  Number of reflections in file  90428
>  Number of reflections read  90428
> 
> 
>  CGMAT cycle number =  1
> 
>  Bond distance outliers   
>   
> 
> Bond distance deviations from the ideal >10.000Sigma will be monitored
> 
> A  5 PRO C   A - A  5 PRO HB1 A mod.= 3.344 id.= 1.329 dev= -2.015 
> sig.= 0.014
> A  5 PRO C   B - A  5 PRO HB1 B mod.= 2.997 id.= 1.329 dev= -1.668 
> sig.= 0.014
> A  5 PRO HB1 A - A  5 PRO HG1 A mod.= 2.292 id.= 1.458 dev= -0.834 
> sig.= 0.021
> A  5 PRO HB1 A - A  6 LEU HD23A mod.= 7.407 id.= 0.860 dev= -6.547 
> sig.= 0.020
> A  5 PRO HB1 B - A  5 PRO HG1 B mod.= 2.247 id.= 1.458 dev= -0.789 
> sig.= 0.021
> A  5 PRO HB1 B - A  6 LEU HD23B mod.= 6.529 id.= 0.860 dev= -5.669 
> sig.= 0.020
> A  5 PRO HG1 A - A  5 PRO HD1 A mod.= 2.267 id.= 0.980 dev= -1.287 
> sig.= 0.020
> A  5 PRO HG1 A - A  6 LEU N   A mod.= 4.860 id.= 1.530 dev= -3.330 
> sig.= 0.020
> A  5 PRO HG1 A - A  6 LEU HD21A mod.= 6.129 id.= 1.525 dev= -4.604 
> sig.= 0.021
> A  5 PRO HG1 B - A  5 PRO HD1 B mod.= 2.236 id.= 0.980 dev= -1.256 
> sig.= 0.020
> A  5 PRO HG1 B - A  6 LEU N   B mod.= 4.922 id.= 1.530 dev= -3.392 
> sig.= 0.020
> A  5 PRO HG1 B - A  6 LEU HD21B mod.= 6.664 id.= 1.525 dev= -5.139 
> sig.= 0.021
> A  6 LEU N   A - A  6 LEU CA  A mod.= 1.467 id.= 0.970 dev= -0.497 
> sig.= 0.020
> A  6 LEU N   A - A  6 LEU HA  A mod.= 2.005 id.= 0.970 dev= -1.035 
> sig.= 0.020
> A  6 LEU N   A - A  6 LEU CB  A mod.= 2.497 id.= 1.530 dev= -0.967 
> sig.= 0.020
> A  6 LEU N   B - A  6 LEU CA  B mod.= 1.469 id.= 0.970 dev= -0.499 
> sig.= 0.020
> A  6 LEU N   B - A  6 LEU HA  B mod.= 2.032 id.= 0.970 dev= -1.062 
> sig.= 0.020
> A  6 LEU N   B - A  6 LEU CB  B mod.= 2.446 id.= 1.530 dev= -0.916 
> sig.= 0.020
> A  6 LEU CB  A - A  6 LEU HB2 A mod.= 0.969 id.= 1.521 dev=  0.552 
> sig.= 0.020
> A
> 
> Rfree goes form 17 to 28 and R from 15 to 25.
> Coot map looks like a bunch of busted insect parts.
> 
> 
> I use the exact same input using ccp4 6.1.13 and Refmac 5.5 and all is good. 
> I am forced to use the
> old ccp4 and refmac to publish. Rf 17 R 15. 
> thanks
> 
> --
> Kenneth A. Satyshur, M.S.,Ph.D.
> Associate Scientist
> University of Wisconsin
> Madison, Wisconsin 53706
> 608-215-5207
  

Re: [ccp4bb] raw data deposition

[Robbie Joosten]

Hi Francis,

Even though they are not published, there are enough models in the PDB for
which reevaluation of the crystallographic data leads to new biological
insight. Unfortunately, a lot of the insight is of the type "that ligand
doesn't really bind, or at least not in that pose". Another nice one is a
sequencing error in a Uniprot entry that became obvious after critically
looking at the structure and the maps (the authors, of both structure and
sequence, acknowledge the problem, but the entry is not yet fixed, so no
names). Yesterday, I had a case where I didn't so much mistrust the model,
but I would still have liked to have access to the images. There was
something weird in the maps that was also clearly there in pictures of the
maps in the linked publication, but it was not discussed.

Needless to say, I'm in favour of depositing images. At least for published
structure models. There is still a lot of interesting things to find in
current and future PDB entries.

Cheers,
Robbie


> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> James Stroud
> Sent: Friday, October 28, 2011 07:57
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] raw data deposition
> 
> On Oct 27, 2011, at 5:22 PM, Francis E Reyes wrote:
> > So I ask again, are there literature examples where reevaluation of the
> crystallographic data has directly resulted in new biological insights
into the
> system being modeled?
> 
> This is a poor criterion on which to base any conclusions or decisions. We
can
> blame the lack of examples on unavailability of the data.
> 
> Right now, I'd love to get my hands on the raw images for a particular
cryoEM
> data set, but they are not available--only the maps. But the maps assume
> one symmetry and I have a hypothesis that the true symmetry is different.
I
> could test my hypothesis by reprocessing the data were it available.
> 
> James

Re: [ccp4bb] weight matrix and R-FreeR gap optimization

[Robbie Joosten]

Hi James,

 

That is not exactly a lot of info to decide the best weight. The optimal
weight is (very loosely) resolution dependent. At normal resolutions the
optimal matrix weight is usually well below 1.0. Start at 0.3 and try a few
weights to see what works best for your data. To close the R-free gap you
can also try to optimize other refinement parameters such as NCS restraints,
B-factor model (and restraint weight). Jelly body restraints sometimes work
really well to keep the R-free gap sensible, especially at low resolution.

 

Cheers,

Robbie

 

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
james09 pruza
Sent: Tuesday, November 08, 2011 06:40
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] weight matrix and R-FreeR gap optimization

 


Dear ccp4bbers,

 

I wonder if someone can help me defining proper weight matrix term in
Refmac5 to lower the R-FreeR gap. The log file indicates weight matrix of
1.98 with a gap of 7. Thanks for suggestions in advance.

James

 

Re: [ccp4bb] FreeR in the case of few reflections

[Robbie Joosten]

Hi Aaron,

 

You don't explain why you have so few reflections. Is it a small cell, low
resolution or just really bad data?

 

Assuming it's not the last one and your data is reasonably complete, I would
try this:

-  Divide your reflections into six groups (and check that these
groups are really of equal size).

-  Refine with one set excluded and optimize your refinement
protocol. Do a lot of cycles of refinement to ensure that the refinement
converges.

-  Generate maps using all reflections (i.e. do not exclude the set
you excluded in refinement). If you leave out 17% of your reflection you
either get poor maps due to missing Fourier terms or your maps will be very
biased towards your model.

-  Once you are content with your model. Do six refinements with
different sets excluded like Pavel said. You can reset the B-factor if you
worry about model bias. Use even more cycles of refinement than before to be
sure your refinements converge.

-  Report ALL the R-free values in your publication and describe the
methods really well.

-  Deposit the model with the R-free closest to the mean. 

 

HTH,

Robbie

 

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Pavel
Afonine
Sent: Friday, November 18, 2011 17:25
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] FreeR in the case of few reflections

 

Hi Aaron,

here is what I would do:

- create 10-20 independent test sets containing 5% of reflections (make sure
lattice symmetry is taken into account - Phenix does it by default);
- solve and refine structure for each of the data set (make sure you use
such a refinement strategy so you don't get very poor Rfree-Rwork gap (like
you have right now: 28/40).

See how final models, maps and R-factors are different. That will give you
an idea about reliability of the results you get and starting point for
further thoughts.
Of course this is not the only way to tackle this problem, but a
possibility.

Pavel



On Fri, Nov 18, 2011 at 6:36 AM, Aaron Alt  wrote:

Hi all,

I have data indexed in I23 with ~3000 unique reflections. Having set
aside 10% of these my refinements still go berserk. The maps do look
fine though. The same happens when reindexed in lower symmetries.
Phenix autobuild finishes for example with 28/40 and I get similiar
results (although it took me longer) tracing manually and refining
with refmac. Does it make sense to set aside 500 reflections in my
case, which would be ~17% of the data? What is the correct way to
deal with data of this type? Ignoring the Rfree completely?
A nice weekend to all,
Aaron

 

Re: [ccp4bb] How to distinguish between Na+ and Mg2+?

[Robbie Joosten]

Hi Florian,

There are quite a few tools that do this check for you. To name a few: WASP
(old but good, build the ion as water), WHAT_CHECK
(http://swift.cmbi.ru.nl/servers/html/index.html), Check My Metal and
probably quite a few others. All of them use the bond valence sum, but they
all have a different implementation so the results may differ. That said, it
is usually reasonably easy to tell Na+ and Mg2+ apart. 
At the risk of stating the obvious: think of what you added in the
crystallization, buffer counter ions are easily overlooked.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Florian Sauer
> Sent: Thursday, December 01, 2011 19:40
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] How to distinguish between Na+ and Mg2+?
> 
> Dear CCP4BBers,
> 
> I'm refining the structure of a Ca-binding protein with several EF-hands
> against 2.2A data.
> There is clear density for an ion in several EF-hands coordinated by
Asp/Glu,
> Ser, one backbone O and one water (coordination number 5 and 6). Ca2+ can
> be excluded as there are no anomalous difference peaks at these sites when
> I calculate a map from data collected at 2A wavelength.
> I suppose that either Na+ or Mg2+ are bound.
> I'd like to ask whether there is a clear way to distinguish between both
ions in
> a model from data at this resolution.
> 
> Thank you in advance for your suggestions,
> 
> Florian
> 
> P.S. The distances between ion and protein are:
> 
> Asp/Glu carboxyl O: 2.04-2.75A
> Ser OH: 1.98-2.6A
> Backbone O: 2.4-2.65A

Re: [ccp4bb] How to assess geometry in a model?

[Robbie Joosten]

Hi Matt,

WHAT_CHECK writes out a file called check.db that contains per-residue scores 
for several quality metrics. It is fairly easy to parse.

Cheers,
Robbie  

Date: Thu, 8 Dec 2011 23:08:45 -0500
From: mattw...@gmail.com
Subject: [ccp4bb] How to assess geometry in a model?
To: CCP4BB@JISCMAIL.AC.UK

Hi Folks
I'm looking for a way to score each atom (or residue) in a model based on it's 
geometry.  I know these scores exists because various software packages speak 
of outliers, even including a sigma value in some cases.

So I'm looking for a simple way to get a complete list (not just outliers).  
Does anyone know of a package that can be made to output these scores?
Thanks, 

Matt
  

Re: [ccp4bb] chirality problem

[Robbie Joosten]

Hi Afshan,

Just swap the (names of) the CD and CG atoms, no need for refinement. The CCP4 
dictionary allows both chiralities for LEU and VAL, so Refmac won't detect the 
problem. The problem is still very real to many programs so it should be fixed.

Cheers,
Robbie Joosten

Date: Thu, 5 Jan 2012 02:46:30 -0800
From: afshan...@yahoo.com
Subject: [ccp4bb] chirality problem
To: CCP4BB@JISCMAIL.AC.UK

Dear Users,
I am facing difficulties to validate my structure according to PDB server. I 
have solved my structure and now want to submit in PDB but during validation 
process i have  some chirality problem specially   VAL and LEU amino acids 
there are total 18 amino acids which deviated from the chirality so how can i 
solve this problem.
Any suggestion would be highly appreciated.
 

Best Regards
AFSHAN

  

Re: [ccp4bb] chirality problem

[Robbie Joosten]

Hi Afshan,
 
I assumed, because you mentioned only VAL and LEU, that you were refering to 
the CB (VAL) and CG (LEU) as problematic chiral centers. Paul is right that 
these atoms are not chiral in a chemical sense, but they are in a computational 
sense because every connected atom has a unique name. The PDB is pretty strict 
in this sense (as it should be), but they could/should call it a nomenclature 
error. They could also just swap the atom names like I described and solve the 
problem for you. Anyway, please give a bit more details about your problem.
 
Computational chirality problem can be a serious problem for refinement: if the 
chirality is wrong due to swapped atom names, the chiral volume restraint will 
try to invert your chiral center. This can lead to malformed geometry, 
typically flattening of of the group. This means that a computational chirality 
problem can lead to a 'real' chirality problem. In Refmac, this will not happen 
for LEU or VAL, but it will happen for things like SO4, GOL, and a whole lot of 
other more interesting hetero compounds. 
 
@ Paul, I don't think it will be a CCP4 program that reported the problem. Does 
the 'fix nomenclature problems' option in Coot also do VAL and LEU?
 
Cheers,
Robbie




Date: Fri, 6 Jan 2012 10:44:58 +
From: paul.ems...@bioch.ox.ac.uk
Subject: Re: [ccp4bb] chirality problem
To: CCP4BB@JISCMAIL.AC.UK


Hi Afshan, 

This is not the solution if you are right about the problem being one of 
chirality (and it is if it is not and is merely an issue of nomenclature (as I 
suspect is the case)).  So the question is, if the problem is indeed one of 
nomenclature, what software (if any) described it as a chirality issue?  If it 
is one of ours we should fix that.

Paul


On 05/01/12 11:44, Robbie Joosten wrote: 



Hi Afshan,

Just swap the (names of) the CD and CG atoms, no need for refinement. The CCP4 
dictionary allows both chiralities for LEU and VAL, so Refmac won't detect the 
problem. The problem is still very real to many programs so it should be fixed.

Cheers,
Robbie Joosten



Date: Thu, 5 Jan 2012 02:46:30 -0800
From: afshan...@yahoo.com
Subject: [ccp4bb] chirality problem
To: CCP4BB@JISCMAIL.AC.UK



Dear Users,


I am facing difficulties to validate my structure according to PDB server. I 
have solved my structure and now want to submit in PDB but during validation 
process i have  some chirality problem specially   VAL and LEU amino acids 
there are total 18 amino acids which deviated from the chirality so how can i 
solve this problem.


Any suggestion would be highly appreciated.

 

Best Regards
AFSHAN


  

Re: [ccp4bb] chirality problem

[Robbie Joosten]

Hi Phil,

It is annoying problem especially for Phe and Tyr which have standard
rotamers close to the critical chi angles (-90 and +90). Asp and Glu do not
have standard rotamers near critical angles, so the problem should be much
smaller (but I still get them too often). If Val, Leu and Arg problems
reoccur after refinement, then there is something seriously wrong.

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Phil Evans
> Sent: Monday, January 09, 2012 12:54
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] chirality problem
> 
> The problem with fixing the nomenclature "problems" in Coot is that they
are
> back again after the next round of refinement (or at least some of them
are,
> if they are right on the edge of an arbitrary distinction) - indeed
irritating Phil
> 
> On 9 Jan 2012, at 11:43, Paul Emsley wrote:
> 
> > On 08/01/12 10:36, ccp4 wrote:
> >> Won't coot fix the nomenclature issue, then you can check whether you
> >> have a real chirality problem - eg a squashed flattened VAL..
> >>
> >
> > It will indeed [1].  So Afshan need only read in the file, Press OK and
then
> Save.
> >
> > Robbie and I think that it is more likely than not that Afshan did not
really
> have a chirality problem.
> >
> > Afshan and Kim have been in touch and confirm that it is the adit
validation
> report that describes a nomenclature error on a VAL CB as a chirality
problem
> (rather than anything from CCP4).
> >
> > Paul.
> >
> >
> > [1] well, modern ones do [2]
> > [2] and you can turn it off (some people find the feature annoying)

Re: [ccp4bb] reliable/unreliable maps?

[Robbie Joosten]

Hi Frank,

EDS already does that. Even so, reproducing the R-factor does not prove that
the map is reliable. See for instance 3frk for which the deposited dataset
is much smaller and less complete than the one used for refinement. The map
from EDS is therefore completely model biased. 
I only recently started looking for this problem of lower-than-reported
completeness with. I have not found a lot of cases, but already too many.
Fortunately, at least a few depositors deposited the rest of the dataset
after I sent a bug report to the PDB (e.g. 3mbs).

Cheers,
Robbie

> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Frank von Delft
> Sent: Tuesday, January 10, 2012 16:23
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] reliable/unreliable maps?
> 
> Or just print both Rfactors...?
> 
> 
> On 10/01/2012 15:21, Luca Pellegrini wrote:
> > Hi Paul,
> >
> >
> >> What would you rather it say, I'm happy to change the message. "The EDS
> does not think that this is a reliable map, in that it is or may be
inconsistent
> with what the authors were looking at during deposition"?
> > How about "Warning: the R-factor calculated for this map differs
> significantly from the published R-factor"?
> >
> > Then we can discuss what is significant ;-)
> >
> > Luca
> >
> > Luca Pellegrini
> > Department of Biochemistry
> > University of Cambridge
> > 80 Tennis Court Road
> > Cambridge CB2 1GA - UK
> >
> > Email: lp...@cam.ac.uk
> > Tel: 0044-1223-760469
> > Fax: 0044-1223-766002
> > Sanger building, room 3.59

Re: [ccp4bb] on Rwork and Rfree

[Robbie Joosten]

Hi Dialing,

 

Most water picking tools are rather overenthusiastic and end up placing some
waters at places where they should not be. This causes some overfitting and
an increase of R-free. I'm hideously old-fashioned and recommend
conservatively building waters by hand. 

There are some good validation tools that help get rid of excess water:
centrifuge in PDB_REDO does the basic work; "check/delete waters" in Coot
highlights other suspicious waters; WHAT_CHECK checks hydrogen bonding
thoroughly, finds nonsense clusters of water and also finds possible ions.
It must be noted that all these tools break down at very high resolution
where you may get alternate waters. Fortunately, this problem doesn't occur
very often.

 

Cheers,

Robbie

 

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
Dialing Pretty
Sent: Tuesday, February 07, 2012 09:31
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] on Rwork and Rfree

 

Dear All,

 

After we refine the structure of the protein to satisfactory with
satisfactory Rwork and Rfree, we pick water by phenix refine, and I find
Rfree always increases slightly after the water picking refinment. 

 

Do you have nay idea to solve this problem or any comment?

 

Cheers,

 

Dialing

 

 

 

Re: [ccp4bb] REFMAC Riding Hydrogens

[Robbie Joosten]

Hi Everyone, 

 

Pavel’s statement is likely a bit of an exaggeration, but he has a valid (yet 
hard to prove point). The default in CCP4i was (and is?) to use hydrogens only 
if present in the input file. This is IMO not a safe default. 

Because there were some reporting errors in the past 
(http://proteincrystallography.org/ccp4bb/message18808.html) it is hard to tell 
from the PDB when refinement with hydrogens became hip. Discussions on this BB 
show that at the use of riding hydrogens is still not fully accepted, 
especially at low resolution (where they actually help most). 

 

Cheers,

Robbie

 

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Pavel 
Afonine
Sent: Monday, March 05, 2012 21:53
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] REFMAC Riding Hydrogens

 

Dear Tim,

 

good catch, thanks; I could craft that phrase more carefully! Although often it 
may not be quite fair to take phrases out of context: this newsletter article 
was written in the context of macromolecular refinement. And yes, "recently" 
may be a broad term -:)

 

All the best,

Pavel

On Mon, Mar 5, 2012 at 12:45 PM, Tim Gruene  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Pavel,

you may want to add to the structures mentioned in [1] one or two
organic structures present in the Cambridge Database.

"Until recently it was customary to ignore hydrogen atoms throughout the
process of crystallographic X-­‐ray structure determination." [1]

'recently' as in 1997 [2]? Even though 1997 is probably a poor
estimation of the corresponding year...

Cheers,
Tim


[1] "On contribution of hydrogen atoms to X-ray scattering"
http://www.phenix-online.org/newsletter/
[2] http://shelx.uni-ac.gwdg.de/SHELX/shelx.pdf


On 03/05/2012 09:14 PM, Pavel Afonine wrote:
> Hi,
>
> On Mon, Mar 5, 2012 at 11:52 AM, Matthew Franklin wrote:
>
>> Adding the riding hydrogens generally gives you some improvement in R
>> factors even with a good quality (i.e. stereochemically correct) model.
>>
>
> and here are the results of more or less systematic test that prove this:
>
> see "On contribution of hydrogen atoms to X-ray scattering"
> here:
> http://www.phenix-online.org/newsletter/
>
> Pavel
>

- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPVSXkUxlJ7aRr7hoRAm1TAJ9Hyfhkl3yhD5QSKw9I4RSK58m0fACgmlxk
YGILzeMam/3gQVmCeh0vQ8k=
=3m2J
-END PGP SIGNATURE-

 

Re: [ccp4bb] very informative - Trends in Data Fabrication

[Robbie Joosten]

Dear CCP4BBers,

The PDB_REDO entry Bernhard referred to in his interesting and very thorough
article was automatically deleted because the original PDB entry was
obsoleted. Since access to the 'experimental' data of any study is
important, we have made a compressed copy of the PDB_REDO entry available at
http://www.cmbi.ru.nl/pdb_redo/others/3k78.tar.bz2 
Our apologies to those who have looked for this entry in vain.

Best wishes,
Robbie Joosten (on behalf of the PDB_REDO team)

Biochemistry
Netherlands Cancer Institute

P.S. The whole fraud thing seems to have interfered with the annual April
fools' post on CCP4BB. Let's hope this will not happen again. 





> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Michel Fodje
> Sent: Saturday, March 31, 2012 21:55
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] very informative - Trends in Data Fabrication
> 
> Very interesting
> 
> "Response to Detection and analysis of unusual features in the structural
> model and structure-factor data of a birch pollen allergen"
> doi:10.1107/S1744309112008433
> 
> a quote from the response:
> 
> "Author Schwarzenbacher admits to the allegations of data fabrication and
> deeply apologizes to the co-authors and the scientific community for all
the
> problems this has caused
> 
> .
> 
> Note added in proof: subsequent to the acceptance of this article for
> publication, author Schwarzenbacher withdrew his admission of the
> allegations.
> "
> 
> 
> 
> 
> 
> From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Bernhard Rupp (Hofkristallrat a.D.) [hofkristall...@gmail.com]
> Sent: Saturday, March 31, 2012 12:42 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] very informative - Trends in Data Fabrication
> 
> This is an unresolved problem, and no real satisfactory solution exists,
> because the underlying reasons for zero occupancy can be different.
> For people who understand this and look at electron density, it is not a
> problem. For users who rely on some graphics program displaying only atom
> coordinates, it can be. The same holds for manipulation of B-factors,
‘trading’
> high B-factors against reduced occupancy, and other (almost always purely
> cosmetic but still confusing or inconsistent) practices.
> 
> Best, BR
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> Nian Huang
> Sent: Saturday, March 31, 2012 11:29 AM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] very informative - Trends in Data Fabrication
> 
> I don't model zero occupancy in my model. But can't the refinement
> programs just treat those atoms with zero occupancy as missing atoms?
> 
> Nian Huang
> On Sat, Mar 31, 2012 at 10:26 AM, Bosch, Juergen
> mailto:jubo...@jhsph.edu>> wrote:
> really fascinating, bringing back the discussion for a repository for your
> collected frames.
> 
> Jürgen
> 
> 
> Acta Cryst. (2012). F68, 366-376
> doi:10.1107/S1744309112008421<http://dx.doi.org/10.1107/S17443091120084
> 21>
> 
> Detection and analysis of unusual features in the structural model and
> structure-factor data of a birch pollen allergen B.
> Rupp<http://scripts.iucr.org/cgi-
> bin/citedin?search_on=name&author_name=Rupp,%20B.>
> 
> Abstract: Physically improbable features in the model of the birch pollen
> structure Bet v 1d (PDB entry 3k78<http://pdb.pdb.bnl.gov/pdb-
> bin/opdbshort?3k78>) are faithfully reproduced in electron density
> generated with the deposited structure factors, but these structure
factors
> themselves exhibit properties that are characteristic of data calculated
from a
> simple model and are inconsistent with the data and error model obtained
> through experimental measurements. The refinement of the
> 3k78<http://pdb.pdb.bnl.gov/pdb-bin/opdbshort?3k78>model against these
> structure factors leads to an isomorphous structure different from the
> deposited model with an implausibly small R value (0.019). The abnormal
> refinement is compared with normal refinement of an isomorphous variant
> structure of Bet v 1l (PDB entry 1fm4<http://pdb.pdb.bnl.gov/pdb-
> bin/opdbshort?1fm4>). A variety of analytical tools, including the
application
> of Diederichs plots, R plots and bulk-solvent analysis are discussed as
> promising aids in validation. The examination of the Bet v 1d structure
also
> cautions against the practice of indicating poorly defined protein chain
> residues through zero occupancies. The recommendation to preserve
> diffraction images is amplified.
> ..
> Jürgen Bosch
> Johns Hopkins University
> Bloomberg School of Public Health
> Department of Biochemistry & Molecular Biology Johns Hopkins Malaria
> Research Institute
> 615 North Wolfe Street, W8708
> Baltimore, MD 21205
> Office: +1-410-614-4742
> Lab:  +1-410-614-4894
> Fax:  +1-410-955-2926
> http://web.mac.com/bosch_lab/

Re: [ccp4bb] Refmac and sigma value

[Robbie Joosten]

Hi Uma,
 
The optimal weight is indeed resolution dependent, but hard to predict. In 
Refmac you can follow LLfree when you optimize the restraint weight and also 
keep an eye on the gap between R and R-free (it should not be too wide). Like 
Rob said, your geometry should be 'reasonable'. This may be a bit vague, but 
there is no clear target for bond/angle rmsd at a given resolution (some 
referees will disagree). If you look at the rmsZ values Refmac gives, the 
target is a bit clearer: rmsZ < 1.000. The average rmsZ does go down with 
resolution (i.e. lower resolution gives lower rmsZ), but an ideal value cannot 
be given easily (or at all).
Tightening the restraints improves the effective data/parameter ratio of your 
model. You can also improve it by adding additional restrains (e.g. NCS 
restraints) or by removing parameters (e.g. changing the complexity of your 
B-factor model).  
Note that the absence of geometric outliers does not prove that your model is 
optimal. If you use too tight restraints you can end up hiding genuine fitting 
errors.
 
Cheers,
Robbie
 



Date: Fri, 27 Apr 2012 10:04:11 +0200
From: herman.schreu...@sanofi.com
Subject: Re: [ccp4bb] Refmac and sigma value
To: CCP4BB@JISCMAIL.AC.UK


It all will depend on the resolution. At low resolution, relaxing the geometric 
restraints will allow the refinement program to tweak the model such that the 
difference between Fobs and Fcalc is minimized, but not that the model gets 
closer to the "truth". I once struggled for a long time with a 3.5Åish data set 
with a protein where the most important feature was a rather flexible loop. It 
was before maximum likelyhood methods and Rfrees and the only way I could get 
rid of the model bias was to use extremely tight geometric restraints. The 
Rfactor would go up, but suddenly the electron density maps would no longer 
accept incorrectly placed side chains and new features, not present in the 
model, would appear. 
 
So my advice: at low resolution use as tight restraints as possible and monitor 
with Rfree if you are going in the right direction. At high or very high 
resolution, you can follow what your diffraction data tells you. In fact many 
very high resolution structures (< 1.5 Å) have higher rmsd's for bond lenghts 
and angles as medium resolution structures. However, at medium or low 
resolution there is not enough data to justify to relax the geometric 
restraints too much.
 
Best regards,
Herman




From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Robert 
Nicholls
Sent: Friday, April 27, 2012 9:25 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Refmac and sigma value



Hi Uma,


Altering sigma affects the strength of geometry restraints throughout the model 
- bonds, angles, etc. Choosing a very low sigma will cause geometry to be more 
tightly restrained towards "ideal" values, which is why you observe 
improvements in Coot validation.  Note that strengthening the geometry weight 
causes the observations (data) to be less influential in refinement. The "risk" 
of this is that your model may no longer appropriately/optimally describe your 
data. You can assess this locally by manual inspection of the electron density, 
and globally by considering overall refinement statistics (as reported at the 
bottom of the Refmac5 log file). Ideally, you want your model to both describe 
the data and have reasonable geometry.


Regards
Rob




On 26 Apr 2012, at 21:26, Uma Ratu wrote:

Hi, Alex:
 
> Which sigma do you mean?
 
The one for automatic weight, not for Jelly-body refinement.
 
I did not turn the "Jelly-body refinement" on.
 
Thanks
 
Ros


On Thu, Apr 26, 2012 at 4:08 PM, aaleshin  wrote:

Hi Uma,
Which sigma do you mean? The one for Jelly-body refinement?
J-B sigma=0.01 means very small fraction of the gradient will be used in each 
step. It is used usually with very low resolution (less then 3A)

Alex



On Apr 26, 2012, at 11:38 AM, Uma Ratu wrote:

>
> Dear All:
>
> I use Refmac5 to refine my structure model.
>
> When I set the sigma value to 0.3 (as recommended from tutorial), the 
> resulted model has many red-bars by coot validation (geometry, rotamer, 
> especially, Temp Facotr).
>
> I then lower the sigma value to 0.1, the resulted model is much improved by 
> coot validation.
>
> I then lower the sigma value to 0.01, the resulted model is almost perfect, 
> by coot validation and Molprobity.
>
> My question is: what is the risk for very low value sigma value?
>
> Thank you for your advice
>
> Ros




  

Re: [ccp4bb] Ligand geometry

[Robbie Joosten]

Hi Uma,

How different are your NADs optimised in Refmac and Coot? Are you sure you are 
using the same geometric restraints? Coot has to know where Refmac's restraint 
files are. This info is passed through an environment setting on your computer 
(I don't know the name by hart. Anyone?). Are you using Windows, Linux or OSX 
or something else?

You can try to find more details about geometric outliers by checking Refmac's 
log file. That way you may find which specific bond/angle is the problem.

Cheers,
Robbie

Date: Sat, 28 Apr 2012 11:47:58 -0400
From: rosiso2...@gmail.com
Subject: [ccp4bb] Ligand geometry
To: CCP4BB@JISCMAIL.AC.UK

Dear All:
 
I use Refmac5 to refine my model. After the run, I check the model quality by 
Coot. 
 
Here is the problem:
 
In Coot, the ligand - NAD, has bad geometry as indicated by a big red bar. 
While the geometry of NAD fit nicely with the electron density. 
 
If I use refine tools (i.e. regularize Zone or real space refine zone), the 
geometry of NAD turns to perfec with bond, angle and so on. But the ligand 
slightly turn away from the electron density map.

 
If I run Refmac5 again with this modified model, the NAD turns back, fit nice 
to electron density, but gives red bar in coot geometry. 
 
The Refinment Parameters in Refmac5 is set @ "use automatic weight" and "use 
experinmental sigmals to weight X-ray terms".
 
Thank you for advice and comments
 
Ros
  

Re: [ccp4bb] Ligand geometry

[Robbie Joosten]

Quasi on-topic rant:

I would advice against using the 'both' option for any well defined ligand. 
It's a hack to avoid thinking about which atom belongs where and it allows you 
to be inconsistent. This makes it difficult for others to use your model, 
because aligning atoms of ligands becomes needlesly complicated. To the eye an 
oxygen is an oxigen, to a computer O1 is different from O2.  Just stick to the 
definition given by the PDB (see Ligand Expo). It's there for a reason.

Cheers,
Robbie

> Date: Sun, 29 Apr 2012 11:14:01 +0200
> From: hraaijmak...@xs4all.nl
> Subject: Re: [ccp4bb] Ligand geometry
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Hmm, what are the perfect bonds, angles for NAD in your protein? remember
> that reactive groups can be in a "stressed" conformation, compared to
> ideal in vacuo conformations. As part of their functon.
> anyway, you'll have to check the restraints definition file (.cif). Bond
> lengths and angles are usually ok, but make sure only chiral atoms are
> defined as chiral, others need to be deleted or defined as "both".
> Check that the torsion angles make chemical sense, especially the
> "repetition factor" for rotatable bonds.  Rotatable bonds next to aromatic
> rings are often problematic. You might need to set high sigmas, and
> "repetition" factors (x/360 degrees). On the other hand, you say that
> refmac behaves well, so the weighting scheme can't be far off.
> 
> Cheers,
> Hans.
> 
> And
> Uma Ratu schreef:
> > Dear All:
> >
> > I use Refmac5 to refine my model. After the run, I check the model quality
> > by Coot.
> >
> > Here is the problem:
> >
> > In Coot, the ligand - NAD, has bad geometry as indicated by a big red bar.
> > While the geometry of NAD fit nicely with the electron density.
> >
> > If I use refine tools (i.e. regularize Zone or real space refine zone),
> > the
> > geometry of NAD turns to perfec with bond, angle and so on. But the ligand
> > slightly turn away from the electron density map.
> >
> > If I run Refmac5 again with this modified model, the NAD turns back, fit
> > nice to electron density, but gives red bar in coot geometry.
> >
> > The Refinment Parameters in Refmac5 is set @ "use automatic weight" and
> > "use experinmental sigmals to weight X-ray terms".
> >
> > Thank you for advice and comments
> >
> > Ros
> >
  

Re: [ccp4bb] correlations of B-factors and resolution

[Robbie Joosten]

Hi Tim,

With small test sets, R-free doesn't become meaningless you just have to take 
into account that R-free has an error margin which is higher than for cases 
with a large test set. 
Few people report this error margin, but with a small data set you can easily 
do K-fold cross validation. I.e. do K refinements with K = 1/(test set 
fraction) and report R and R-free as averages with a standard deviation 
(instead of what we call cross validation, but is actually holdout validation). 
The CCP4 program freerflag already splits your data set in K groups to make it 
easier for the user. 
I do this automatically in PDB_REDO if the test set contains fewer than 500 
reflections. It's amazing how much R-free is influenced by the choice of ones 
test set.

Cheers,
Robbie

> Date: Wed, 16 May 2012 16:06:24 +0200
> From: t...@shelx.uni-ac.gwdg.de
> Subject: Re: [ccp4bb] correlations of B-factors and resolution
> To: CCP4BB@JISCMAIL.AC.UK
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear Qiang,
> 
> without much explanation, rather from experience, the average B-factor
> rises as resolution drops. It does make sense in a way because high
> B-factors indicate some degree of disorder and disorder is usually the
> cause for the resolution limit. 48A^2 for a 2.4A structure sound
> perfectly fine with me, I would not worry provided that all other
> statistices seem sound.
> 
> High solvent content surely affects the B-values. The larger the
> solvent channels and smaller the contact area between the molecules,
> the more likely they become less stable and less ordered.
> 
> R and Rfree seem also very good, although the gap is relatively tight.
> Did you make sure your Rfree set contains at least 500 reflections?
> The default of 5% often used, can lead to fewer reflections than 500
> at medium or low resolution, and with less than 500 reflection Rfree
> becomes statistically meaningless - at least according to Axel
> Brunger's article about that topic.
> 
> Cheers,
> Tim
> 
> On 05/16/12 15:46, Qiang Chen wrote:
> > Dear all,
> > 
> > I have a 2.4A structure(pdb code 3LAF)with an average protein
> > b-factor of 48. I wonder whether it's acceptable. Is there a direct
> > correlation of b-factor and resolution? The R and Rfree are 21.1%
> > and 23.1%, respectively. This structure has a very high solvent
> > content, 75%. Does it affect the b-factors?
> > 
> > Thanks a lot!
> > 
> > Qiang
> > 
> > 
> > The information in this e-mail is intended only for the person to
> > whom it is addressed. If you believe this e-mail was sent to you in
> > error and the e-mail contains patient information, please contact
> > the Partners Compliance HelpLine at 
> > http://www.partners.org/complianceline . If the e-mail was sent to
> > you in error but does not contain patient information, please
> > contact the sender and properly dispose of the e-mail.
> > 
> 
> - -- 
> - --
> 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/
> 
> iD8DBQFPs7RgUxlJ7aRr7hoRAnS8AJ472kwIWxf7rqDOhEPSBG5ipvQOWQCeNHNk
> bum4yGTB56Wtt0JbkixleCw=
> =uIfE
> -END PGP SIGNATURE-
  

Re: [ccp4bb] molecule on symmetry axis

[Robbie Joosten]

Hi Tim,

I'm all for automation and 'smart' software but it should not be a substitute 
for common sense. In the case of occupancies, not all software seems to be 
smart. There are about 1100 structures in the PDB that have problems with wrong 
occupancies at special positions and a good part of them seem to be fairly new 
(pdbids 3[a-n]??). 

I agree that Jackie should build the whole molecule to make sure all restraints 
kick in. It's only a little extra work to set the occupancy correctly for all 
atoms. In Coot one can do that with the 'residue info' option.

Cheers,
Robbie Joosten

> Date: Sat, 16 Oct 2010 10:25:47 +0200
> From: t...@shelx.uni-ac.gwdg.de
> Subject: Re: [ccp4bb] molecule on symmetry axis
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Hello Jackie Vitali,
> 
> What happens if you model the tartaric acid as if it were not on a symmetry 
> axis
> and then let phenix deal with the symmetry? I once had a water of which refmac
> stubbornly lowered the occupancy to 0.5 even though i kept on bringing it back
> to 1.0 until I realised that it was on a 2-fold axis. And this was seven years
> ago, so by now programs might be able to deal with more complicated molecules
> than just an oxygen.
> 
> As for the SO4, you should set the occupancy of S and O to 0.33 because you 
> only
> have one third per asymmetric unit. Now since the other oxygens belong to the
> same molecule, their occupancies should also be 0.33. But again, of you leave 
> it
> at 1 and feed it into phenix, that should be corrected for. If it's not, try
> refmac!
> 
> Cheers, Tim
> 
> On Fri, Oct 15, 2010 at 06:28:52PM -0400, Jacqueline Vitali wrote:
> > Dear colleagues,
> > 
> > I have a tartaric acid on a two fold axis with its two halves related
> > by the two fold.  How do I refine this in Phenix?
> > 
> > Also I have a SO4 on a 3 fold with S and one O on tthe 3 fold.  The
> > other 3 oxygens are related by the 3-fold.  How do I refine this in
> > phenix?  I can put S and one O occupancy 1, what occupancy do I put
> > for the 3 oxygens that overlap their symmetry mates?
> > 
> > And how do I maintain stereochemistry around the symmetry axis?  These
> > are not just one atom. For the tartaric acid the 2 fold goes through
> > the middle of the bond.  I could split it in two halves but I do not
> > see how to keep stereochemistry.
> > 
> > I would appreciate all suggestions.
> > 
> > I apologize because the question should go to another newsgroup but I am
> > still working with my subscription in phenixbb.
> > 
> > Jackie Vitali
> 
> -- 
> --
> Tim Gruene
> Institut fuer anorganische Chemie
> Tammannstr. 4
> D-37077 Goettingen
> 
> phone: +49 (0)551 39 22149
> 
> GPG Key ID = A46BEE1A
> 
  

[ccp4bb] Rules of thumb (was diverging Rcryst and Rfree)

[Robbie Joosten]

Dear Anthony,

That is an excellent question! I believe there are quite a lot of 'rules of 
thumb' going around. Some of them seem to lead to very dogmatic thinking and 
have caused (refereeing) trouble for good structures and lack of trouble for 
bad structures. A lot of them were discussed at the CCP4BB so it may be nice to 
try to list them all.
 
 
Rule 1: If Rwork < 20%, you are done.
Rule 2: If R-free - Rwork > 5%, your structure is wrong.
Rule 3: At resolution X, the bond length rmsd should be < than Y (What is the 
rmsd thing people keep talking about?)
Rule 4: If your resolution is lower than X, you should not 
use_anisotropic_Bs/riding_hydrogens
Rule 5: You should not build waters/alternates at resolutions lower than X
Rule 6: You should do the final refinement with ALL reflections
Rule 7: No one cares about getting the carbohydrates right  
 
 
Obviously, this list is not complete. I may also have overstated some of the 
rules to get the discussion going. Any addidtions are welcome.
 
Cheers,
Robbie Joosten
Netherlands Cancer Institute
 
> Apologies if I have missed a recent relevant thread, but are lists of
> rules of thumb for model building and refinement?
>
>
>
>
>
> Anthony
>
>
>
> Anthony Duff Telephone: 02 9717 3493 Mob: 043 189 1076
>
>
> 

Re: [ccp4bb] Against Method (R)

[Robbie Joosten]

Hi Bart,

I agree with the building strategy you propose, but at some point it stops 
helping and a bit more attention to detail is needed. Reciprocal space 
refinement doesn't seem to do the fine details. It always surprises me how much 
atoms still move when you real-space refine a refined model, especially the 
waters. I admit this is not a fair comparison.

High resolution data helps, but better data makes it tempting to put too little 
effort in optimising the model. I've seen some horribly obvious errors in 
hi-res models (more than 10 sigma difference density peaks for misplaced side 
chains). At the same time there are quite a lot of low-res models that are 
exceptionally good. 

Cheers,
Robbie

> Date: Thu, 28 Oct 2010 16:32:04 -0600
> From: bart.ha...@ualberta.ca
> Subject: Re: [ccp4bb] Against Method (R)
> To: CCP4BB@JISCMAIL.AC.UK
> 
> On 10-10-28 04:09 PM, Ethan Merritt wrote:
> > This I can answer based on experience.  One can take the coordinates from a 
> > structure
> > refined at near atomic resolution (~1.0A), including multiple conformations,
> > partial occupancy waters, etc, and use it to calculate R factors against a 
> > lower
> > resolution (say 2.5A) data set collected from an isomorphous crystal.  The
> > R factors from this total-rigid-body replacement will be better than 
> > anything you
> > could get from refinement against the lower resolution data.  In fact, 
> > refinement
> > from this starting point will just make the R factors worse.
> >
> > What this tells us is that the crystallographic residuals can recognize a
> > better model when they see one. But our refinement programs are not good
> > enough to produce such a better model in the first place. Worsr, they are 
> > not
> > even good enough to avoid degrading the model.
> >
> > That's essentially the same thing Bart said, perhaps a little more 
> > pessimistic :-)
> >
> > cheers,
> >
> > Ethan
> >
> 
> Not pessimistic at all, just realistic and perhaps even optimistic for 
> methods developers as apparently there is still quite a bit of progress 
> that can be made by improving the "search strategy" during refinement.
> 
> During manual refinement I normally tell students not to bother about 
> translating/rotating/torsioning atoms by just a tiny bit to make it fit 
> better. Likewise there is no point in moving atoms a little bit to 
> correct a distorted bond or bond length. If it needed to move that 
> little bit the refinement program would have done it for you. Look for 
> discreet errors in the problematic residue or its neighbors: peptide 
> flips, 120 degree changes in side chain dihedrals, etc. If you can find 
> and fix one of those errors a lot of the stereochemical distortions and 
> non-ideal fit to density surrounding that residue will suddenly 
> disappear as well.
> 
> The benefit of high resolution is that it is much easier to pick up and 
> fix such errors (or not make them in the first place)
> 
> Bart
> 
> -- 
> 
> 
> 
> Bart Hazes (Associate Professor)
> Dept. of Medical Microbiology&  Immunology
> University of Alberta
> 1-15 Medical Sciences Building
> Edmonton, Alberta
> Canada, T6G 2H7
> phone:  1-780-492-0042
> fax:1-780-492-7521
> 
> 
  

Re: [ccp4bb] Bug in c_truncate?

[Robbie Joosten]

Hi Phil,

I do, but the freeR flag problem is easily circumvented. One can just use cad 
with the output mtz from ctruncate and the input mtz:

cad \
HKLIN2 $WORKDIR/raw.mtz \
HKLIN1 $WORKDIR/ctruncate.mtz \
HKLOUT $WORKDIR/ctruncate_withRfree.mtz \
<>$WORKDIR/mtz_creation.log
  LABIN FILE 2  E1=FREE
  LABIN FILE 1  ALLIN
  END
eof

Cheers,
Robbie




> Date: Fri, 29 Oct 2010 13:05:40 +0100
> From: p...@mrc-lmb.cam.ac.uk
> Subject: Re: [ccp4bb] Bug in c_truncate?
> To: CCP4BB@JISCMAIL.AC.UK
>
> The normal use of [c]truncate is to take intensities from Scala, so it 
> wouldn't expect FreeR flags in the file.
>
> I suppose this should be added for other uses of the program
>
> Is this something that is often used? Do people import intensities into CCP4 
> to convert them to Fs?
>
> Phil
>
>
> On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote:
>
> > Dear Peter,
> >
> > Since I did not hear that your problem is solved here my two cents. I
> > did some tests using the ccp4i option "Convert Intensities to SFs" and
> > found that here ctruncate completely ignored the FreeRflags. So my
> > conclusion is that ctruncate does not need FreeRflags and you can use
> > the following procedure:
> >
> > 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz
> > without any special SHELX options. --> mtz 1
> > Careful: a FreeRflag of 1 means an unfree reflection and the free
> > reflections have a FreeRflag of zero.
> > 2) run ctruncate with the "Convert Intensities to SFs". You will loose
> > your FreeRflags in this stage. --> mtz 2
> > 3) add the FreeRflags from mtz 1 to mtz 2 using cad.
> >
> > If you wish, I can give you a command file which will do this. It is a
> > somewhat roundabout procedure and I hope that this bug (or feature) will
> > be fixed by the next release of ccp4.
> >
> > Best,
> > Herman
> >
> > -Original Message-
> > From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
> > George M. Sheldrick
> > Sent: Friday, October 29, 2010 12:30 PM
> > To: CCP4BB@JISCMAIL.AC.UK
> > Subject: Re: [ccp4bb] Bug in c_truncate?
> >
> > Tim,
> >
> > Although I always like to advocate XPREP, that would not work because
> > the .sca format - most unfortunately - does not know about free R flags.
> >
> > George
> >
> > Prof. George M. Sheldrick FRS
> > Dept. Structural Chemistry,
> > University of Goettingen,
> > Tammannstr. 4,
> > D37077 Goettingen, Germany
> > Tel. +49-551-39-3021 or -3068
> > Fax. +49-551-39-22582
> >
> >
> > On Fri, 29 Oct 2010, Tim Gruene wrote:
> >
> >> Hello Peter,
> >>
> >> the easiest way to overcome the problem might be to use xprep to
> >> export to sca-format and use scalepack2mtz for the conversion. That
> >> seems to be the least hasslesome way, although I am not totally sure
> >> that this procedure preserves the R-free flags set by xprep.
> >>
> >> Tim
> >>
> >> On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote:
> >>>
> >>> Hello Tim,
> >>>
> >>> Thank you for the suggestion. I have now tagged the working set as
> > "1" and test set as "0". Unfortunately, it still gives the same error
> > about all Rfree being the same, and only in c-truncate but not
> > old-truncate. Perhaps I should install 6.1.3 and see if the problem
> > still persist.
> >>>
> >>> Best,
> >>> Peter
> >>>
>  Date: Thu, 28 Oct 2010 16:29:31 +0200
>  From: t...@shelx.uni-ac.gwdg.de
>  Subject: Re: [ccp4bb] Bug in c_truncate?
>  To: CCP4BB@JISCMAIL.AC.UK
> 
>  Hello Peter,
> 
>  I faintly rememeber a similar kind of problem, and think that if
>  you replace "-1" with "0", the problem should go away. It seemed
>  that "-1" is not an allowed flag for (some) ccp4 programs.
> 
>  Please let us know if this resolves the issue.
> 
>  Tim
> 
>  On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote:
> >
> >
> >
> >
> > Dear Crystallographers,
> >
> > Thank you all for the emails. Below are some details of the
> > procedures I performed leading up to the problem.
> >
> > The reflection file is my own data, processed in XDS and then
> > flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i
> > version 6.1.2. I tried looking for known/resolved issues/updates in
> > version 6.1.3 but could not find any so I assumed it is the same version
> > of f2mtz/ctruncate/uniqueify.
> >
> >
> > I used the GUI version of F2MTZ, with the settings below:
> >
> > - import file in SHELX format
> >
> > - "keep existing FreeR flags"
> >
> > - fortran format (3F4.0,2F8.3,F4.0)
> >
> > - added data label "I other integer" // FreeRflag
> >
> > The hkl file, in SHELX format, output by XPREP look something
> > like this:
> >
> > -26 -3 1 777.48 39.19
> > 26 -3 -1 800.83 36.31
> > -26 3 -1 782.67 37.97
> > 27 -3 1 45.722 25.711 -1
> > -27 3 1 -14.20 3

Re: [ccp4bb] How to add methyl group on the NZ atom of lysine

[Robbie Joosten]

Hi Peter,
 
Iff you are sure you are dealing with methyl-lysine, you can get it into your 
structure by using "Get monomer" to get the compound MLZ. Position it correctly 
and then merge it into the structure. 
I prefer using a text editor to do this. Make sure you put the ATOM records at 
the right position in the file (otherwise real-space refinement won't work). 
You probably also need to make LINK records, which you can copy from an 
existing PDB file (1xer has the links you need).
 
Helix-Turn-Helix,
Robbie Joosten


> Date: Thu, 4 Nov 2010 09:04:53 -0400
> From: yoge...@scripps.edu
> Subject: Re: [ccp4bb] How to add methyl group on the NZ atom of lysine
> To: CCP4BB@JISCMAIL.AC.UK
>
>
> Dear All and Peter,
>
> In one of my structure, I find similar positive density though my
> protein was not methylated.
>
> Are there are any other reasons for appearance of such positive density
> next to Lysine.
>
> Thanking you
>
> Yogi
>
>
>
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
> peter66 wright
> Sent: Thursday, November 04, 2010 7:26 AM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] How to add methyl group on the NZ atom of lysine
>
>
>
> Dear All,
>
> Could anyone please tell me how to add methyl group in COOT on the NZ
> atom of lysine that has been methylated before crystallisation? The
> density map is attached to this mail from which you can clearly see the
> methyl group should be there, but I do not know how to add.
> Many thanks for help.
>
> Peter   

[ccp4bb] Protein structures and/or X-ray crystallography in TV shows

[Robbie Joosten]

Hi Everyone,
 
I'm looking for examples of protein structures/X-ray crystallography being used 
in fictional TV shows. So far, I've only managed to find a CSI episode in which 
they show a 3D structure and an X-files episode in which a primary structure 
was shown (litteraly just a chemical diagram of a tripeptide with 'R1', 'R2' 
and 'R3' at the side chain positions). Do any of you know nicer examples 
(preferably with episode title/number)?
 
Best wishes,
Robbie Joosten

Re: [ccp4bb] REFMAC 5.2.0019 question

[Robbie Joosten]

Dear Hailiang,
 
I regularly separate TLS refinement from restraint refinement to spead things 
up when I try to optimise the restraint weights. Using Refmac 5.6, I do the 
following:
- Do TLS Refinement in refmac
- Use TLSanl to change the total B-factors to residual B-factors.
- Load the output TLS file from the first Refmac run as static TLS tensors and 
do restrained refinement. Use ISOtropic B-factors!
 
See if this works for you. Keep in mind that there still may be small 
differences in (free) R-factor.
 
Cheers,
Robbie
 
 
> Date: Mon, 20 Dec 2010 14:44:34 +
> From: ianj...@gmail.com
> Subject: Re: [ccp4bb] REFMAC 5.2.0019 question
> To: CCP4BB@JISCMAIL.AC.UK
> 
> PS one other thought: in your run 2b you are not reading in (as TLSIN)
> the TLSOUT file produced by run 2a. So run 2b is not starting from
> the same point that it would have done as in run 1.
> 
> I.
> 
> On Sun, Dec 19, 2010 at 11:58 PM, Hailiang Zhang  wrote:
> > Hi,
> >
> > I am using REFMAC 5.2.0019 to run the following script:
> > ***
> > refmac5 hklin a xyzin b < > REFI TLSC ${CTLS}
> > REFI BREF OVERall
> > NCYC ${CC}
> > **
> >
> > I thought this script will do CTLS cycles of TLS refinement followed by CC
> > cycles of verall B and geometry refinement. Then I did the following 2
> > tests:
> > 
> > (1). CTLS=a, CC=b
> > (2). CTLS=a, CC=0; followed by: CTLS=0, CC=b
> > ***
> > The results are just very different from (1) and (2), and I am not sure why.
> >
> > By the way, my system has a small region with identical ADPs. After doing
> > (2), the ADPs at this region becomes different; however, after doing (1),
> > these ADPs are still identical, although different from the original ADPs.
> >
> > Thanks for any clarifications!
> >
> > Best Regards, Hailiang
> >
  

Re: [ccp4bb] Mg2+ or water

[Robbie Joosten]

Dear jlliu liu,
 
Also note that Mg2+ is significantly smaller than water. It fits in places 
where water cannot go. This doesn't look like a magnesium site on first glance. 
If you can (privately) give the PDBid of the previous publication, I can have a 
look in 3D.
 
Cheers,
Robbie
 
> Date: Mon, 20 Dec 2010 21:31:58 +
> From: p...@mrc-lmb.cam.ac.uk
> Subject: Re: [ccp4bb] Mg2+ or water
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Mg2+ is (almost) aways octahedrally coordinated, usually by oxygen atoms, 
> with distances of ~2A. 
> Phil
> 
> On 20 Dec 2010, at 21:16, jlliu liu wrote:
> 
> > Hi All,
> > 
> > I am refining a structure and encountered a problem of modeling a 
> > difference density as water or Mg2+, and would like to hear opinions from 
> > the community. It has the following coordinations (attached): the 
> > water/Mg2+ forms salt bridge/H-bonding interaction with a carboxylate group 
> > from the ligand, it also forms salt bridge/H-bonding interaction with a Glu 
> > residue from the protein, it is also within hydrogen bonding distance to 
> > the main chain N of another protein residue. In provious publication, it 
> > was modelled as a Mg2+ and the author reasoned the dual salt-bridge 
> > stabilizes the liganding binding, also the Mg2+ is present in the protein 
> > solution for crystallization. For my case, I have no Mg2+ present in the 
> > protein buffer, also modelling it with water refines perfectly with no 
> > indication of positive difference density even at 2.0 sigma cut off. Should 
> > I modelled this density as water or as Mg2+. Your opinions are appreciated.
> > 
> > JL
> > 
> > 
> > 
  

Re: [ccp4bb] Mg2+ or water

[Robbie Joosten]

You could also try the original WASP here (also for coloured Indo-dutch 
catholics): http://xray.bmc.uu.se/cgi-bin/gerard/rama_server.pl or you can use 
the latest WHAT_CHECK that also has an implementation of Nayal and Di Cera's 
algorithm.
 
Cheers,
Robbie
 
> Date: Mon, 20 Dec 2010 22:59:53 +
> From: paul.ems...@bioch.ox.ac.uk
> Subject: Re: [ccp4bb] Mg2+ or water
> To: CCP4BB@JISCMAIL.AC.UK
> 
> On 20/12/10 21:48, Robbie Joosten wrote:
> >
> >
> > Also note that Mg2+ is significantly smaller than water. It fits in 
> > places where water cannot go. This doesn't look like a magnesium site 
> > on first glance.
> 
> I tend to agree with Robbie. I wonder what WASP would say... (if you 
> use Coot, you can try the "Highly Coordinated Waters" validation test - 
> a symmetry-enhanced implementation of the Nayal & Di Cera (1996) algorithm).
> 
> Paul.
  

Re: [ccp4bb] deposited SF (or not)?

[Robbie Joosten]

Hi Bernhard,

1) I'm sure the PDB has this sorted out now. Perhaps someone atone of the sites 
can give some details.
2) Backfilling all 10k missing reflection files will be nearly impossible,  but 
the subset of 'promised' reflection files should be recovered. I guess the 
first step is getting a list of IDs. That would involve some serious text 
mining. The next step is getting in touch with the depositors (and hoping they 
are still alive). If that fails, a public posting of all the depositors who 
didn't stick to previous promises may be a more drastic option.

Ideally, depositors who didn't deposit their reflections yet, but have them 
lying around, should deposit them now. Perhaps the PDB should keep a list of 
all depositions of 'old' data. Naming and praising is better than naming and 
shaming.

Cheers,
Robbie

> Date: Sun, 9 Jan 2011 16:15:09 -0800
> From: hofkristall...@gmail.com
> Subject: Re: [ccp4bb] deposited SF (or not)?
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Yes, exactly. 2002 papers, the question is how to 
> 1) assure consistent deposition verification 
> 2) how to fix omissions in earlier entries 
> 
> Best, BR
> 
> PS: How did the EO confirm deposition - just ask you or the PDB, or some
> more automated mechanism?
> 
> -Original Message-
> From: mat...@itqb.unl.pt [mailto:mat...@itqb.unl.pt] 
> Sent: Sunday, January 09, 2011 3:35 PM
> To: hofkristall...@gmail.com
> Cc: ccp4bb@jiscmail.ac.uk
> Subject: Re: [ccp4bb] deposited SF (or not)?
> 
> Hi, Bernhard,
> 
> I recently published a paper in JBC that was published online only after
> the Editorial Office confirmed release of PDB coordinates and structure
> factors. Maybe those structures you mention are older and their internal
> checking procedures were not yet fully developed ?
> 
> Cheers,
> 
> Pedro.
> 
> > Dear All,
> >
> > during a random search for a model structure I found a situation where the
> > journal article clearly states that coordinates and SFs were deposited for
> > a
> > series of structures. EDS and SF files were absent and I confirmed with
> > PDB
> > that no SFs were ever deposited.
> >
> > I have no feeling for how frequent this is nor do I suggest anything more
> > than book-keeping errors. Nevertheless I wonder if there is a way to
> > crosscheck this in an automatic fashion (maybe PDB has some tools to do
> > that?) or whose responsibility it is to ensure consistency here. JBC
> > editors
> > have not responded so far.
> >
> > Best, BR
> > -
> > Bernhard Rupp
> > 001 (925) 209-7429
> > +43 (676) 571-0536
> > b...@ruppweb.org
> > hofkristall...@gmail.com
> > http://www.ruppweb.org/
> > -
> > No animals were hurt or killed during the production of this email.
> > -
> >
  

Re: [ccp4bb] So many clashes

[Robbie Joosten]

Dear Careina,
 
Keep in mind that MolPrrobity does not see symmetry (unlike RefDens or 
WHAT_CHECK). This means that the clashes that may come from having the wrong 
spacegroup are not detected.
 
Good luck,
Robbie Joosten
 
> Date: Tue, 18 Jan 2011 10:52:48 +0100
> From: mjvanra...@cnb.csic.es
> Subject: Re: [ccp4bb] So many clashes
> To: CCP4BB@JISCMAIL.AC.UK
> 
> - look at the clashes one by one and fix them, using your biochemical 
> knowledge and common sense
> - make sure there are no mistakes in the protein sequence used (resequence if 
> necessary), a few amino acids may be different from what you expect and, 
> combined with local ambiguous density, lead to clashes
> 
> Mark J van Raaij
> Laboratorio M-4
> Dpto de Estructura de Macromoleculas
> Centro Nacional de Biotecnologia - CSIC
> c/Darwin 3, Campus Cantoblanco
> E-28049 Madrid, Spain
> tel. (+34) 91 585 4616
> http://www.researcherid.com/rid/B-3678-2009
> 
> On 18 Jan 2011, at 10:34, Careina Edgooms wrote:
> 
> > Dear CCP4 bulletin board
> > 
> > I am trying to solve structure with molecular-replacement. I have got good 
> > solution using Phaser. The refined structure fits well toelectron density 
> > and appears reasonable in terms of geometry, ramachandran, rotamers etc. 
> > The problem I experience is that there are very many clashes and MolProbity 
> > check gives a score of 34th percentile and when I refine, the Rfree does 
> > not go below 30% for under 2A resolution. I tried reprocessing in different 
> > space group (from P212121 to P21) and also got a MR solution. In P21 number 
> > of clashes was reduced but still very high and Rfree was slightly reduced 
> > but the gap between Rfree and R was still high. I am not sure what this 
> > means and how I can sort out the problem of so many clashes? Any 
> > suggestions would be helpful and appreciated
> > 
> > regards
> > Careina
> > 
> > 
  

Re: [ccp4bb] quality homology model

[Robbie Joosten]

Dear Susy,

You describe two things: making a homology model and designing mutants.

As Oliv pointed out, the first step is getting the alignment right. Even with a 
multiple sequence alignment and knowledge of the template that can be quite 
difficult. You may need to make several models for alternative alignments.
When validating your model, packing is IMO the most useful thing to look at. 
Rosetta-holes is very good at finding poor models. What_check also has very 
good packing analysis and also flags unsatisfied hydrogen bond donors/acceptors 
which may help a lot. There are also some compound scores such as the 
MolProbity score and Q-mean which may help you to find the best model from a 
set.
The quality of the template is also important. Get the best template or use 
more than one. If the sequence identity isn't too low you should also use 
templates from pdb_redo. They helped (a lot?) in the previous CASP.

If you want to analyse single mutants you can try to work from simple 
principles such as minimizing the loss of torsional freedom of the main and 
side chain (entropy) or optimizing the gain of water entropy when the protein 
folds. Also minimising the loss of hydrogen bonds upon folding is quite useful. 
Just don't expect miracles.

Cheers,
Robbie Joosten



Date: Tue, 8 Feb 2011 10:52:09 -0800
From: eid...@blur.compbio.ucsf.edu
Subject: Re: [ccp4bb] quality homology model
To: CCP4BB@JISCMAIL.AC.UK



  



  
  
Hi Susy,



Before going into details: you have to get the alignment right.
After that, you may look into packing quality and geometry of your
models.



Regarding the parameters you are interested in: I talked to a guy
from the Sali lab (Modeller) about quality assessment of homology
models. He recommends to compare the gromos or anolea profiles per
residue (or whatever packing score your software uses) to the
template. In case there is gap: pay attention to the alignment!
Regarding cut-off values (what's ok and what not) you may want to
look into published work on your modeling software and/or contact
the authors directly. 



Another way to look at model quality, and maybe more significant, is
to check geometry (clashes, rotamers, bond angles etc.). You could
use MolProbity for that. The supplementary material of the following
article contains a good example (Table S1) on the evaluation of a
trimer interface:

http://www.ncbi.nlm.nih.gov/pubmed/20457942



Good luck!



  Oliv





On 02/07/11 01:13, Susy Rao wrote:

  
  

  Dear Community,



I have a question regarding protein model quality for
introduction of point mutations which should increase
solibity/stability of my protein of interest.



I plan to do homology models so that I can check the most
promising amino acids.



Which quality/resolution of the model do I need?

Which parameters would you check (gromos, anolea), and what
would you use as cut-off values?



At the moment I thought, that it could be interesting to
model a homologue of my protein and check the RMSDs with the
crystal structure.



Maybe you know some good literature, describing this?



Thank you



Susy

  

  
  




-- 
Oliv Eidam, Ph.D.
Postdoctoral fellow

University of California, San Francisco
Dept. of Pharmaceutical Chemistry
1700 4th Street, Byers Hall North, Room 501
San Francisco, CA 94158 - Box 2550 

Phone: 415-514-4253
Fax  : 415-514-4260
Email: eid...@blur.compbio.ucsf.edu



  

  

Re: [ccp4bb] quality homology model

[Robbie Joosten]

Dear Susy,

You describe two things: making a homology model and designing mutants.

As Oliv pointed out, the first step is getting the alignment right. Even with a 
multiple sequence alignment and knowledge of the template that can be quite 
difficult. You may need to make several models for alternative alignments.
When validating your model, packing is IMO the most useful thing to look at. 
Rosetta-holes is very good at finding poor models. What_check also has very 
good packing analysis and also flags unsatisfied hydrogen bond donors/acceptors 
which may help a lot. There are also some compound scores such as the 
MolProbity score and Q-mean which may help you to find the best model from a 
set.
The quality of the template is also important. Get the best template or use 
more than one. If the sequence identity isn't too low you should also use 
templates from pdb_redo. They helped (a lot?) in the previous CASP.

If you want to analyse single mutants you can try to work from simple 
principles such as minimizing the loss of torsional freedom of the main and 
side chain (entropy) or optimizing the gain of water entropy when the protein 
folds. Also minimising the loss of hydrogen bonds upon folding is quite useful. 
Just don't expect miracles.

Cheers,
Robbie Joosten



Date: Tue, 8 Feb 2011 10:52:09 -0800
From: eid...@blur.compbio.ucsf.edu
Subject: Re: [ccp4bb] quality homology model
To: CCP4BB@JISCMAIL.AC.UK



  



  
  
Hi Susy,



Before going into details: you have to get the alignment right.
After that, you may look into packing quality and geometry of your
models.



Regarding the parameters you are interested in: I talked to a guy
from the Sali lab (Modeller) about quality assessment of homology
models. He recommends to compare the gromos or anolea profiles per
residue (or whatever packing score your software uses) to the
template. In case there is gap: pay attention to the alignment!
Regarding cut-off values (what's ok and what not) you may want to
look into published work on your modeling software and/or contact
the authors directly. 



Another way to look at model quality, and maybe more significant, is
to check geometry (clashes, rotamers, bond angles etc.). You could
use MolProbity for that. The supplementary material of the following
article contains a good example (Table S1) on the evaluation of a
trimer interface:

http://www.ncbi.nlm.nih.gov/pubmed/20457942



Good luck!



  Oliv





On 02/07/11 01:13, Susy Rao wrote:

  
  

  Dear Community,



I have a question regarding protein model quality for
introduction of point mutations which should increase
solibity/stability of my protein of interest.



I plan to do homology models so that I can check the most
promising amino acids.



Which quality/resolution of the model do I need?

Which parameters would you check (gromos, anolea), and what
would you use as cut-off values?



At the moment I thought, that it could be interesting to
model a homologue of my protein and check the RMSDs with the
crystal structure.



Maybe you know some good literature, describing this?



Thank you



Susy

  

  
  




-- 
Oliv Eidam, Ph.D.
Postdoctoral fellow

University of California, San Francisco
Dept. of Pharmaceutical Chemistry
1700 4th Street, Byers Hall North, Room 501
San Francisco, CA 94158 - Box 2550 

Phone: 415-514-4253
Fax  : 415-514-4260
Email: eid...@blur.compbio.ucsf.edu



  

  

Re: [ccp4bb] very low R factor for twin refinement

[Robbie Joosten]

Hi Yuri,

The biggest drop I've seen as the result of detwinning is 10% lower R-free. 
Perhaps the detwinning has helped your refinement in othed ways. What R(-free) 
do you get when you take you pdb from the twinned refinement and your input mtz 
file and do 0 cycles of refinememt without detwinning. If you R(-free) is still 
considerably lower than the one from the 'regular' refinememt then you are a 
lucky guy and the twinned refinement just brought you to a lower minimum.

Cheers,
Robbie Joosten

> Date: Thu, 10 Feb 2011 21:36:31 +
> From: ga...@ysbl.york.ac.uk
> Subject: Re: [ccp4bb] very low R factor for twin refinement
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Maximum theoretical drop R/Rfree for perfect twin from 30% is around 25% 
> (i.e. it could go down to 5%). However it could only happen only if twinning 
> is perfect and there is no pseudo rotation parallel to twin operator. 
> Hypothetical case it can happen if you have refined one crystal structure at 
> sufficiently high resolution till (almost convergence) and another crystal is 
> twinned but otherwise perfectly isomorphous to the first crystal and you take 
> coordinates from the first crystal and refine against the second crystal.
> 
> regards
> Garib
> 
> 
> On 10 Feb 2011, at 20:14, Patskovsky Yury wrote:
> 
> > Dear all,
> > 
> > 
> >Twin refinement has yielded  Rwork/Rfree values of about 0.10/0.12 
> > for a nice quality 1.8A dataset (Rmerge 6%, space group I4, twin fractions 
> > 0.6/04) and almost the same R/Rfree (0.095/0.115) for another 1.5A nice 
> > quality data set (Rmerge 6%, space group I4, twin fractions 0.74/0.26). 
> > Refinement of untwinned data resulted in Rfree of ~32% and ~22% 
> > respectively.  REFMAC and PHENIX both have produced the same results and 
> > almost identical R factors, which are suspiciously VERY LOW for this 
> > resolution of data.  Twin refinement in REFMAC has produced exceptional 
> > quality maps even for 1.8A data (they look rather like 1.2A maps)  - I can 
> > not tell the same for PHENIX - maps were looking worse (may be someone has 
> > a better idea why).
> >   Normally twin refinement results in lowering R-factors - say, the 
> > drop in R from 30% (without twin refinement) to 20% (with twin refinement) 
> > would be considered normal, however we can see the drop from 32% to 12%.
> >I wonder if anyone else has experienced similar problems and what 
> > would be the most reasonable explanation for that.
> > 
> > 
> > Thank you
> > 
> > Yury
> > 
> > 
> > 
> > 
> > 
> > Yury Patskovsky, Ph.D.
> > Associate,
> > Dept of Biochemistry
> > Albert Einstein College of Medicine
> > 1300 Morris Park Ave
> > Bronx, NY 10461
> > phone 718-430-2745
> > yu...@medusa.vioc.aecom.yu.edu
  

Re: [ccp4bb] very low R factor for twin refinement

[Robbie Joosten]

Hi Yuri,

The biggest drop I've seen as the result of detwinning is 10% lower R-free. 
Perhaps the detwinning has helped your refinement in othed ways. What R(-free) 
do you get when you take you pdb from the twinned refinement and your input mtz 
file and do 0 cycles of refinememt without detwinning. If you R(-free) is still 
considerably lower than the one from the 'regular' refinememt then you are a 
lucky guy and the twinned refinement just brought you to a lower minimum.

Cheers,
Robbie Joosten

> Date: Thu, 10 Feb 2011 21:36:31 +
> From: ga...@ysbl.york.ac.uk
> Subject: Re: [ccp4bb] very low R factor for twin refinement
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Maximum theoretical drop R/Rfree for perfect twin from 30% is around 25% 
> (i.e. it could go down to 5%). However it could only happen only if twinning 
> is perfect and there is no pseudo rotation parallel to twin operator. 
> Hypothetical case it can happen if you have refined one crystal structure at 
> sufficiently high resolution till (almost convergence) and another crystal is 
> twinned but otherwise perfectly isomorphous to the first crystal and you take 
> coordinates from the first crystal and refine against the second crystal.
> 
> regards
> Garib
> 
> 
> On 10 Feb 2011, at 20:14, Patskovsky Yury wrote:
> 
> > Dear all,
> > 
> > 
> >Twin refinement has yielded  Rwork/Rfree values of about 0.10/0.12 
> > for a nice quality 1.8A dataset (Rmerge 6%, space group I4, twin fractions 
> > 0.6/04) and almost the same R/Rfree (0.095/0.115) for another 1.5A nice 
> > quality data set (Rmerge 6%, space group I4, twin fractions 0.74/0.26). 
> > Refinement of untwinned data resulted in Rfree of ~32% and ~22% 
> > respectively.  REFMAC and PHENIX both have produced the same results and 
> > almost identical R factors, which are suspiciously VERY LOW for this 
> > resolution of data.  Twin refinement in REFMAC has produced exceptional 
> > quality maps even for 1.8A data (they look rather like 1.2A maps)  - I can 
> > not tell the same for PHENIX - maps were looking worse (may be someone has 
> > a better idea why).
> >   Normally twin refinement results in lowering R-factors - say, the 
> > drop in R from 30% (without twin refinement) to 20% (with twin refinement) 
> > would be considered normal, however we can see the drop from 32% to 12%.
> >I wonder if anyone else has experienced similar problems and what 
> > would be the most reasonable explanation for that.
> > 
> > 
> > Thank you
> > 
> > Yury
> > 
> > 
> > 
> > 
> > 
> > Yury Patskovsky, Ph.D.
> > Associate,
> > Dept of Biochemistry
> > Albert Einstein College of Medicine
> > 1300 Morris Park Ave
> > Bronx, NY 10461
> > phone 718-430-2745
> > yu...@medusa.vioc.aecom.yu.edu
  

Re: [ccp4bb] Crystallographic Breakthrough - DarkMatter Version 1.0

[Robbie Joosten]

Hi Ethan,
 
Awsome progress! Really, I looked for other options like such. 2011 
will be a good year for crystallography. I should implement this in PDB_REDO.
 
Cheers,
Robbie
 
> Date: Thu, 31 Mar 2011 23:06:47 -0700
> From: merr...@u.washington.edu
> Subject: [ccp4bb] Crystallographic Breakthrough - DarkMatter Version 1.0
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Hi to all on ccp4bb:
> 
> What better day to announce the availability of a breakthrough technique
> in macromolecular crystallography?
> 
> Given recent discussion and in particular James Holton's suggestion that
> the problem of disordered sidechains is a problem akin to the difficulty
> of describing dark matter and dark energy...
> 
> I am happy to announce a new crystallographic tool that can improve your
> model by accounting for an often-neglected physical property. A detailed
> explanation, references, and a preliminary implementation of the program
> can be downloaded from
> 
> http://skuld.bmsc.washington.edu/DarkMatter
> 
> -- 
> Ethan A Merritt
> Karmic Diffraction Project
> Fine crystallography since April 1, 2011
> "What goes around, comes around - usually as a symmetry equivalent"
  

Re: [ccp4bb] The meaning of B-factor, was Re: [ccp4bb] what to do with disordered side chains

[Robbie Joosten]

Hi Frank,

> > I described in the previous e-mail the probabilistic interpretation of
> > B-factors. In the case of very high uncertainty = poorly ordered side
> > chains, I prefer to deposit the conformer representing maximum a
> > posteriori, even if it does not represent all possible conformations.
> > Maximum a posteriori will have significant contribution from the most
> > probable conformation of side chain (prior knowledge) and should not
> > conflict with likelihood (electron density map).
> > Thus, in practice I model the most probable conformation as long as it
> > it in even very weak electron density, does not overlap significantly
> > with negative difference electron density and do not clash with other
> > residues.
> If it's probability you're after, if there's no density to guide you 
> (very common!) you'd have to place all "likely" rotamers that don't 
> clash with anything, and set their occupancies to their probability (as 
> encoded in the rotamer library).
Which library? The one for all side chains of a specific type, or the one for a 
specific type with a given backbone conformation? These are quite different and 
change with the content of the PDB.
'Hacking' the occupancies is risky bussiness in general: errors are made quite 
easily. I frequently encounter side chains with partial occupancies but no 
alternatives, how can I relate this to the experimental date? Even worse, I 
also see cases where the occupancies of alternates sum up to values > 1.00. 
What does that mean? Is that a local increase of DarmMatter accidentally 
encoded in the occupancy?

> This is now veering into data-free protein modeling territory... wasn't 
> the idea to present to the downstream user an atomic representation of 
> what the electron density shows us?
Yes, but what we see can be deceiving.

> Worse, what we're also doing is encoding multiple different things in 
> one place - what database people call "poorly normalised", i.e. to 
> understand a data field requires further parsing and if statements. In 
> this case: to know whether there was no density, as end-user I'd have 
> to have to second-guess what exactly those 
> high-B-factor-variable-occupancy atoms mean.
> 
> Until the PDB is expanded, the conventions need to be clear, and I 
> thought they were:
> High B-factor ==> means atom is there but density is weak
> Atom missing ==> no density to support it.
Unfortunately, it is not trivial to decide when there is 'no density'. We must 
have a good metric to do this, but I don't think it exists yet. Removing atoms 
is thus very subjective. This explaines why I frequently find positive 
difference density peaks near missing side chains. Leaving side chains in 
sometimes gives negative difference density but refining them with proper 
B-factor restrainsts reduces the problem a lot. There is still the problem of 
radiation damage, but that is relatively small. At least refining the B-factor 
is more reproducible and less subjective than making the binary choice to keep 
or remove an atom.
 
Cheers,
Robbie

> 
> Oh well...
> phx.
  

Re: [ccp4bb] what to do with disordered side chains

[Robbie Joosten]

Dear James,
 
You make a very good point. So far we only discussed the option of removing 
alls side chain atoms except for CB. What if only a few side chain atoms are 
outside the density? Should we just remove those? If we use the argument that 
we should remove the atoms we cannot see, then surely we should keep the ones 
we can see. 
A problem is that if someone else recalculates the maps and inspects them 
(which is the point of the EDS), some atoms may very well fall inside or 
outside the density differently than in the original crystallographic study: 
software changes, other reflections are included (remember the recent I/sigI 
discussion), and last (but not least) when atoms are removed the solvent mask 
changes. 
 
Anyway, I don't think that the side chain discussion will be solved in this 
thread. PDB users are not all the same and treat the options that are proposed 
differently. They are all used in the PDB and that complicates matters for the 
users. In PDB_REDO (plug, plug ;) we build all missing side chains (and rebuild 
the zero-occupancy ones) and let the B-factor sort it out. Not everyone will 
agree with this, but at least it is consistent. If anyone studies a single 
structure properly, he should use the density and there is no problem. For 
statistics studies the first thing people do is filter by resolution and 
B-factor (and sequence identity) so the really bad side chains are removed from 
the testset anyway.
 
Cheers,
Robbie
 

 
> Date: Sun, 3 Apr 2011 23:45:10 -0700
> From: jmhol...@lbl.gov
> Subject: Re: [ccp4bb] what to do with disordered side chains
> To: CCP4BB@JISCMAIL.AC.UK
> 
> At the risk of throwing a little gasoline on the flame war, what about 
> side chains that will ALWAYS poke outside of the electron density? For 
> example, pretty much any terminal aliphatic at 3.5 A resolution? I 
> first learned this about 15 years ago when I made this movie:
> 
> http://bl831.als.lbl.gov/~jamesh/movies/resolution.mpeg
> 
> For those of you whose browser no longer supports MPEG-1, this is a 
> movie of a calculated (aka noise-free) electron density map, contoured 
> at "1 sigma", but cut to the resolution shown after applying an overall 
> B factor sufficient to suppress series-termination. By that I mean the 
> maps don't look all that different with or without the cutoff. The 
> coordinates shown are the "correct" model used to calculate the map. At 
> about 3.5 A you start to see side chains poking out of the density, and 
> at 6 A, all the side chains are "gone". Does this mean they should be 
> modeled with zero occupancy? ;)
> 
> -James Holton
> MAD Scientist
> 
> 
> On 4/3/2011 9:57 PM, Maia Cherney wrote:
> > I guess, most hydrophilic side chains on the surface are flexible, 
> > they don't keep the same conformation. If you cut those side chains 
> > off, the surface will be looking pretty hydrophobic and misleading 
> > (and very horrible). I prefer to see them intact. I know, most of them 
> > are flexible and don't have one exact position, but it's OK. I know 
> > they are there not far from the main chain. Usually, their exact 
> > position is irrelevant.
> >
> > Maia
> >
> >
> >
> > Jacob Keller wrote:
> >> Well, what about getting the default settings on the major molecular
> >> viewers to hide atoms with either occ=0 or b>cutoff ("novice mode?")?
> >> While the b cutoff is still be tricky, I assume we could eventually
> >> come to consensus on some reasonable cutoff (2 sigma from the mean?),
> >> and then this approach would allow each free-spirited crystallographer
> >> to keep his own preferred method of dealing with these troublesome
> >> sidechains and nary a novice would be led astray
> >>
> >> JPK
> >>
> >> On Sun, Apr 3, 2011 at 2:58 PM, Eric Bennett  wrote:
> >>> Most non-structural users are familiar with the sequence of the 
> >>> proteins they are studying, and most software does at least display 
> >>> residue identity if you select an atom in a residue, so usually it 
> >>> is not necessary to do any cross checking besides selecting an atom 
> >>> in the residue and seeing what its residue name is. The chance of 
> >>> somebody misinterpreting a truncated Lys as Ala is, in my 
> >>> experience, much much lower than the chance they will trust the xyz 
> >>> coordinates of atoms with zero occupancy or high B factors.
> >>>
> >>> What worries me the most is somebody designing a whole biological 
> >>> experiment around an over-interpretation of details that are implied 
> >>> by xyz coordinates of atoms, even if those atoms were not resolved 
> >>> in the maps. When this sort of error occurs it is a level of pain 
> >>> and wasted effort that makes the "pain" associated with having to 
> >>> build back in missing side chains look completely trivial.
> >>>
> >>> As long as the PDB file format is the way users get structural data, 
> >>> there is really no good way to communicate "atom exists with no 
> >>> reliable coordinates" to the user, given t

Re: [ccp4bb] what to do with disordered side chains

[Robbie Joosten]

Nice one Pavel. PDB_REDO actually runs on these files but it's not pretty. I 
updated my stripper program to remove all atoms with occ<0.00 instead of 0.00
 
Cheers,
Robbie
 


Date: Mon, 4 Apr 2011 07:26:23 -0700
From: pafon...@gmail.com
Subject: Re: [ccp4bb] what to do with disordered side chains
To: CCP4BB@JISCMAIL.AC.UK

Hi Dale,



 Set the occupancy of a marker atom to -99.99.
This will unambiguously mark the atom as an imaginary one.  This
will, of course, break every program that reads PDB format files,


may be not every -:)


phenix.model_vs_data works just fine with


http://www.rcsb.org/pdb/files/1BQU.pdb
http://www.rcsb.org/pdb/files/1azr.pdb


(Um... I guess I just created some work for PDB_REDO folks, sorry -:) )


All the best!
Pavel.


  

Re: [ccp4bb] what to do with disordered side chains

[Robbie Joosten]

Hi Jacob,

The PDB header has a record for missing atoms. Coot has an option to find them 
and any decent validation software will warn about incomplete residues. There 
are PDBREPORT entries for every PDB file with a list of incomplete residues. If 
a user makes a very small effort, he doesn't have to go around clicking every 
'alanine'.

Cheers,
Robbie

> Date: Mon, 4 Apr 2011 16:15:58 -0500
> From: j-kell...@fsm.northwestern.edu
> Subject: Re: [ccp4bb] what to do with disordered side chains
> To: CCP4BB@JISCMAIL.AC.UK
> 
> I like your IMGATM proposal, but wouldn't it also potentially break
> some of the programs? Also--and this is a problem with deleting only
> sidechain atoms in general--it seems that many, myself included, might
> totally miss that an apparent "alanine" is really a trunco-lysine.
> What I like is that it does get around the problem of people
> over-interpreting bogus sidechains, but it falls short, perhaps, in
> misleading people about what residue is there. I, for one, would not
> feel that I had to click on all the alanines in a model to verify that
> they were not lysines, and would be surprised and puzzled for a while
> about why this ala said lys when I clicked on it. Wouldn't you be
> surprised? (Well, maybe not after this thread...)
> 
> JPK
> 
> 
> 
> On Mon, Apr 4, 2011 at 1:55 AM, Dale Tronrud  
> wrote:
> >   The definition of _atom_site.occupancy is
> >
> >  The fraction of the atom type present at this site.
> >  The sum of the occupancies of all the atom types at this site
> >  may not significantly exceed 1.0 unless it is a dummy site.
> >
> > When an atom has an occupancy equal to zero that means that the
> > atom is NEVER present at that site - and that is not what you
> > intend to say.  Setting the occupancy to zero does not mean that
> > a full atom is located somewhere in this area.  Quite the opposite.
> >
> >   (The reference to a dummy site is interesting and implies to
> > me that mmCIF already has the mechanism you wish for.)
> >
> >   Having some experience with refining low occupancy atoms and
> > working with dummy marker atoms I'm quite confident that you can
> > never define a B factor cutoff that would work.  No matter what
> > value you choose you will find some atoms in density that refine
> > to values greater than the cutoff, or the limit you choose is so
> > high that you will find marker atoms that refine to less than the
> > limit.  A B factor cutoff cannot work - no matter the value you
> > choose you will always be plagued with false positives or false
> > negatives.
> >
> >   If you really want to stuff this bit into one of these fields
> > you have to go all out.  Set the occupancy of a marker atom to -99.99.
> > This will unambiguously mark the atom as an imaginary one.  This
> > will, of course, break every program that reads PDB format files,
> > but that is what should happen in any case.  If you change the
> > definition of the columns in the file you must mandate that all
> > programs be upgraded to recognized the new definitions.  I don't
> > know how you can do that other than ensuring that the change will
> > cause programs to cough.  To try to slide it by with a magic value
> > that will be silently accepted by existing programs is to beg for
> > bugs and subtle side-effects.
> >
> >   Good luck getting the maintainers of the mmCIF standard to accept
> > a magic value in either of these fields.
> >
> >   How about this: We already have the keywords ATOM and HETATM
> > (and don't ask me why we have two).  How about we create a new
> > record in the PDB format, say IMGATM, that would have all the
> > fields of an ATOM record but would be recognized as whatever the
> > marker is for "dummy" atoms in the current mmCIF?  Existing programs
> > would completely ignore these atoms, as they should until they are
> > modified to do something reasonable with them.  Those of us who
> > have no use for them can either use a switch in the program to
> > ignore them or just grep them out of the file.  Someone could write
> > a program that would take a model with only ATOM and HETATM records
> > and fill out all the desired IMGATM records (Let's call that program
> > WASNIAHC, everyone would remember that!).
> >
> >   This solution is unambiguous.  It can be represented in current
> > mmCIF, I think.  The PDB could run WASNIAHC themselves after deposition
> > but before acceptance by the depositor so people like me would not
> > have to deal with them during refinement but would be able to see
> > them before our precious works of art are unleashed on the world.
> >
> >   Seems like a win-win solution to me.
> >
> > Dale Tronrud
> >
> >
> > On 4/3/2011 9:17 PM, Jacob Keller wrote:
> >>
> >> Well, what about getting the default settings on the major molecular
> >> viewers to hide atoms with either occ=0 or b>cutoff ("novice mode?")?
> >> While the b cutoff is still be tricky, I assume we could eventually
> >> come to consensus on some reasonable cu

Re: [ccp4bb] anisotropy vs TLS

[Robbie Joosten]

Dear Kenneth,

IMO there is no resolution cut-off to decide to go from TLS to individual 
anisotropic Bs. I use the number of reflections per atom. You are refining 9 
parameters per atom so you need quite a lot. When I have>18 ref/atom I switch 
to anisotropic. I try both isotropic and anisotropic Bs with> 13.5 reflections 
per atom. You need good evidence that the anisotropic model  is better than an 
isotropic model, looking at R-free is not good enough. When you add so many 
parameters R-free will drop anyway. Ethan Merritt discussed a good test for 
this at the CCP4 study weekend. If you use Refmac, I have a tool that uses that 
method to compare the logfiles from too models and helps decide which model is 
best.
Combining TLS and anisotropic Bs is a bit over the top. You could use 
anisotropic Bs and then use TLSMD to extract the bulk movement.

Cheers,
Robbie  

> Date: Thu, 7 Apr 2011 19:39:39 -0500
> From: satys...@wisc.edu
> Subject: [ccp4bb] anisotropy vs TLS
> To: CCP4BB@JISCMAIL.AC.UK
> 
> peoples:
> 
> I know that TLS is a group B factor for regions of proteins that are moving 
> the same.
> It is used in low res structures. But at what resolution does one begin 
> anisotropic, i.e
> individual aniso for each atom, and leave TLS out. Or can one still use TLS 
> to first
> compensate for large motions and then dampen down the individual atoms with 
> aniso ADP?
> If both the aniso and TLS are used, how does a person interpret the results? 
> What programs
> are there to see just what is large body motions and what is atoms.
> thanks
> 
> --
> Kenneth A. Satyshur, M.S.,Ph.D.
> Associate Scientist
> University of Wisconsin
> Madison, Wisconsin 53706
> 608-215-5207
  

Re: [ccp4bb] Insertion codes

[Robbie Joosten]

Hi Ed,

> Personally I don't care one way or the other, but it may be pointed out
> that if D25 is actually number 37 in a homologous protein, it should be
> D37. Just as acknowledgement of the (somewhat purist) point of view
> that the residue number should denote its linear distance from the
> N-terminus.
> 
But which N-terminus should we use? The N-terminus of the protein, the one of 
the construct, or the N-terminus of what is ordered in the PDB file? And what 
about deletions, isn't it usefull to have gaps in the residue numbering 
indicating a deletion?
 
Getting proper residue numbering is difficult and there will always be 
exceptions. Dealing with all the different possible schemes is a nightmare. 
That is why residue numbering is always one of the first topics in structural 
bioinformatics. The PDB now seems to follow the numbering from UniProt which 
makes things a lot clearer, but fusion proteins now lead to crazy jumps in the 
residue numbering resulting in chains with numbers going from 100, to 1200 and 
back to 300. 
For many well studied groups of proteins insertion codes help the biological 
interpretation of the structures. Unfortunately, insertion codes are 
surprisingly poorly supported by software that uses PDB files especially 
outside crystallography (but even CCP4 software has some remaining problems). I 
hope this thread will at least increase awareness of the existence of insertion 
codes. It is very much needed...
 
Cheers,
Robbie
 
 

> 
> Cheers,
> 
> Ed.
> 
> -- 
> "Hurry up before we all come back to our senses!"
> Julian, King of Lemurs
  

[ccp4bb] Zotero style

[Robbie Joosten]

Hi Everyone,
 
Does anyone have a Zotery style template for Acta Cryst and the like, (s)he 
wishes to share? I cannot find it in the repository, but perhaps someone has 
made one for private use.
 
Cheers,
Robbie Joosten
 
Biochemistry
Netherlands Cancer Institute  

Re: [ccp4bb] Zotero style

[Robbie Joosten]

Hi Ian,
 
Indeed the word 2007 template is very good (I never got the 2003 version 
working well), but it becomes a problem when your co-authors are Mac users with 
old Word versions.
 
Cheers,
Robbie
 
> Date: Wed, 4 May 2011 12:18:59 +0100
> Subject: Re: [ccp4bb] Zotero style
> From: ianj...@gmail.com
> To: robbie_joos...@hotmail.com
> CC: CCP4BB@jiscmail.ac.uk
> 
> Hi Robbie
> 
> My understanding is that the templates for Acta Cryst. are here:
> 
> http://journals.iucr.org/services/wordstyle.html
> 
> or here:
> 
> http://journals.iucr.org/d/services/latexstyle.html
> 
> At least that's what I've always used.
> 
> Cheers
> 
> -- Ian
> 
> On Wed, May 4, 2011 at 8:05 AM, Robbie Joosten
>  wrote:
> > Hi Everyone,
> >
> > Does anyone have a Zotery style template for Acta Cryst and the like, (s)he
> > wishes to share? I cannot find it in the repository, but perhaps someone has
> > made one for private use.
> >
> > Cheers,
> > Robbie Joosten
> >
> > Biochemistry
> > Netherlands Cancer Institute
> >
  

Re: [ccp4bb] Zotero style

[Robbie Joosten]

Hi Darren,
 
Thank you for the link. It may be a usefull tool. Unfortunately, the site was 
buggy in IE9. It worked much better in FF4, but it stopped when I tried to 
generate the final style file. 
It turns out that you can also import an EndNote style into Zotero. I tried 
this for the .ens file on the Acta Cryst site but the import destroyed all the 
interpunction. Still it may provide a good starting point to create a final 
Zotero style.
 
Cheers,
Robbie
 


From: h...@embl.fr
Date: Wed, 4 May 2011 13:33:15 +0200
Subject: Re: [ccp4bb] Zotero style
To: robbie_joos...@hotmail.com
CC: CCP4BB@jiscmail.ac.uk

You can use this

http://www.somwhere.org/csl/

to build your style.

Darren




On 4 May 2011 09:05, Robbie Joosten  wrote:


Hi Everyone,
 
Does anyone have a Zotery style template for Acta Cryst and the like, (s)he 
wishes to share? I cannot find it in the repository, but perhaps someone has 
made one for private use.
 
Cheers,
Robbie Joosten
 
Biochemistry
Netherlands Cancer Institute


-- 
** 
Dr. Darren Hart, 
Team Leader
High Throughput Protein Lab
Grenoble Outstation
European Molecular Biology Laboratory (EMBL) 
**  
www.embl.fr/research/unit/hart/index.html

For funded access to ESPRIT construct screening via EU FP7 PCUBE: 
http://tinyurl.com/ydnrwg4

Email: h...@embl.fr
Tel: +33 4 76 20 77 68 
Fax: +33 4 76 20 71 99 
Skype: hartdarren
Postal address: EMBL, 6 rue Jules Horowitz, BP181, 38042 Grenoble, Cedex
9, France 
**
  

Re: [ccp4bb] Zotero style

[Robbie Joosten]

Hi Bjorn,
 
Thank you for the file. I gave it a go, but it kept saying 'this.style is 
undefined' or word used the next style in the list. It seems like a 
compatibility problem, Zotero has changed a lot since 2009. It tried some 
hacking, but that didn't work.
 
Cheers,
Robbie
 
> Date: Wed, 4 May 2011 12:06:32 -0700
> From: bj...@msg.ucsf.edu
> Subject: Re: [ccp4bb] Zotero style
> To: CCP4BB@JISCMAIL.AC.UK
> 
> I made one some time ago (attached). It's not perfect (missing 
> definitions for e.g. books) but works well for article-references.
> 
> -Bjørn
> 
> -- 
> Bjørn Panyella Pedersen
> Macromolecular Structure Group
> Dept. of Biochemistry and Biophysics
> University of California, San Francisco
> 
> 
> 
> On 2011-05-04 05:32, Robbie Joosten wrote:
> > Hi Darren,
> >
> > Thank you for the link. It may be a usefull tool. Unfortunately, the
> > site was buggy in IE9. It worked much better in FF4, but it stopped when
> > I tried to generate the final style file.
> > It turns out that you can also import an EndNote style into Zotero. I
> > tried this for the .ens file on the Acta Cryst site but the import
> > destroyed all the interpunction. Still it may provide a good starting
> > point to create a final Zotero style.
> >
> > Cheers,
> > Robbie
> >
> > 
> > From: h...@embl.fr
> > Date: Wed, 4 May 2011 13:33:15 +0200
> > Subject: Re: [ccp4bb] Zotero style
> > To: robbie_joos...@hotmail.com
> > CC: CCP4BB@jiscmail.ac.uk
> >
> > You can use this
> >
> > http://www.somwhere.org/csl/
> >
> > to build your style.
> >
> > Darren
> >
> >
> >
> > On 4 May 2011 09:05, Robbie Joosten  > <mailto:robbie_joos...@hotmail.com>> wrote:
> >
> > Hi Everyone,
> >
> > Does anyone have a Zotery style template for Acta Cryst and the
> > like, (s)he wishes to share? I cannot find it in the repository, but
> > perhaps someone has made one for private use.
> >
> > Cheers,
> > Robbie Joosten
> >
> > Biochemistry
> > Netherlands Cancer Institute
> >
> >
> >
> >
> > --
> > **
> > Dr. Darren Hart,
> > Team Leader
> > High Throughput Protein Lab
> > Grenoble Outstation
> > European Molecular Biology Laboratory (EMBL)
> > **
> > www.embl.fr/research/unit/hart/index.html
> > <http://www.embl.fr/research/unit/hart/index.html>
> >
> > For funded access to ESPRIT construct screening via EU FP7 PCUBE:
> > http://tinyurl.com/ydnrwg4
> >
> > Email: h...@embl.fr <mailto:h...@embl.fr>
> > Tel: +33 4 76 20 77 68
> > Fax: +33 4 76 20 71 99
> > Skype: hartdarren
> > Postal address: EMBL, 6 rue Jules Horowitz, BP181, 38042 Grenoble, Cedex
> > 9, France
> > **
> 
  

Re: [ccp4bb] refmac problem with anisotropic Us

[Robbie Joosten]

Hi Ethan,

> > I also reset the temperature factors to 20 at 
> > the beginning of each refinement round. The refinement resolution is 75 
> > to 1.8 A, and the space group is C2, if it matters.
> 
> I am virtually certain that refinement of individual anisotropic
> U^ij terms cannot be justified at 1.8A. Too many parameters,
> too few observations.
In some cases (high solvent) there may be enough reflections to give your atoms 
anisotropic B-factors. Look for instance at PDB entry 1tv4, it has 19.5 
reflections per atom, 1rzh has even more. When in doubt, I use a Hamilton test 
to see if anisotropic Bs are acceptable.
 
That said, of course your residual B-factors after TLS can be anisotropic, but 
TLS + anisotropic Bs don't seem right to me either. You might as well use 
anisotropic B-factors and then extract TLS tensors from them. That was the 
original point of TLS anyway.
 
Cheers,
Robbie
 


> 
> 
> 
> 
> > 
> > The problem comes when I take the output from such a run, model build in 
> > Coot, and feed it back in for the next round of refinement. As you can 
> > see from the summary table below (trimmed for brevity), the refinement 
> > blows up rather badly, making the R factors and the geometry 
> > substantially worse.
> > 
> > Ncyc Rfact Rfree FOM -LL -LLfree rmsBOND zBOND 
> > rmsANGL zANGL rmsCHIRAL $$
> > $$
> > 0 0.3376 0.3576 0.556 115671. 6318.1 0.0 
> > 0.0 0.0 0.0 0.0
> > 5 0.2676 0.2921 0.680 109411. 6009.2 0.0 
> > 0.0 0.0 0.0 0.0
> > 9 0.2529 0.2785 0.703 108589. 5978.4 0.0 
> > 0.0 0.0 0.0 0.0
> > 10 0.2516 0.2787 0.710 108459. 5975.2 0.0170 
> > 0.829 1.534 0.731 0.097
> > 15 0.2503 0.2876 0.711 108711. 6042.1 0.0241 
> > 0.998 1.729 0.833 0.111
> > 20 0.2739 0.3152 0.672 110787. 6147.3 0.0268 
> > 1.103 1.837 0.885 0.119
> > 25 0.2949 0.3388 0.638 112219. 6215.4 0.0255 
> > 1.049 1.808 0.866 0.116
> > 30 0.3114 0.3575 0.609 113094. 6257.7 0.0243 
> > 1.006 1.794 0.854 0.114
> > 
> > This refinement also throws out an enormous number of warnings about 
> > adjacent atoms' B factors being substantially different. Most of these 
> > warnings appear to involve the autobuilt riding hydrogens and their 
> > adjacent heavy atoms.
> > 
> > If I use pdbcur to strip out the ANISOU lines, but otherwise keep the 
> > file and refinement protocol unchanged, it goes along nicely:
> > 
> > Ncyc Rfact Rfree FOM -LL -LLfree rmsBOND zBOND 
> > rmsANGL zANGL rmsCHIRAL $$
> > $$
> > 0 0.2912 0.3233 0.667 112220. 6151.2 0.0 
> > 0.0 0.0 0.0 0.0
> > 5 0.2476 0.2787 0.751 107853. 5934.7 0.0 
> > 0.0 0.0 0.0 0.0
> > 9 0.2468 0.2764 0.754 107501. 5915.6 0.0 
> > 0.0 0.0 0.0 0.0
> > 10 0.2469 0.2763 0.754 107480. 5914.2 0.0170 
> > 0.829 1.534 0.731 0.097
> > 15 0.1933 0.2387 0.810 101501. 5723.3 0.0238 
> > 0.994 1.791 0.868 0.118
> > 20 0.1849 0.2327 0.817 100446. 5694.7 0.0239 
> > 0.992 1.826 0.884 0.120
> > 25 0.1818 0.2316 0.821 100034. 5681.0 0.0223 
> > 0.925 1.775 0.855 0.114
> > 30 0.1804 0.2296 0.824 99820. 5669.4 0.0221 
> > 0.913 1.763 0.848 0.113
> > 
> > (Without TLS refinement, the final R and Rfree would be 0.1896 and 0.2503.)
> > 
> > So, what's happening here? Does Refmac not like ANISOU lines in the 
> > input PDB file? I don't usually work with structures at a resolution 
> > high enough to warrant aniso B refinement, so I haven't encountered this 
> > before.
> > 
> > Thanks for any advice,
> > 
> > Matt
> > 
> > 
> > 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center, K-428 Health Sciences Bldg
> University of Washington, Seattle 98195-7742
  

Re: [ccp4bb] non-waters among structured solvent atoms

[Robbie Joosten]

Hi Wolfram,
 
This was an early study on the subject: 
http://www.ncbi.nlm.nih.gov/pubmed/8594192
The software is still accessible via the STAN server.
 
Cheers,
Robbie
 
> Date: Tue, 14 Jun 2011 17:51:21 -0400
> From: wtem...@gmail.com
> Subject: [ccp4bb] non-waters among structured solvent atoms
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Dear colleagues,
> following a discussion in our lab, I have volunteered to dig out
> articles from the literature about erroneous assignments of non-water
> entities such as metal ions, halides in protein models. For example I
> have the faint recollection that data mining of the PDB for suspect
> "water" assemblies matching the geometry of coordinated cations has
> previously been described. But none of my google searches has turned
> up the references I was looking for. Could someone point me in the
> right direction, please?
> Many thanks,
> Wolfram Tempel
  

Re: [ccp4bb] Help! low resolution protein-DNA complex

[Robbie Joosten]

Dear Xun,
 > >   I have a 3.2A dataset for a protein-DNA complex. The protein is
> > a homodimer, and the DNA is almost palindromic (except one base pair
> > in the middle and two or three base pairs at both two ends). It is my
> > first time solving structures, and unfortunately the resolution is
> > low. No body in our lab has used ccp4 or phenix, so I am really
> > frustrated as a second year student. 
> Your frustration is understandable.  It is somewhat of an expectation in
> academia that your advisor will either help you directly or if she/he is
> not familiar with the methodology you are forced to use, will find
> someone to help you.  The questions you ask surely may be answered by
> someone in your department.  IMHO, a second year student should not be
> left alone to battle his first structure which happens to be 3.2A
> protein/DNA complex.Indeed, this is just asking for problems. It's a good 
> call that you asked for help. Perhaps your supervisor can arrage for you to 
> be embedded in a crystallography lab for a while. That should give you easy 
> access to people with experience.  > >   I mainly used ccp4. So far, the 
> best R/Rfree I got is 0.27/0.34.
> and that is not bad given the resolutionYou are heading the right way. You 
> should be able to close the R/R-free gap a bit more.
> >   I went to the crystallography meeting, and people suggested me to
> > rely more on geometry. I remember I got a DNA restraints file and a
> > refmac script from someone on this mailing list, and that really
> > helped (otherwise the DNA base pairing will be weird). Can someone
> > tell me how to restraint the protein (helix)?
> one way of doing it would be to restrain the hydrogen bonds that
> stabilize the helix.  It is not advisable at higher resolution, but
> sounds alright at 3.2A.  I once used a restraint file to keep DNA sane
> by forcing Watson-Crick pairing, the helical restraints would work
> pretty mnuch in the same way.  Look at the structure of the restraint
> file that you have and modify it to include the helix-stabilizing
> hydrogen bonds.I like real-space refining everything in Coot with tight 
> helical restraints. You may need to chainge the default restraint weight 
> matrix (lower numbers give tighter restraints). The options are under the 
> "R/RC" button. > >   People also suggested me to include NCS and TLS in 
> the
> > refinement, but I don't know how to. For NCS, I should define a region
> > that are the same in both monomers? Should I use tight or loose
> > restraints?  For TLS, I don't have a clue.
> Yes and tight (at least at first).  For TLS you may want to take a look
> at the TLSMD server. (Also, consider tighter restraints on B-factors).
> Otherwise, just define TLS for the whole thing, then protein and DNA
> separately, then individual monomers and whatever pieces of DNA common
> sense suggests would move together.  Keep whatever combination gives you
> the lowest Rfree.In Refmac you can use "local NCS" which takes away the need 
> to mess with NCS selections (which can be really difficult). Although it is 
> not needed for Refmac, you should make sure that the same residues in 
> different monomers have the same residue number. Be conservative with TLS (in 
> the beginning). One group per chain sounds right. In the case of your DNA you 
> can consider putting both chains in one group. Tight B-factor weights may be 
> needed, you could also trying one overall B factor. I personally only do that 
> when TLS works well. Oh, and always use riding hydrogens in refinement. It 
> helps a lot at low resolution, because of the VDW restraints. For that same 
> reason you should not be too conservative with the sidechains (at least not 
> for the ones in the core of the protein).
Since you have only started building you should probably go through the entire 
structure a few times. After that, use structure validation tools frequently. 
WHAT_CHECK and Molprobity are must-use tools for that. Coot also has many 
usefull features for validation. Good luck. Cheers,Robbie Joosten   
   

Re: [ccp4bb] Follow-up: non-waters among structured solvent atoms

[Robbie Joosten]

For the record:-UNK is for unknown residues only. That means that you know that 
you are looking at an amino acid you just don't know which. You should assign 
element types. It used to be defined to CB (just like ALA), it now goes to CG. 
I don't see the point of this update.-UNL is for unknown hetero compounds.-UNX 
is for unknown solo atoms.-DN id for unknown deoxy nucleotide. Cheers,Robbie
 Date: Fri, 17 Jun 2011 12:22:50 +0100
From: twom...@globalphasing.com
Subject: Re: [ccp4bb] Follow-up: non-waters among structured solvent atoms
To: CCP4BB@JISCMAIL.AC.UK




On 16 Jun 2011, at 17:19, Pavel Afonine wrote:Hi,

On Thu, Jun 16, 2011 at 7:49 AM, Jan Dohnalek  wrote:



Modeling more UNKNOWN atoms might be the future for these cases?

one needs to specify chemical element type in 77-78 position, otherwise these 
records are useless. 
But if you know the chemical element type then there's no point in calling it 
UNK.
BUSTER uses the scattering factors for oxygen for modelling X, on the grounds 
that you'll have put in an X because it doesn't look enough unlike water to be 
obviously something else.  
Tom   

Re: [ccp4bb] Waters in ADIT

[Robbie Joosten]

Dear Petr,

Did you try WHAT_CHECK? It has a number of tests for water and will take 
indirect interactions with the macromolecule into account.

Cheers,
Robbie

> Date: Wed, 22 Jun 2011 16:01:45 +0200
> From: arnaud.goepf...@unibas.ch
> Subject: Re: [ccp4bb] Waters in ADIT
> To: CCP4BB@JISCMAIL.AC.UK
> 
> Dear Petr,
> 
> I guess ADIT only looks for interaction between water molecules and the 
> protein and does not take into account the interactions between water 
> molecules. So if a water molecule interacts with another water molecule but 
> not with the protein, ADIT will give you these error report even though the 
> water is well coordinated.
> 
> 
> On Jun 22, 2011, at 1:18 PM, Petr Kolenko wrote:
> 
> > Dear colleagues,
> > 
> > I want to deposit one structure, but ADIT reports tens more waters
> > that are further than 3.5 AA away from macromolecule atoms. I
> > inspected about half of them manually, but all of them are OK. I have
> > observed this "incorrect behavior" of ADIT also in one previous
> > structure for deposition, but just ignored three or four reports,
> > because I knew, I was doing the right thing. Does anyone know how to
> > solve this problem?
> > 
> > I have already tried:
> > - changing HETATM to ATOM
> > - assigning different chain ID for waters to have same ID as protein chain
> > - renumbering of residues (not in this case, but the previous one)
> > 
> > I do not have to solve this problem, but I do not want to have so
> > strange Validation Report from ADIT.
> > Many thanks for any idea.
> > 
> > Petr
> > 
> > 
> > PS: Not important, but refined with REFMAC5 at medium resolution.
> > 
> > -- 
> > Petr Kolenko
> > kole...@imc.cas.cz
> > http://kolda.webz.cz
  

Re: [ccp4bb] low resolution refinement

[Robbie Joosten]

Dear Qixu,

 

refamac 5.6 works well at these resolutions. You can add commands to your 
refinement in CCP4i by using the 'Run and view command script' (or something 
like that) option and just typing in the extra commands. Jelly-body has worked 
very well for me (although I use tigheter restraints than the default). Also 
local NCS works well (provided you have NCS). I never used reference 
structures, but I heared good things about it. Don't forget to use riding 
hydrogens, for some reason it is not the deafault. 
 Perhaps you should also switch of the automatic X-ray weighting in favour of 
optimizing the matrix weight yourself (start with 0.05 and compare refinements 
for higher and lower values).

 

HTH,

Robbie

 

 

> Date: Sat, 9 Jul 2011 16:59:29 +0800
> From: caiq...@gmail.com
> Subject: [ccp4bb] low resolution refinement
> To: CCP4BB@JISCMAIL.AC.UK
>
> Dear all,
>
> Recently, I refine two low resolution structures in refmac 5.5. Their
> resolutions are 3A and 3.5A respectively.
> For 3A structure, after MR by phaser and rigidbody refinement&restraint
> refinement by refmac5.5, I got R factor 25% and R free 35%. And then
> each time, after my model building in coot and restraint refinement by
> refmac 5.5, the R factor stays 25%, but R free increases to 38%, even 39%.
> For 3.5A structure, the R factor stays 27%, but R free increases from
> 37% to 42% after my slightly model building in coot.
> Could you help me to find the reason?
>
> Maybe the reason is the overfit of the structure? I found that new
> version of refmac 5.6 has many new features for low resolution
> refinement, such as jelly boy, secondary structure restraints. But I
> don't know how to use these new features in old version ccp4i (6.1.13)?
>
> I also used phenix.refine with the "reference model" ( I have high
> resolution model for one domain of the low resolution protein) and
> "secondary structure restraints", but it seams the same. Any suggestion?
>
> BTW, is that simulator annealing not suitable for low resolution
> structure? I used the simulator annealing method of CNS and
> phenix.refine, but the geometry of the structure is always destroyed
> seriously.
>
> Could you help me?
>
> Thank you very much!

Re: [ccp4bb] low resolution refinement

[Robbie Joosten]

Hi Qixu,

 

In CCP4i the option is in the refinement parameters: 

Use hydrogen atoms: ["build all hydrogens"] and [] output to coordinate file

 

What is does is build all hydrogens at the expected coordinates and constrain 
them in refinement (i.e. adding hydrogens does not add extra parameters to the 
model). The effect on explaining your experminetal data is typically small, but 
the hydrogens help with the VdW restraints. In effect they reduce the number of 
bumps and improve your torsion angles.

 

You can use a reference structure to generate external restraints:

http://www.ysbl.york.ac.uk/~garib/refmac/data/refmac_news.html#External

I hope someone else on the BB can explain how. I think it is also explained in 
the talk and tutorials of the Refmac website.

 

HTH,

Robbie

  

> From: caiq...@gmail.com 
> Date: Sun, 10 Jul 2011 00:44:25 +0800 
> Subject: Re: [ccp4bb] low resolution refinement 
> To: robbie_joos...@hotmail.com 
> CC: CCP4BB@jiscmail.ac.uk 
> 
> Hi, 
> 
> Thank you for your suggestion. 
> Could you tell me what is "riding hydrogens"? 
> And it seems there is not "reference model" function in refmac5.6? 
> 
> 
> 
> 2011/7/9 Robbie Joosten 
> mailto:robbie_joos...@hotmail.com>> 
> Dear Qixu, 
> 
> 
> 
> refamac 5.6 works well at these resolutions. You can add commands to 
> your refinement in CCP4i by using the 'Run and view command script' (or 
> something like that) option and just typing in the extra commands. 
> Jelly-body has worked very well for me (although I use tigheter 
> restraints than the default). Also local NCS works well (provided you 
> have NCS). I never used reference structures, but I heared good things 
> about it. Don't forget to use riding hydrogens, for some reason it is 
> not the deafault. 
> Perhaps you should also switch of the automatic X-ray weighting in 
> favour of optimizing the matrix weight yourself (start with 0.05 and 
> compare refinements for higher and lower values). 
> 
> 
> 
> HTH, 
> 
> Robbie 
> 
> 
> 
> 
>  
> > Date: Sat, 9 Jul 2011 16:59:29 +0800 
> > From: caiq...@gmail.com<mailto:caiq...@gmail.com> 
> > Subject: [ccp4bb] low resolution refinement 
> > To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK> 
> > 
> > Dear all, 
> > 
> > Recently, I refine two low resolution structures in refmac 5.5. Their 
> > resolutions are 3A and 3.5A respectively. 
> > For 3A structure, after MR by phaser and rigidbody refinement&restraint 
> > refinement by refmac5.5, I got R factor 25% and R free 35%. And then 
> > each time, after my model building in coot and restraint refinement by 
> > refmac 5.5, the R factor stays 25%, but R free increases to 38%, even 39%. 
> > For 3.5A structure, the R factor stays 27%, but R free increases from 
> > 37% to 42% after my slightly model building in coot. 
> > Could you help me to find the reason? 
> > 
> > Maybe the reason is the overfit of the structure? I found that new 
> > version of refmac 5.6 has many new features for low resolution 
> > refinement, such as jelly boy, secondary structure restraints. But I 
> > don't know how to use these new features in old version ccp4i (6.1.13)? 
> > 
> > I also used phenix.refine with the "reference model" ( I have high 
> > resolution model for one domain of the low resolution protein) and 
> > "secondary structure restraints", but it seams the same. Any suggestion? 
> > 
> > BTW, is that simulator annealing not suitable for low resolution 
> > structure? I used the simulator annealing method of CNS and 
> > phenix.refine, but the geometry of the structure is always destroyed 
> > seriously. 
> > 
> > Could you help me? 
> > 
> > Thank you very much! 
> 

Re: [ccp4bb] low resolution refinement

[Robbie Joosten]

When in doubt, try both. In my personal experience, adding hydrogens always 
works. Especially at low resolution. But don't take my word for it, experiment 
a little.

Cheers,
Robbie

Date: Sun, 10 Jul 2011 16:01:59 +0800
From: caiq...@gmail.com
Subject: Re: [ccp4bb] low resolution refinement
To: CCP4BB@JISCMAIL.AC.UK

Hi,

Thank you very much.

In the example5 of this page 
http://www.ysbl.york.ac.uk/~garib/refmac/docs/usage/examples.html#exam5, It 
seems that for 3A dataset, "MAKE HYDRogens No".


Is it mean that the hydrogen just usefull for high resolution data?








2011/7/10 Robbie Joosten 


Hi Qixu,







In CCP4i the option is in the refinement parameters:



Use hydrogen atoms: ["build all hydrogens"] and [] output to coordinate file







What is does is build all hydrogens at the expected coordinates and constrain 
them in refinement (i.e. adding hydrogens does not add extra parameters to the 
model). The effect on explaining your experminetal data is typically small, but 
the hydrogens help with the VdW restraints. In effect they reduce the number of 
bumps and improve your torsion angles.









You can use a reference structure to generate external restraints:



http://www.ysbl.york.ac.uk/~garib/refmac/data/refmac_news.html#External



I hope someone else on the BB can explain how. I think it is also explained in 
the talk and tutorials of the Refmac website.







HTH,



Robbie







> From: caiq...@gmail.com

> Date: Sun, 10 Jul 2011 00:44:25 +0800

> Subject: Re: [ccp4bb] low resolution refinement

> To: robbie_joos...@hotmail.com

> CC: CCP4BB@jiscmail.ac.uk

>

> Hi,

>

> Thank you for your suggestion.

> Could you tell me what is "riding hydrogens"?

> And it seems there is not "reference model" function in refmac5.6?

>

>

>

> 2011/7/9 Robbie Joosten

> mailto:robbie_joos...@hotmail.com>>

> Dear Qixu,

>

>

>

> refamac 5.6 works well at these resolutions. You can add commands to

> your refinement in CCP4i by using the 'Run and view command script' (or

> something like that) option and just typing in the extra commands.

> Jelly-body has worked very well for me (although I use tigheter

> restraints than the default). Also local NCS works well (provided you

> have NCS). I never used reference structures, but I heared good things

> about it. Don't forget to use riding hydrogens, for some reason it is

> not the deafault.

> Perhaps you should also switch of the automatic X-ray weighting in

> favour of optimizing the matrix weight yourself (start with 0.05 and

> compare refinements for higher and lower values).

>

>

>

> HTH,

>

> Robbie

>

>

>

>

> 

> > Date: Sat, 9 Jul 2011 16:59:29 +0800

> > From: caiq...@gmail.com<mailto:caiq...@gmail.com>

> > Subject: [ccp4bb] low resolution refinement

> > To: CCP4BB@JISCMAIL.AC.UK<mailto:CCP4BB@JISCMAIL.AC.UK>

> >

> > Dear all,

> >

> > Recently, I refine two low resolution structures in refmac 5.5. Their

> > resolutions are 3A and 3.5A respectively.

> > For 3A structure, after MR by phaser and rigidbody refinement&restraint

> > refinement by refmac5.5, I got R factor 25% and R free 35%. And then

> > each time, after my model building in coot and restraint refinement by

> > refmac 5.5, the R factor stays 25%, but R free increases to 38%, even 39%.

> > For 3.5A structure, the R factor stays 27%, but R free increases from

> > 37% to 42% after my slightly model building in coot.

> > Could you help me to find the reason?

> >

> > Maybe the reason is the overfit of the structure? I found that new

> > version of refmac 5.6 has many new features for low resolution

> > refinement, such as jelly boy, secondary structure restraints. But I

> > don't know how to use these new features in old version ccp4i (6.1.13)?

> >

> > I also used phenix.refine with the "reference model" ( I have high

> > resolution model for one domain of the low resolution protein) and

> > "secondary structure restraints", but it seams the same. Any suggestion?

> >

> > BTW, is that simulator annealing not suitable for low resolution

> > structure? I used the simulator annealing method of CNS and

> > phenix.refine, but the geometry of the structure is always destroyed

> > seriously.

> >

> > Could you help me?

> >

> > Thank you very much!

> 

  

Re: [ccp4bb] large R-Rfree difference in "final" structure

[Robbie Joosten]

Hi Careina,

 

Assuming you don't suffer from a very poor data parameter ratio that would lead 
to such a large R-free/R, you need to improve your refinement. If you have NCS 
you should use local NCS restraints. You could also try jelly-body restraints, 
although they may not work at your resolution.

 

Cheers,

Robbie


> Date: Wed, 13 Jul 2011 08:38:38 -0700 
> From: careinaedgo...@yahoo.com 
> Subject: [ccp4bb] large R-Rfree difference in "final" structure 
> To: CCP4BB@JISCMAIL.AC.UK 
> 
> Dear ccp4 bulletin board 
> 
> I just have a slight concern regarding my Rwork Rfree difference. I 
> have a structure that I have solved. I am reasonably content that it is 
> complete because it has refined well, it no longer has bad geometries 
> and contacts and all the rotamers, ramachandra, bond lengths etc are 
> good. It gives favourable scores on molprobity and procheck. My only 
> concern is the R factor difference. The resolution of the structure is 
> 2.3A. The R factor is 0.24 after refinement but the Rfree is 0.33 which 
> seems to me to be rather high. Should I be concerned? 
> 
> During refinement Rfree only drops from about 0.36 to 0.33 while the R 
> factor drops from 0.31 to 0.24.. I have removed automatic weighting in 
> refmac in order to constrain my bond lengths and angles during a couple 
> of rounds of refinement. This did not have any effect on the R factors, 
> however. I am fairly content that the space group I have chosen is 
> correct so I am not sure what else could cause the big difference in R 
> factors? There is no twinning. 
> 
> Can I be satisfied that my structure is correct despite the high R free 
> or should I be doing other checks/ trying other things before I can 
> submit this structure? 
> 
> Thank you for any help 
> Careina 

Re: [ccp4bb] output individual redundancies

[Robbie Joosten]

Hi Ed,

 

I was recently looking for that value myself, but couldn't find it. I suppose 
(at some point) it may be useful information to deposit. If something is a mean 
value, it is nice to know how many individual values were used to construct 
that mean. Unfortunately, there doesn't seem to be a cif token for that.

 

Cheers,

Robbie


> Date: Fri, 15 Jul 2011 09:26:39 +0100
> From: p...@mrc-lmb.cam.ac.uk
> Subject: Re: [ccp4bb] output individual redundancies
> To: CCP4BB@JISCMAIL.AC.UK
>
> No M/ISYM is different it's the symmetry number plus a full or partial flag.
>
> Ed. You could count them from the unmerged output as you say, or I could make 
> you a special version of SCALA or Aimless maybe next week
>
> Phil
>
> Sent from my iPhone
>
> On 14 Jul 2011, at 23:15, Ethan Merritt  wrote:
>
> > On Thursday, July 14, 2011 02:55:26 pm Ed Pozharski wrote:
> >> I am looking for a way to output redundancy per individual reflection,
> >> preferably for scala but if that is not possible then maybe for
> >> scalepack.
> >
> > If you read the unmerged file from scalepack into ccp4 using
> > combat, it creates a data column with label M/ISYM that I think is
> > what you are asking for. You can use the "Import Unmerged Data (Combat)"
> > tab in the ccp4i GUI.
> >
> > Ethan
> >
> >
> >>> From my (admittedly quick) look at the scala manual it seems that I can
> >> use something like UNMERGED output option to exclude outliers and then
> >> would need to write a bit of code to calculate the redundancies. But I
> >> hope that I missed something and there is a secret keyword that would
> >> add redundancies to the merged mtz file.
> >>
> >> Cheers,
> >>
> >> Ed.
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Ethan A Merritt
> > Biomolecular Structure Center, K-428 Health Sciences Bldg
> > University of Washington, Seattle 98195-7742
> >   

Re: [ccp4bb] unusual sighting of a crystal structure

[Robbie Joosten]

Hi Artem,

Thank for that nice example of a protein structure used to pimp a movie. Ribbon 
representations are always the scariest.

Cheers,
Robbie

Date: Sat, 16 Jul 2011 10:57:21 -0500
From: artem.evdoki...@gmail.com
Subject: [ccp4bb] unusual sighting of a crystal structure
To: CCP4BB@JISCMAIL.AC.UK

Fellow structural biologists, I just caught a brief glimpse of a crystal 
structure (looks like an Fv complex or maybe an IG-like receptor ectodomain 
complex?) in the trailer for the upcoming 'scary virus' movie "Contagion" and 
thought you'd want to share the amusement.
 Sorry about the 300K attachment :) Artem 
  

Re: [ccp4bb] Straw poll: polysaccharide building?

[Robbie Joosten]

Hi Kim and Kevin,

 

Even then you can have chirality inversions during real-space refinement, which 
would destroy the SWEET input model from. There is no substitute for common 
sense (and validation) here. 

 

That said, Kevin, something to autobuild carbohydrates (given a sequence) would 
be awesome. I'd use it a lot. Just don't make a WMD (weapon of model 
destruction).

 

Cheers,

Robbie


> Date: Tue, 26 Jul 2011 11:06:03 +0100
> From: henr...@ebi.ac.uk
> Subject: Re: [ccp4bb] Straw poll: polysaccharide building?
> To: CCP4BB@JISCMAIL.AC.UK
>
> Yes but it is easier to take the sweet model for the required sequence
> and fit that to density rather than do it residue by residue
> which will lead to glycan structures unknown to the source
>
> kim
>
> > Dear Kim,
> >
> > I asume that Kevin plans to build in electron density maps. As far as I
> > can see Sweet will produce a model unhindered by experimental data.
> >
> > Herman
> >
> > -Original Message-
> > From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> > Kim Henrick
> > Sent: Tuesday, July 26, 2011 11:44 AM
> > To: CCP4BB@JISCMAIL.AC.UK
> > Subject: Re: [ccp4bb] Straw poll: polysaccharide building?
> >
> > why not use
> > http://glycosciences.de/modeling/sweet2/doc/index.php
> > which works perfectly
> > and would save the duplication of effort
> >
> > cut & paste
> > #---
> >
> > a-D-Neup5Ac-(2-3)-b-D-Galp-(1-4)+
> > |
> >
> > b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)+
> > |
> > |
> > a-L-Fucp-(1-3)+
> > b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)-b-D-GlcpNAc-(1-6)+
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> > a-L-Fucp-(1-3)+
> >
> >
> >
> > a-D-Manp-(1-6)+
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> > b-D-Galp-(1-4)-b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)-b-D-GlcpNAc-(1-3)-b-D-Ga
> > lp-(1-4)-b-D-GlcpNAc-(1-2)+
> > | a-L-Fucp-(1-6)+
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > |
> > b-D-Galp-(1-4)+
> >
> >
> > |
> > b-D-GlcpNAc-(1-4)-Asn
> > |
> >
> >
> >
> > |
> > |
> >
> > b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)+
> >
> >
> > b-D-Manp-(1-4)-b-D-GlcpNAc-(1-4)+
> > |
> >
> > |
> >
> > |
> > a-L-Fucp-(1-3)+
> > b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)+
> > |
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> > a-L-Fucp-(1-3)+
> >
> >
> > b-D-GlcpNAc-(1-4)+
> > |
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> >
> >
> >
> >
> >
> >
> > |
> >
> > a-L-Fucp-(1-3)+
> >
> >
> >
> >
> >
> > a-D-Manp-(1-3)+
> >
> > |
> > a-D-Neup5Ac-(2-6)-b-D-Galp-(1-4)-b-D-GlcpNAc-(1-3)-b-D-Galp-(1-4)-b-D-Gl
> > cpNAc-(1-3)-b-D-Galp-(1-4)-b-D-GlcpNAc-(1-2)+
> >
> >
> >
> >
> > and click and your o/p is as attached
> > apart from the poor excuse for a pdb file it has the model with
> > glycosidic torsion angles as expected as in glycomapsdb
> >
> >
> >
> >
> >> Straw poll:
> >>
> >> Are you interested in software to autobuild polysaccarides?
> >>
> >> Kevin
> >>
> >> p.s. I expect I'll have to spend at least a year working on the
> >> problem before before I spell polysaccharide consistently.
> >>
> >   

Re: [ccp4bb] Creating a non-minimal mmCIF dictionary for DNA?

[Robbie Joosten]

Hi Brittney, 

 

DNA is pretty standard so the restraints should be in the dictionary. Perhaps 
the DNA in your model has non-standard residue names (PDBv2). Are your bases 
called DT, DA, etc? Do your atom names have "*" or "'"?

 

Cheers,

Robbie


> Date: Tue, 26 Jul 2011 12:45:08 -0400 
> From: bmanv...@umaryland.edu 
> Subject: [ccp4bb] Creating a non-minimal mmCIF dictionary for DNA? 
> To: CCP4BB@JISCMAIL.AC.UK 
> 
> I am trying to refine a protein-DNA structure, and I am having 
> difficulties refining the DNA using COOT. I used the ccp4i Phaser 
> program to molecular replace the protein and DNA simultaneously (there 
> are solved crystal structures of the free protein and a similar DNA 
> bound to another protein), but I am only able to manually refine the 
> protein in COOT. If I try to refine the DNA, a window pops up with the 
> following statement: No Restraints Found! Non-existent or minimal 
> description of restrained residues. How do I create a non-minimal mmCIF 
> dictionary for just the DNA? I am relatively new to crystallography 
> and would appreciate any guidance. 
> 
> Brittney 
> 

Re: [ccp4bb] research paper

[Robbie Joosten]

Jung-Hoon,

This is a so-called WaReZ request, which could get you banned a lot of webfora. 
Of course, we are all guilty of it at some occasions. The best way to get an 
article is to ask the authors, they are allowed give away free copies 
(depending on the journal I guess). Hooray, for authors who pay open access 
fees.

Cheers,
Robbie


> Date: Thu, 28 Jul 2011 12:23:10 -0400
> From: f...@bernstein-plus-sons.com
> Subject: Re: [ccp4bb] research paper
> To: CCP4BB@JISCMAIL.AC.UK
>
> The article is available for purchase for $40. Journals
> cannot survive without funding which can come from many
> sources - subscriptions, author payment to make the
> article open-access, etc. But asking someone to provide
> a 'free' copy without Acta's permission is tantamount to
> theft.
>
> Frances Bernstein
>
> =
>  Bernstein + Sons
> * * Information Systems Consultants
>  5 Brewster Lane, Bellport, NY 11713-2803
> * * ***
>  * Frances C. Bernstein
> * *** f...@bernstein-plus-sons.com
> *** *
> * *** 1-631-286-1339 FAX: 1-631-286-1999
> =
>
> On Thu, 28 Jul 2011, Ed Pozharski wrote:
>
> > On Thu, 2011-07-28 at 14:35 +, Jung-Hoon Lee wrote:
> >> Acta Cryst D63 (2007), 550-554.
> >
> > I can't believe Cornell has no access to Acta D.
> >
> > --
> > "Hurry up before we all come back to our senses!"
> > Julian, King of Lemurs
> >