Re: [ccp4bb] Quantifying electron density inside of a given volume

[Jessica Bruhn]

Hi all,

There are lots of great suggestions in this thread. I will just add a
little trick from small molecule crystallography: when trying to estimate
how many atoms can fit in a given volume, you can use the Rule of 18. Take
the volume of interest in Angstroms^3 and divide it by 18 Angstroms^3. This
will give you an estimate of the number of atoms that can fit in this
volume (ignoring hydrogens of course). This calculation assumes tight
packing, like we would see in a small molecule structure, so it should be a
good approximation of the maximum number of atoms that can fit in this void
and a good place to start for occupancy refinement.

Best of luck!

Cheers,
Jessica

On Mon, Aug 15, 2022 at 5:17 PM Pavel Afonine  wrote:

> Hi James,
>
> I like your approach with dummy atoms and occupancy refinement. Dealing
> with actual maps sounds like hell to me indeed (especially given that we
> deal with weighted Fourier maps!). Reading this as someone who immediately
> translates this into a computer code (in my mind), a few things that aren't
> clear to me:
> - Where exactly inside the blob of density do you place these dummy atoms?
> - How many do you place?
> - Is there a risk of placing them too close to the boundary of the blob
> (in which case the question remains: what is the boundary?)?
> - I guess O or C as an atom type should do it, but what about B factor
> (would you refine B as well?)?
> - if you refine B, how do you deconvolute occupancy from refined B values
> (and eventually from effects of positional errors of your DAs)?
> -
> - How all these choices are going to affect the result?
>
> All the best!
> Pavel
>
>
> On Mon, Aug 15, 2022 at 4:38 PM James Holton  wrote:
>
>> There are several programs for integrating electron density, but please
>> let me assure you that it is almost always the wrong thing to do.
>>
>> A much better strategy is occupancy refinement.  Throw in dummy atoms,
>> turn off non-bonded interactions to them, and refine their occupancy until
>> it a) stops changing (may be more than one round), and b) there are no
>> Fo-Fc differences left in the region of interest.  Then all you do is add
>> up the occupancies, multiply by the relevant atomic number (usually 8), and
>> voila! you get the best-fit number of electrons in your blob. You may want
>> to try re-running with random starting points to get an idea of the error
>> bars.
>>
>> What is wrong with integrating density?  Well, for one, it is hard to
>> know where to set the boundaries. Integrated density can be VERY sensitive
>> to the choice of radius, making your arbitrary decision of which radius to
>> use a source of error. Too small and you miss stuff. Too big and you add
>> unnecessary noise. Also, neighboring atoms have tails, and if you don't
>> subtract them properly, that is another source of error. Also, because of
>> the missing F000 term, there is an offset, which adds a term proportional
>> to the integration volume.  For example, an integral resulting in zero
>> "electrons" does NOT mean you have vacuum. It just means that the area you
>> integrated has the same average density as the entire map. This may not be
>> the number you want.
>>
>> The beauty of occupancy refinement is that it automatically handles all
>> these problems. The "vacuum level" and F000 are known quantities in the
>> calculated map. The B factors given to the dummy atoms als o allow the
>> borders of your integration region to be "soft": down-weighting the
>> contribution of map noise far from your region of interest.  And, finally,
>> by including atoms in the green density, neighboring atoms won't be sucked
>> into it.
>>
>> Think of it as fitting a smooth curve to noisy data and the number of
>> electrons is just a parameter in that fit, rather than trying to integrate
>> the noisy data itself.  This is not an analogy. Refinement programs are
>> really just very sophisticated curve-fitting programs.  And if you have a
>> forest of overlapping peaks and you are trying to de-convolute the
>> area/volume of one peak, it is best to include that peak in the fit, rather
>> than leave it out. Shoulder peaks especially tend to get "eaten" by large
>> neighboring peaks.
>>
>> How do you turn off non-bonds? Well, there is documentation for refmac:
>> http://www.ysbl.york.ac.uk/refmac/data/refmac_keywords.html
>> and phenix:
>> https://phenix-online.org/documentation/reference/refinement.html
>>
>> All that said, to answer the original question:
>>  One very easy thing to do within the CCP4 suite is to use "mapmask" to
>> make a mask corresponding to your "sphere", or other region of interest.
>> Perhaps place a water at the center of your peak, and either use the
>> "border" feature of mapmask, or use "sfall" to compute a calculated map and
>> convert that to a mask using "threshold" in mapmask.  This mask should have
>> values of 0 or 1 at every voxel. (or, if you feel like being clever,
>> something between 0 and 1 to reflect how much you

Re: [ccp4bb] Quantifying electron density inside of a given volume

[Pavel Afonine]

Hi James,

I like your approach with dummy atoms and occupancy refinement. Dealing
with actual maps sounds like hell to me indeed (especially given that we
deal with weighted Fourier maps!). Reading this as someone who immediately
translates this into a computer code (in my mind), a few things that aren't
clear to me:
- Where exactly inside the blob of density do you place these dummy atoms?
- How many do you place?
- Is there a risk of placing them too close to the boundary of the blob (in
which case the question remains: what is the boundary?)?
- I guess O or C as an atom type should do it, but what about B factor
(would you refine B as well?)?
- if you refine B, how do you deconvolute occupancy from refined B values
(and eventually from effects of positional errors of your DAs)?
-
- How all these choices are going to affect the result?

All the best!
Pavel


On Mon, Aug 15, 2022 at 4:38 PM James Holton  wrote:

> There are several programs for integrating electron density, but please
> let me assure you that it is almost always the wrong thing to do.
>
> A much better strategy is occupancy refinement.  Throw in dummy atoms,
> turn off non-bonded interactions to them, and refine their occupancy until
> it a) stops changing (may be more than one round), and b) there are no
> Fo-Fc differences left in the region of interest.  Then all you do is add
> up the occupancies, multiply by the relevant atomic number (usually 8), and
> voila! you get the best-fit number of electrons in your blob. You may want
> to try re-running with random starting points to get an idea of the error
> bars.
>
> What is wrong with integrating density?  Well, for one, it is hard to know
> where to set the boundaries. Integrated density can be VERY sensitive to
> the choice of radius, making your arbitrary decision of which radius to use
> a source of error. Too small and you miss stuff. Too big and you add
> unnecessary noise. Also, neighboring atoms have tails, and if you don't
> subtract them properly, that is another source of error. Also, because of
> the missing F000 term, there is an offset, which adds a term proportional
> to the integration volume.  For example, an integral resulting in zero
> "electrons" does NOT mean you have vacuum. It just means that the area you
> integrated has the same average density as the entire map. This may not be
> the number you want.
>
> The beauty of occupancy refinement is that it automatically handles all
> these problems. The "vacuum level" and F000 are known quantities in the
> calculated map. The B factors given to the dummy atoms als o allow the
> borders of your integration region to be "soft": down-weighting the
> contribution of map noise far from your region of interest.  And, finally,
> by including atoms in the green density, neighboring atoms won't be sucked
> into it.
>
> Think of it as fitting a smooth curve to noisy data and the number of
> electrons is just a parameter in that fit, rather than trying to integrate
> the noisy data itself.  This is not an analogy. Refinement programs are
> really just very sophisticated curve-fitting programs.  And if you have a
> forest of overlapping peaks and you are trying to de-convolute the
> area/volume of one peak, it is best to include that peak in the fit, rather
> than leave it out. Shoulder peaks especially tend to get "eaten" by large
> neighboring peaks.
>
> How do you turn off non-bonds? Well, there is documentation for refmac:
> http://www.ysbl.york.ac.uk/refmac/data/refmac_keywords.html
> and phenix:
> https://phenix-online.org/documentation/reference/refinement.html
>
> All that said, to answer the original question:
>  One very easy thing to do within the CCP4 suite is to use "mapmask" to
> make a mask corresponding to your "sphere", or other region of interest.
> Perhaps place a water at the center of your peak, and either use the
> "border" feature of mapmask, or use "sfall" to compute a calculated map and
> convert that to a mask using "threshold" in mapmask.  This mask should have
> values of 0 or 1 at every voxel. (or, if you feel like being clever,
> something between 0 and 1 to reflect how much you want to weight a given
> voxel). You can check it in coot. If you then multiply this mask by your
> mFo-DFc map the result will have a non-zero average value. This will be
> printed out in the log file. Multiply this average value by the volume of
> the unit cell and you have your integrated number of electrons. Yes, its
> that simple.
> One issue you may have is map parameter compatibility (grid spacing, axis
> order, xyz limits, etc.). You get around these by using the same grid in
> all your fft or sfall runs, and then use mapmask to make the axis and
> limits match before you multiply the map and mask.  The only other issue
> here might be the average value being a very small number and rounded off
> by the default print precision. You can fix this by multiplying the map by
> a large constant (again, using mapmask), 

Re: [ccp4bb] Quantifying electron density inside of a given volume

[James Holton]

There are several programs for integrating electron density, but please 
let me assure you that it is almost always the wrong thing to do.


A much better strategy is occupancy refinement.  Throw in dummy atoms, 
turn off non-bonded interactions to them, and refine their occupancy 
until it a) stops changing (may be more than one round), and b) there 
are no Fo-Fc differences left in the region of interest.  Then all you 
do is add up the occupancies, multiply by the relevant atomic number 
(usually 8), and voila! you get the best-fit number of electrons in your 
blob. You may want to try re-running with random starting points to get 
an idea of the error bars.


What is wrong with integrating density?  Well, for one, it is hard to 
know where to set the boundaries. Integrated density can be VERY 
sensitive to the choice of radius, making your arbitrary decision of 
which radius to use a source of error. Too small and you miss stuff. Too 
big and you add unnecessary noise. Also, neighboring atoms have tails, 
and if you don't subtract them properly, that is another source of 
error. Also, because of the missing F000 term, there is an offset, which 
adds a term proportional to the integration volume. For example, an 
integral resulting in zero "electrons" does NOT mean you have vacuum. It 
just means that the area you integrated has the same average density as 
the entire map. This may not be the number you want.


The beauty of occupancy refinement is that it automatically handles all 
these problems. The "vacuum level" and F000 are known quantities in the 
calculated map. The B factors given to the dummy atoms als o allow the 
borders of your integration region to be "soft": down-weighting the 
contribution of map noise far from your region of interest.  And, 
finally, by including atoms in the green density, neighboring atoms 
won't be sucked into it.


Think of it as fitting a smooth curve to noisy data and the number of 
electrons is just a parameter in that fit, rather than trying to 
integrate the noisy data itself.  This is not an analogy. Refinement 
programs are really just very sophisticated curve-fitting programs. And 
if you have a forest of overlapping peaks and you are trying to 
de-convolute the area/volume of one peak, it is best to include that 
peak in the fit, rather than leave it out. Shoulder peaks especially 
tend to get "eaten" by large neighboring peaks.


How do you turn off non-bonds? Well, there is documentation for refmac:
http://www.ysbl.york.ac.uk/refmac/data/refmac_keywords.html
and phenix:
https://phenix-online.org/documentation/reference/refinement.html

All that said, to answer the original question:
 One very easy thing to do within the CCP4 suite is to use "mapmask" to 
make a mask corresponding to your "sphere", or other region of 
interest.  Perhaps place a water at the center of your peak, and either 
use the "border" feature of mapmask, or use "sfall" to compute a 
calculated map and convert that to a mask using "threshold" in mapmask.  
This mask should have values of 0 or 1 at every voxel. (or, if you feel 
like being clever, something between 0 and 1 to reflect how much you 
want to weight a given voxel). You can check it in coot. If you then 
multiply this mask by your mFo-DFc map the result will have a non-zero 
average value. This will be printed out in the log file. Multiply this 
average value by the volume of the unit cell and you have your 
integrated number of electrons. Yes, its that simple.
One issue you may have is map parameter compatibility (grid spacing, 
axis order, xyz limits, etc.). You get around these by using the same 
grid in all your fft or sfall runs, and then use mapmask to make the 
axis and limits match before you multiply the map and mask.  The only 
other issue here might be the average value being a very small number 
and rounded off by the default print precision. You can fix this by 
multiplying the map by a large constant (again, using mapmask), then the 
printed value will have lots of digits.


This may seem complicated, but the use of masks can be a very valuable 
skill to develop.  In fact, one way to simplify, stabilize and 
accelerate the occupancy refinement described above is to use a mask to 
isolate the region of interest. That is, take the mFo-DFc map, zero out 
everything far away from your peak, and convert the result to structure 
factors. You can then call these structure factors "Fobs" (alongside the 
original sigma(Fobs)) in a new refinement. The Rwork/Rfree then becomes 
a local statistic, indicative of the % error in your refined total 
occupancy. One caveat is that if every atom in the new refinement is 
having its occupancy refined you will lose the absolute scale. To fix 
this, you need to add back at least one well-ordered atom into "Fobs", 
and also include it in the model.  For example, take a well-ordered 
helix, extract those atoms, calculate a map using "sfall", and add it to 
the masked-off difference ma

[ccp4bb] Postdoc positions

[Quyen Hoang]

Hi All,

My group has a couple of Postdoc positions available immediately to study the 
structures and functions of proteins associated with neurodegenerative diseases.
The projects utilize cryo-EM and X-ray crystallography along with a battery of 
other biophysical and biochemical methods.
As such, they might be good opportunities for crystallographers looking to 
learn cryo-EM or microscopists wishing to learn X-ray crystallography (however, 
experiences with these methods are not necessary to apply).
These positions are supported by a new 5-year NIH grant.

Please email me directly (qqho...@iu.edu) if you are interested in learning 
more about these positions.

Cheers,
Quyen

___
Quyen Hoang, PhD
Associate Professor of Biochemistry and Molecular Biology
Director of IUSM Center for Electron Microscopy (iCEM)
Adjunct Associate Professor of Neurology
Primary Investigator of the Stark Neuroscience Research Institute
Indiana University School of Medicine
635 Barnhill Drive, MS0013C
Indianapolis, IN, 46202
(317)274-4371
https://qqhoang.pages.iu.edu



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] Multiple AlphaFold DB jobs available at EMBL-EBI

[David Armstrong]

**

*We are currently recruiting for several positions at the AlphaFold 
Protein Structure Database (AlphaFold DB)to join the Velankar team at 
the European Bioinformatics Institute (EMBL-EBI).*


*

These are exciting opportunities to work as part of EMBL and DeepMind's 
new partnership to make the most complete and accurate database of 
predicted protein structures freely and openly available to the 
scientific community.


The jobs are detailed below but for more information and to apply, visit 
https://pdbe.org/jobs.



AlphaFold DB front-end developer

A technical role, developing and maintaining user-facing web pages and 
developing innovative data visualizations that interact with the 3D 
molecular graphics viewer, Mol*.


Deadline: 12th September 2022


AlphaFold DB search engine developer

A technical role, further developing the search engine of AlphaFold DB, 
and designing and implementing ways to improve the information display, 
including improving the relevance of search hits.


Deadline: 12th September 2022


AlphaFold DB UX/UI expert

A technical role, designing and validating new user interface elements 
and improving existing ones, with responsibility for maintaining the 
graphics design asset library of AlphaFold DB.


Deadline: 19th September 2022


AlphaFold DB Bioinformatician (Data Integration)

A scientific, technical role, responsible for discovering, mapping and 
integrating sequence, structure and functional annotations for AlphaFold 
protein structure predictions.


Deadline: 26th September 2022


AlphaFold DB Bioinformatician (Training)

Design and develop training for the AlphaFold DB, liaise with user 
communities, promote training materials, and publicly represent 
AlphaFold DB at various training events. There is the option for a part 
time role in this position.


Deadline: 26th September 2022


For more information on all these job roles and to apply, visit 
https://pdbe.org/jobs.


*

--
David Armstrong
Outreach and Training Lead
PDBe
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
Cambridge CB10 1SD UK
Tel: +44 1223 492544



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] CCPBioSim Industry Talk

[Sarah Fegan - STFC UKRI]

Dear all,

Our next industry talk is on Wednesday 28 September 2022 at 2pm UK time. The 
speaker is John Liebeschuetz from Astex and his talk is "Do proteins ever 
strain drug-like ligands?"

Details and registration at https://www.ccpbiosim.ac.uk/astex2022. If you had 
registered for the talk in June that was cancelled because of illness and are 
still available and interested in attending, please register again.

Best wishes,
Sarah F



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] circular peptide structure refinement

[Matthew Snee]

Hi All

To prevent Phenix removing link records, you can use Readyset to create a 
parameters file based on LINK records, and feed it to the refinement program, 
otherwhise they are deleted.

Best wishes

Matthew.

From: CCP4 bulletin board  on behalf of Nicholas Clark 

Sent: 14 August 2022 16:01
To: CCP4BB@JISCMAIL.AC.UK 
Subject: Re: [ccp4bb] circular peptide structure refinement

Phenix in the past, and I’m assuming still, does not recognize “link records”. 
You’ll likely need to generate the peptide in AceDRG, making sure to link the 
carboxy- and amino-termini, and include the cif during refinement.

This was the only way I was able to get Phenix to properly refine an inhibitor 
covalently linked to an active site Cys. Thus, the same procedure may be 
required for your circular peptide.

Best,

Nick Clark

On Sun, Aug 14, 2022 at 1:06 AM Jiang Xu 
mailto:foxj...@gmail.com>> wrote:
Hi Joel,
 Thank you for your reply. I just got time to refine the circular peptide 
structure 1 month later. I use MR to solve the structure. I made the 
link(Calculate-->Modeling-->Make Link) as the guy who replied to my question 
suggested. The link generated is a dashed line but disappeared after refinement 
with Phenix.  It seemed that the program didn't consider the link made in coot 
as a valid bond and intentionally avoided forming a bond between the C atom and 
the N atom. I still don't know how to fix the problem.
Thank you,
Best regards,
Jiang
Lin Chen Lab
University of Southern California

P.S.
coot manually made link between the C and N terminal
[unnamed.jpg]
After refinement
[unnamed (1).jpg]



On Wed, Jul 6, 2022 at 3:29 PM Joel Tyndall 
mailto:joel.tynd...@otago.ac.nz>> wrote:

You will need to add the “link” line to the PDB file so the software recognises 
the covalent bond.

See the pdb file for 6U6K



Hope this helps



J



From: CCP4 bulletin board mailto:CCP4BB@JISCMAIL.AC.UK>> 
On Behalf Of Jiang Xu
Sent: Thursday, 7 July 2022 10:15 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] circular peptide structure refinement



Hello everyone,

   I have a peptide that forms a peptide bond between the N terminal and C 
terminal.  I used X-ray crystallography to solve the structure and found the N 
and C terminals are pretty close to each other with extra electron densities 
clearly showing that they form a peptide bond. However in Coot I could not make 
the peptide bond, the two terminals seem to repel each other when I do real 
space refinement in coot and, couldn't form the peptide bond. Any suggestions 
on how to do it?

Thank you,

Best,

Jiang Xu

Lin Chen Research Group

Molecular and Computational Biology

Department of Biological Sciences

University of Southern California





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

--
Nicholas D. Clark
PhD Candidate
Malkowski Lab
University at Buffalo
Department of Structural Biology
Jacob's School of Medicine & Biomedical Sciences
955 Main Street, RM 5130
Buffalo, NY 14203

Cell: 716-830-1908



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/