Re: [COOT] stereochemical violations in real space refinement?

[Sheriff, Steven]

Francis:



When I had a similar issue, Paul told me that one had to mutate a residue to be 
sure that the stereochemistry is correct.  Moreover, as of the last time I 
checked with Paul, COOT does look at the chiral volumes for pseudo-chiral 
centers such as Leu and Val, so it is no surprise that COOT doesn't catch it.



Try either Simple Mutate or Mutate & Auto Fit ...



Steven



>-Original Message-

>From: Mailing list for users of COOT Crystallographic Software

>[mailto:c...@jiscmail.ac.uk] On Behalf Of Francis E Reyes

>Sent: Thursday, March 05, 2009 6:36 PM

>To: COOT@JISCMAIL.AC.UK

>Subject: Re: stereochemical violations in real space refinement?

>

>Actually i just checked my structure with the Validate -> Incorrect

>Chiral Volumes. It seems to check out OK, but the PDB doesn't like it?

>Anyone?

>

>thanks

>FR

>On Mar 5, 2009, at 4:25 PM, Francis E Reyes wrote:

>

>> Hi all,

>>

>> Just tried to submit a PDB and it seems that LEU is not correctly

>> positioned (CG/CD1,CD2). I real space refined this residue, does the

>> real space refinement take into account stereochemical considerations?

>>

>> Thanks

>> FR

>>

>> -

>> Francis Reyes M.Sc.

>> 215 UCB

>> University of Colorado at Boulder

>>

>> gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D

>>

>> 8AE2 F2F4 90F7 9640 28BC  686F 78FD 6669 67BA 8D5D

>

>-

>Francis Reyes M.Sc.

>215 UCB

>University of Colorado at Boulder

>

>gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D

>

>8AE2 F2F4 90F7 9640 28BC  686F 78FD 6669 67BA 8D5D

Re: [COOT] Updating measured distance/angle

[Sheriff, Steven]

Andy:



To get Dynamic Distance to work, one first has to activate part of the molecule 
to be movable, e.g. with Rotate/Translate Zone.  Then go to Measures->Distance 
& Angles...->Dynamic Distance and click on two atoms, one of which must be in 
the movable part of the molecule.  Surprisingly, I don't think the order 
matters.  You may choose additional Dynamic Distances, by click on Dynamic 
Distance again and then two atoms.



Steven



>-Original Message-

>From: Mailing list for users of COOT Crystallographic Software

>[mailto:c...@jiscmail.ac.uk] On Behalf Of Andy Torelli

>Sent: Tuesday, March 31, 2009 10:44 AM

>To: COOT@JISCMAIL.AC.UK

>Subject: Updating measured distance/angle

>

>Hello everyone,

>

> I'm wondering if it's possible to configure COOT to update

>distances/angles automatically when atoms are moved.  I read a 2007

>COOTbb post indicating this would be implemented as "dynamic distances"

>in the 0.5 release, however I'm running 0.5.2 and I can't seem to get

>the "dynamic distances" button in the geometry menu to do anything.  So

>far I haven't found the right information in the manual.  The Jan. 2008

>COOT 0.4 announcement post to the bb says that Dynamic Distances are

>"distances to intermediate atoms", but I'm not sure what that means.

>Any insight would be greatly appreciated.

>

>Best Regards,

>-Andy Torelli

>--

>

>=

>Andrew T. Torelli Ph.D.

>Postdoctoral Associate

>Laboratory of Steven E. Ealick

>Department of Chemistry and Chemical Biology

>Cornell University

>=

Re: [COOT] deleting coot backup directories

[Sheriff, Steven]

Simon:



If you want to get rid of all the files, why not get rid of the coot-backup 
directories?  In which case, it should be simple:



find . -name "coot-backup" -print -exec /bin/rm {} \;



where the "dot" following the find will start from wherever you currently are, 
but you could specify the directory to start in.



If COOT doesn't lead such long names, I would opt for something like 
2009_04_24_13:15:01-1650.pdb, which will cause ls to list the files in time 
order, which would be useful.



Steven



>-Original Message-

>From: Mailing list for users of COOT Crystallographic Software

>[mailto:c...@jiscmail.ac.uk] On Behalf Of Simon Kolstoe

>Sent: Friday, April 24, 2009 11:52 AM

>To: COOT@JISCMAIL.AC.UK

>Subject: deleting coot backup directories

>

>Dear Cootbb,

>

>As I am a crystallographer and not a programmer, could anyone suggest

>a bash script that will go through my hard drive deleting all the

>pesky "coot-backup" directories with their horribly long file names

>that zipping software cannot cope with? Also, in a future version of

>coot, would it be possible to change the names of the coot-backup

>files to something simpler e.g. just date and time (for instance

>something like 240409-1650.pdb)?

>

>Thanks,

>

>Simon

Re: [COOT] MSE

[Sheriff, Steven]

Phil:



Paul or the people who know what is really going under the hood in COOT can 
tell you more.  However, my understanding is that COOT uses distances to draw 
bonds and the Se atom in the MSE residue must be outside of that radius.  I 
have occasionally, although not recently, seen this phenomena with the s atom 
in MET.



Steven



>-Original Message-

>From: Mailing list for users of COOT Crystallographic Software

>[mailto:c...@jiscmail.ac.uk] On Behalf Of Phil Evans

>Sent: Friday, March 19, 2010 7:24 AM

>To: COOT@JISCMAIL.AC.UK

>Subject: MSE

>

>When Coot displays an MSE residue after refmac, it doesn't join up the

>Se atom to the atoms on either side (they appear as crosses). If I RS-

>refine it in coot, the bonds are drawn. Comparing MSE.cif from the

>refmac library & the Coot library, they are identical.

>

>What's going on? Do other people see this?

>

>Phil


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] simplify CA->Mainchain selection [was Re: a request]

[Sheriff, Steven]

Paul:



Dirk's is a great idea.  I had been wishing that COOT would at least ask if the 
residue was a Gly or Pro, but at least with good side chain density the real 
space positioning might work better and choose the proper path for the main 
chain and side chain.



Steven



>-Original Message-

>From: Mailing list for users of COOT Crystallographic Software

>[mailto:c...@jiscmail.ac.uk] On Behalf Of Dirk Kostrewa

>Sent: Friday, March 26, 2010 10:19 AM

>To: COOT@JISCMAIL.AC.UK

>Subject: Re: simplify CA->Mainchain selection [was Re: a request]

>

>Dear Paul,

>

>another point for your wish-list: when I add a terminal residue, an

>alanine is added that I have to mutate into the proper amino acid type

>in a second step. I would find it very useful, if a popup-window would

>ask me, which amino acid type I want to add. This would have two

>advantages: I don't have to mutate the amino acid afterwards, and,

>maybe, the real space positioning would be even better.

>

>Best regards,

>

>Dirk.

>

>Am 25.03.10 17:24, schrieb Kevin Cowtan:

>> Paul Emsley wrote:

>>> Eleanor Dodson wrote:

 When converting from CA to Main chain it would be wonderful to just

 have to select a CHAIN - not click on the first and last residues..

 In that I cant think of any time when you would want to only convert

 a limited span of residues..

>>>

>>> On reflection, I agree with you and will schedule this for

>>> implementation.

>>

>> Hmmm... perhaps something paralleling the A-key usage.

>>

>> Click RSR zone (or whatever).

>> Hit the key - whole chain is selected.

>>

>> Maybe another key to pop up a GUI to select residue range for the

>> clicked chain.

>

>--

>

>***

>Dirk Kostrewa

>Gene Center, A 5.07

>Ludwig-Maximilians-University

>Feodor-Lynen-Str. 25

>81377 Munich

>Germany

>Phone: +49-89-2180-76845

>Fax:   +49-89-2180-76999

>E-mail:kostr...@genzentrum.lmu.de

>WWW: www.genzentrum.lmu.de

>***


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] centering at xyz

[Sheriff, Steven]

Tim:

Calculate->Scripting[->Scheme]
(set-rotation-centre x y z)

Used to work at least before the choice of Python or Scheme, but when I just 
tried it, 0.6.2.-pre-1-revision-3237 crashed before it presented a scripting 
window.

Steven

>-Original Message-
>From: Mailing list for users of COOT Crystallographic Software
>[mailto:c...@jiscmail.ac.uk] On Behalf Of Tim Gruene
>Sent: Monday, December 06, 2010 9:44 AM
>To: COOT@JISCMAIL.AC.UK
>Subject: centering at xyz
>
>Hello,
>
>I am looking for the command to centre at some given coordinates,
>corresponding to the centre_xyz command in O.
>
>Cheers, Tim
>--
>--
>Tim Gruene
>Institut fuer anorganische Chemie
>Tammannstr. 4
>D-37077 Goettingen
>
>phone: +49 (0)551 39 22149
>
>GPG Key ID = A46BEE1A


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] New restraints, same name

[Sheriff, Steven]

All:

At BMS, we use the same ligand identifier, e.g. LG1, for all compounds that 
bind at overlapping sites. If we have multiple compounds bound in a single 
structure, i.e. non-overlapping sites, then we would use LG2, etc. for them.  
Using a common naming system makes it easy for upstream and downstream programs 
and users to know what to look for. So, if I want to compare two proprietary 
structures in COOT pre-0.7, then something along the lines that Paul suggests 
is the easiest way to deal with this.  Otherwise I have to modify both the PDB 
file and relevant CIF restraint file. Someday some of these structures do end 
up in the wwPDB and they do a good job of disambiguating them and assigning 
unique 3-character identifiers (BTW, the PDB as far as I know is still using 
only capital letters, so this translates into only 36**3 (46656) unique 
3-character names of which >8000 have been assigned as of the last time I paid 
attention).

And, yes, companies do have unique "names" for their compounds. At BMS, they 
consist of 9 characters, but I have seen other companies naming schemes use 11 
characters.  Neither of which is easily translated into 3 characters.

Steven

From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Seth Harris
Sent: Tuesday, January 24, 2012 4:53 PM
To: COOT@JISCMAIL.AC.UK
Subject: Re: New restraints, same name

Hi all,

Working in industry, we do end up with conventions that just give a generic 
name to whatever small molecule happens to be in that structure, typically LIG 
or DRG or XXX, e.g.. Makes it easy to navigate solved structures en masse 
without having to figure out what arbitrary name it has in structure X vs Y vs 
Z and the benefits of the convention outweigh the potential drawbacks, so far. 
Generally I don't find conflict between different structures because at that 
stage I'm done with refinement and the viewer programs don't care about the 
restraint dictionaries. I'm assuming coot can still draw the atoms based on 
coordinates and only creates the tangles if you try to refine those with the 
restraints, yes??
So then the issue of multiple small molecules in one structure, Carsten's point 
is spot on for me as well, where there's no point in having a coot-specific 
solution since the other refinement packages are going to choke as soon as you 
have two different ligands sharing the residue name so you might as well fix it 
on the pdb side. I think Paul's original question was really around the issue 
of loading two separate structures which have a common residue name identifier 
despite being different chemical entities. I guess I am wondering more and more 
about the opening statement of "Now that Coot uses the restraints dictionary to 
render ligands..." as i have not kept up with the latest...Nonetheless for my 
particular workflow I have scripts that launch an instance of Coot with a given 
structure and maps and it is rare that I bring in a second one. If I did, and 
Coot is going to not display the ligand correctly because its name is already 
taken then true it would be handy if Coot could sort this out and keep the 
separate restraints definitions appropriately sorted by molecule number of some 
internal identifier. If the molecules look fine and it's only when one attempts 
real space refinement or such that it would get scrambled (current behavior in 
my admittedly-not-the-most-recent version of Coot, 0.6.1) then I wouldn't 
bother as that situation is rare for me (and I imagine for others(?)) and I 
agree with the votes that the fix should be on the user to sort out. Perhaps 
Paul you can clarify if we're talking even simple display is affected or just 
refinement operations as past?

On a side note, during yesterday's run by the bay here I passed a grazing flock 
or two of what must surely have been coots given their striking resemblance to 
the splash screen icon. Watching my step, I can attest that there is certainly 
quite a mess in their internals, but I imagine Paul's coot is better kept...!

Cheers,
Seth

On Tue, Jan 24, 2012 at 12:46 PM, Ed Pozharski 
mailto:epozh...@umaryland.edu>> wrote:
On Tue, 2012-01-24 at 15:26 -0500, Kendall Nettles wrote:
> That didn't come out right. What I meant to say was that he are often
> comparing structures from a series of closely related compounds.
But isn't it true that non-identical compounds should have different
names?  Paul also refers to refinement (i.e. when dictionary is needed),
not comparison (the latter should be fine with identical names).

Cheers,

Ed.

--
Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
   Julian, King of Lemurs



This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you

Re: [COOT] New restraints, same name

[Sheriff, Steven]

All:

Although I also like Dale's idea of paying attention to HETNAM records, I think 
we should stay in concordance with PDB rules and use HETNAM records only for 
IUPAC names.  Fortunately, the PDB also has HETSYN records and that is where we 
place the BMS name (number) of a compound when we store the coordinates for 
internal use.  The PDB also uses HETSYN records for this type of information. 
Currently, we add this information only at time we store coordinates in our 
internal database, but no reason exists that we couldn't do so earlier. I am 
reasonably certain GlobalPhasing, Ltd.'s BUSTER refinement program would carry 
this along and retain it in the output PDB file (input to COOT), but I can't 
speak to what REFMAC or PHENIX.REFINE would do.  Here is an example, based, 
with a little poetic license, on PDB entry 1Z6E:

HETNAM IK8 1-(3-AMINO-1,2-BENZISOXAZOL-5-YL)-N-(4-{2-
HETNAM   2 IK8  [(DIMETHYLAMINO)METHYL]-1H-IMIDAZOL-1-YL}-2-
HETNAM   3 IK8  FLUOROPHENYL)-3-(TRIFLUOROMETHYL)-1H-PYRAZOLE-5-
HETNAM   4 IK8  CARBOXAMIDE
HETSYN IK8 BMS-561389

[BMS does publish compound numbers for molecules that enter clinical trials, 
whence my ability to use it here. The poetic license consists of removing the 
other information in the HETSYN records, which are a different IUPAC name 
(IUPAC names are not unique), the generic name of the compound (RAZAXABAN), and 
another numeric designation for the compound (DPC906).]
[Of course, as explained in my previous email, for internal storage, we would 
use the identifier LG1 rather than the IK8 used in entry 1Z6E].

If it is very little work for Paul to implement the connection between a 
compound ID and a particular CIF restraint file, then that makes this an 
extremely attractive solution.

However, I don't understand without embedding the compound number in the CIF 
restraint file, how you are going to connect a particular CIF restraint file 
with a particular ligand, when one has multiple CIF restraint files that all 
use the same residue code.

I will note that GlobalPhasing Ltd's GRADE CIF restraint file generator, GRADE, 
does embed the name of the input file in its "header" records.  Since GRADE 
prefers MOL2 files, although it accepts SMILES strings, which would defeat 
this, and other formats.  In GRADE's earliest days, GPhL recommended SMILES 
strings and that is what is embedded in the "header" records of those CIF 
restraint files. Using the example above and my current scripts that would look 
like: bms561389.mol2, i.e. the line currently looks like:

# GEN: Generated by GRADE 1.1.1 from mol2 file bms561389.mol2 using mogul+qm

However, if you needed the dash and/or CAPITAL letters for easy comparison, I 
could change my scripts accordingly.

You asked about molecular modeling software.  I have very limited experience 
with various packages, knowing only enough to invert chiral centers when our 
corporate database serves up the "wrong" hand for racemic mixtures or 
homochiral molecules, where the chirality was guessed wrong.  At the moment 
since our computational chemists overwhelmingly use MAESTRO and thus that is 
what I have used to do this for the past 5 years or so.  MAESTRO has an 
extremely hard time with figuring out organic (non-proteinaceous) molecules in 
PDB format, so I feed it only mol (or sdf) and/or mol2 formats.  These formats 
don't know anything about residue codes, but, of course, specify bonding order 
and chirality quite well. So MASESTRO must use internal identifiers for each 
molecule (and, in fact, the project table in MAESTRO, uses numbers to identify 
various version of a molecules). I will ask one of our computational chemists 
to address the issue more fully and get back to you with more complete answer 
(probably off-line).

Steven



>-Original Message-
>From: Mailing list for users of COOT Crystallographic Software
>[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Paul Emsley
>Sent: Tuesday, January 24, 2012 9:54 PM
>To: COOT@JISCMAIL.AC.UK
>Subject: Re: New restraints, same name
>
>Thanks to all contributors, I have been informed, educated and
>entertained.
>
>A bit of background perhaps... (it seems that I have been living in the
>0.7 world long enough to forget that not everyone else is here). "[T]he
>viewer programs don't care about the restraint dictionaries"  says Seth
>Harris - haha - in olden Coots that was the case... :)  It is my hope
>that Coot will be used for comparison, evaluation, validation and
>manipulation of ligands in protein-ligand complexes and their electron
>density.
>
>My current obsession is with chemical structure diagrams - here's a
>recent screenshot:
>http://lmb.bioch.ox.ac.uk/coot/screenshots/Screenshot-example-2010-01-
>02.png
>
>... and here's one I made earlier today, illustrating the sorts of
>problems I am trying to handle (PI3 Kinase ligand, 4a55):
>http://lmb.bioch.ox.ac.uk/coot/screenshots/Screenshot-Coot-prodrg-
>valence-problem.png
>amusing, eh?
>
>Anyway, to make the

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

[Sheriff, Steven]

Paul:

It appears to me that you have provided the Python rather than the Scheme 
version of this command, at least based on the use of underscores rather than 
dashes and the fact that the entire command is not in parentheses as opposed to 
just the parameter.  Are you switching entirely to Python?  [No problem from my 
end, just curious.]  Or was this an oversight?  Would the Scheme version be:

(set-nomenclature-errors-on-read "ignore") ?

Also, I have noticed when reading certain RCSB/PDB files that the Fix 
Nomenclature Errors pop-up often questions a few residues.  I thought the RCSB 
(and associated centers) fixed these sorts of errors, so I am concerned about 
why COOT picks up occasional residues as having nomenclature errors.  Any 
thoughts?

Steven

>-Original Message-
>From: Mailing list for users of COOT Crystallographic Software
>[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Paul Emsley
>Sent: Monday, March 05, 2012 9:53 AM
>To: COOT@JISCMAIL.AC.UK
>Subject: Re: Version 7 not repainting screen after initial load.
>
>On 05/03/12 13:56, Ian Tickle wrote:
>> Hello, I just installed WinCoot_0.7-pre-1-4040 (because I kept getting
>> the message "this is an old Coot" from version 0.6.2.1 !).
>
>Sorry about that.  We're just slower at making released that I thought
>we'd be.
>
>I am considering a dynamic check, rather than this built-in
>pre-calculated date...
>
>Anyway...
>
>> I just spotted one minor infelicity: when it starts it pops up a
>> window "Fix Nomenclature Errors" (which is very nice).  However if I
>> close this it still remains visible but inactive.  The same thing
>> happens if I open other dialogs, so eventually I can cover the screen
>> with inactive dialogs!  So it looks like it's not repainting the main
>> window when the dialog window is closed.  This didn't happen with v6.
>> I can however force a repaint by minimising and maximising the window,
>> and after that the dialog windows behave normally.
>
>Sounds like a driver bug.  Although why it should be different for
>different coot versions, I do not know.
>
>> Also is there a
>> way to disable the initial "Fix Nomenclature Errors" pop-up (couldn't
>> see anything in the manual).  I don't want to fix them right away
>> (because it's not my structure), and it keeps reminding me every time!
>
>set_nomenclature_errors_on_read("ignore")
>
>I will add this to the main documentation - thanks for the reminder.
>
>Paul.

This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Animated gif of density

[Sheriff, Steven]

Oliver:

Why not use PyMol for this purpose?

Steven

>-Original Message-
>From: Mailing list for users of COOT Crystallographic Software
>[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Oliver Clarke
>Sent: Wednesday, June 26, 2013 8:29 AM
>To: COOT@JISCMAIL.AC.UK
>Subject: Animated gif of density
>
>Hi all,
>
>This is perhaps more of a wish list request... I often use coot to make
>density figures for presentations of a structure still in progress, but
>it is difficult to convey the shape or quality of density from a 2D
>snapshot.
>
>A feature that perhaps might be helpful in this regard would be to add
>an option, in addition to taking a simple screenshot, to take an
>"animated screenshot".
>
>I would envision the user being able to select the rotation axis (x, y
>or z), and coot stitching together a few screenshots to create an
>animation of rocking about said axis, perhaps 10 or 20 degrees either
>side.
>
>I realize this is a feature that will probably be near the bottom of the
>list in terms of desired features, but I believe it would be helpful for
>conveying density quality and the fit of the structure to the density to
>those not actively involved in the model building process.
>
>Cheers,
>Oliver.

This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Problem with Check waters dialog

[Sheriff, Steven]

All:

I second Mark's points

1. that "electrons/A3" doesn't make any sense in the context of an r.m.s.d. 
level, i.e. the "electrons/A3" should be deleted.  Moreover, I would note the 
inconsistency in nomenclature between that line and the previous one where 
"with B factor greater than:  A^2", where the caret (circumflex) is used to 
indicate that the 2 should superscripted.

3. No way exists to specify the map used, although presumably it is using the 
first 2Fo-Fc map in the list and the list of suspect water molecules is 
consonant with that assumption.

However, I have never seen the dialog freeze COOT.

Additionally, for this dialog to be more useful:

4. it should use the PDB definition of a distant contact, which is not any 
protein atom, but rather a protein atom with a potential to form a hydrogen 
bond.  To compensate for this deficiency, I search for water molecules whose 
closest contact is > 3.2 A.  However, I have seen water molecules that are >~ 
3.35 A from a hydrogen bonding atom sometimes move to farther than 3.5 A away 
on a subsequent round of refinement.

5. it should pay attention to LINK records and exclude water molecules whose 
closest contact is less than specified, but included in a LINK record.

Steven

>-Original Message-
>From: Mailing list for users of COOT Crystallographic Software
>[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Mark A Saper
>Sent: Thursday, February 06, 2014 9:02 PM
>To: COOT@JISCMAIL.AC.UK
>Subject: Problem with Check waters dialog
>
>I've never understood the Check Waters Dialog.
>
>1. The line "with map r.m.s.d. level less than 1.0 electrons/A3" doesn't
>make sense.  Shouldn't it be with map density less than 1.0 sigma above
>mean (or r.m.s.) density value of the map?
>
>2.  Sometimes the dialog causes the program to freeze, yet there are no
>informatory messages on the console.
>
>3. I would just like to find the waters that have 2Fo-Fc density less
>than 1 sigma.  Also I don't think there is a place to specify the map
>name.
>
>-Mark
>
>___
>Mark A. Saper, Ph.D.
>Associate Professor of Biological Chemistry, U-M Medical School
>3040 Chemistry Building  |  sa...@umich.edu  |  +1 (734) 764-3353

This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] symmetry operator notation question

[Sheriff, Steven]

Bill:

From earlier COOT mail:

=
-Original Message-
From: Paul Emsley [mailto:pems...@mrc-lmb.cam.ac.uk]
Sent: Tuesday, February 11, 2014 9:43 AM
To: Yong Wang
Cc: COOT@JISCMAIL.AC.UK
Subject: Re: symmetry operator style in new coot

On 10/02/14 21:46, Yong Wang wrote:
> Dear Coot users,
>
> The symmetry operator in the new Coot (0.7.2) has a different style from that
> in the older version.  For example, the current symmetry operator (based on
> the label) would have something like -X+Y,-X,Z+(1 1 0)&{0 1 0} and the saved
> coordinates file would be named _symmetry_3010100.pdb.  The translational
> part does not look as simple as the old style.  Could someone explain the
> part "+(1 1 0)&{0 1 0}"?  Is there a command to export the matrix out?
>

Dear Yong,

I don't know how other programs do symmetry expansion, but Coot moves the
molecules close to the origin (by cell translations), does the symmetry
expansion there and then moves everything back around where the origin molecule
was placed.  The vector after the & shows the necessary origin-shift needed to
bring the molecule close to the origin.

In the past, the atom symmetry label was the sum of the actual translation (due
to symmetry operator) and the pre-translation. Some time ago I decided that
that, although shorter, was confusing.

I don't think that there is a function to write out symmetry matrices
explicitly, but I suppose that it would be straightforward to write to the
screen the symmetry operator of the selected symmetry molecule when
you write a symmetry related file.   Would that do?

Paul.
=

However, a colleague and I have found an error in what COOT writes out and, at 
least at the GRC on Diffraction Methods, Paul agreed was problem, but noted 
that he had not yet fixed it. In an email that I sent to Paul on 1 July 2014:

You state “The vector after the & shows the necessary origin-shift needed to 
bring the molecule close to the origin.”  However, in a real life example, we 
found the center-of-mass of a molecule at 0.45, 0.55, -0.10 unit cell 
translations, but in COOT after the “&” we found {0 1 0}.  We would have 
thought in this situation based on your explanation below that it should have 
been {0 -1 0}.
=

Steven


-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of William G. Scott
Sent: Saturday, August 30, 2014 10:03 AM
To: COOT@JISCMAIL.AC.UK
Subject: symmetry operator notation question

Hi folks:

What is the meaning of the last field — the one in curly brackets -- that 
describes the symmetry transformation of a given atom in coot? For example, for 
a given X Y Z, coot displays the symmetry transformation of an equivalent 
position as " Y+1/2, -X+1/2, Z + (0 -1 1) & { 1 0 1 }”.

Thanks.

Bill




William G. Scott
Professor, Department of Chemistry and Biochemistry and The Center for the 
Molecular Biology of RNA University of California at Santa Cruz Santa Cruz, 
California 95064 USA

http://scottlab.ucsc.edu/~wgscott

This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Reordering chains in a pdb file

[Sheriff, Steven]

Rex:

COOT->Extensions->Modeling...->Reorder Chains...

But be forewarned that if the PDB file has insertion residue numbering this 
process will strip the insertion residue character from the ATOM records, so 
the file will end up with multiple residues with the same apparent residue 
number.

Steven

From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Rex Palmer
Sent: Tuesday, January 20, 2015 11:54 AM
To: COOT@JISCMAIL.AC.UK
Subject: Reordering chains in a pdb file

My protein has 4 separate chains A,B,C and D but the pdb file has the chains in 
order C,D,A,B. Is there any existing software that would rearrange my pdb file 
as A,B,C,D?

Rex Palmer
http://www.bbk.ac.uk/biology/our-staff/emeritus-staff


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Reordering chains in a pdb file

[Sheriff, Steven]

Paul:

I just checked one file and indeed reorder chains no longer strips the 
insertion residue record. Hurray!

Steven

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Paul Emsley
Sent: Tuesday, January 20, 2015 12:51 PM
To: COOT@JISCMAIL.AC.UK
Subject: Re: Reordering chains in a pdb file

On 20/01/15 17:32, Sheriff, Steven wrote:
>
> Rex:
>
> COOT->Extensions->Modeling...->Reorder Chains...
>
> But be forewarned that if the PDB file has insertion residue numbering
> this process will strip the insertion residue character from the ATOM
> records, so the file will end up with multiple residues with the same
> apparent residue number.
>
>

I doubt that this bug still exists in 0.8.1.

(haven't tested it though)

Paul.

This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information.  The information is intended to be for 
the use of the individual or entity designated above.  If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments.  Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] NCS ligand

[Sheriff, Steven]

Even better than my suggestion ...

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Paul Emsley
Sent: Tuesday, February 17, 2015 1:57 PM
To: COOT@JISCMAIL.AC.UK
Subject: Re: NCS ligand

On 17/02/15 18:02, Phil Evans wrote:
> I've got 4 molecules in the asu (chains A,B,C,D), and have just built a 
> peptide ligand as chain S on to chain D. Is there an easy way to copy it to 
> the right position on the other chains, or do I have to put it into chain D?
>

Extensions -> NCS ... -> NCS Ligands

works one ligand residue at a time.  Maybe that will do?


Paul.

 This message (including any attachments) may contain confidential, 
proprietary, privileged and/or private information. The information is intended 
to be for the use of the individual or entity designated above. If you are not 
the intended recipient of this message, please notify the sender immediately, 
and delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Dragged refinement fails with riding hydrogens

[Sheriff, Steven]

All:

Following up on Carsten's comment. Buster also does not add hydrogen atoms 
automatically. It does have a command external to buster, hydrogenate, which 
uses the Duke University (read MolProbity) group's reduce underneath along with 
CIF restraint files for ligands to allow reduce to properly hydrogenate both 
protein and ligands. So Carsten's statement "one has to be very conscientious 
to add hydrogens back after mutating or adding residues" holds for buster as 
well.

Steven

P.S. I should note that Gelly, which is Buster's geometry engine, does an 
excellent job of producing typically >90th percentile Clash and MolProbity 
scores even in the absence of hydrogen atoms.

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Schubert, Carsten [JRDUS]
Sent: Wednesday, May 27, 2015 12:54 PM
To: COOT@JISCMAIL.AC.UK
Subject: Re: Dragged refinement fails with riding hydrogens

Hi Tim,

that does not work for phenix, not sure about Buster/TNT; refmac behavior is 
different. In phenix, which uses a riding model as well, but defines explicit 
hydrogens, one has to be very conscientious to add hydrogens back after 
mutating or adding residues. In part this is a phenix issue as well, but all in 
all I do have to side with Oliver on this one. Coot is not very well adapted to 
a handle explicit hydrogens and could benefit from improvement in that regard.

Cheers,

Carsten

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Tim Gruene
Sent: Wednesday, May 27, 2015 12:16 PM
To: COOT@JISCMAIL.AC.UK
Subject: Re: [COOT] Dragged refinement fails with riding hydrogens

Hi Oliver,

unless these are neutron data, you could simply remove the hydrogen atoms from 
the model before model building. They would be regenerated on the next round of 
refinement. At least this is the philosophy of some refinement programs.

Cheers,
Tim


On Wed, May 27, 2015 at 04:16:38PM +0100, Oliver Clarke wrote:
> Hi all, dragged refinement doesn't seem to work for structures with riding 
> hydrogens - see linked screen recording showing dragged refinement of the 
> same structure with and without hydrogens.
>
> https://www.dropbox.com/s/15xs8ylhrx98ljk/dragged_refinement_H_bug.mov
> ?dl=0
>
> Would it be possible to alter this behaviour at some point such that 
> hydrogens remain firmly attached during dragging, to remedy this?
>
> In the past I have got around this by just doing real space corrections in 
> the absence of any hydrogens and adding them back in before every cycle of 
> reciprocal space refinement, but this does not seem like the optimal way to 
> be doing things.
>
> Cheers,
> Oliver.
>

--
--
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
phone: +49 (0)551 39 22149

GPG Key ID = A46BEE1A

 This message (including any attachments) may contain confidential, 
proprietary, privileged and/or private information. The information is intended 
to be for the use of the individual or entity designated above. If you are not 
the intended recipient of this message, please notify the sender immediately, 
and delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] PyMOL v. Coot map 'level'

[Sheriff, Steven]

Emilia:



It appears to me that based on discussion on the CCP4BB by Thomas Holder and 
James Holton that you should do the following:

· Run MAPMASK twice, first on an asymmetric unit to normalize, and a 
second time to extend the map over your molecule

· Issue the command “unset normalize_ccp4_maps” either in your PyMol 
script or the GUI

· Contour the map at your choice of r.m.s.d. level

· This should lead to a map that should look identical to a COOT map



Alternatively, PyMol now reads MTZ files and according to an off-line 
discussion with Thomas Holder, “PyMOL converts MTZ files to ccp4 maps 
internally before loading, this means that "normalize_ccp4_maps" also applies 
to MTZ files.” What isn’t clear to me from this and I’ve never tried to have 
PyMOL read an MTZ file and I neglected to ask Thomas in our offline discussion 
is whether PyMOL is then capable of extending the electron density over regions 
of the molecule that were not in the asymmetric.



Steven





-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Tim Gruene
Sent: Friday, June 05, 2015 2:55 AM
To: COOT@JISCMAIL.AC.UK
Subject: Re: PyMOL v. Coot map 'level'



-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1



Hi Emilio,



for publication purposes you can get something similar to carving by setting 
the map radius in Coot, creating a Raster3D output file and adjusting front and 
back clip. Not perfect and difficult for fine tuning, but it's a step in the 
right direction, I think.



Best,

Tim



On 06/05/2015 07:34 AM, Emilia C. Arturo (Emily) wrote:

> Thanks Paul.

>

> To help with others' future Googling efforts on the topic of PyMOL

> versus Coot map levels, I'll leave here the link to the discussion

> that began from my initial post, on the ccp4bb:

> https://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg39219.html

>

>>

>>>

>>> Alternatively, does anyone have instructions on how to use Coot to

>>> do what I'm trying to do in PyMOL?

>>

>>

> Is there a way in Coot to display a selection of the map about a set

> of residues - something akin to PyMOL's 'carve' option?

>

>

>> In Coot, we use all the grid points in the asymmetric unit - other

>> programs make a selection of grid points around the protein (and

>> therefore have less solvent).

>>

>> More solvent means lower rmsd. If one then contours in n-rmsd levels,

>> then absolute level used in Coot will be lower - and thus seem to be

>> noisier (perhaps).

>

>

> This makes sense to me - thanks for the clear response :-) It appeared

> to me--and it turns out to be pointless, IMO, to supply an image to

> prove my point, because the image is too crowded--that the Coot map

> was much tidier/less 'noisy' around my selection of residues. In fact,

> I wondered if Coot was sampling the map more/at higher frequency (?)

> than is PyMOL. I'll have to Google more about that; there are probably

> settings I need to adjust. Anyway, it definitely didn't seem noisier

> than PyMOL's display of the same map, which is why I am asking if Coot

> has something like a 'carve'

> feature.

>

>

>> I suppose that if you want comparable levels from the same map/mtz

>> file then you should use absolute levels, not rmsd. What does PyMOL's

>> "1.0" mean in electrons/A^3?

>>

>

> I don't know how PyMOL's map level relates to electron density, but in

> case Thomas Holder knows, I'll ask the question at the related ccp4bb

> thread where he's participating. I guess you're asking about how the

> maps are scaled in PyMOL? ...how are they scaled in Coot?

> The idea of an absolute scale, frankly, confuses me, so I am fine to

> take the last two questions back to my crystallography notes

> :-)

>

> Thanks, Emily.

>

>

>> Regards,

>>

>> Paul.

>>

>



- --

- --

Dr Tim Gruene

Institut fuer anorganische Chemie

Tammannstr. 4

D-37077 Goettingen

phone: +49 (0)551 39 22149



GPG Key ID = A46BEE1A



-BEGIN PGP SIGNATURE-

Version: GnuPG v1



iD8DBQFVcUfHUxlJ7aRr7hoRAsdHAKDWwbxfJyXWnxPgqXBMBAh/NhY7PACgnKdZ

CWwWVhFNjjzv2NPagny5+Z8=

=iRG5

-END PGP SIGNATURE-


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] New ligand 3-letter code

[Sheriff, Steven]

All:

Why the concern for unassigned three-letter codes? The wwPDB isn’t going to let 
you assign a three-letter code, it will choose its own code.

At BMS (a pharmaceutical company), we do many hundreds of structures a year 
with ligands and we assign the same, already assigned, three-letter code for 
all of our ligands (unless we have two or more different ligands in a single 
structure, in which case we use two or more different already assigned 
three-letter codes).  COOT can mostly handle this.

However, I believe that if you want an unassigned code, the wwPDB has set aside 
UNK[nown] for this purpose.

Steven

From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson
Sent: Friday, June 05, 2015 6:28 AM
To: COOT@JISCMAIL.AC.UK
Subject: Re: New ligand 3-letter code

I use your method - trial & error..
It would be nice if at least there was a list somewhere of unassigned codes!

On 5 June 2015 at 09:16, Lau Sze Yi (SIgN) 
mailto:lau_sze...@immunol.a-star.edu.sg>> 
wrote:
Hi,

What is the proper way of generating 3-letter code for a new ligand? As of now, 
I insert my ligand in Coot using smiles string and for the 3-letter code I 
picked a non-existent code by trial and error (not very efficient). A cif file 
with corresponding name which I generated using Phenix was imported into Coot.

I am sure there is a proper way of doing this. Appreciate your feedback.

Regards,
Sze Yi


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

[COOT] FW: New ligand 3-letter code (help-7071)

[Sheriff, Steven]

All:

Since the original query was cross-posted on both the COOT mailing list and the 
CCP4BB Rachel Green gave me permission to forward this to both. She provides 
links about the mechanism of assignment of 3-letter codes. In the third link 
below, my original suggestion to the COOT mailing list that one could just use 
UNK is incorrect as that is reserved for unknown amino acids. According to this 
document, I should have suggested UNL for an unknown ligand.

Steven

From: Rachel Kramer Green [mailto:kra...@rcsb.rutgers.edu]
Sent: Tuesday, June 16, 2015 10:21 AM
To: Sheriff, Steven
Cc: info
Subject: Re: New ligand 3-letter code (help-7071)

Dear Steven,

During annotation of ligands, all chemical components present in the structure 
are compared against the definitions in the Chemical Component Dictionary 
(http://www.wwpdb.org/data/ccd). If the ligand is not in the dictionary, a 
three letter code is assigned. See 
http://www.wwpdb.org/documentation/policy#toc_assignment.  In the future, a 
group of three-letter codes may be set aside to be used during refinement to 
flag new ligands.

Clarification about the ligand ids assignment and in particular the usage of 
UNX/UNL/UNK residues can be found at 
http://www.wwpdb.org/documentation/procedure#toc_2.

Best wishes,
Rachel


Rachel Kramer Green, Ph.D.
RCSB PDB
kra...@rcsb.rutgers.edu<mailto:kra...@rcsb.rutgers.edu>

New! Deposit X-ray data with the wwPDB at:
http://deposit.wwpdb.org/deposition (NMR and 3DEM coming soon).
___
Twitter: https://twitter.com/#!/buildmodels
Facebook: http://www.facebook.com/RCSBPDB



On 6/5/2015 7:50 AM, Sheriff, Steven wrote:
All:

Why the concern for unassigned three-letter codes? The wwPDB isn’t going to let 
you assign a three-letter code, it will choose its own code.

At BMS (a pharmaceutical company), we do many hundreds of structures a year 
with ligands and we assign the same, already assigned, three-letter code for 
all of our ligands (unless we have two or more different ligands in a single 
structure, in which case we use two or more different already assigned 
three-letter codes).  COOT can mostly handle this.

However, I believe that if you want an unassigned code, the wwPDB has set aside 
UNK[nown] for this purpose.

Steven

From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson
Sent: Friday, June 05, 2015 6:28 AM
To: COOT@JISCMAIL.AC.UK<mailto:COOT@JISCMAIL.AC.UK>
Subject: Re: New ligand 3-letter code

I use your method - trial & error..
It would be nice if at least there was a list somewhere of unassigned codes!

On 5 June 2015 at 09:16, Lau Sze Yi (SIgN) 
mailto:lau_sze...@immunol.a-star.edu.sg>> 
wrote:
Hi,

What is the proper way of generating 3-letter code for a new ligand? As of now, 
I insert my ligand in Coot using smiles string and for the 3-letter code I 
picked a non-existent code by trial and error (not very efficient). A cif file 
with corresponding name which I generated using Phenix was imported into Coot.

I am sure there is a proper way of doing this. Appreciate your feedback.

Regards,
Sze Yi


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] NCS

[Sheriff, Steven]

Santhosh:

Modern molecular replacement programs, e.g. PHASER and MOLREP, look for and 
take, at least translational, NCS into account.

Modern refinement programs, e.g. BUSTER, REFMAC, and PHENIX.REFINE, use LSSR 
(Local Structure Similarity Restraints) for NCS and improve geometry to 
resolutions better than 2 A (maybe even better than 1.5 A) and reduce 
overfitting. NCS should therefore be used during refinement, UNLESS one can 
prove that it is hurting refinement by increasing R-free. Even then, it may 
only require some hand editing of the residues to exclude from LSSR.

Steven

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
[mailto:COOT@JISCMAIL.AC.UK] On Behalf Of SUBSCRIBE COOT santhosh
Sent: Tuesday, September 08, 2015 8:22 AM
To: COOT@JISCMAIL.AC.UK
Subject: NCS

Hi every body,

Is it needed to consider NCS with space group P61 (two molecules in the 
asymmetric unit ) during molecular replacement and refining at a resolution of 
1.9 A.

How it will effect processing of the data ?

Please provide your suggestions.


santhosh

 This message (including any attachments) may contain confidential, 
proprietary, privileged and/or private information. The information is intended 
to be for the use of the individual or entity designated above. If you are not 
the intended recipient of this message, please notify the sender immediately, 
and delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.

Re: [COOT] Feature suggestion: Check/Delete Waters, toggle hydrogens on/off

[Sheriff, Steven]

Paul:

I second this request, which I have made to you by private (as opposed to 
mailing list) email.

Steven

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
 On Behalf Of CRAIG A BINGMAN
Sent: Friday, June 4, 2021 2:45 PM
To: COOT@JISCMAIL.AC.UK
Subject: Feature suggestion: Check/Delete Waters, toggle hydrogens on/off

[Use CAUTION when opening links/attachments]

The "Check/Delete Water" function under "Validate" would be more useful to me 
if it were possible to ignore hydrogen atoms in the distance calculations. 
There seems to be no distance window that works simultaneously for water O-O 
distances, where riding hydrogens are almost never present, and water O-protein 
distances, where the protein almost always carries riding hydrogens.

A check box that directs the program to ignore hydrogens in the distance 
calculations would be very helpful.

Thanks for a wonderful program that makes my professional life better and more 
productive.



To unsubscribe from the COOT list, click the following link:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2FWA-JISC.exe%3FSUBED1%3DCOOT%26A%3D1&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Cffd563af89a14ad3f15808d92788fb05%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637584291547365276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FTHK6deYf9VaSuU%2Fl5%2Blp6hv0aaQNF6adbmMy8yioIY%3D&reserved=0

This message was issued to members of 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jiscmail.ac.uk%2FCOOT&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Cffd563af89a14ad3f15808d92788fb05%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637584291547365276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=xMI%2Fgiam4KuT2mIB7B%2Btg1ub4vho4zy9UIV0g4MdeH4%3D&reserved=0,
 a mailing list hosted by 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jiscmail.ac.uk%2F&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Cffd563af89a14ad3f15808d92788fb05%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637584291547365276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=oiPWjaq0xLOfk%2FBVUIMz1MBZO1YY6hEyT7tuuacz3HU%3D&reserved=0,
 terms & conditions are available at 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fpolicyandsecurity%2F&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Cffd563af89a14ad3f15808d92788fb05%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637584291547365276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ikVEut1oeec3pswypzDQ0FP49ZoNhkh7Eu6QCYKEGK4%3D&reserved=0

 This message (including any attachments) may contain confidential, 
proprietary, privileged and/or private information. The information is intended 
to be for the use of the individual or entity designated above. If you are not 
the intended recipient of this message, please notify the sender immediately, 
and delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.



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

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

Re: [COOT] Feature suggestion: Check/Delete Waters, toggle hydrogens on/off

[Sheriff, Steven]

Paul:

Thank you!!

Steven

-Original Message-
From: Mailing list for users of COOT Crystallographic Software 
 On Behalf Of Paul Emsley
Sent: Tuesday, June 8, 2021 10:49 AM
To: COOT@JISCMAIL.AC.UK
Subject: Re: Feature suggestion: Check/Delete Waters, toggle hydrogens on/off

[Use CAUTION when opening links/attachments]

On Fri, 2021-06-04 at 18:45 +, CRAIG A BINGMAN wrote:
> The "Check/Delete Water" function under "Validate" would be more
> useful to me if it were possible to ignore hydrogen atoms in the
> distance calculations. There seems to be no distance window that works
> simultaneously for water O-O distances, where riding hydrogens are almost 
> never present, and water O-protein distances, where the protein almost always 
> carries riding hydrogens.
>

I managed to find a useful PDB file on an old laptop. The fix to ignore water 
hydrogen atoms has now been published and will be available in 0.9.6.

Paul.



To unsubscribe from the COOT list, click the following link:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fcgi-bin%2FWA-JISC.exe%3FSUBED1%3DCOOT%26A%3D1&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Ce337e4110b6d4375062908d92a8c7d4e%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637587605315041570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=E8rD7g9vo9k%2B0NfT%2FzGDQKwfnL9a1UrQfBbey281yr0%3D&reserved=0

This message was issued to members of 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jiscmail.ac.uk%2FCOOT&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Ce337e4110b6d4375062908d92a8c7d4e%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637587605315041570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=XwCiuwzNFWSJMilpi9vqG44rtmm6RTsiJ0yBYSNYqkU%3D&reserved=0,
 a mailing list hosted by 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jiscmail.ac.uk%2F&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Ce337e4110b6d4375062908d92a8c7d4e%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637587605315041570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Y%2BSAj2QwZxsCgkLrmOGypqsg5%2FZzMsuZOTBaJPk7Hbw%3D&reserved=0,
 terms & conditions are available at 
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jiscmail.ac.uk%2Fpolicyandsecurity%2F&data=04%7C01%7Csteven.sheriff%40BMS.COM%7Ce337e4110b6d4375062908d92a8c7d4e%7C71e34cb83a564fd5a2594acadab6e4ac%7C0%7C0%7C637587605315041570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=apro23uaR4lvKx4spwf%2FuFih7KFkL1Feyc1OIUzcWhc%3D&reserved=0

 This message (including any attachments) may contain confidential, 
proprietary, privileged and/or private information. The information is intended 
to be for the use of the individual or entity designated above. If you are not 
the intended recipient of this message, please notify the sender immediately, 
and delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.



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

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

Re: [COOT] Pointer Atoms - Potassium

[Sheriff, Steven]

John:

I recently (22-Nov) pointed out to Paul Emsley that if one entered potassium 
through the popup menu, it places the "K" of potassium in the wrong column of a 
PDB file, column 13 rather than column 14. The element is right-justified, so 
single letter elements use only column 14, but two letter elements use both 
columns 13 and 14. If you manually edit your file so that the "K" is in column 
14, the potassium should then refine.

Steven

From: Mailing list for users of COOT Crystallographic Software 
 On Behalf Of John Smith
Sent: Friday, December 2, 2022 10:31 AM
To: COOT@JISCMAIL.AC.UK
Subject: Pointer Atoms - Potassium

[Use CAUTION when opening links/attachments]
Dear all!
I am using Coot 0.9.8.5 EL (ccp4) and I want to add K/potassium ions during 
model building.
Adding Na and Cl is straightforward, but if I click on Pointer Atom Type other, 
enter K and hit OK, then a grey atom is added, but it does not refine.
Warning: Failed to match the dictionary.
Similar problem occurs if I do it via Calculate - Modelling - add other solvent 
molecules. If I specify K as three letter code, it brings up potassium ion but 
it does not refine.

Any tips why this is not working?
Thank you!

Best regards
John



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


This message (including any attachments) may contain confidential, proprietary, 
privileged and/or private information. The information is intended to be for 
the use of the individual or entity designated above. If you are not the 
intended recipient of this message, please notify the sender immediately, and 
delete the message and any attachments. Any disclosure, reproduction, 
distribution or other use of this message or any attachments by an individual 
or entity other than the intended recipient is prohibited.



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

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