Re: [COOT] DB-loop
On 30 January 2012 14:47, Phil Evans wrote: > Can someone explain Extensions->Modelling->DB Loop or point to documentation > (I've tried Google)? What are "Number of residues for basis"? > > Phil Assume we have a missing loop that we would like to get built. The conformation of the newly built loop candidates will depend on the residues we have already modeled on both sides of the gap. My understanding is that residues picked for basis (i.e. residues already modeled) will be included in the search and used as starting points for the new loop (and not just treated as "correct"). J.
Re: [COOT] New restraints, same name
I would like to second to most of Steven's, Seth's and Garib's points and would welcome a change that would enable us to use the same three letter code for different ligands within one coot session. Renaming ligands in pdb and cif files is a good workaround, however it is not more than a workaround and assigning different dictionaries to different sets of coordinates seems to be the Right Way to me. Just one comment to add: coot already has a mechanism to determine if a cif file matches the ligand with the three letter code in question: by checking the atom names. This, IIRC, was implemented to prevent ligands from flying apart in refinement in the case of a dictionary-mismatch. This check would still be useful (i.e. even if cif assignment to different molecules goes ahead), especially if coot continues to read in dictionaries from the refmac library, but also since different programs produce different atom names starting from the same smiles string. Coot could perhaps use the same mechanism to decide whether to use the dictionary for ligand rendering and simply not do it if atom names don't match? Using mmcif for coordinates and dictionaries in one file? -- yes please. And good luck with making it work consistently across programs so that users can just "get used to it"... On 24 January 2012 22:33, Garib N Murshudov wrote: > Hi All > > As I see the best available solution is to go for coordinates all in one. > I.e. ligands description and the rest of structure in one file. It should be > possible to do it with mmcif. > then each ligand (apart from standard ones) will be property of a coordinate > set and no conflict between ligands > Then everybody should use mmcif and get used to it. > > Regards > Garib > > > On 24 Jan 2012, at 22:12, Sheriff, Steven wrote: > > 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 h
Re: [COOT] mutate a residue to a custom monomer
Have you tried loading both the pdb and cif files for the custom residue? As far as I remember, custom ligands need both to be used in mutation -- but I rarely do that so I might be wrong... You can always revert to mutating "by hand": load pdb and cif, delete old residue, merge in new one, renumber residue, change chain ID, refine or edit torsions -- a little bit more clicks. JED. 2012/1/18 Takaaki Fukami : > Dear Paul, > > You taught me how to mutate a residue to a non-standard one. > >> [Centre on the VAL to be replaced] >> Extensions -> Modelling -> Replace Residue -> MVA > > It failed when I specify my custom monomer. > > To obtain a monomer, Coot seems to use "get-monomer", > and it was extracted from the default library file, > even if I supplied a custom cif file for the monomer. > > How do I mutate a residue to my custom monomer in Coot? > > Regards, > > Takaaki Fukami > > > > -Original Message- > From: Paul Emsley [mailto:paul.ems...@bioch.ox.ac.uk] > Sent: Friday, January 13, 2012 9:16 PM > To: 深海隆明(探索研究部蛋白構造解析Ｇ) > Cc: COOT@JISCMAIL.AC.UK > Subject: Re: How to connect N-methylated amino acid? > > On 13/01/12 12:00, Takaaki Fukami wrote: >> Dear Coot experts, >> >> I'm working on a peptide with an N-methyled amino acid in the middle. >> How can I connect this residue to previous/next residues? >> >> To simplify the problem, first I changed the residue to MVA >> (N-methyled-L-VAL), >> because its library file (MVA.cif) exists in $CCP4/lib/data/monomers/, >> in which it is defined as M-peptide as below. >> >> data_comp_list >> loop_ >> _chem_comp.id >> _chem_comp.three_letter_code >> _chem_comp.name >> _chem_comp.group >> _chem_comp.number_atoms_all >> _chem_comp.number_atoms_nh >> _chem_comp.desc_level >> MVA MVA 'N-METHYLVALINE ' M-peptide 21 >> 9 . >> # >> >> I prepared coordinates of the residue and make Coot read the MVA.cif file, >> then "refine zone" around the residue MVA, but MVA won't connect to >> neither previous/next residues. >> >> Doesn't coot recognize the M-peptide as with L/D-peptide? >> How can I define the connectivity between a special residue and >> standard amino acids? > > I have never before heard of an M-peptide - I need to update Coot to > handle such things properly. > > This is what I would do in the meantime, starting from scratch: > > File -> Search Monomer Library > "valine" > [I search list to fine the methyl-valine - MVA as you say] > Click "MVA" button > [Centre on the VAL to be replaced] > Extensions -> Modelling -> Replace Residue -> MVA > Edit -> Restraints -> "MVA" -> OK > Change the Group to "L-peptide" > [Triple Refine] > Done. > > Paul.
Re: [COOT] How we process the change of the conformation of the terminal residue in this situation
On 26 December 2011 03:25, Dialing Pretty wrote: > Dear All, > > You see the part labelled "D and "LARGE" in the attached image is the part > for the last residue in a chain, however it localizes in the red part. If I > can change the part labelled "D" and "LARGE" into the part labelled "F", the > red should have disapeared. > > But after several rounds of try by Coot, I have not make the above exchange. > > Will you please give me your suggestions on how to change the part labelled > with "D and "LARGE" into the part labelled by "F" with Coot or with some > other methods? > > Cheers, > > Dialing This is almost certainly doable in coot, with a bit of fiddling/practice. I would try to real-space-refine the terminal Glu (perhaps together with the Lys), and over-drag one of the side chain atoms into the blob of interest (hold Ctrl and drag a single atom further than its desired destination and it will pull the other atoms along once Ctrl is released). In some cases it can be easier to start with regularisation instead of real space refinement. There are other methods too, like editing torsion angles (both single and multi-residue, I think) and the rotate-translate option can come handy too. Just keep poking at those pesky residues -- it might take a couple of tries and some patience. It might actually be the main chain continuing into the area labeled F, with little density for the side chain, but it is hard to judge from a 2D image.
Re: [COOT] imodel vs delete-residue-with-altconf
On 20 December 2011 16:37, Paul Emsley wrote: > Hi JED, > > > On 09/12/11 13:29, Judit Debreczeni wrote: >> >> I used to use delete-residue-with-altconf in an extension, looping >> over a subset of residues returned by residues-with-alt-confs. >> >> As delete-residue-with-altconf no longer exists, > > > I must say that I was unaware of the disappearance of > delete-residue-with-altconfs. I don't remember it. Removing it does seem a > retrograde step. > Santa took it away about a year ago (I thought it was a result of the NMRification of coot) and we got unbound variable errors since, but I've got bullied into fixing it only recently. > >> I use >> delete-residue-with-full-spec instead, which requires an imodel. >> Unfortunately, residues-with-alt-confs does not return the imodel. >> >> I can, of course, assume that imodel = 1, which is true for the >> majority of the cases, > > > It is true for almost all crystallographic models. > > Most of the functions which take atom or residue descriptor arguments ignore > the model. This is historical laziness/unforesightedness/simplification > (call it what you will). > > >> but it is still an uneducated guess. My >> question is: what is the easiest way to get imodel in this context? >> > > Not possible AFAICS, sadly. even active-residue ignores the model. > OK, thanks, good to know. For the time being I will let it fall over if imodel!=1. > Now that I am more NMR-ified, this may well change. This will mean quite a > bit of change to the API. (I am OK with API changes until version 1.0 (then > stability restraints will be instated)). > I would be fine with API changes whatever the version number as long as they are announced and consistent. JED.
[COOT] imodel vs delete-residue-with-altconf
I used to use delete-residue-with-altconf in an extension, looping over a subset of residues returned by residues-with-alt-confs. As delete-residue-with-altconf no longer exists, I use delete-residue-with-full-spec instead, which requires an imodel. Unfortunately, residues-with-alt-confs does not return the imodel. I can, of course, assume that imodel = 1, which is true for the majority of the cases, but it is still an uneducated guess. My question is: what is the easiest way to get imodel in this context? JED.
Re: [COOT] reading chiral restraints from grade's cif files
>>> Anyway, it's something that I should fix. I'll add it for 0.7. > > revision 3793. > That seems to work, thanks. It seems, however, that the restraints editor fails to display/edit planar restraints if one of the planar groups has more than 25 atoms, which some molecules can be "contrary" enough to have... JED.
Re: [COOT] reading chiral restraints from grade's cif files
On 30 November 2011 15:06, Paul Emsley wrote: > On 30/11/11 10:52, Judit Debreczeni wrote: >> >> Grade (from Global Phasing) produces cif files with non-loop_ >> descriptions of chiral restraints, e.g.: >> >> _chem_comp_chir.comp_id INH >> _chem_comp_chir.id chir_01 >> _chem_comp_chir.atom_id_centre C1 >> _chem_comp_chir.atom_id_1 C >> _chem_comp_chir.atom_id_2 C2 >> _chem_comp_chir.atom_id_3 O >> _chem_comp_chir.volume_sign negativ >> >> >> This format seems correct to me and actually makes a lot of sense if >> there is only one chiral centre in the molecule. >> >> Coot, however, ignores such records entirely, so the chirality remains >> unrestrained, cannot be edited in the restraints editor or flipped by >> a keystroke. Using 0.7-pre-1 (revision 3792) [with guile 1.8.7 >> embedded] [with python 2.7.0 embedded]. >> >> Bug? Oversight? Feature? >> >> > > Oversight. I didn't think that anyone would be so contrary as to format > their chirality in such a way (it seems to me that they must have gone out > of their way to do so - I wonder why...) > Contrary? -- We are talking about the genuine and vanilla RCSB cif parser which I thought should be the gold standard? > Anyway, it's something that I should fix. I'll add it for 0.7. > Thanks. JED.
[COOT] reading chiral restraints from grade's cif files
Grade (from Global Phasing) produces cif files with non-loop_ descriptions of chiral restraints, e.g.: _chem_comp_chir.comp_id INH _chem_comp_chir.id chir_01 _chem_comp_chir.atom_id_centre C1 _chem_comp_chir.atom_id_1C _chem_comp_chir.atom_id_2C2 _chem_comp_chir.atom_id_3O _chem_comp_chir.volume_sign negativ This format seems correct to me and actually makes a lot of sense if there is only one chiral centre in the molecule. Coot, however, ignores such records entirely, so the chirality remains unrestrained, cannot be edited in the restraints editor or flipped by a keystroke. Using 0.7-pre-1 (revision 3792) [with guile 1.8.7 embedded] [with python 2.7.0 embedded]. Bug? Oversight? Feature? JED.
Re: [COOT] request to download free coot tutorial with free downloadable PDB file and mtz file used in the tutorial
Modern coots come with tutorial data. You can load them by: Extensions->Load tutorial model and data 2011/11/18 herohonan : > Hello: > http://www.biop.ox.ac.uk/coot/ > This website is about the "coot". You can download the software and the > tutorial here. And there are many other useful > information here. I hope it is helpful to you. > -- > Tong Huo > Ph.D candidate > College of Life Sciences > Nankai University > Tianjin, China > At 2011-11-18 15:14:56,"Dialing Pretty" wrote: > > Dear All, > > I am now learning coot baton peptide (or protein) building. Will you please > tell me a website where I can download free coot tutorial with free > downloadable PDB file and mtz file used in the tutorial as example? > > I am looking forward to getting your reply. > > Cheers, > > Dialing Pretty > >
Re: [COOT] solutions / workarounds for conect records.
On 9 November 2011 20:04, Francis E Reyes wrote: > Hi all > > It seems that converting a small molecule refined (shelx) with openbabel to > pdb results in a slew of CONECT records which Coot doesn't recognize. As a > result I've got a bunch of unbonded atoms for my ligand. Anyone have a > solution/workaround? > Coot reads shelx .res files, so potentially no need to convert, just try to open that with Files->Open coordinates. (The connectivity might still get messy if the structure is centrosymmetric, IIRC.) JED.
Re: [COOT] coloring by B-factors
On 17 October 2011 21:24, Alejandro Buschiazzo wrote: > Hi, > > I wonder how should I go about changing the range of the B-factor ramp for > coloring atoms, at will, in order to have a full range of colors even when > my pseudo-B factors go from, say, 0 to 1 (default settings in this case > display all atoms blue of course...) > Might not be exactly the scaling you are after, but in most cases this one does the job: http://biop.ox.ac.uk/coot/doc/coot.html#set_002db_002dfactor_002dbonds_002dscale_002dfactor
Re: [COOT] ball-and-stick issues
On 4 October 2011 00:41, Paul Emsley wrote: > On 30/09/11 19:58, Judit Debreczeni wrote: >> >> 1. Displaying ball-and-stick representation of a residue turns dashed >> lines representing LINKs ball-and-stick style for other (unrelated) >> residues. > > Driver bug, IMHO. > I can reproduce it on different machines and builds so I doubt that it is the case of a driver bug. > >> 3. Ball-and-stick representations are written to the state file, but >> seem to be mixed up in the display manager with other objects (e.g. >> displaying/undisplaying the first one switches the second map on/off >> etc.) after the state file is read back in. > > This can happen if a coordinates file is missing on re-reading the state > file. This is not easy to fix (due to scheme and python state files need to > be handled). > I can confirm that this happens even when all files are available for re-read, on the same machine. There are multiple maps and proteins loaded in the state, with multiple residues in ball-and-stick. Oh, and another one (from today's presentation): ball-and-stick representation does not follow colour changes of the model. I.e., changing the colour of the model does not change the colour of the ball-and-sticked residues. Should it? JED.
[COOT] crash upon mmcif read
0.7-pre-1 (revision 3669) [with guile 1.8.7 embedded] [with python 2.6.0 embedded] crashes when trying to read 1x8b-sf.cif, freshly downloaded from the PDB, on fedora12, fedora12 build. Earlier versions detected that this file was lacking cell, symmetry and phase info and failed more gracefully. The current version bombs with this: --- >> CCP4 library signal mtz:File not identified as MTZ (Error) raised in MtzGet << CCP4MTZfile: open_read - File missing or corrupted: /home/juditd/work/1x8b-sf.cif INFO:: not an mtz file: /home/juditd/work/1x8b-sf.cif cns_file_has_phases_p called cns_file_has_phases_p returns 0 >> CCP4 library signal mtz:File not identified as MTZ (Error) raised in MtzGet << CCP4MTZfile: open_read - File missing or corrupted: /home/juditd/work/1x8b-sf.cif INFO:: not an mtz file: /home/juditd/work/1x8b-sf.cif INFO:: data file /home/juditd/work/1x8b-sf.cif is not a valid mtz file /home/juditd/work/1x8b-sf.cif is not a .phs file /home/juditd/work/1x8b-sf.cif is a mmCIF file CIFfile: import_hkl_info - error getting cell /home/juditd/work/1x8b-sf.cif terminate called after throwing an instance of 'clipper::Message_fatal' ./coot-Linux-i386-fedora-12-gtk2-python/bin/coot: line 247: 3455 Aborted $coot_real $@ --- JED.
[COOT] ball-and-stick issues
1. Displaying ball-and-stick representation of a residue turns dashed lines representing LINKs ball-and-stick style for other (unrelated) residues. 2. Ball-and-stick representations are undisplayed and can no longer be turned on using the display manager if the stereo status is changed (e.g. to hardware and back to mono). 3. Ball-and-stick representations are written to the state file, but seem to be mixed up in the display manager with other objects (e.g. displaying/undisplaying the first one switches the second map on/off etc.) after the state file is read back in. Using 0.7-pre-1 (revision 3669) [with guile 1.8.7 embedded] [with python 2.6.0 embedded] on fedora12, fedora12 build and 0.6.2 stable on RHEL5, centos5 build. Tiny nuisances... and rather disastrous if one wishes to impress a VIP guest in the movie room. JED.
Re: [COOT] Change map name
> You can use (pythonic): > > set_molecule_name(imol, name_str) > > [Note: I recall some warning that you are encouraged not to use this on > maps; not sure why] > Perhaps because it only works on model molecules and not on map molecules?
Re: [COOT] show_select_map_dialog
> (Python scripting option verendus est)
>
> In python script, it appears that show_select_map_dialog simply shows
> the dialog and quits. I am trying to set up a method that would do
> certain things depending on the choice of map. So I use
> show_select_map_dialog, but it appears that it does not wait until user
> makes a choice there. I tried to put a sleep cycle for 10 seconds that
> would keep checking if map selection changed, but the dialog does not
> show until the cycle is over. Is there any way to show the dialog and
> then wait for user to make selection?
>
> Here is the version of the code that shows the dialog but then proceeds
> further without waiting for selection
>
> ---
> show_select_map_dialog()
> imodel = (imol_refinement_map() - shknum)/2
> highlight_model(imodel)
> ---
>
> Her is the code with sleep-cycle. This one only shows the map selection
> dialog after 10 seconds (something equivalent to yield function in wx is
> needed)
>
> ---
> from time import sleep
> imap = imol_refinement_map()
> show_select_map_dialog()
> for i in range(10):
> if imap != imol_refinement_map():
> break
> sleep(1)
> imodel = (imol_refinement_map() - shknum)/2
> highlight_model(imodel)
>
> ---
>
Not sure what you'd like to achieve, but perhaps the
map_molecule_chooser_gui is what you are looking for.
Something along the lines:
map_molecule_chooser_gui("This is what I'll do to your map",
lambda imol: my_map_manipulation_function(imol))
This brings up a map selector gui, the user selects the map, and you
do whatever you want with the imol picked up.
Other useful little widgets here:
http://www.biop.ox.ac.uk/coot/doc/coot.html#coot_002dgui
> --
> Coot verendus est
>
Indeed.
Re: [COOT] Selecting map for adjusting contour level by scroll wheel
> Does anyone have a script to assign a key to step the map number connected to > the scroll wheel? The scheme commands exist and I thought someone may have > done this already. It seems like an obvious shortcut. > > Thanks, Mark If you mean stepping to another map and making that scrollable, this might do what you want: --- (add-key-binding "Step scrollable map number" "M" (lambda() (let ((maps(map-molecule-list)) (current (scroll-wheel-map))) (if (not (null? maps)) (let ((l (memq current maps))) (if (> (length l) 1) (set-scrollable-map (cadr l)) (set-scrollable-map (car maps --- (Strangely, this doesn't update the scrolling radio button in the display manager...) If it's just about changing the current scrollable map's contour level, that can already be done with + and - on the keyboard. JED.
Re: [COOT] Coot balking at SHELX refined anisotropy
> Hi all, > > I am running Coot 0.6.2-pre-1(revision 2816). The OS is Open Suse 11.1. > Every time I try to open a SHELX refined pdb file with ANISOU cards I get > this error > > ERROR 14 READ: Unmatch in different records for the same atom > > Then it lists the line number of the first ANISOU card. If you remove all > the ANISOU cards it works. If you open an anisotropically refined pdb from > PHENIX it works. I've even checked the spacing in the pdb file to make sure > its correct. I can not see any difference between the SHELX and PHENIX > derived coordinates. I'm sure this is some simple idiocy on my part but if > you have any ideas I'm all ears. > > Katherine > > Hi Katherine, I've seen this error before -- it seemed to be related to the coexistence of ANISOU cards (correctly formatted) and a badly formatted HEADER record in the pdb file. If your file has a HEADER but no deposition code in it (which was the problem in my case) coot will fail to read the file on certain systems. RHEL4 is one of them, SuSE might be another one... Just get rid of the HEADER or fix it and see what happens. JED.
Re: [COOT] rigid-body fit by residue ranges
2010/1/15 Tatsuya KAMINISHI :
> Hi Paul,
>
> Thank you for your reply. But I would like to use this function quite often,
> and python/guile scripting could be helpful.
> In fact, the following guile one-liner I made based on Judit's suggestion
> still doesn't work for me:
>
> (rigid-body-refine-by-residue-ranges 0 (("G" 68 69) ("G" 109 110)))
>
> The version of coot I'm using is 0.6 (2540) from last December. Am I missing
> something?
yes... Well, my example was just to show what the list should look
like and not how it's generated. Sorry.
Try this:
(rigid-body-refine-by-residue-ranges 0 (list (list "G" 68 69) (list
"G" 109 110)))
or
(rigid-body-refine-by-residue-ranges 0 '(("G" 68 69) ("G" 109 110)))
JED.
useful?
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html
and also
http://xkcd.com/353/
Re: [COOT] keyboard shortcut for Rotate/Translate Zone
2009/11/13 Ben Eisenbraun : > Hello Cooters, > > I'm trying to add a keyboard shortcut for Rotate/Translate Zone. I > stumbled around a bit and decided on: > > (add-key-binding "Rotate-Translate Zone" "r" (do-rot-trans-setup 1)) > > But it doesn't quite work. I get this error: > > ((safe_scheme_command) Error in proc: key: misc-error args: (#f Wrong > type to apply: ~S (#) #f)) > > Any ideas on what I'm doing wrong? > > Thanks. > > -ben > > -- > | Ben Eisenbraun | Software Sysadmin | > | Structural Biology Grid | http://sbgrid.org | > | Harvard Medical School | http://hms.harvard.edu | > Try this: (add-key-binding "Rotate-Translate Zone" "r" (lambda () (do-rot-trans-setup 1)))
Re: [COOT] Real space refine with hydrogens
2009/9/9 Arnaud Basle :
> Hi,
>
> I have a peptide structure at 0.92A and for the latest stage of refinement I
> would like to real space refine a Met residue including hydrogens. The H are
> flying away from their original position and density.
>
> I am using shelxl for refinement (.res and .ins format not pdb).
>
> I read from the coot mailing list archive that coot 0.4.1 was not able to do
> so ("coot currently does not handle PDB V3 hydrogens. You need to tell
> reduce to write out old style hydrogens. This should take of this
> problem.").
>
> Is it still the case with the latest version of coot?
>
Well, yes and no.
Coot's been pdb v3 compliant for a while. This helps very little with
SHELX hydrogens though, as SHELX has a different convention for H
names. AFAICS, Met H atoms behave just fine (that's 0.6-pre (r2276) vs
SHELX-97-2). Other H atoms, e.g. those of Leu and Ile and the like are
somewhat more volatile. (The easiest is to ignore this and get them
HFIXed again in the next round of shelxing).
But hey, there are zillions of other reasons for upgrading to the
latest Coot (and a bleeding-edge OS... hmm).
JED.
Re: [COOT] Display Probe dots
2009/7/31 Paul Emsley : > Alex Theodossis wrote: > >> >> Is it is possible to configure the Probe output in Coot not to display >> contact dots between atoms of the same residue? >> > > I don't see how to do that in probe, so I guess not. If you can persuade the > authors/maintainers of probe to create such an option, then Coot will > support it. > > Paul. > Probe provides a flexible way to define the source and the target atoms that are used to calculate overlaps. So if you wish to visualise the environment of a residue with probe dots, you could specify the residue itself as the source and the rest of the protein as the target. E.g. for chain A reisude 318: probe -once -u -stdbonds -mc "chainA 318" "not (chainA 318)" my-protein-with-H.pdb > my-probe-dots.out where my-protein-with-H.pdb is the output of reduce. Ultimately one could build up the whole interaction map residue-by-residue, appending the new dots onto the already existing ones -- I'd imagine that this wouldn't be too difficult. The resulting dots can be read in like this: (handle-read-draw-probe-dots-unformatted "path/to/the/probe-dots.out" imol 1) where imol is the reduced model's imol. But I do agree with Frank that this would be a rather esoteric way of using coot/reduce/probe... JED. ps. for those who love to misuse coot in esoteric ways: wait until coot switches to guile 1.9 (or above) -- that comes with a brainfuck compiler embedded http://wingolog.org/archives/2009/07/26/the-good-hack
Re: [COOT] quick shortcut or script to zero occupancy using mouse
2009/6/5 hari jayaram : > Hi I have a very low resolution map in which I can barely see side chains . > I want to set to zero occupancy many residues and residue side-chains before > I do a refinement. > > Currently I am using the Residue-Info menu item to set each occupancy to > zero residue by residue . And in cases where part of the residue is seen , > atom-by-atom inside this menu entry. > > Is there a mode where I can keep the mouse active and clicking an atom will > set the occupancy to zero - and I can embark on a clickfest setting atoms to > zero occupancy. > Hi, seeing that no-one picked this up... here's a couple of suggestions. 1. I don't think there's a mechanism to set occupancies to zero with continuous clicks. (It would be a useful addition to the delete items window though.) We can, however, bind such a function to a key. Below an example of binding it to the key "z" (for zero). So you just hit z and then click on an atom to be zeroed. 2. My suggestion would be to simply set the occupancy of the whole sidechain to zero by hitting a key. Below a snippet that does that, again bound to "z". In this case you hit z and the occupancy of the active residue's (the one that's closest to the rotation centre) sidechain will be set to zero. 3. The most common scenario for me seems to be when I want to trim a sidechain in a way that only atoms sticking out of the density (at a given sigma level) are deleted or given zero occupancies. The third example is an attempt to do that with active residues, such that the connectivity of the sidechain atoms is preserved (as opposed to the function trim-molecule-by-map). You might need to tweak the sigma cutoff, see comments below. 4. As for setting occupancies of zones: http://www.ysbl.york.ac.uk/~emsley/coot/doc/user-manual.html#SEC147 HTH, JED. --- ;;; Example 1: set occupancy to zero by click. (define (set-occ-zero-by-click) (user-defined-click 1 (lambda (atom-info) (let ((imol (list-ref (car atom-info) 0)) (chain-id (list-ref (car atom-info) 1)) (res-no(list-ref (car atom-info) 2)) (ins-code (list-ref (car atom-info) 3)) (atom-name (list-ref (car atom-info) 4)) (alt-conf (list-ref (car atom-info) 5))) (set-atom-attribute imol chain-id res-no ins-code atom-name alt-conf "occ" 0.0) (if (residue-info-dialog-displayed?) (residue-info-dialog imol chain-id res-no ins-code)) (add-key-binding "Set clicked atom occupancy to zero" "z" set-occ-zero-by-click ) --- ;;; Example 2: set side chain occ to zero for active residue ;; might do nasty things to non-standard residues. (define (set-zero-occ-sidechain) (let ((atom-info (active-residue))) (if atom-info (let* ((imol (list-ref atom-info 0)) (chain-id (list-ref atom-info 1)) (res-no(list-ref atom-info 2)) (ins-code (list-ref atom-info 3)) (atom-list (residue-info imol chain-id res-no ins-code)) (mainchain (list " N " " CB " " CA " " O " " C "))) (let loop ((a atom-list)) (if (not (null? a)) (if (not (member (caaar a) mainchain)) (begin (set-atom-attribute imol chain-id res-no ins-code (caaar a) (cadaar a) "occ" 0.0) (loop (cdr a))) (loop (cdr a) (add-key-binding "Set sidechain atoms occupancy to zero" "z" set-zero-occ-sidechain) --- ;;; Example 3: trim sidechain by map for active residue (define (trim-sidechain sigma-cutoff del-or-zero) ;; del-or-zero: 0 for zero occ, delete otherwise (define (sigma-level-at-point imol-map x y z) (let ((density (density-at-point imol-map x y z)) (sigma (map-sigma imol-map))) (/ density sigma))) (let ((atom-info (active-residue))) (if (not (and atom-info (valid-map-molecule? (imol-refinement-map (info-dialog "No refinement map and model set") (let* ((imol-mol (list-ref atom-info 0)) (chain-id (list-ref atom-info 1)) (res-no(list-ref atom-info 2)) (ins-code (list-ref atom-info 3)) (imol-map (imol-refinement-map)) (atom-list (residue-info imol-mol chain-id res-no ins-code)) (simple-residues (list "ARG" "ANS" "ASP" "CYS" "GLN" "GLU" "ILE" "LEU" "LYS" "MET" "SER" "THR" "VAL")) (cyclics (list "HIS" "PHE" "TRP" "TYR")) (tlc (residue-name imol-mol chain-id res-no ins-code)) (delete-func (lambda (n) (if (eq? del-or-zero 0) (set-atom-attribute imol-mol chain-id res-no ins-code (car (cadr n)) (cadr (cadr n)) "occ" 0.0) (delete-atom imol-mol chain-id res-no ins-code (car (cadr n))
Re: [COOT] can coot get my monomers?
> Hello Everyone > > Where does coot get monomers from? > Is it my ccp4 distribution? Or the coot distribution (It's a kind of old > coot) > > I'd like to use get monomer for a ligand I've created a dictionary for - not > one known to ccp4. > > I can create the cif for the monomer (and the pdb) and give it an unused > 3-letter code. > I put the cif into the ccp4 monomer library directory tree > I added the new monomer to mon_lib.list > > I did this for both the ccp4 and coot distributions. > > I still get a fatal error that the monomer is not found in the library. > > If I read in the cif file, that doesn't work either (but I bet refinement > would work). > > Is there a different index file I need to update? > If I understood your question correctly, you would like to add some of your frequently used ligands/cofactors to the standard monomer library so that they can be easily loaded with get-monomer and refined without fiddling with a cif file. Following Garib's recent advice, one should 1. copy the cif file into the corresponding directory in $CLIBD_MON, i.e. ligand foo's cif file FOO.cif would go into $CLIBD_MON/f/ 2. add a line to $CLIBD_MON/list/mon_lib_list.cif to describe the ligand, e.g. FOO FOO 'FOO: Fluoro-O-orotyl bar ' non-polymer12 15 . I'm not sure if this is what you meant by mon_lib.list. There is another mon_lib.list file in $CLIBD_MON, but editing that doesn't seem to do the trick. My coot uses the refmac dictionary -- at least that's where it gets the user-defined ligands from. HTH JED
[COOT] ligands in alternate conformations
Hi, I'm wondering why adding alternate conformations to ligands (i.e. non amino acid residues) restricts the occupancy ratio to 50:50. I understand that ligands don't have rotamers (at least not ones that coot would know about) so I can't pick rotamers but I'd like to be able to specify the new occupancy with a little slide bar similarly to amino acid residues. Having non-1.0 occupancies complicate things further: I have a ligand with a bromine atom that has partly fallen off at the synchrotron and I refined it with occupancy = 0.5 (1.0 for all other atoms). When I split this residue coot sets the occupancies to 0.5 for every atom, except for the first half of the Br which will have 0.0. Again, I understand the logic behind this... but wouldn't it be nicer to have 0.25 for both halves of the Br so that it adds up to the original 0.5? RSR and regularize zone are also problematic for ligands in alternate conformations: unless I click on atoms that are part of the split region, RSR and regularize make the ligand explode. JED
Re: [COOT] how do I delete all objects with a script?
2009/3/2 Nathaniel Echols : > Is this even possible? Either Python or Scheme would be okay. I figured > out how to hide everything (in Python), but I'm trying to reload files via a > button, and they always have the same name, so the display manager becomes > confusing quickly. > thanks, > Nat This should close all molecules and maps: (map (lambda (imol) (close-molecule imol)) (number-list 0 (- (graphics-n-molecules) 1))) J.
Re: [COOT] python or scheme?
2009/2/25 Frank von Delft : > I'm totally not with Paul on this one (is scheme object-oriented???), and > eternally grateful to him and Bernhard for implementing python scripting. I think that the point was that scheme is not imperative and not particularly object-oriented (but allows both). > Once you understand how python fits, it's spectacularly powerful. > If you want a list of all commands available in the python interpreter -- > some native python, some from the scripting -- you can run the following in > the python script window: > import inspect; inspect.currentframe().f_globals.keys() > It doesn't tell you what the functions do or the arguments are (it's > possible in theory, haven't figured it out yet though), but it's a start. > You can do that in scheme too (in the scheme scripting window): (apropos-internal "") It will be a rather long list, but it will give you a hint what to google for. Another couple of hints: - there is no command completion in the scheme scripting window, there is in python - wincoot doesn't do scheme, but does python. - you can't do all gtk2 things from scheme (as coot doesn't come with guile-gnome), there's no such limitation in python. Hopefully one day there will be no such differences...? But I feel that these shouldn't put anyone off. Scheme is still fun and well worth picking up. J.
Re: [COOT] Key-binding for changing active map/molecule color
2009/2/24 Victor Alves : > Hi > > I have looked at the reference manual and can't seem to find a way to > fulfill my desire to change colors of the active map or molecule at > key-press. > > All the commands I found use "imol" which means you have to know the exact > number. If you're launching Refmac from within Coot, its useful that Coot > changes the map and molecule colors (as it does automatically) but sometimes > I don't like the chosen colors and would like to change them, just by > pressing a key. > > So, I would like to add a key binding to set the current (active) map to a > certain color and likewise do the same for the active molecule. > > Something like: > > (add-key-binding "Blue Map" "b" (lambda () (set-map-colour active-imol 51 > 128 178)) > > instead of having to use "imol". > > Thank you > > Victor Alves > > > This message was sent using IMP, the Internet Messaging Program. > This would colour the last non-difference map: (add-key-binding "Blue Map" "b" (lambda () (let loop ((map-imol-list (reverse (map-molecule-list (if (not (null? map-imol-list)) (if (= (map-is-difference-map (car map-imol-list)) 0) (set-map-colour (car map-imol-list) 51 128 178) (loop (cdr map-imol-list)))
Re: [COOT] where did add alt conf go?
Well, you still have to click on a residue to actually add the alt .conf. -- exactly the same way as you'd do when starting from the gui. On Wed, Jul 23, 2008 at 5:01 PM, Roni Gordon <[EMAIL PROTECTED]> wrote: > That only seems to get/set the type of alt. conf. required (Ca or entire > residue)... > > On Wed, 2008-07-23 at 16:48 +0100, Judit Debreczeni wrote: >> Even though it's not showing up in the terminal window, 'Add Alt Conf' >> does have a schemey equivalent: (altconf), so do many of it's siblings >> -- see section 3.73 in >> http://www.ysbl.york.ac.uk/~emsley/coot/doc/coot-reference-manual.html >> >> JED >> >> >> >> >> On Wed, Jul 23, 2008 at 3:20 PM, Roni Gordon <[EMAIL PROTECTED]> wrote: >> > Thanks Kevin... though I still don't see the scheme command; the only >> > thing in the terminal window is the (...-type-number) option. >> > >> > Roni >> > >> > On Wed, 2008-07-23 at 09:19 +0100, Kevin Cowtan wrote: >> >> Oops - it appears to be missing from the toolbar, however I can still >> >> get to it by opening the model/fit/refine panel from the calculate menu. >> >> >> >> K >> >> >> >> Roni Gordon wrote: >> >> > Hi all, >> >> > >> >> > I'm using coot-0.5-pre-1-revision-1185 -- love the new menus, look & >> >> > feel on FC8, but it looks like "Add Alt. Conf..." disappeared from the >> >> > menu choices and the dialogs. >> >> > >> >> > I tried to look in the reference manual, but I can't find something >> >> > obviously named as a script function... Paul/anyone? >> >> > >> >> > Thanks, >> >> > >> >> > Roni >> >> > >> >> > >> >> >> > > > >
