Re: [COOT] Can't download pdb files nor density maps in WinCoot 0.9.8.1 EL
Hi,
I copied the file Paul recommended into
lib/python2.7/site-packages/coot and I'm now able to download
coordinates and maps from EBI from within 0.9.8.1 again. Thanks.
This file doesn't work in 1.0.01 because that program uses python 3.8.
Dale Tronrud
On 6/8/2023 3:55 AM, Paul Emsley wrote:
Hi Dale,
Without testing, I guess that you can replace get_ebi.py with this one
https://github.com/pemsley/coot/blob/refinement/python/get_ebi.py
(use Raw of course)
Paul.
On 08/06/2023 08:35, Sameer Velankar wrote:
CAUTION: This email originated from outside of the LMB.
Do not click links or open attachments unless you recognize the sender
and know the content is safe.
*.-owner-c...@jiscmail.ac.uk-.*
Hi Dale
The correct url for accessing files are as follows -
1. PDB file - https://www.ebi.ac.uk/pdbe/entry-files/pdb1cbs.ent
2. mmCIF file - https://www.ebi.ac.uk/pdbe/entry-files/1cbs.cif
Kind regards
Sameer
On 8 Jun 2023, at 07:25, Dale Tronrud wrote:
Hi,
When I click on "Fetch PDB entry using Accession Code..." or "Fetch
PDB & Map using EDS..." I get
PDB Accession Code: 3eoj
DEBUG:: extracted accession code handle mode n 1
BL WARNING:: retrieve of url
https://www.ebi.ac.uk/pdbe-srv/view/files/3eoj.ent failed
handle_read_draw_molecule_with_recentre ("coot-download/3eoj.pdb.ent".1)
WARNING:: Error reading coot-download/3eoj.pdb.ent
That web site, indeed, does not exist and I presume the PDBe has
moved the data.
To the best of my knowledge this is the most recent version of
WinCoot. I've downloaded the "unstable" version 1.0.01 and it fails
in the same way (but does show a very pretty display when downloading
from PDB Redo).
I've done my best to search the "coot" and "ccp4bb" archives and
don't see mention of this problem, but my search skills are limited.
What do I do to download PDB's and maps again?
Dale Tronrud
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a
mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
available at https://www.jiscmail.ac.uk/policyandsecurity/
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
<https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1>
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
<https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1>
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list
hosted by www.jiscmail.ac.uk, terms & conditions are available at
https://www.jiscmail.ac.uk/policyandsecurity/
[COOT] Can't download pdb files nor density maps in WinCoot 0.9.8.1 EL
Hi,
When I click on "Fetch PDB entry using Accession Code..." or "Fetch
PDB & Map using EDS..." I get
PDB Accession Code: 3eoj
DEBUG:: extracted accession code handle mode n 1
BL WARNING:: retrieve of url
https://www.ebi.ac.uk/pdbe-srv/view/files/3eoj.ent failed
handle_read_draw_molecule_with_recentre ("coot-download/3eoj.pdb.ent".1)
WARNING:: Error reading coot-download/3eoj.pdb.ent
That web site, indeed, does not exist and I presume the PDBe has
moved the data.
To the best of my knowledge this is the most recent version of
WinCoot. I've downloaded the "unstable" version 1.0.01 and it fails in
the same way (but does show a very pretty display when downloading from
PDB Redo).
I've done my best to search the "coot" and "ccp4bb" archives and
don't see mention of this problem, but my search skills are limited.
What do I do to download PDB's and maps again?
Dale Tronrud
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list
hosted by www.jiscmail.ac.uk, terms & conditions are available at
https://www.jiscmail.ac.uk/policyandsecurity/
Re: [COOT] absolute map levels
I too use the scroll wheel quite a lot when exploring a map. I just like to be grounded by the knowledge of what contour level I'm looking at so I can make estimations of physical interpretations as I'm going. Is this peak likely a Zinc atom? A water molecule? Something at partial occupancy? I can't tell at all from the appearance of the peak, but if I know the contour level on a physically relevant scale (not a statistically relevant scale) I can have a feel for what I'm looking at. I believe that is valuable information to add to that of the surrounding chemical environment and leads me to an interpretation that refinement is likely to support. I find that I'm much less likely to build a Zinc atom into that "strong" difference map peak only to be rewarded with a huge negative peak after refinement because the peak could only support a Zinc at 10% occupancy. Sure, look at your map with a low contour level -- Just be aware that you are looking at a low contoured map. Dale Tronrud On 5/3/2022 6:32 AM, Paul Emsley wrote: On 02/05/2022 20:19, Dale Tronrud wrote: When I watch people model building I see many scrolling the contour level up and down without regard for the numeric value of the level, apparently just choosing a value that makes the peaks appear the way they prefer the peaks to appear. I recall a few years ago that Alex McPherson asked me how I chose the contour level and I said more or less this. He didn't like my answer :-). This way of choosing a contour level seems dangerous to me as it seems to bias the appearance of the map towards the modeler's expectation. I don't choose one level and don't recommend that others do so - the continuous re-contouring allow one to get a feel for where the signal descends into noise - so I am scrolling very frequently when deciding where a side-chain should go. I hum the Rawhide theme tune as I do so. Paul. To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/ To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [COOT] absolute map levels
If you view the value of the density as the number of electrons per
cubic Angstrom relative to the local average it is both accurate and
precise. This framing avoids the most serious problems with a measure
based on the rms, such as the problem that the "rms" depends on the
particular volume of space calculated (how much of the bulk solvent
region is included) and what stage of refinement is the project (late in
refinement the difference map will have a much smaller rmsd and the same
missing water molecule will have a much taller peak.).
When a map is viewed at a particular contour based on e/A^3 a
missing atom will tend to have the same difference map peak height in
all stages, while the height will vary all over the place when the
contour is based rmsd. When I watch people model building I see many
scrolling the contour level up and down without regard for the numeric
value of the level, apparently just choosing a value that makes the
peaks appear the way they prefer the peaks to appear. This way of
choosing a contour level seems dangerous to me as it seems to bias the
appearance of the map towards the modeler's expectation.
Dale Tronrud
On 5/2/2022 11:51 AM, Tim Gruene wrote:
Hi Ian,
thanks - this makes it clear(er) to me. The unit [e/A^3] suggested an
accuracy to me that isn't really there, while rmsd felt more what it
really is (maybe only due to habit and training).
Cheers,
Tim
On Mon, 2 May 2022 15:27:13 +0100
Ian Tickle wrote:
Hi Tim
I would say that it's not the displayed map density value in whatever
units that's arbitrary: it's completely defined as the true density
on an absolute scale minus the F000 contribution ('b' below) and
optionally divided by the RMS. It's just that we don't have a good
estimate of F000 and as I said it's your choice of contour level
that's arbitrary.
The Buster map is scaled to the model so is on an absolute scale. We
can write the linear transformation:
rho[map] = a.(rho[true] - b)
where the scale factor a = 1 so that rho[map] is on the same absolute
scale as rho[true] (i.e. differences in rho[true] are equal to
differences in rho[map]), and b is the F000 contribution.
Cheers
-- Ian
On Mon, 2 May 2022 at 15:04, Tim Gruene
wrote:
Hi Paul,
I'd rather you comment on the unit "e/A^3" displayed at the top of
my Coot canvas when I change the contour level of a map. Is this
arbitrary?
I noticed that the Buster Wiki states that their FWT is on an
absolute scale. Would there be a paper or url to advance my rusty
habits?
Cheers,
Tim
On Mon, 2 May 2022 13:52:05 +0100 Paul Emsley
wrote:
On 02/05/2022 12:44, John R Helliwell wrote:
I was intrigued by Paul’s 5sigma Fo-Fc default cut off, rather
than 3.
It's 5.6 now :-)
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a
mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
available at https://www.jiscmail.ac.uk/policyandsecurity/
--
--
Tim Gruene
Head of the Centre for X-ray Structure Analysis
Faculty of Chemistry
University of Vienna
Phone: +43-1-4277-70202
GPG Key ID = A46BEE1A
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a
mailing list hosted by www.jiscmail.ac.uk, terms & conditions are
available at https://www.jiscmail.ac.uk/policyandsecurity/
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1
This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list
hosted by www.jiscmail.ac.uk, terms & conditions are available at
https://www.jiscmail.ac.uk/policyandsecurity/
[COOT] Problems with "Go To Atom..." dialog box
Hi,
I wanted to get some experience with a large model so I am exploring
4YBB.
Problem 1
If I select "Fetch PDB using Accession Code..." in the file menu and
ask for 4YBB the download fails with
PDB Accession Code: 4YBB
BL WARNING:: Retrieve of url
http://www.ebi.ac.uk/pdbe-srv/view/files/4ybb.ent failed
handle_read_draw_molecule_with_recentre ("coot-download/4YBB.pdb.ent", 1)
WARNING:: Error reading coot-download/4YBB.pdb.ent
Clearly Coot is trying to download the old PDB format and not the new mmCIF.
Problem 2
I downloaded 4ybb.cif from the RCSB site and loaded it into Coot via
the "Open Coordinates..." option of the File menu. This loaded the
model into the window and I can do all the mouse stuff I expect.
I want to go to a specific location, however, so I opened the "Go To
Atom..." dialog. If I select the QA chain in the chain box, there is no
arrow to open the residue list. This seems to be the case for many RNA
chains, although some like AA and AB do work. Protein chains seem to
work fine.
Even if I enter the chain, residue number, and atom name in the
individual boxes the terminal window says that the atom cannot be found.
WARNING:: atom with name "MG" alt-loc "", res-no: 3147, ins-code "",
chain: "IN" not found in molecule 0
I have tried version 0.8.9.2 of either Coot on a CentOS 7 system or
winCoot on a Windows 8.1 system.
This model is a little large to just click around and hope to stumble
upon the place I want to look at.
Thanks for your help
Dale Tronrud
To unsubscribe from the COOT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
Re: [COOT] Map smoothening in Coot
If, as Paul says, the "smooth" map is just more finely sampled than a not smooth one, there is no doubt. The smooth map is a more accurate representation of the electron density map, which is in fact a continuous function. The sampling of a map on a grid is a computational simplification of the map. This approximation is made for the convenience of the computer software. I presume that Coot's real space refinement includes corrections for the course size of the grid, but such corrections usually assume that the variation of the map function between grid points is linear. The finer the grid the more accurate these corrections will be. Paul knows the properties of his software so he is the best source for the effect of grid size on the real space refinement software and his default sampling rate will be good enough, but a finer grid can't hurt other than slowing the calculation. Dale Tronrud On 11/20/2019 11:36 AM, Daniel Larsson wrote: > Hi Karim, > > If in doubt, you can load both maps and use the original one for > refinement but hiding it and use the smooth map for visualization. > > Regards, > Daniel > > >> On 20 Nov 2019, at 14:28, Karim Rafie > <mailto:karim.ra...@umu.se>> wrote: >> >> Dear all, >> >> I have a question regarding the map smoothening option in coot >> (Calculate -> Map Tools -> Make a (very) smooth copy). If I understand >> correctly, the Shannon sampling factor applied by default is 1.5 and >> that the smoothening process adjusts that factor. >> Does that have any effect on the validity of the map, i.e. can I still >> use it for model builduing or will it "smoothen-out" possibly >> important data? >> >> Any help would be greatly appreciated. >> >> Best wishes, >> Karim >> ## >> Karim Rafie; PhD, AMRSC >> Postdoctoral Research Fellow >> Carlson Lab >> Department of Medical Biochemistry and Biophysics >> Umeå University >> Umeå / Sweden >> >> >> To unsubscribe from the COOT list, click the following link: >> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1 > > Page Title > > > > > > > > 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 COOT list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1 > To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
Re: [COOT] pdb file problem with duplicate amino acid
On 1/31/2017 11:51 AM, Paul Emsley wrote: > On 31/01/17 17:54, Edwin Pozharski wrote: >> Whatever the rationale was, there is a structure in the PDB that has >> alternate conformer of a residue listed with different residue type - >> A is arginine and B is glutamine. Coot fails to load the model >> complaining in the command window >> >> WARNING:: Error reading small-molecule cif "/home/epo/coot/foo.pdb" >> There was an error reading /home/epo/coot/foo.pdb. >> ERROR 42 READ: Duplicate sequence number and insertion code. >> LINE #1571 >> ATOM 1666 N BGLN B 93 24.448 28.340 -33.325 0.50 >> 9.34 N >> >> No Spacegroup found for this PDB file >> There was a coordinates read error >> > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1503=COOT===25056 > > Paul. I think this is a poor solution. Microheterogeneity is not a duplicate residue number. Not any more so than the alternative conformation that is also indicated with "alt loc" letters. Both come up quite often in the PDB, and microheterogeneity probably should be put in models more often than it currently is. May modelers simply don't realize it is a possibility. Your users rarely going to know about the need to put this option into their startup file. Dale
Re: [COOT] pdb file problem with duplicate amino acid
This is an occurrence of microheterogeneity and it is not all that uncommon. See Crambin as a classic prototype. Coot should be able to handle this. The work-around you suggest creates a very different model. Residue 93A lies between 93 and 94 so you are actually inserting an entire residue into the chain. Dale Tronrud On 1/31/2017 9:54 AM, Edwin Pozharski wrote: > Whatever the rationale was, there is a structure in the PDB that has > alternate conformer of a residue listed with different residue type - A > is arginine and B is glutamine. Coot fails to load the model > complaining in the command window > > WARNING:: Error reading small-molecule cif "/home/epo/coot/foo.pdb" > There was an error reading /home/epo/coot/foo.pdb. > ERROR 42 READ: Duplicate sequence number and insertion code. > LINE #1571 > ATOM 1666 N BGLN B 93 24.448 28.340 -33.325 0.50 > 9.34 N > > No Spacegroup found for this PDB file > There was a coordinates read error > > > One way to deal with it is to take the second conformer and manually add > a sequence modifier (make it 93A), and that pdb file loads just fine. > > This is observed with Coot-0.8.8-pre, rev.6506. > > This is only a minor nuisance, of course, so I completely understand if > no fix is made to load such strange models. > > Cheers, > > Ed. > > --- > Coot verendus est > >
[COOT] Bugs related to insertion codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Happy New Year, I have been comparing the two PDB entries 2EWD and 4ND2 to try to figure out why the older was replaced by the latter. This task is surprising hard with Coot, but that is not my issue. When I SSM superimposed the A chain from each model a potion of the text printed to the terminal was confusing. (sorry but I can't figure out how to cut from a DOS window so I've attached a screen shot.) You will note that residue 208 matches 208 and 209 matches 209 but then 209 matches 209 again and then 210 matches 209 and then again 210 matches 209. The answer to this riddle is that on the left there really should be 209A, 209B, 210A, and 210B while on the right it should be 209 A through D and 210A and 210B. The SSM code is not writing the insertion codes to the output. A second issue becomes apparent when I open the Go To Atom... dialog box and select 2ewd!A|209A. All four 209 residues are properly shown in the residue table. The atom table, however shows the atoms for all four 209 residues. This table is identical when each of the 209 residues are selected. If I select 209A and double-click on the fourth CA atom I am, indeed, taken to 209D. Dale Tronrud -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlSnI7QACgkQU5C0gGfAG11ZyQCfXUIo8Jh5t9NzlUEKb42E5yrR liUAoJatGSTMU5tLZBp1DkTx7cUhgCKL =qsBa -END PGP SIGNATURE-
Re: [COOT] truncate/modify a MTZ file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Your question is vague so I will try to guess what you want. First, an MTZ file is just a container for data in reciprocal space. It can contain intensities (merged or unmerged), amplitudes, sigmas, phases, figure-of-merits, Hendrickson-Lattman coefficients, flags, or pretty much anything that is described by hkl. It does not contain maps or coordinates because they are real space items described by xyz. One use of the MTZ format is to contain amplitudes and phases which, when Fourier Transformed, become a map. You can't just say I have an MTZ file and expect someone to know what that file contains. Now we come to your Q1. Since I don't know what your MTZ file contains, and MTZ files cannot contain atoms I'm not sure what you want. One possibility is that your MTZ contains the amplitudes and phases of an electron density map and you want to mask out all the density except for that close to a backbone atom. That can be done, but it is complicated and I don't want to attempt to explain it without knowing for sure that is what you want. Since you are feeding a PDB file that contains only backbone atoms into Refmac hoping for a map, perhaps you just want a calculated electron density map for your backbone atoms. This can be done with the CCP4 program SFALL. I'm looking at www.ccp4.ac.uk/html/sfall.html#files_generate_atom_map It looks like Example 6 does what you want. You only want to run REFMAC is you want a complicated map like mFo-DFc or 2mFo-DFc which are difference maps used to evaluate a model during refinement. If you just want to calculate a map from coordinates, or structure factors from either a map or coordinates SFALL does the trick. If you really want to take an existing map and mask out certain features, that's a different kettle of fish. Dale Tronrud On 5/29/2014 2:20 PM, George Devaniranjan wrote: Hi, This is really 2 questions, one related to the other coming from someone who is just starting to learn/use CCP4/COOT so this question might sound rather naive. Q1) I have a MTZ file and I want to generate a another MTZ from it but limited to the backbone atoms only. (Similar to FFT with all atoms in PDB file) but I need a MTZ file since I want to use the map sharpening tool (B factor attenuation) in COOT. I tried using REFMAC with the input PDB only having the backbone atoms but it fails due to the inconsistency between the input MTZ and input PDB. Any other way I can generate a truncated MTZ? Q2) Once I use the map sharpen tool, could I save (as MTZ ) the new sharpened map? Thank you. George -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOHr8sACgkQU5C0gGfAG12QTwCfQVcEMCc8GlZlPLkDBGhYizQE p2sAniirY6S7RqJ0ae9PhVokAPr9XWfT =CMOz -END PGP SIGNATURE-
Re: [COOT] truncate/modify a MTZ file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 And here is the problem. Coot sharpens maps. The process has nothing to do with atoms. I still don't understand the question. Dale On 5/29/2014 3:17 PM, George Devaniranjan wrote: Thank you for your reply, Dale. Let me rephrase the question: Essentially I want to use COOT's Calculate--map sharpening but only use the backbone atoms in the process. On Thu, May 29, 2014 at 6:08 PM, Dale Tronrud de...@daletronrud.com mailto:de...@daletronrud.com wrote: Hi, Your question is vague so I will try to guess what you want. First, an MTZ file is just a container for data in reciprocal space. It can contain intensities (merged or unmerged), amplitudes, sigmas, phases, figure-of-merits, Hendrickson-Lattman coefficients, flags, or pretty much anything that is described by hkl. It does not contain maps or coordinates because they are real space items described by xyz. One use of the MTZ format is to contain amplitudes and phases which, when Fourier Transformed, become a map. You can't just say I have an MTZ file and expect someone to know what that file contains. Now we come to your Q1. Since I don't know what your MTZ file contains, and MTZ files cannot contain atoms I'm not sure what you want. One possibility is that your MTZ contains the amplitudes and phases of an electron density map and you want to mask out all the density except for that close to a backbone atom. That can be done, but it is complicated and I don't want to attempt to explain it without knowing for sure that is what you want. Since you are feeding a PDB file that contains only backbone atoms into Refmac hoping for a map, perhaps you just want a calculated electron density map for your backbone atoms. This can be done with the CCP4 program SFALL. I'm looking at www.ccp4.ac.uk/html/sfall.html#files_generate_atom_map http://www.ccp4.ac.uk/html/sfall.html#files_generate_atom_map It looks like Example 6 does what you want. You only want to run REFMAC is you want a complicated map like mFo-DFc or 2mFo-DFc which are difference maps used to evaluate a model during refinement. If you just want to calculate a map from coordinates, or structure factors from either a map or coordinates SFALL does the trick. If you really want to take an existing map and mask out certain features, that's a different kettle of fish. Dale Tronrud On 5/29/2014 2:20 PM, George Devaniranjan wrote: Hi, This is really 2 questions, one related to the other coming from someone who is just starting to learn/use CCP4/COOT so this question might sound rather naive. Q1) I have a MTZ file and I want to generate a another MTZ from it but limited to the backbone atoms only. (Similar to FFT with all atoms in PDB file) but I need a MTZ file since I want to use the map sharpening tool (B factor attenuation) in COOT. I tried using REFMAC with the input PDB only having the backbone atoms but it fails due to the inconsistency between the input MTZ and input PDB. Any other way I can generate a truncated MTZ? Q2) Once I use the map sharpen tool, could I save (as MTZ ) the new sharpened map? Thank you. George -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOHszoACgkQU5C0gGfAG10olACdGxDCDaDI6jbaFXwCnYtc9xnO XkgAnjuoRavrGJW3FQHYfDrDuhp+qAwR =NRFM -END PGP SIGNATURE-
[COOT] Coot Performance on Intel HD Graphics 5000
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, My lab desktop PC broke and I'm looking into replacements. Being tired of the enormous tower (full of air) occupying much of my desk I looking at systems like the Intel NUC. These systems are too small for video cards so I'd be working with the integrated Intel graphics. Is the 5000 version of their graphics good enough for Coot to work nice? I am not interested in stereo. Dale Tronrud -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM0bRwACgkQU5C0gGfAG11raACgrYltSYvIbVrVVLHxMfMPgfyn MJEAn1i2cUEedyXeYOtjIAw7HvAB2qeL =YIfi -END PGP SIGNATURE-
[COOT] Downloading Coot
I was looking for the download site for Coot but the links have have found point to http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/ but there is nothing there. Where do I go to find prebuilt coot binaries? Dale Tronrud
Re: [COOT] Downloading Coot
Very nice wiki but it points back to the same, empty, directories. Dale On 09/03/2013 01:08 PM, Bosch, Juergen wrote: http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT#Installing_Coot_on_Linux Jürgen On Sep 3, 2013, at 4:04 PM, Dale Tronrud wrote: I was looking for the download site for Coot but the links have have found point to http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/ but there is nothing there. Where do I go to find prebuilt coot binaries? Dale Tronrud .. 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://lupo.jhsph.edu
Re: [COOT] Downloading Coot
We seem to be having a communications problem. I have looked in http://www2.mrc-lmb.cam.ac.uk/Personal/pemsley/coot/binaries/, there is nothing there under release. pre-release has a few files but not a variety of distributions. This location appears to be broken. Dale Tronrud On 09/03/2013 01:59 PM, William G. Scott wrote: On Sep 3, 2013, at 1:04 PM, Dale Tronrud det...@uoxray.uoregon.edu wrote: I was looking for the download site for Coot but the links have have found point to http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/ but there is nothing there. Where do I go to find prebuilt coot binaries? Dale Tronrud Paul's binaries are here: http://www2.mrc-lmb.cam.ac.uk/Personal/pemsley/coot/binaries/ OS X ones I built are here: http://scottlab.ucsc.edu/~wgscott/xtal/wiki/index.php/Stand-Alone_Coot Source code is here: http://www2.mrc-lmb.cam.ac.uk/Personal/pemsley/coot/source/ Windows version is here: http://www.ysbl.york.ac.uk/~lohkamp/coot/
[COOT] Error in Chiral Centers in bacteriopheophytin a (BPH)
It was just pointed out to me that there is an error in the cif in Coot for BPH. The two chiral centers in the phytol tail, C8 and C13, are inverted. I'm including a cif with the correct definitions. As an example you can check out the BPH residues in 2J8C. These chiral centers are correct in the model, but Coot will invert them. Oddly enough the matching chiral centers in this model's BCL molecules are wrong but Coot fixes them. In Coot BCL is correct, BPH is not. I'll have to check all the chlorophyll-like molecule definitions in Coot but it will take me a bit of time. Bad chiral centers are endemic for chlorophyll molecules in the PDB so it is very hard to be sure you are looking at something that makes sense. What I'm sure of is that the chiral centers of the BCL's in 3EOJ are correct. It's based on 1.3 A X-ray data and you don't need chiral restraints. Since all phytol tails are the same you can compare any chlorophyll-like molecule to the tails in this model to see if you are correct. Dale Tronrud bph-med-res-v030.cif Description: CIF chemical test
Re: [COOT] map level
On 01/17/12 06:18, Ian Tickle wrote:
On 17 January 2012 12:43, Paul Emsley paul.ems...@bioch.ox.ac.uk wrote:
On 17/01/12 08:33, Dayana Nisbar wrote:
How to change the map level from rmsd to sigma?
You can't. Electron density levels should not be expressed in terms of
sigma. Sigma refers to probability distributions - and an electron density
map is not one of those. I used to not understand this and there may be
some references to sigma in the code/interface which I need to clean up.
But an electron density, being an experimentally determined quantity,
has an error and an error certainly does have a probability
distribution. The standard deviation of that error distribution,
which is not the same as and should not be confused with the RMSD, is
what I assume is here being referred to as 'sigma'. The RMSD would be
the s.d. if the electron density were to be treated as a probability
density function (which I agree it isn't); however this pseudo-PDF is
not in any case relevant to the discussion because what we are
concerned about here is the error distribution (characterised by
sigma), not the electron density distribution (characterised by the
RMSD).
When we are judging significance of the (difference) electron density
the relevant statistic is the signal/noise ratio (delta-)rho/sigma,
analogous to I/sigma for the diffraction data (no-one would think of
expressing I in terms of its RMSD!). The s.d. (sigma) of the
difference density can be estimated from a Q-Q ('normal probability')
plot. (Delta-)rho/RMSD has no meaning in terms of significance (it
has no meaning period), so electron densities should not expressed in
terms of RMSD, unless you can legitimately claim that the RMSD is a
good estimate of the s.d., which means that you are really expressing
it in terms of sigma. Also it begs the question how accurate an
estimate of the s.d. is the RMSD? and is a more accurate estimate
available?.
Your point is correct, Ian, but you are ignoring the problem that
in our field the terms rmsd and sigma are considered synonyms when
it comes to maps. In nearly every case where the word sigma is used
the intent is not the sigma that you describe (quite correctly) but
simply the rmsd of the map. First we have to stomp out this nonsense
of saying we are contouring a difference map at +/-3 sigma when we
mean +/-3 rmsd and then we can discuss the fact that contouring in
rmsds is not the right thing to do. Appropriating the word sigma
merely gives the illusion that some sort of statistics is being done.
Dale Tronrud
Cheers
-- Ian
Cheers
-- Ian
[COOT] Sigma levels of ncs averaged maps
Hi, I have a crystal structure at 3A resolution with six copies in the asu. When I average the map over the ncs I find that the original 2Fo-Fc style map has a sigma of 1.5 at 0.3 e/A^3. When I adjust the contour level of the averaged map to match, by eye, the level of the unaveraged map I find them equivalent at a sigma of 2.6 at 0.28 e/A^3. These results imply that the sigma level of the original map was 0.2 e/A^3 and the averaged map was 0.11 e/A^3. The sigma of a 2Fo-Fc style map is not an estimate of uncertainty, of course, because nearly everything in the map is signal. It is just a measure of the variability of the signal, i.e. the rms. With averaging the signal should be preserved and the noise reduced, but the noise of a 2Fo-Fc map is small compared to the signal. How is it that the rms of my averaged map drops to half of the unaveraged value and yet the electron density looks about the same when contoured at the same e/A^3 (0.3 vrs 0.28)? I guess the real question is, how does Coot calculate the sigma of an averaged map? You can't calculate the rms over the asymmetric unit because the asymmetric unit is many millions of unit cells in size (and hugely variable depending on small changes in the ncs operators). The problem at hand is that I want to quote the sigma level I insisted upon when creating water molecules and think it will sound weird if I say I used a value of 12, which I did. The numbers just don't seem right to me so I'd like a little reassurance. Dale Tronrud
Re: [COOT] Sigma levels of ncs averaged maps
Thanks Paul, I don't know of a perfect solution to the question of rms for an ncs averaged map. Knowing your imperfect solution clarifies the results I'm seeing and that helps a lot. I guess I'm seeing greater anomalies than others because I have 6-fold ncs and 50% solvent. I take it that each copy of the map ends up being surrounded by a large number of zeros. Dale On 12/22/2010 6:38 PM, Paul Emsley wrote: When creating an NCS average map, Coot draws a box around the chain of interest and averages the map inside that. Everywhere else is set to 0. So inside the box, yes, one might expect the rms value to be a small amount larger (considering points inside the box). However, most of the ASU is set to 0, so overall, the rms of the average map will be considerably less. Bottom line is that y.y is difficult to calculate unless you cut the map back to the box values - I suppose that the output of Coot and mapmask would help there, although for clarity you would have to explain how sigma is derived (it is often opaque, it seems to me). Paul. On 22/12/10 23:37, Dale Tronrud wrote: The 12 sigma I want to put in the paper is from the Fo-Fc map where the rms is more comparable to a sigma. You are right that e/A^3 is the best units for describing density but for my water creation criteria I would like to say higher than x.xx e/A^3 in the difference map which is y.y sigma. I would never attempt to ascribe statistical meaning to the rms of a 2Fo-Fc map. I chose to describe my confusion about its calculation in Coot for ncs averaged maps because I could describe my puzzlement more easily. With a Fo-Fc style map you expect the sigma of the peaks to get bigger after averaging and you have to argue how much larger is plausible. For a 2Fo-Fc style map the density should not get much higher, in terms of rms, with averaging and yet in Coot it does. My guess is that the calculation is done the same way for both types of maps. Dale On 12/22/10 15:08, Phil Evans wrote: Why do you want to quote sigma level anyway? It's more or less meaningless for the reasons you give. Stick to e/A^3 /flame Phil On 22 Dec 2010, at 22:02, Dale Tronrud wrote: Hi, I have a crystal structure at 3A resolution with six copies in the asu. When I average the map over the ncs I find that the original 2Fo-Fc style map has a sigma of 1.5 at 0.3 e/A^3. When I adjust the contour level of the averaged map to match, by eye, the level of the unaveraged map I find them equivalent at a sigma of 2.6 at 0.28 e/A^3. These results imply that the sigma level of the original map was 0.2 e/A^3 and the averaged map was 0.11 e/A^3. The sigma of a 2Fo-Fc style map is not an estimate of uncertainty, of course, because nearly everything in the map is signal. It is just a measure of the variability of the signal, i.e. the rms. With averaging the signal should be preserved and the noise reduced, but the noise of a 2Fo-Fc map is small compared to the signal. How is it that the rms of my averaged map drops to half of the unaveraged value and yet the electron density looks about the same when contoured at the same e/A^3 (0.3 vrs 0.28)? I guess the real question is, how does Coot calculate the sigma of an averaged map? You can't calculate the rms over the asymmetric unit because the asymmetric unit is many millions of unit cells in size (and hugely variable depending on small changes in the ncs operators). The problem at hand is that I want to quote the sigma level I insisted upon when creating water molecules and think it will sound weird if I say I used a value of 12, which I did. The numbers just don't seem right to me so I'd like a little reassurance. Dale Tronrud
Re: [COOT] opening PDB downloaded .cif files in Mac OS
It would be helpful if you said exactly what kind of CIF you have. The CIFs from the PDB-RCSB only contain observed structure factors or intensities. If you want a map you have to go to the Electron Density Server. Dale Tronrud subh wrote: Hi, I am trying to open the .cif file (in coot) that I downloaded from PDB, in my Mac OS X. Coot cannot open the map. Could you suggest how I can see the map that is downloaded form the PDB-RCSB web site. Thanks, Subh
Re: [COOT] deleting atoms from alternate conformations
Paul Emsley wrote: wtempel wrote: Hi all, judging from what I see being used by my colleagues, COOT is well on its way to world domination. Like Linux (haha). Anyway, suppose I have split a residue, say lysyl, to model alternate conformations of its side chain. Suppose further that I would like to remove NZ from conformer B. Upon doing so, the current COOT implementation will remove the atom. Good. It will also remove the confID from what was conformer A's NZ atom and re-set its occupancy to 1. On the latter part, intuition tells me that instead, conformer A's atoms should be unaffected, namely keep their confID and sub-unity occupancy. My questions: 1) What behavior is expected by other COOT users in comparable situations? Would the answer be different if a C or an O had been deleted? I'd rather ask: is Coot doing the right thing in such a case? I suspect that Garib or Pavel may know. My problem is that I agree with the original poster that the remaining NZ atom should continue with a confID of A, but I also agree with Paul that the deleted C atom should be changed to a single conformation. However, if the residue that the C atom is linked to is also split I would feel differently. In my favorite structure there is a stretch of five residues where the main chain has two conformation. If I deleted a C atom from the B conformer in the middle it would not be my intention to have only a single conformation for that atom. How about this suggestion? If the deleted atom is bonded to an atom with a single conformation then the other conformer becomes a single conformation. If the deleted atom makes bonds only with atoms that also have alternative conformations then the remaining atom retains its partial occupancy. This would keep the poster happy, keep Paul happy with his C atom when the neighbor has a single conformation, and will keep me happy when there is a stretch of main chain disorder. A problem with this scheme occurs with the lysine mentioned before. If the user decides to delete the entire B conformation one atom at a time the result will differ depending on the end of the side chain they start deleting atoms from. I don't know if this is a serious problem, or even a problem at all. Dale Tronrud 2) Should a few folks align themselves with my opinion, can COOT's behavior be modified without unintended side effects? Yes. Specifically, I like COOT's current behavior when Delete Residue is applied to alternative conformations: Delete the conformer completely and set the remaining conformer's atoms to Occ=1 and remove the confID. I think that that is just doing the above for many atoms. Paul.
[COOT] Residue Density Fit
Hi, I am looking at the residue density fits in my protein, but am not sure what these numbers actually are. They are not real space R factors because higher is better, but they are not correlation coefficients because some are greater than one. I have checked the documentation for Coot but have not found a definition. Your help will be appreciated. Dale Tronrud
