[COOT] key binding for difference map peaks
Hi all, this used to work (a while ago) from my-settings.scm for a key binding to get a list of difference map peaks: (add-key-binding "Difference map peaks" "b" (lambda () (difference-map-peaks 2 0 4 2.0 1 1))) but now (and for quite some time) it mentions wrong number of arguments: *(graphics-general-key-press-hook 98)* ((safe_scheme_command) Error in proc: key: wrong-number-of-args args: (#f Wrong number of arguments to ~A (difference-map-peaks) #f)) >From what I can tell, the manual still indicates 6 arguments. 11.57.1 difference-map-peaksfunction: *difference-map-peaks* *imol imol_coords level max_closeness do_positive_level_flag do_negative_level_flag* Where: - *imol* is an integer number - *imol_coords* is an integer number - *level* is a number - *max_closeness* is a number - *do_positive_level_flag* is an integer number - *do_negative_level_flag* is an integer number generate a list of difference map peaks peaks within max_closeness (2.0 A typically) of a larger peak are not listed. Any hints or ideas if something has changed on the command or I'm missing something? Thanks, Seth 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] large non-native peptide .cif restraints
Hi all, I am increasingly dealing with large macrocycles or cyclized peptides that include unnatural amino acids or modifications. Early on my approach was to treat most of it as the native peptide scaffold, then add a few custom 'LINK' records to capture covalent bonds to some non-native moiety, and that moiety would be defined as we do for small molecule synthetic ligands. Advantage was that it was efficient for refinement of the conventional amino acid scaffold. Disadvantage, a bit cumbersome and I do find that while the covalently bonded attachment point is reasonable, the neighboring atoms to that new attachment don't always behave reliably (as in perhaps don't have the knowledge that their neighbor has something new attached which affects their space.) As our chemists got more creative, it also is tedious to sit there trying to make 5 or 6 little bits and pieces that all have to be attached to different atoms along the scaffold. Plus the bookkeeping of made up names for little extra ethylenes, halognes, and their atom name attachment points and such was pretty painful. So, that led to approach two, which was to just let the dictionary generation happen for the whole peptide or macrocycle. This ignores knowledge that it's essentially an amino acid type of base scaffold (so a bit inefficient for purists) and just redefines all those as if it's some small molecule, albeit a relatively large version of one of those. You also lose residue number indexing, as the whole thing is typically called "LIG" with a single residue identifier, but it seems a small price to pay for the convenience of it taking care of all the sundry modifications and cyclization points, etc. The problem I'm having is that COOT is having trouble reading or using these large .cif files. The files may be 1000 or more lines long with the hydrogens defined. I've tried dropping all hydrogens but it's still large and when I go to real space refine or do any editing to move the starting conformation of the molecule in question into the clear density for it bound to some protein, Coot basically hangs either indefinitely or for several minutes at a time at least with each attempted motion, step. Is there some memory allocation for the .cif dictionary that perhaps is limiting? I don't have a handy non-proprietary example currently, but could likely generate one if needed. Or have people had success with this approach (e.g. taking a 10-14 amino acid peptide, treat it as a SMILES string and generate a .cif for the whole thing as a single molecule and then be able to use it in real space refinement in Coot? ) I've tried a few workarounds to get the atoms pretty close and then let reciprocal space refinement do the rest, but there really aren't so many good ways to do that (Pymol's sculpting drifts, was playing with Isolde but having similar technical issues with the restraints definitions). Thanks for thoughts, or info on Coot and large .cif dictionaries? Cheers, Seth 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] Glyco module going off script at the B1-4 BMA?
Hi Paul, That's a good control and yes, the coot glyco module works beautifully on 2qc1; as well my own structure/maps when loaded alongside. This led me to find that it was only happening in my project directory and using some scripts I have that pre-load a working environment as coot is opened...and among those 'pre-loads' it was finding an old .cif restraints file which included a definition for BMA -- and was thus overwriting the atom definitions for that sugar which was naturally throwing off the builder. Once removed (that erroneous .cif I had), it's back to its incredible self, the Glyco module.Thanks for helping track that down, and more so for the terrific glycosylation builder (in fact this is an old structure I came back to years later only now that the tools improved enough to build these without going insane!). Cheers, Seth On Thu, Jul 15, 2021 at 1:10 AM Paul Emsley wrote: > On Tue, 2021-07-13 at 23:59 -0700, Seth Harris wrote: > > > > I have some good resolution (~1.3 A) data with glycosylation that can > pretty clear describe the expected N-linked tree > > of Asn-NAG-NAG-BMA with two MAN off the end and a FUC at the base NAG > (plus something on the other side of the base > > NAG that also looks like a sugar??). But the main issue I have is that > the rather impressive and lovely glycosylation > > tools in Coot that I think I've used before to build this are (at least > now in Coot 0.9.5) doing well on the first > > NAG-FUC-NAG combo and then the coot module correctly suggests the B1,4 > BMA attachment which at first is placed nearby > > at density and then is refined or moved way out, with the heavy dashed > connector that should be a regular bond length > > seemingly forced to be 2 to 3x too long. No type of sphere or real space > refinement brings it back, it always flips > > itself through any kind of gymnastics it can to keep it too far away, > despite really terrific density that would be > > good with a regular bond distance. I haven't put any LINK or such in the > PDB yet, these are just being built by COOT > > itself and I can't see any waters or sym mates that would push it away > in this manner. > > > > I tried carrying on through with some alpha 1,3 MANnose and alpha 1,6 > MANnose additions to that in case I could > > correct it all after a rough build, but the same problems occur here, > with janky and irretrievable placements in the > > end. Meanwhile the first 3 sugars are pretty perfectly placed. Did > something go different with the mannose that I'm > > doing wrong? > > > > Am I allowed to attach a screenshot? I'll try to here...The second NAG > out is nicely in density at the bottom center, > > the beta 1,4 BMA is the first one seemingly ignoring density and pushed > out on that dashed line with the other MAN > > also way off... > > > > Hi Seth, > > Just to make sure that there's something wrong with your Coot, can you try > to build the glycosylation in 2qc1? > > Thanks, > > 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/
[COOT] real space refine with insertion codes
Hi all, I'm sure this has been asked, but after some searching I can't find hints. Apologies if redundant, but can someone refresh me on how to get Coot to be graceful about residues with insertion codes...particularly during real space refinement. I have a protease structure with very good resolution/density but some odd numbering conventions with insertion code (e.g. 124A, 124B, 124C between residues 124 and 125 numbering) in other areas continuous residues have non-contiguous numbering. When doing real space refinement both situations tend to blow apart, each individual insertion code-numbered residue becoming its own disconnected amino acid and well out of the density, I assume due to sterics and it not interpreting these as being connected. Also common in Fab structures. I know there are painful workarounds to number it contiguously without insertions and then add back when done refining (but then you find one more thing...), but I am aspiring to greater elegance these days. Also hoping I don't have to define with LINK records or such for each case? Thanks, Seth To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
[COOT] middle mouse button center versus drag
Hello Paul et al., Click and drag on the middle mouse button is a quick and familiar way to translate around the scene and navigate, generally working well. However, if at the initiation of the click and drag I happen to be near an atom, the fact that I'm holding down the mouse button isn't distinguished from a single click and release, such that a re-centering first happens on whatever atom I was over (often deep back in Z direction and off to the side) and then the panning comes into play, but now I'm off horribly lost somewhere random in the molecule. Anyone else noticed this? Is there a more robust way to distinguish click and drag from click and release such that I don't have to be sure to be over empty space when starting the drag (even pretty faint atoms are still active)? Thanks, Seth p.s. Thanks also for the "o" shortcut tip to jump NCS copies equivalently. Works a treat!
Re: [COOT] navigating across symmetry mates
Super! And Paul, thanks for always being so terrifically responsive, thoughtful in reply and often in anticipation when things already exist, and also tolerating my imprecision...yes I meant NCS! Will check out the other functions and scripting thereof! Cheers Seth On Wed, Sep 6, 2017 at 10:22 AM, Paul Emsley <pems...@mrc-lmb.cam.ac.uk> wrote: > On 06/09/2017 18:14, Seth Harris wrote: > >> Hello Paul, Coot users! >> >> In the wonderful pantheon of Coot tools, is there a way to leap between >> equivalent points in symmetry mates with a nice single key shortcut, for >> instance? Or could there be? I seem to be getting several cases with 8 >> copies/asu and while initially one may build a single version and then >> clone it into all 8 positions, at some point one gets down to wanting to >> check the similarities/differences of all copies, and it would be handy if >> I've just visiting chain A, Leu30, for instance, to be able to rapidly go >> to chain B, Leu30 and so on >> > > This is not possible with symmetry mates, but is possible with NCS mates > (but perhaps that's what you mean). Press the "O" key. > > (yes, more rapidly than entering chain letters in the Go To Atom > dialogue...). Similar case for > >> ligands...the ligand button short cut is pretty good, but if I navigate >> off the ligand to look at surroundings, the next click of the heteroatom >> /ligand center button will likely have reset to the top of the list, and >> with cofactors in all copies that can be 16 clicks until I get back to >> through the cycle. >> > > :-) Yes. This could be better. > > You could probably make a script for "Quick View Save" and "Go To Last > View" - I imagine that would do most of what you want. > > >> In related aspects, in the Go To Atom dialog, I often have a single chain >> per ligand residue, but find I have to expand the sub menu to show the >> single residue to click on that to center. Anyway that the chain listing >> itself could be sensitive to clicks for centering? Obviously would be >> different behavior for protein chain, but perhaps the center of mass, or >> more simply centering on whatever is the first residue of the chain would >> be a consistent and desired behavior. >> > > This is a good idea and may be very easy to add. If it is, I'll do it > tomorrow. > > Paul. >
[COOT] navigating across symmetry mates
Hello Paul, Coot users! In the wonderful pantheon of Coot tools, is there a way to leap between equivalent points in symmetry mates with a nice single key shortcut, for instance? Or could there be? I seem to be getting several cases with 8 copies/asu and while initially one may build a single version and then clone it into all 8 positions, at some point one gets down to wanting to check the similarities/differences of all copies, and it would be handy if I've just visiting chain A, Leu30, for instance, to be able to rapidly go to chain B, Leu30 and so on (yes, more rapidly than entering chain letters in the Go To Atom dialogue...). Similar case for ligands...the ligand button short cut is pretty good, but if I navigate off the ligand to look at surroundings, the next click of the heteroatom /ligand center button will likely have reset to the top of the list, and with cofactors in all copies that can be 16 clicks until I get back to through the cycle. In related aspects, in the Go To Atom dialog, I often have a single chain per ligand residue, but find I have to expand the sub menu to show the single residue to click on that to center. Anyway that the chain listing itself could be sensitive to clicks for centering? Obviously would be different behavior for protein chain, but perhaps the center of mass, or more simply centering on whatever is the first residue of the chain would be a consistent and desired behavior. Indeed, the residue number in the Go To dialogue could default to that first chain first residue rather than "-"? Anyway, I'm heading off into more trivial things, but the main question was whether I've missed or could request a sym-mate-equivalent-jump function? Thank you!! Seth
[COOT] key binding for waters added to mol 0
Hi all Paul, Sometime back I found or was taught or given this: (add-key-binding Add Water w (lambda () (place-typed-atom-at-pointer Water))) (Probably from Pauls-key-bindings-for-coot...) I was looking for a quick way while browsing map peaks to add waters that the 'find waters' algorithms had overlooked for one reason or another. It fell into disuse, however, as I'd end up with all these waters in the Pointer Atoms object, and it would be a chore to reunite them with the primary pdb in question, accounting for numbering differences of already existing waters. I'd much rather replicate what the Place atom at pointer... + icon dialogue does, where you tell it which molecule you want to add to and it takes care of the numbering appropriately. So, is it simple to do this on key binding where function would be put water at pointer but add it to mol 0 with appropriate incremental residue numbering? (I tend to fire coot up from scripts, so can guarantee that mol number 0 is the one I want to use...) Thanks for any tips/guidance (or flat out working answer!) or suggestions I go read the scheme scripting manual... Seth
Re: [COOT] key binding for waters added to mol 0
Well how about that? Thanks...so it does. (Of course, if I didn't have to do the first one the 'slow' way...!) Thanks, Scott! -Seth On Thu, Jan 9, 2014 at 7:30 PM, Scott Classen sclas...@lbl.gov wrote: Hi Seth, I think if you place your first water using the place atom at this position button on the right side, then select your PDB file - all subsequent invocations of the w key will add waters to your PDB of interest instead of putting them in a separate PDB. Sincerely, Scott On Jan 9, 2014, at 18:30, Seth Harris set...@gmail.com wrote: Hi all Paul, Sometime back I found or was taught or given this: (add-key-binding Add Water w (lambda () (place-typed-atom-at-pointer Water))) (Probably from Pauls-key-bindings-for-coot...) I was looking for a quick way while browsing map peaks to add waters that the 'find waters' algorithms had overlooked for one reason or another. It fell into disuse, however, as I'd end up with all these waters in the Pointer Atoms object, and it would be a chore to reunite them with the primary pdb in question, accounting for numbering differences of already existing waters. I'd much rather replicate what the Place atom at pointer... + icon dialogue does, where you tell it which molecule you want to add to and it takes care of the numbering appropriately. So, is it simple to do this on key binding where function would be put water at pointer but add it to mol 0 with appropriate incremental residue numbering? (I tend to fire coot up from scripts, so can guarantee that mol number 0 is the one I want to use...) Thanks for any tips/guidance (or flat out working answer!) or suggestions I go read the scheme scripting manual... Seth
[COOT] add terminal residue...keep it nearby?
Hi all, I and others have occasionally been plagued by the Add Terminal Residue function placing the new residue somewhere distant. While there are various workarounds (reject and try again, do more searches, real space refine or regularize after it's been placed which kind of sucks it over to the build point..., workaround that with fix atom and then clearing the fix atoms...). In my current case of 3-ish Å resolution and doing a fair bit of building from scratch, residues I've just built get pulled out of visually obvious density when I do my old favorite workaround of RSR after the new residue ends up off screen 20 Å away from the residue I picked to add it to. I have some suggestions, or else questions if there are settings that already achieve the below: 1. Would it be possible for Add Terminal Residue to only consider density within a reasonable distance from the selected attachment point residue? 2. Second area is that at this resolution, or at least with the maps I have at this resolution, the behavior of real space refinement which I've grown accustomed to has gone kind of squidgy (hard to describe, but less snappy and during real space refinement things will drift away a bit from what visually looks like a good fit. I assume the lower resolution map has 'softer' edges, perhaps, and have yet to explore map sharpening, e.g.). I have, however, played with the refinement weights, but it doesn't much improve the way that side chain density can stop the main chain from translating into good position, or sometimes the side chain battles the main chain for its rightful density. I wondered whether there is or could be a real space refinement weighting scheme where main chain atoms have a stronger weight and the further one goes out a side chain the less pull (lower weight) it would have towards density. I think this might prove quite useful at the moderate/low resolution range where a fair bit of manual building transpires. It could prevent long side chains from invading neighboring strands' main chain density and be kind of like working with polyala but without having to mutate away and later put back side chains, and also still having some weight for the larger side chains that do have good density which are critical landmarks. It would be neat to be able to tune the fall off of such a weighting gradient from strong (where side chains are just about absent in the context of RSR) up to zero fall off, matching current behavior with all atoms present. I suppose I could mimic this to see how it works by setting occupancies to zero (or partial) in all side chain atoms beyond C-beta, e.g. but I wasn't sure with low occupancy if they still ride along appropriately with their main chain. Perhaps this parameter already exists? In the near term that distance restraint on where new residues land would be great! Thanks Seth
Re: [COOT] Coot - 3D Anaglyph
Ha. Now that's just about where I went running (comments in the other thread on ligand restraints...). See what I mean? Got to watch your step...next run I'll bring my red/green glasses... On Thu, Jan 26, 2012 at 12:06 PM, William G. Scott wgsc...@ucsc.edu wrote: Does coot do red/greed (anaglyph) stereo? All google showed me was this: http://www.flickr.com/photos/hindt3d/2268014240/ This would be useful for classroom settings. -- Bill William G. Scott Professor Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA 228 Sinsheimer Laboratories University of California at Santa Cruz Santa Cruz, California 95064 USA phone: +1-831-459-5367 (office) +1-831-459-5292 (lab) fax:+1-831-4593139 (fax) email: wgsc...@ucsc.edu
Re: [COOT] script to delete waters below 0.8 e/A^3
Thanks Paul, You think of everything, if only I always knew how to find it... I added this line to my key bindings: (add-key-binding Goodbye weak waters z (lambda () (delete-checked-waters-baddies 0 300 0.8 2.0 3.8 0 0 1))) which followed from your post with arguments of imol, b factor limit, sigma level limit, min dist, max dist, part_occ_contact_flag, zero_occ_flag, logical_and_or_flag So as advertised this seems to remove mostly the weak waters below 0.8 sigma of the (current?) map. And I was generous on the B factors and the distances since often I find that a weak water near a good one can taint the good one by its proximity, so best to remove the weak before checking the remaining for distance. Which brings to mind is there a check-checked-waters-baddies that I could key bind? Thanks a bunch, Seth On Fri, Jun 3, 2011 at 4:37 PM, Paul Emsley paul.ems...@bioch.ox.ac.ukwrote: On 03/06/11 23:11, Seth Harris wrote: Hi all, I often use the Check/Delete waters dialog to delete only those waters below 0.8 level in the map. I do this often enough that it is high time to find/create a script version, preferably even something I could launch from the command line, or barring that maybe could generate a single-click button on the main menu/control panel. Would that be as simple as falling off a log for some out there to give me pointers or a template to work from? Basically it is scripting whatever that Validate Check/Delete waters dialog is doing. Thanks so much, Seth Maybe this will be of some use? http://lmb.bioch.ox.ac.uk/coot/doc/coot/delete_002dchecked_002dwaters_002dbaddies.html#delete_002dchecked_002dwaters_002dbaddies If you need some help working that up into a menu item we can do that tomorrow. Paul.
[COOT] script to delete waters below 0.8 e/A^3
Hi all, I often use the Check/Delete waters dialog to delete only those waters below 0.8 level in the map. I do this often enough that it is high time to find/create a script version, preferably even something I could launch from the command line, or barring that maybe could generate a single-click button on the main menu/control panel. Would that be as simple as falling off a log for some out there to give me pointers or a template to work from? Basically it is scripting whatever that Validate Check/Delete waters dialog is doing. Thanks so much, Seth
[COOT] always on mouse button mode?
Hi all/Paul, I spend a great deal of time stepping through stuctures residue-by-residue (space bar) and rotating the molecule to and fro as a check up. Basically I have the mouse button held down almost constantly. I wondered if it would be simple to have a key binding to toggle in/out of a special rotate only mode, analogous to the mouse button being taped down while in that mode. This would also make apple's little track pad pretty handy for rotating which it currently isn't since it's hard to depress the whole pad (the click) and keep it down while rotating. I've tried using the i = constant rotate but you end up wanting to rotate different ways at each new residue, and yes, I've even briefly experimented with a very literal mouse button taped down hardware implementation (generous term for it), but I'd like a faster way to get in and out of the mode (for when you need to interact with accept/decline windows, click on a menu, or go to other applications, of course). Not sure I've thought it through completely, but for my style of work I think this would be pretty useful. Maybe it exists already? Thanks, Seth
[COOT] how to set the refinement map
Hello, After what felt like a reasonable amount of poking about, I can't find how to set the refinement map (yes, I tried 'set-refinement-map') although I did find that guess-refinement-map returns a good guess but doesn't seem to stop the Oops! Must Select Map to fit to! box from bothering me. (It could at least open the map selection dialog like what happens when you do Validate Check/Delete waters without first specifying a map.) Seems a bit perverse to be able to determine I very likely want to refine against map 1, but not to actually set it for me. I am usually launching coot from a script-generated command, so my maps are always in the same order and I can reliably set the refinement map to imol #1, so I'd like to do that on startup. Is there any real danger in coot just going ahead with a guessed refinement map instead of the halting dialog? (Given the subsequent confirmation screen and the possibility to undo.) Or likely I am missing something everyone else has figured out? Thanks, Seth
Re: [COOT] how to set the refinement map
Thanks Paul, Actually I do have a map button. But I'd rather write something in a script somewhere once than click the button and confirm the click EVERY time I start the program! Hmmm, I had tried the (set-imol-refinement-map 1) in my .coot but obviously the problem was the map did not yet exist. So close! A monkey in the wrench... but it works beautifully if I put the (set-imol-refinement-map 1) into a coot_refinement_map.scm file and then my script adds the --script coot_refinement_map.scm option to the command line launching the program (at the end, I guess, to be sure the map is already loaded by then). A small thing, but it felt time to get it right! Much gratitude (especially after building up a few new proteins and feeling that tangible time savings from coot's nice tools and keyboard shortcuts!), Seth On Mon, May 10, 2010 at 3:23 PM, Paul Emsley paul.ems...@bioch.ox.ac.ukwrote: Seth Harris wrote: Hello, After what felt like a reasonable amount of poking about, I can't find how to set the refinement map (yes, I tried 'set-refinement-map') although I did find that guess-refinement-map returns a good guess but doesn't seem to stop the Oops! Must Select Map to fit to! box from bothering me. Wow. It now strikes me that this is a pain if you don't have a Map button - which I guess you don't. Which makes me think that you are using the gtk1 version. OK, time for that to die out. (It could at least open the map selection dialog like what happens when you do Validate Check/Delete waters without first specifying a map.) Seems a bit perverse to be able to determine I very likely want to refine against map 1, but not to actually set it for me. I am usually launching coot from a script-generated command, so my maps are always in the same order and I can reliably set the refinement map to imol #1, so I'd like to do that on startup. In that case, I would have thought that (set-imol-refinement-map nnn) would do the trick (nnn is 1, in this case presumably). (you can only do that if map number nnn exists at the time). Is there any real danger in coot just going ahead with a guessed refinement map instead of the halting dialog? (Given the subsequent confirmation screen and the possibility to undo.) Or likely I am missing something everyone else has figured out? Maybe most others are using gtk2 version. Paul.
