Re: [COOT] two operating systems two problems

[Kevin Cowtan]

Leonard Thomas wrote:
As for the other problem, I have a linux box running Fedora 6.   When 
trying to run through the sequence using the space bar the jump is VERY 
slow, go out get a coffee slow.  I know it is computer specific but 
really have no idea what to look at.   Oh, this problem is not version 
specific and Coot use to run fine.  No changes have been made to the 
system in ages which is why this is so puzzling.


Yup, same for me.

I think the problem is that the 'Smooth recentering' settings have 
changed to take into account faster graphics cards. So those of us who 
either have slow graphics cards, or chose not to enable 3d acceleration 
now suffer poor performance.


Go to Draw/Smooth recentering, and either turn it off or reduce the 
number of steps.


Kevin

Re: [COOT] 0.4.1 - Ubuntu packages

[Kevin Cowtan]

Hi!

Yup, there is an issue with these packages.

You need to edit the file bin/coot. Look for the line:

GUILE_LOAD_PATH=\
$COOT_PREFIX/share/guile/1.6:$COOT_PREFIX/share/guile:$COOT_PREFIX/share/guile/g
tk-1.2:$COOT_PREFIX/share/guile/gui:$COOT_PREFIX/share/guile/www:$COOT_PREFIX/sh
are/guile/site

Edit 1.6 to read 1.8.

You may also need to edit gtk-1.2 to read gtk-2.0.

Kevin

Mehdi AMINI wrote:

Hello,

It seems that there is an issue with the coot-ubuntu tar.gz packages. It
complain about a guile file "ice-9/boot-9.scm" :

DEBUG:: stating pydirectory /home/coot/autobuild/coot-gtk2/share/coot/python
WARNING python directory /home/coot/autobuild/coot-gtk2/share/coot/python
does not exist
ERROR: In procedure primitive-load-path:
ERROR: Unable to find file "ice-9/boot-9.scm" in load path


It will only works if I put it into /home/coot/autobuild/coot-gtk2/ , is
it a known issue ?

Thanks,

Mehdi

Re: [COOT] B value of new AAs

[Kevin Cowtan]

Or even better, we could implement B-factor refinement in coot!

(Working on it...)

Paul Emsley wrote:

I would use something like this:

(set-default-temperature-factor-for-new-atoms 50)

I see that this is not well documented.  Will fix.

Thanks,

Paul.

junfeng liu wrote:
Yes. the  default B factor of new AA is 20. I usually manual change it 
from that to the avearge B. Otherwise I have to copy fragment from 
other homology structures.
It will be much better for us  to set the B factor as  we expected 
instead of 20 in coot.

ta
leo
Daniel Schlieper wrote:

Hello,

just to make Coot even more luxurious: Would it be possible if added 
terminal amino acids inherited the B-value of the amino acid they get 
attached to?


I am building a loop at about 50 A^2, and would like to start the 
following refinement with my best guess as far as the B-values are 
concerned. Currently, that means revisiting all newly built amino 
acids and change their B-values.


Best regards, Daniel

Re: [COOT] how to display cartoon in coot

[Kevin Cowtan]

Not yet.

CCP4mg and pymol are both good tools for this task - the CCP4mg picture 
wizards make it particularly easy, and can do lots of other neat stuff 
too. Here's a screenshot...

http://www.ccp4.ac.uk/newsletters/newsletter46/articles/picture_wizard.png

and more info...
http://www.ccp4.ac.uk/newsletters/newsletter46/articles/newsletter_ccp4mg.html

Yong-Fu Li wrote:

Hello,

Is there a way to render the secondary structures in Coot? What are such 2ndary motifs based on? 


Thanks.

Yong-Fu


Yong-Fu Li
IAVI

Re: [COOT] gtk2 version for redhat

[Kevin Cowtan]

Don't use clipper from my site - you've probably picked up the new 
threaded version - we haven't tested this with coot yet.


You should run Paul's build-it-gtk2-simple script, which should build 
all the dependencies for you.

http://www.ysbl.york.ac.uk/~emsley/build-logs/build-it-gtk2-simple


hari jayaram wrote:

Hi , Bill,
Sorry I skipped this mail and have not yet tried the rpm you send out 
for 0.4.1 on my redhat machine. ( see below)


I really feel the need to get the traffic-lights working and get coot 
0.5-pre-1 compiled on my gentoo linux machine.

I have been trying to do get the compile to work

The coot configure command fails to see my clipper libraries. I have 
built my clipper libraries from scratch using the shell script on Kevin 
Cowtans page 
. 
The clipper build completed successfully and got installed in 
/usr/local/clipper


For coot, The configure command I am using is

" ./configure --with-python=/usr/lib/python2.5 --with-glib-prefix=/usr  
--with-glut-prefix=/usr/lib  --with-gtk-prefix=/usr  
--with-gtkgl-prefix=/usr/lib/gtkglext-1.0  --with-gtkgl-prefix=/usr 
--with-clipper-prefix=/usr/local/clipper 
--with-mmdb-prefix=/usr/local/clipper/lib  
--with-ssmlib-prefix=/usr/local/clipper/lib/"



Coot still refuses to "see" the library. ALso,  just once , the 
configure command did get past the Clipper library check and was running 
a "cc1plus" command. That command continued running for around 2 hrs and 
I finally killed the process. Now the configure gives the same output ..i.e


"checking for gsl-config... /usr/local/bin/gsl-config
checking for GSL - version >= 1.3... yes
checking for glib-config... /usr/bin/glib-config
checking for GLIB - version >= 1.2.8. .. yes
checking for gtk-config... /usr/bin/gtk-config
checking for GTK - version >= 0.99.7. .. yes
checking for GL... yes
checking for GtkGLArea... yes
checking for GtkCanvas... yes
checking for GLUT... yes
checking for MMDB... yes
checking for SSMLib... /usr/local/clipper/lib/
checking for Clipper... no
Error locating Clipper - a shiny new version of Clipper is required now
"
Any help in getting a brand new version of coot with traffic lights 
compiled will be greatly appreciated

Thank you for all your help
Hari



On Wed, Apr 16, 2008 at 7:18 PM, William Scott 
<[EMAIL PROTECTED] > wrote:


Please see if this works:

http://diablo.ucsc.edu/~wgscott/debian/rpm/coot-0.4.1-1.i386.rpm


If it does, I'll put together a 0.5-pre1 version.



On Apr 16, 2008, at 2:09 PM, Paul Emsley wrote:

hari jayaram wrote:

Hi I noticed that there is no redhat gtk2 version of coot
0.5pre 1 rev 958 or even earlier
I guess that means I am going to have to compile coot on my
redhat machine to get access to the traffic-lights and other
features

Can I cast my vote for a redhat python-gtk2 binary


I tried quite hard to do this (on RH8).

I failed and gave up.

Paul.

[COOT] Using Coot with PHENIX

[Kevin Cowtan]

There are some issues which may be affecting some people using Coot with 
PHENIX. If you try and use the two together in the wrong way, then you 
may get unexpected results. (Problems hashed out with help from Dirk).


phenix.refine produces two different sets of output files. I quote from 
the documentation:

  At the end of refinement the program generates:
  ...
  two maps: likelihood weighted mFo-DFc and 2mFo-DFc. These are
  in ASCII X-PLOR format. A reflection file with map coefficients
  is also generated for use in Coot or XtalView (e.g.
  lysozyme_refine_001_map_coeffs.mtz);

There are some CNS maps, which may be used in conventional graphics 
programs, and there is an MTZ file, which may be used in Coot or XtalView.


The difference is important. Coot and XtalView have a fundamentally 
different concept of what a map is to other graphics programs. As a 
result they require different information. Phenix.refine recognises this 
and provides appropriate information for each type of program.


In the last year we incorporated the ability to read CNS files into 
coot. As a result, some users have started reading the CNS map files 
into coot instead of the MTZ file. Unfortunately, this does not always 
work the way you would expect, because the map files has not been 
generated with Coot in mind. This may lead to misleading sigma levels, 
or, if the map is modified or masked in any way before giving it to 
Coot, much more serious artifacts.


The solution is simple: When using Coot, use the MTZ file which the 
phenix developers have provided for that purpose, *not* the CNS map 
files. In addition to giving the right answers, there are some other 
benefits:

 - The MTZ is much smaller, in case you want to archive it.
 - Using auto-open mtz, you get both maps at once, and the difference 
map is automatically displayed as such, saving mouse clicks.
 - The spacegroup and cell information are in the file, so it works 
even if you don't open the PDB file first.


..

You can stop reading here, the rest is detail for those who are interested:

Coot and XtalView use a different representation of electron density, a 
continuous crystal representation. Most other graphics programs use a 
bounded box representation.


The continuous crystal representation means that the electron density is 
everywhere, it is omnipresent. "If I scroll up to the heavens, density 
is there; if I place my ligand in the depths, density is there. If I 
drag over to the far side of the solvent, even there the density will 
guide my fitting." (*)


To generate a continuous crystal representation, you need a complete and 
consistent description of the electron density over the asymmetric unit 
(any asymmetric unit - it doesn't matter where in space). The bounded 
box representation need the electron density over the volume of the 
molecule.


It is not always possible to get the asymmetric unit representation from 
the bounded box representation, because in creating the bounded box some 
information may have been lost. However, you can always get it from an 
MTZ file, or from a map file on the condition that the map file is 
appropriately bounded.


Kevin

(*) Psalm 139 v8-10

Re: [COOT] Rotamers !!

[Kevin Cowtan]

P.S. Does anyone else have problems finding Clipper from the COOT 
./configure script even when one specifies the path, (c.f. 
http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT )

 ...or am I overlooking something?


Perhaps you are overlooking the autobuild script, which should do all of 
this for you?

 http://www.ysbl.york.ac.uk/~emsley/build-logs/build-it
or
 http://www.ysbl.york.ac.uk/~emsley/build-logs/build-it-gtk2-simple

Re: [COOT] wired stereo

[Kevin Cowtan]

Joachim Reichelt wrote:

This looks inconsistent to me:
If the center is the brightes, why do you not rotate around a point in 
this plane.
We often got sidechains out of the front of the screen during 
adjustment, if I scale up to fit it into the density.


That's interesting! When I want to move something, I usually lay it in 
the central plane of the screen, instead of having it pointing towards me.


Now the interesting question is whether this difference in practice is a 
result of the different depth cueing styles, or incidental to it.

Re: [COOT] where did add alt conf go?

[Kevin Cowtan]

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

Re: [COOT] Rotation angle !!

[Kevin Cowtan]

john kryst wrote:

Hi all !!


Hi!

1. When we do the superposition in coot, does it give the angle of 
rotation?  like it needs 30 deg to rotate and x A translation along the 
axis. I tried looking in the terminal but i couldn't get it.. it would 
be extreemly usefull, if coot prints the lmn of the rotation axis and a 
point on the rotation axis.


If you are using a pre-release build after revision 963 (April 17 2008), 
then SSM superpose should also display Euler and Polar angles in the 
terminal. The polar angles contain the info you want - kappa (3rd 
number) is the angle of rotation. Omega and phi (1st and second numbers) 
give the direction of the rotation axis.



2. How to colour each molecule separately...


Edit/bond colours

HTH,
Kevin

Re: [COOT] ipod version of coot?

[Kevin Cowtan]

I am hoping one day to make an ubuntu image containing coot, configured 
to run from a USB stick on an Asus EEE PC.


It might happen...

[COOT] Coot on Asus eee netbook...

[Kevin Cowtan]

OK, I got coot running on my Asus eee 900 netbook. It turned out to be 
reasonably simple.


I tried straight ubuntu first, and ran into a few problems. Fortunately 
there is a version of ubuntu for eee, here:

http://www.ubuntu-eee.com/
In addition to various fixes and hardware drivers, it has a smaller font 
and window decorations.


I followed the download and install instructions to create a bootable 
USB stick with ubuntu-eee 8.04 on it. This was plugged into the eee, and 
the machine started. Hit 'Esc' during the splash screen to get the boot 
menu and select the USB stick - I found detecting this to be unreliable 
- it may take a few attempts.


Ubuntu boots (slowly) from the stick, giving you a live system.

Next to install to the internal SD card - use the install icon on the 
desktop, and follow through the wizard. I did a manual partition rather 
than the normal guided partioning, for two reasons:

1. I wanted to use ext2 not ext3 to reduce wear on the SD card.
2. I didn't want to create a swap partition, for the same reason. The 
eee 900 has 1Gb ram, so swap shouldn't be needed.


Let the install run. When it is done, remove the stick and reboot. Note: 
the eee does not shut down properly, you may need to hold down the power 
button for 5s at the end of the shutdown.


Reboot, and you should get a grub menu with the old OS and new ubuntu as 
options. Boot into ubuntu. There are a few tweak to make:

1. Move fast changing directories onto tmpfs to reduce wear:
http://www.ubuntu-eee.com/index.php5?title=How_to:_make_the_fstab_changes
(the other changes are not needed)
2. Fix the shutdown problem:
http://www.ubuntu-eee.com/index.php5?title=Fix:_The_shutdown_on_hardy

No need to change the swapiness, because I didn't make any swap.

Finally, connect to the internet (wireless works fine), and download 
coot (the ubuntu 6.06 build works fine on 8.04). Unpack and run.


Next problem is screen size. I right-clicked on the top and bottom bars, 
properties, show hide buttons to allow me to hide the bars to make space 
when running coot. Launch coot. The default window is much higher than 
the 600px screen. Detach the refinement toolbar - then you can shrink 
the coot window until it just fits on the screen. You'll probably want 
to turn off desktop effects too (System/preferences/appearance).


Coot should work fine. Graphics performance is good - maps and models 
spin just fine. CPU is adaquate.


Kevin

Re: [COOT] Coot on Asus eee netbook...

[Kevin Cowtan]

Coot now fits on the screen of the eee (and hopefully other netbooks 
with 600px high screens) with the full toolbar!


Screenshot here:
 http://www.ysbl.york.ac.uk/~cowtan/coot/coot-eee.png

To get coot to fit on the tiny screen, there are two requirements:

 - firstly, you need the latest build. Bernhard has implemented code to 
automatically resize the icons to match the screen size.


 - secondly, you need to pick a desktop theme which does not put too 
much space between icons in the user interface. There are two suitable 
themes available on ubuntu-eee, called 'Glider' and 'Mist'. You can 
access these through System/Preferences/Appearance.


Note that I have also hidden the top and bottom bars.

Re: [COOT] can coot link to fftw3?

[Kevin Cowtan]

No, it can't. Clipper only speaks to fftw v2.

If fftw v2 is a problem, you can build clipper without fftw at all by 
using the kiss-fft overlay which removes the fftw dependence.

 http://www.ysbl.york.ac.uk/~cowtan/clipper/loveboat.html
That saves one dependency, but the calculation of maps will become 2-3x 
slower.


However I don't think the autoconf knows about this, so it'll need some 
hacking.


William G. Scott wrote:

If so, how do you tell configure?

Thanks.


William G. Scott

Contact info:
http://chemistry.ucsc.edu/~wgscott/

[COOT] Coot mouse controls crib sheet...

[Kevin Cowtan]

For the short of remembering, here is a coot mouse controls crib sheet...



coot-controls.pdf
Description: Adobe PDF document

Re: [COOT] problem with connectivity in Ubuntu-version of Coot

[Kevin Cowtan]

You mean something like this?
http://www.ysbl.york.ac.uk/~emsley/coot/ugly.png

You have a non-default language. setenv LANG C (or LANG=C if you prefer) 
before starting coot.


The problem may also be due to LC_ALL. So, if the above doesn't work try 
also:


 setenv LC_ALL C

 setenv LC_NUMERIC C

if using bash, one would unset LC_ALL and unset LC_NUMERIC


Quoted from the Coot FAQ: 
http://www.ysbl.york.ac.uk/~emsley/coot/coot-faq.html


I normally use
unsetenv LANG LC_ALL LC_NUMERIC
or
unset LANG LC_ALL LC_NUMERIC


Anne Mølgaard wrote:

Dear Coot-users,

We have previously used Coot on Fedora without problems, but switching to 
Ubuntu has created some problems. The problem appears when a molecule is 
loaded into Coot. All atoms are loaded, but the connectivity is corrupted and 
the molecule appears as a collection of two-three atom bits. We have tried to 
run side-by-side executions of Coot on Fedora and Ubuntu respectively, and 
the only difference in the output to the screen is that in Ubuntu, the cell 
parameters are listed without decimals. 

We are running Coot version 0.4.1 precompiled for Redhat and Ubuntu, 
respectively. Our Ubuntu version is 7.10.


Has anyone experienced similar problems, and if so, do you have a fix?

Best regards,

Anne Mølgaard

Re: [COOT] can coot link to fftw3?

[Kevin Cowtan]

MATSUURA Takanori wrote:

Hi all,

From: Tim Fenn <[EMAIL PROTECTED]>
Subject: Re: [COOT] can coot link to fftw3?
Date: Tue, 2 Sep 2008 10:20:17 -0700


try compiling clipper with -fno-strict-aliasing, or drop the
optimization flags to -O1 or lower.


For fundamental solution is "use union type" in clipper.
See the section of -fstrict-aliasing in "man gcc".


The reason I haven't done this is that the one function for which this 
is an issue is performance critical, and it is not clear to me that the 
union implementation will optimize as well. It all comes down to how 
good the gcc optimiser is. I will try it when I get time.


Kevin

Re: [COOT] edit backbone torsions?

[Kevin Cowtan]

Are you looking in the model/fit/refine window, or in the toolbar? The 
toolbar does not contain everything that is in the window, due to space.


Michele Lunelli wrote:
I recently switched from version 0.4 to version 0.5.1-pre-1 gtk2 
revision 1494. It works great, but I cannot find the "edit backbone 
torsions" on the Model/Fir/refine menu or somewhere else. Moreover, I 
cannot find how to modify general torsions.

Am I missing something?

Thanks for helping
Michele

Re: [COOT] edit backbone torsions?

[Kevin Cowtan]

Donnie Berkholz wrote:
As you no doubt know, it creates a lot of confusion and is generally 
poor usability to have two things that appear almost identical but 
aren't. Is there some way to make it more obvious (visually, etc) that 
the toolbar is different from the M/F/R window?


Yes, we are thinking about this. I've answered the same question at 
least 3 times (and Paul and Bernhard probably more). That's a pretty 
robust indicator that the design is not right.


(Of course, changing things always creates confusion, even if the change 
is clearly right, but IMO the level of confusion here goes beyond that.)

Re: [COOT] strict NCS restraints automatic?

[Kevin Cowtan]

Are you aware of "Extensions/NCS/Copy NCS chain"? (You'll need 0.5).
In 3 clicks and a chain ID it will copy all changes from one chain to 
every other copy.


It won't do further changes on the fly though. (That is certainly 
possible, but needs careful design thought - consider the confused user 
who edits chain A, discovers B no longer fits, edits chain B, discovers 
A no longer fits.)


Kevin

Daniel Schlieper wrote:

Dear Paul,

I would like to build a hexamer with strict NCS restraints. The coot 
documentation mentiones the function (add-strict-ncs-matrix ...), but I 
wonder if there is a similar automatic function? Coot does a great job 
in displaying the NCS ghosts, so the matrices are known to the program 
already. The function that I have in mind would repeat all building 
steps to the other chains whenever I change anything in one chain.


Is that implemented already? If not: could you add this function to the 
wish-list, please :-) Or is it to complex to implement?


Best regards, Daniel --
Daniel Schlieper, Heinrich-Heine-Universitaet, Duesseldorf, Germany

Re: [COOT] symmetry molecules in H32

[Kevin Cowtan]

Doesn't mmdb read the 'old' lines from syminfo.lib?

In which case, H 3 2 should work.
H32 without spaces clearly won't, and I don't think such a symbol would 
be present in a modern (remediated) PDB file.


symbol ccp4 155
symbol Hall ' R 3 2"'
symbol xHM  'R 3 2 :H'
symbol old  'H 3 2'


Eleanor Dodson wrote:

Paul Emsley wrote:

James Whittle wrote:

Hi-

I'm trying for the first time to work with a structure in spacegroup 
H32. Coot reads the CRYST card, but when I build a helix, or look at 
a H32 PDB entry, the symmetry mates appear squished. I know there is 
some discussion about handling this spacegroup: do I need to change 
the CRYST line to get the structure to display correctly?


 what timing :-)

OK, so the answer is that Coot does not support such a spacegroup 
symbol.  You need to specify it as "R 3 2 :H".


Paul


Paul - you have to fix this - until such time as PDB depositions return 
such a symbol. At  the moment they have H32

E

Re: [COOT] problem in coot installation in ubuntu

[Kevin Cowtan]

Hi!

Firstly, do you need to build coot at all? There are binary packages 
which work just fine on Gutsy. You can install them wherever you want on 
your system, and they should just work.


Secondly, if for some reason you do want to build your own (you want to 
make changes to the code???), then are you using the 
build-it-gtk2-simple script?

http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT#Installation_from_source_code
Building coot without this script requires days or weeks of messing 
around with dependencies. With this script it is usually pretty easy.


Kevin

Rimi wrote:

Hi all,
  I am new to coot. Recently I tried to install coot in my ubuntu
gutsy. But it can not find mmdb library somehow. Below is the message

Re: [COOT] problem in coot installation in ubuntu

[Kevin Cowtan]

Tim Fenn wrote:

Why does coot require a 3000 line hand written shell script to set up
the build process?


Well, if you look at the script (which I guess you have), then I think 
you already have the answer... which suggests to me that I have 
misunderstood the question. Maybe the question you are actually asking 
is not the one which is obtained by a simple surface reading of your 
message. Could you clarify perhaps?


Thanks,
Kevin

Re: [COOT] Coot and Bond Display wrong in Linux (ubuntu)

[Kevin Cowtan]

Hi!

The problem is that your computer is set up to use comma for separating 
decimals: PDB files use full-stop.


The issue is covered in the coot FAQ - pasted below:

I get bizarre connectivity and other weirdness on reading files

You have a non-default language. setenv LANG C (or LANG=C if you prefer) 
before starting coot. This has recently been added to the setup files in 
the source code (it is not in version 0.0).


The problem may also be due to LC_ALL. So, if the above doesn't work try 
also:


 setenv LC_ALL C

 setenv LC_NUMERIC C

if using bash, one would unset LC_ALL and unset LC_NUMERIC



Willem Bleymueller wrote:

Dear Coot Users,

I have installed several versions of coot (0.3.3, 0.4.1 and 0.5) on
Ubuntu Linux Version 8.04.1 (amd64 and i386).
With each version and on each architecture the bonds are not drawn
correct.
Several bonds are not drawn at all so that there are objects that look
like stars, which correlate with beta or gamma carbons.

I've put an image of the "Complex of Drosophila odorant binding protein
LUSH with butanol"
which you can easily get with the Accession Code 1ooh
and an image of benzene on my webserver at
http://www.crossbone.org/coot/1ooh.ppm
and 
http://www.crossbone.org/coot/benzene.ppm

so you can get a better impression of what I mean.

I hope someone knows how I can solve this issue

Many Thanks Willem Bleymueller

Re: [COOT] Coot 0.5.2 released

[Kevin Cowtan]

One more feature:

Auto-open MTZ now automatically opens all avilable maps from a file. It 
recognizes the default map column names from refmac, phenix.refine, 
phaser, dm, parrot, and pirate.


Paul Emsley wrote:

   o FEATURE: A "Delete Molecule" button is now available in the
 Display Manager [TJS].

   o FEATURE: show-rotamer-dialog is now available from the scripting
 layer (hence `quick rotamer' keybinding) [FvD].

   o FEATURE: Manual definition of NCS ghost matrices - GUI added.

   o FEATURE: overlay-my-ligands function introduced - GUI added.

   o FEATURE: A simple interface to electrostatic surfaces has been
 introduced (Extensions -> Representations).

   o FEATURE: rotate-chi feature introduced.  For use with a PowerMate.

   o FEATURE: keyboard-based Go To Residue for quicker navigation.

   o CHANGE: NCS ghost work using LSQ to get the matrix, not SSM.

   o CHANGE: Display manager toggle buttons replaced with check
 buttons.

   o CHANGE: make-dynamically-transformed-ncs-maps takes an extra
 argument specifying if new maps should overwrite previous maps of
 the same name.

   o CHANGE: Extensions menu re-worked.

   o CHANGE: Keyboard zooming is now smoothed.

   o BUG-FIX: the chi angle bond highlighting works again.

   o BUG-FIX: The Cancel button in Save Restraints now works.

   o BUG-FIX: Check/Delete waters in Check mode no longer causes a
 crash when the "Close" button is clicked.

   o BUG-FIX: Atom elements are inferred from the atom name.

   o BUG-FIX: writing of cifs from the Restraints editor has been
 improved [JED].

   o BUG-FIX: chiral restraints specified as "BOTH" can now be edited.

   o BUG-FIX: "Flip peptide" now flips the peptide H atom too
 [Joel Bard].

   o BUG-FIX: Ligands can now have their torsions manipulated in
 CA+Ligands mode [Ingo Korndoerfer].

   o BUG-FIX: NCS residue range edits now apply to more than the first
 peer.

   o BUG-FIX: Coot now can read PART cards with a site occupancy
 factor from a SHELXL .res file [Mirek Gilski].

   o BUG-FIX: Fixed crash on using multiple geometry (Distance and
 Angles) dialogs.

   o BUG-FIX: The Reset View button has been reworked.

   o BUG-FIX: Ball & Stick additional representations has been
 reworked and now move as the molecule gets updated.

   o BUG-FIX: Ramachandran improvement function has been improved.

   o BUG-FIX: Rotamers and simple refinement now work with residues
 with insertion codes.

   o BUG-FIX: The rotamer graph no longer rescales on updating a
 molecule.

[COOT] A Christmas gift...

[Kevin Cowtan]

For those of you running recent nightly builds (at least 1709, 
preferably 1713):


- open a map
- open a scripting window
- type in scheme:
   (find-helices)
  or in python:
   find_helices()
- There is a corresponding command for strands. I'll leave the 
instructions to your imagination.


(Note the current scripting interfaces is temporary, and will be 
replaced by something more flexible next year).


Kevin

Re: [COOT] Dropping Gtk1 version [was Re: overlapping buttons in molprobity check script]

[Kevin Cowtan]

There is a separate gtk2 build script:

http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT#Installation_from_source_code_via_autobuild_scripts


Pete Meyer wrote:

Is there anyone who needs the GTK1 version?  (And if so, why?)


Last I checked, gtk1 is still the default in the build-it script.  Am I
using an outdated way of compiling coot?

Pete

Re: [COOT] Before/After RMSD for SSM superpositions?

[Kevin Cowtan]

Clipper already uses quaternions internally - I suspect one is already 
used as an intermediate step when converting between Euler and Polar 
conventions. So it *should* be easy to output this (but it is not 
assured - the code in question might be part of ssm, which cannot see 
clipper).


So I can look into this. Is it useful to print out the quaternion, or is 
this information only useful if it can be displayed graphically?


I guess we should be able to put together a clever graphic which shows 
the rotation axis, the angle of rotation, and the screw translation all 
at once.


Kevin

Ethan A Merritt wrote:

SSM superposition is a great tool, but I wonder if Coot could not
report a few additional useful quantities that result from it.

In particular, I would like it to report both before + after RMSD
values for the superposition.  Also, it would be nice if it would
report the rotation as a quaternion in addition to the Euler and
omega/phi/kappa conventions.

For example, suppose that I want to compare two dimeric structures.
Let's say one of them has component monomers A and A'.
The other one has component monomers B and B'.
For simplicity, let's say that really these are the same dimeric
protein but A:A' is the apo form and B:B' is a ligand-bound form.

I can easily use SSM to superimpose B onto A, and B' gets
carried along for the ride.  So then I look at this and notice
that B' is not perfectly superimposed onto A'. I think
to myself, "Aha, the intermonomer angle between A:A' is obviously
different than the angle between B:B'.  I wonder by how much?"

I would like to be able to report the difference between these two
structures by saying something like:

  "Upon ligand binding the second monomer (A') of the dimer rotates by
   XXX degrees relative to the first monomer (A).  This conformational
   change corresponds to an RMSD displacement of YYY for the
   CA atoms in monomer A'"

Both of these quantities XXX and YYY should fall out directly from a
second run of SSM that starts from the B-onto-A model and asks
for a superposition of B' onto A'.  But unfortunately Coot doesn't
report them (or at least not that I can find), so I am reduced to
exporting my various superpositions and Euler angles into other
tools to derive 2 simple numbers.

For bonus points, Coot could actually display the axis of the
quaternion on the screen.  In a favorable case one might immediately
learn that the observed rotation was about a particular hinge point
or other structural element.  (I've switched here to an example
use that involved inter-domain rotation rather than inter-monomer
rotation).

cheers,

Ethan

[COOT] Anyone got Coot to build on openSUSE?

[Kevin Cowtan]

I can't do it, and I can't figure it out. I keep getting errors like 
these at various steps:


/bin/sh: symbol lookup error: 
/home/coot/autobuild/coot-pre-release-gtk2-python/lib/libreadline.so.5: 
undefined symbol: PC


I suspect that LD_LIBRARY_PATH is implicated, but nothing I've tried works.

Re: [COOT] python or scheme?

[Kevin Cowtan]

Some of these things are not difficult, they just need a little time and 
the ideas.


I wonder if we need a 'Coot Janitors' project, modelled on the Linux 
'kernel janitors', which helps people get involved in doing some of the 
easier jobs that needs to be done.


If we were to start writing 'how to contribute to coot' documentation, 
how many people would be interested in actually doing it?


Kevin

Alastair Fyfe wrote:
my nomination for "Most Useful Improvement to the Reference Manual" 
would be a verbosity setting that emitted traces to the console window 
on invocation of each function for which a scriptable wrapper existed 
(basically being able to follow all interpreter to implementation 
transitions). Currently the console output is quite helpful, but could 
be more so.

thanks,
Alastair

Paul Emsley wrote:

Markus Dehnhardt wrote:

> Dear cooters,
>
> I am new to coot, but I have already discovered how powerful
> extensions and key bindings can be. My question is quite simple: if
> I want to generate my own extension or keybinding, which scripting
> language is better suited? I am not very familiar with either but
> willing to experiment.
>
> There were similar questions already on this mailing list but there
> are a couple of things that are not clear to me:
>
> Some of the documentation is for python some for scheme: "the
> scripting interface" is python and the "reference manual" is
> scheme. Are all functions awailable for both? Or does one have any
> advantage over the other?

Sigh... Well, you are not the first person to be confused by this. The
state of the scripting documentation has been reported as problematic
for a while.  I don't know what do to about it that does not involved
a lot of work.

Yes, the User Manual is mostly written with schemey examples.  The
reference manual I have not looked at for years :-/, the scripting
interface page is also automatically generated and provides an
interface from a C-programmers point of view - which is very like that
for Python.  I use often this quite often.  The "scripting interface
for functions written in scheme/python" should equivalent access to
functions that do the same thing.

The syntax of the function calls can be readily converted between
scheme and python.  There are notes available on how to do this.

The functions that we saw today, for example, could have equally well
have been written in python.

> What is other users preference: python or scheme, and why?

For those who are not influenced by me, python I'd say.  And they
chose python because it is more readily picked up for those with an
imperative or object-oriented mind-set.

Like the dolphins, I'd choose scheme for exactly the same reasons.

> How often do people, other than developers, create extensions?

Hard to say, but my feeling is "not often enough".  And that is, I
suppose, is due to the poor state of the scripting/extension
documentation.

That and the fact that it takes an investment of time to learn the 
scripting

language, the Coot extensions API and the GUI toolkit.

> And finally to the scheme scripters: how did you learn scheme?

The Little Schemer and Ken Dybvig's "The Scheme Programming Language".

To answer your question: python or scheme?

Yes!

We provide the best 2 languages so that you have the choice.

How to choose?  Read "The Little Schemer" - if you think it is
delightful and stimulating, use sheme.  If you think it is hateful,
irrelevant and full of irritating silly parentheses, use python.

HTH,

Paul.

Re: [COOT] Feature Request: Notes

[Kevin Cowtan]

Hmmm... Could probably be done with MMDB's UDD records. Then notes would 
be attached to atoms (maybe residues?). THis has the advantage that if 
you move the module to a different assymetric unit you retain the comments.


It might be nice to save them in the PDB file as remarks, but while I 
think recent MMDB can read remarks, I'm not sure if it can write them?


Also relevent to future PDB spec.

David Briggs wrote:

Seconded!

That is a fantastic idea - so essentially a label assoicated with a
feature & a set of co-ordinates.

D

2009/3/11 Dirk Kostrewa :

Dear Paul,

this is a feature request: I would like to attach notes to the structure,
like "water or sodium", "alternative conformation?", "peptide flipped", that
should be displayed in the next session like labels as a "three-dimensional"
notebook of what I've already done or want to do. This can be very useful,
especially to avoid perpetual re-fitting/omitting of the same feature again,
or simply to mark checkpoints. It should be possible to put a note both at
an atomic position or at the pointer position (to mark unexplained density
for instance). The notes could be saved with the session file or as an
external file that could be read into a new session.
Could you please think about adding this feature?

Best regards,

Dirk.

***
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...@lmb.uni-muenchen.de
***

Re: [COOT] Question about scale of ED maps from phenix vs map coeffs when displayed in COOT

[Kevin Cowtan]

You can't read an Xplor map from phenix into coot and get the right 
contour levels UNLESS you change your phenix settings to output a map 
covering the unit cell instead of the molecule.


The Xplor maps output by phenix are output in O mode, not Coot mode, by 
default. This is due to a fundamental difference in understanding what a 
map is between Coot and older programs.


A better solution is not to use the maps at all, and use the mtz output 
by phenix for this purpose.


Schubert, Carsten [PRDUS] wrote:
Hi, 
Sorry for the crosspost, but I am not sure were the problem is located:
I noticed that the xplor maps generated by phenix seem to be on a different scale than the maps generated from the map-coefficients from the same refinement run when the maps-coeffs are read into coot. Usually I only read in the map-coeffs and the scale seems reasonable to me, i.e. average density ~0.28 e/A3 at 1 sigma for a 2fofc map. The map from the same run (converted to ccp4 map in mapman) is at 0.55e/A3 at 1 sigma, when displayed in coot. 

The map should be normalized in phenix (apply_sigma_scaling=True) and the stats from mapman indicate an RMS deviation of ~1. For fofc maps I need to crank up the display to 6 sigma to get an equivalently looking map as the one from the map-coefficients at 3 sigma contour level. Any hints as to were the factor of 2 comes from, coot or phenix? 


Cheers,

Carsten

Re: [COOT] svn revision 1950 and rigid body fit zone

[Kevin Cowtan]

Yes, Eleanor Dodson has reported the same problem. Bernhard is trying to 
fix it.


hari jayaram wrote:

Hello ,

I just noticed that rigid body fit zone in revision 1950 stops expecting 
user mouse clicks after clicking on the first atom .


Is anyone else seeing this.

Also the Extensions-All Molecule MR stepped refine  crashes at random 
points after going through about 200-400 residues ( I noticed this with 
rev 1947 and updated..but am seeing it with revision 1950 as well)


I am running Ubuntu Hardy Heron ( 8.04 , 64 bit , coot subversion gtk2 
python build )

Thanks

Hari

Re: [COOT] graphics window resize Y direction

[Kevin Cowtan]

Two things to try:

1. Have you customized the toolbar? Turn off some of the icons and it'll 
 get smaller.


2. Does "coot --small-screen" help?


Drew Waight wrote:

Hello All,

I recently install coot 0.6-pre. My monitor is 1280x1024 and when I
open coot, the graphics window takes up the entire vertical direction and
cannot be resized any smaller. (I can only move the window by hiding my top
and bottom menus, which is inconvenient). The script graphics_window_resize
only works for the X direction. I did not have this problem in 0.5, and
could even run coot on my 720p TV (768 in the Y). In an effort to fix this
issue I compiled 0.6-pre-gtk2-python myself but with the same result. I
looked through the code to the best of my ability but couldnt locate
anything useful. I am not entirely sure whether this is a ubuntu-gnome,
graphics-card display or coot issue, but any help would be appreciated as I
only need the graphics interface to be ~20pixels smaller. Thanks

   Drew
 (new 2084x1152 monitor ordered anyway)

Re: [COOT] svn revision 1950 and rigid body fit zone

[Kevin Cowtan]

OK, we are struggling to isolate this problem, there may be several 
separate issues at stake.


Can you send a full bug report?
Do you have Ramachandran restrains turned on?
Does the same problem occur if you turn them off?

hari jayaram wrote:

Hello ,

I just noticed that rigid body fit zone in revision 1950 stops expecting 
user mouse clicks after clicking on the first atom .


Is anyone else seeing this.

Also the Extensions-All Molecule MR stepped refine  crashes at random 
points after going through about 200-400 residues ( I noticed this with 
rev 1947 and updated..but am seeing it with revision 1950 as well)


I am running Ubuntu Hardy Heron ( 8.04 , 64 bit , coot subversion gtk2 
python build )

Thanks

Hari

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

Τι γλώσσα είναι ομιλίας σας?

Ezra Peisach wrote:
One of the other misfeatures of rpath is that it sets DT_RPATH and not 
DT_RUNPATH  - which means that LD_LIBRARY_PATH will not override the 
setting... This means if you have a library installed in the RPATH and 
you set LD_LIBRARY_PATH (for in tree development  - or old installation 
and a new tree) you are using the wrong library.  This is a magical 
option to ld to use DT_RUNPATH - but I do not remember it - but then you 
can use LD_LIBRARY_PATH to override... See the ld.so manoage for 
DT_RPATH vs RUNPATH


Ezra


Matt Harrington wrote:

On Thu, May 28, 2009 at 9:45 PM, Johan Hattne
 wrote:
 

However, I was wondering if there's a better way than to just ignore
this.  Perhaps RPATHs could be removed entirely from the upstream
build?
  

Couldn't this, perhaps, be fixed using for instance chrpath (disclaimer:
I've never used it myself)?  I suppose even if the rpaths were removed
by upstream, your problem wouldn't go away.




Yes, that's another workaround I could do at my end of things, but I
was hoping they could be removed entirely from the precompiled
package.  I have a feeling they crept in there through autobuild and
probably aren't even required on Paul's development machine.  I think
he's away right now, so perhaps we can revisit this in a week or two.

Matt

  

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

OK, I understand, RPATH bad.

But as far as I can tell we don't use RPATH. Coot uses LD_LIBRARY_PATH, 
which is only set by a wrapper script which launches the actual binary, 
and so the use of LD_LIBRARY_PATH is never exposed to the rest of the 
system (which I understand is the only problem with LD_LIBRARY_PATH).


Of course, I have no idea how Coot is being built by downstream 
packagers - only how we build our binaries (and I have rather limited 
understanding of that - hopefully Paul will be able to comment later in 
the week).


K


Matt Harrington wrote:

On Mon, Jun 1, 2009 at 1:14 AM, Kevin Cowtan  wrote:


Τι γλώσσα είναι ομιλίας σας?



This should shed some light on the subject:

http://en.wikipedia.org/wiki/Rpath_(linking)

Matt

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

Oh, hang on.

If I do:
 objdump -p `which coot-real` | grep RPATH
then I get:
  RPATH 
/y/people/emsley/autobuild/Linux-bragg1.chem.york.ac.uk-pre-release-gtk2/lib


I can't see where that is coming from, but I'm pretty sure it is 
redundant, since that directory doesn't exist on the machine where I am 
running the program.


K

Kevin Cowtan wrote:

OK, I understand, RPATH bad.

But as far as I can tell we don't use RPATH. Coot uses LD_LIBRARY_PATH, 
which is only set by a wrapper script which launches the actual binary, 
and so the use of LD_LIBRARY_PATH is never exposed to the rest of the 
system (which I understand is the only problem with LD_LIBRARY_PATH).


Of course, I have no idea how Coot is being built by downstream 
packagers - only how we build our binaries (and I have rather limited 
understanding of that - hopefully Paul will be able to comment later in 
the week).


K


Matt Harrington wrote:
On Mon, Jun 1, 2009 at 1:14 AM, Kevin Cowtan  
wrote:



Τι γλώσσα είναι ομιλίας σας?



This should shed some light on the subject:

http://en.wikipedia.org/wiki/Rpath_(linking)

Matt

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

Johan Hattne wrote:

But this is intended behaviour?  If I compile against
${HOME}/lib/libguile* I wouldn't want the runtime linker to use
/usr/lib/libguile*, because presumably my build requires something that
/usr/lib/libguile doesn't provide.


Don't worry about it. The usage of RPATH in coot is as far as I can tell 
completely unintentional. If we can find out where it is sneaking in, 
then we'll get rid of it.

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

Peter Keller wrote:

On Mon, 1 Jun 2009, Kevin Cowtan wrote:


OK, I understand, RPATH bad.

But as far as I can tell we don't use RPATH. Coot uses 
LD_LIBRARY_PATH, which is only set by a wrapper script which launches 
the actual binary, and so the use of LD_LIBRARY_PATH is never exposed 
to the rest of the system (which I understand is the only problem with 
LD_LIBRARY_PATH).


Not quite: if your application starts a subprocess and runs something 
else, that subprocess will inherit LD_LIBRARY_PATH as set in the 
wrapper. That
might be fatal for whatever you are running in the subprocess (unless it 
too is invoked from a wrapper that overrides/unsets LD_LIBRARY_PATH).


On the whole, I prefer to use rpath, because it makes it easier to 
harden an installation against the vagaries of what users have set in 
their environment - using an rpath like '$ORIGIN/../lib' to set a path 
relative to the location of the ELF can help with installation issues. 
OS X and Solaris both allow editing of the runpath inside an executable, 
so are streets ahead of Linux here.


Which breaks the (currently rather desirable) behaviour that you can 
unpack our Coot packages anywhere you want and they will just work.


I can see that might work well for people packaging Coot for a Linux 
distro, where it will always be installed in the same place, but it 
doesn't work for us.


So we have two incompatible requirements on the build system for two 
different situations. Given the complexity of the build system as it 
stands, my suggestion is that you fork or replace it (although Paul may 
have different views). I'm afraid I don't have the time or expertise to 
get involved in that though.


K

Re: [COOT] use of RPATH in coot libraries

[Kevin Cowtan]

Clemens Vonrhein wrote:

I think the point Peter is making that one can use rpath _and_ $ORIGIN
to exactly get this behaviour _without_ the need to add
LD_LIBRARY_PATH settings! So you can unpack Coot packages anywhere you want
with all its additional libraries refered with a relative rpath
'$ORIGIN/../lib'.



I guess this $ORIGIN feature isn't very widely known ... see e.g.

 http://www.scons.org/wiki/UsingOrigin
 http://linuxreviews.org/man/ld.so/
 http://blogs.sun.com/dipol/entry/dynamic_libraries_rpath_and_mac
 http://www.codeshorts.ca/tag/osx/

It works great for us.


OK, that is pretty cool, looks like the correct technical solution for 
our relocatable binaries.


I can see implementation problems. It looks to me as though this will 
only work if you build in place. All the coot dependencies get built in 
their own trees and the installed later. I suspect therefore that the 
link step might not work, because the rpath will be wrong until the 
binaries are shifted into place. Maybe that can be dealt with using 
LD_LIBRARY_PATH while building (but I'm out of my depth here).


I also suspect the packagers will then be unhappy:
 http://wiki.debian.org/RpathIssue

Re: [COOT] Coot fails to read numeric chain IDs

[Kevin Cowtan]

Hi!

Hybrid-36 (initial idea from Ralph Grosse Kunstleve, I think) works 
around this problem by allowing higher numbered atoms to be numbered in 
base 36 starting from A. CCP4 v6.1.1 and recent versions of Coot 
support this, as does phenix.refine.

http://cci.lbl.gov/hybrid_36/

However, last time I checked, it wasn't available in refmac. I think 
refmac ignores atom numbers on read, and writes out its own atom numbers 
sequentially, looping at 10. As a result, you cannot read a refmac 
output PDB file with more 10 atoms into Coot or any other CCP4 
application without somehow renumbering the atoms first.


Garib: Have I got that right? Is that still the case in recent versions?

Kevin


Edward Miller wrote:

Hey Paul,

I believe I have figured out the problem - but not the solution.

On closer inspection, it wasn't just  the numerically labelled chain IDs 
that weren't read, a few of the alphabetical chains were also not read.


What happens is REFMAC restarts atom numbering once 10 atoms are 
reached when outputting the refined coordinates.


COOT was reading in the first 9 atoms, numbered 1-9 by REFMAC, 
then the second 9 atoms, again numbered 1-9 by REFMAC. At this 
point, however, REFMAC for some reason made the next atom 10 and 
then restarted numbering at 1. This atom, numbered 10, was not read 
by COOT and nor where any subsequent atoms.


The input coordinates that I used for REFMAC, which again consisted of 
60 chains, was created by combining sets of 10mers, thus the atom 
numbering restarted after each 10 chains. REFMAC had no problem refining 
these coordinates and COOT had no problem reading these coordinates.


To further confirm that COOT is failing once it reads atom 10, I 
wrote a little perl script to properly renumber the atoms in the REFMAC 
refined coordinates. In this file, there are correctly 246960 atoms.


Within my perl script, I formatted the output such that the atom numbers 
eat into the spaces after "ATOM"  like so:


ATOM 246960  O   LEU 7 736  64.294  96.393-111.576  1.00 34.97


I see now that the last atom COOT reads in is atom number 9.


Perhaps, I fear, this is a problem with the PDB format - that the column 
width for atom numbers can not accommodate more than 9 atoms.


Ed

On Tue, Jun 2, 2009 at 9:39 AM, Paul Emsley > wrote:


Edward Miller wrote:

Hey Folks,

I'm working on refining a full capsid containing 60 chains.

Using the chain ID column, I've numbered my chains A-Z, a-z, and
0-7. I was successfully able to refine my capsid in refmac using
this chain ID naming scheme.

However, coot fails to read in any of the chains labeled 0-7.


I don't know why this is failing - I will try to make a synthetic
PDB file with 60 chains to see if I can reproduce this.

Relatively recently Eugene has extended mmdb to  work with the
hybrid_36 format.  So for now you could go that route.

Paul.

Re: [COOT] Coot fails to read numeric chain IDs

[Kevin Cowtan]

I thought it did. But apparently it doesn't.

None of this is Coot code, it's CCP4 library code, so it's beyond our 
control.


Phil Evans wrote:
why does Coot ignore these atoms renumbered back to 1 beyond 1? 
Shouldn't it just ignore the irrelevant atom number?

Phil

Re: [COOT] sequencing gui

[Kevin Cowtan]

It's very unlikely to be right on anything much shorter than 12 
residues. The confidence scores are a bit gung-ho.


Phil Evans wrote:



OK thanks.

I tried a different example, which did give me a (wrong) assignment - is 
there any way of picking an alternative?


What partly confused me before and again was that this command assigns 
the sequence but doesn't build the side chains - you have to use the 
Fill Partial Residues command, I suppose


Also if I go back to the GUI for the same "molecule", it displays 2 
sequences


Thanks again
Phil

---

then cootaneer

iv: 0 seq.size: 1
debug pythoning  and 
MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ 


in assign_sequence_from_string
storing sequence: 
MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ for 
chain id: A
(assign-sequence-from-string2 "A" 
"MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ") 



Sequence: ?KIEFT?
Confidence: 0.912518


On 4 Jun 2009, at 13:37, Bernhard Lohkamp wrote:



I guess you didnt give it a chain id. When sequencing the closest
fragment this information is required (maybe it shouldnt, or at least it
should give the appropriate warning - I will look into it at some point).

B


I'm trying to understand the Extensions-> Dock sequence dialogue.
How
does it work?

I've tried

Place helix here
Select Dock Sequence
choose Helix molecule
Load sequence from a file
click "Sequence closest fragment"

then I get

assign-sequence-from-file2 "/Users/pre/Documents/Talks/
Crystallography/LMB-2009/MapFitting/Examples/amph2.seq")
iv: 0 seq.size: 1
debug pythoning  and

MAEMGSKGVTAGKIASNVQKKLTRAQEKVLQKLGKADETKDEQFEQCVQNFNKQLTEGTRLQKDLRTYLASVKAMHEASKKLSECLQEVYEPEWPGRDEANKIAENNDLLWMDYHQKLVDQALLTMDTYLGQFPDIKSRIAKRGRKLVDYDSARHHYESLQTAKKKDEAKIAKPVSLLEKAAPQWCQGKLQAHLVAQTNLLRNQAEEELIKAQKVFEEMNVDLQEELPSLWNSRVGFYVNTFQSIAGLEENFHKEMSKLNQNLNDVLVSLEKQHGSNTFTVKAQPSDSAPEKGNKSPSPPPDGSPAATPEIRVNHEPEPASGASPGATIPKSPSQLRKGPPVKHTPSKEMKQEQILSLFDDAFVPEISVTTPSQFEAPGPFSEQASLLDLDFEPLPPVASPVKAPTPSGQSIPWDLWEPTESQAGVLPSGEPSSAEGSFAVAWPSQTAEPGPAQPAEASEVVGGTQEPGETAASEATSSSLPAVVVETFSATVNGAVEGSTTTGRLDLPPGFMFKVQAQHDYTATDTDELQLKAGDVVLVIPFQNPEEQDEGWLMGVKESDWNQHKELEKCRGVFPENFTERVQ 


apply the sequence info here

then cootaneer

ERROR:: the input contains an invalid chain and/or sequence
BL ERROR:: something went wrong assigning the sequence



What should I have done?  (Coot 0.6-pre 1 1941, OSX)

Best wishes
Phil

Re: [COOT] nan sigma when I try to make Dano map in expert mode

[Kevin Cowtan]

Yes, I think you'll need to run fft or cfft to make a dano map, and then 
read that in coot.


(Alternatively, some phasing programs offer LLG map coefficients, which 
are probably a better solution).


Pete Meyer wrote:



CCP4MTZfile: Mtz column type mismatch: DANO_Se32-4 D-F




Could this be the problem?  If the column type is correct in your mtz
file, then possibly coot is attempting to use an amplitude column type
instead of an anomalous difference column type (would might be confusing
fft).

Of course, I wasn't even aware that coot would try to calculate these
maps internally, so I could be completely wrong.

Pete

Re: [COOT] Refine zone set-matrix

[Kevin Cowtan]

Stephen Graham wrote:

Incidentally, would it be possible to condense all of these options
into the one place?  In the regularisation/refinement dialog box that
is linked off the model/fit/refine toolbar???  At the moment these
controls seem to be scattered all over the place (and thus easy to
miss if you're a 'newbie').


I think they're all there, aren't they?

<>

Re: [COOT] small squares on certain atoms

[Kevin Cowtan]

Ah, that's what happens when a colourblind person tries to help.

I'm guessing you are unintentionally using the 'anchor atoms' tool to 
fix atoms. Click the 'anchor' icon (3rd down on the toolbar) and you 
should get a little window with 'fix' and 'unfix' options.


K

Craig Smith wrote:

Here is an update on this:

I checked my pdb file and the occ. are 1 or 0.5.  I'm noticing that when 
I click on a residue I leave these green squares behind and the atoms 
become "locked".  The atoms won't move when I regularize or real space 
refine.



On Jul 17, 2009, at 11:09 AM, Kevin Cowtan wrote:


Zero occupancies?

Craig Smith wrote:

Hi everyone
I'm refining and fixing geometry on a structure and I notice on some 
atoms there are some small green square on certain atoms.  What are 
these small squares telling me?

Thanks in advance,
Craig

Re: [COOT] Automatic column asignment for refmac

[Kevin Cowtan]

Hi!

Coot has to be told what columns to use for different programs. We've 
coded fore refmac, phenix.refine and my density modification programs, 
but not for phaser because no-one has asked.


Can you send me a dump of the mtz header with a list of the columns?
Which columns would you like used by default on auto open?
Should there be a difference map as well?

Thanks,
Kevin

alexander.schif...@sanofi-aventis.com wrote:

Dear Paul,

There seems to be a problem with the automatic asignment for F and SIGF when 
using a file from phaser (processed by autoproc). The FCTR column seems to be 
used instead of F but there is no reference what has been used in the logfile 
(sample attached). Unfortunately the only indication something went wrong is 
the high R-Factor, which in this case could also be due to the fact that the MR 
solution is incorrect.

Best rega <> rds,

Alexander

 
Mit freundlichen Grüßen / Best regards / Cordialement


Dr. Alexander Schiffer

Sanofi-Aventis Deutschland GmbH
R&D CAS Structural Biology FFM
Industriepark Hoechst
Bldg. G877, Room 029
D-65926 Frankfurt am Main
t: +49 69 305 24896
f: +49 69 305 80169
w:www.sanofi-aventis.de

*
Sanofi-Aventis Deutschland GmbH ·  Sitz der Gesellschaft: Frankfurt am Main · 
Handelsregister: Frankfurt am Main, Abt. B Nr. 40661
Vorsitzender des Aufsichtsrats: Hanspeter Spek - Geschäftsführer: Dr. Martin Siewert (Vorsitzender), Ulf Bialojahn, Dr. Matthias Braun, 
Peter Guenter, Prof. Dr. Dr. Werner Kramer, Dr. Klaus Menken, Dr. Heinz Riederer

*

Re: [COOT] Automatic column asignment for refmac

[Kevin Cowtan]

OK, so the map coefficients are:

1. FCTR PHICTR
2. 2FOFCWT PH2FOFCWT
3. FOFCWT PHFOFCWT
4. FOFRGSLV PHFOFRGSLV
5. FC PHIC
6. FOSC SIGFOSC

I think that auto-open (assuming you are using a 0.6pre from the last 6 
months) should automatically pick up (2) and (3) for a normal and 
difference map - is that what you see?


Which other columns would you like maps from? Just (1)?

Do you see a way to include in the refmac-from-coot logfile which mtz columns were used? 


Sorry, didn't understand this bit.

K

Re: [COOT] Automatic column asignment for refmac

[Kevin Cowtan]

Bernhard is right, sorry. Ignore me!

Kevin

Bernhard Lohkamp wrote:

Hi,

the automatic selection of structure factors for refinement happens in 
Refmac and not in Coot. This is one for Garib. I dont know exactly how 
Refmac chooses which structure factors to use, but it certainly should 
write the selected ones in the log file (maybe newer versions of refmac 
already do so?!). If you want to make sure Refmac uses the structure 
factors you want, then select the corresponding option and do not trust 
Refmac to do the job for you. Furthermore you probably should work with 
the original mtz file when doing refinement. In that case there wont be 
too many different options to pick the 'wrong' structure factors for 
refinement as well.


Hope this helps,

B

P.S. Kevin, I guess you misunderstood the problem. It's about SF used in 
refmac (via Coot) rather than (auto)open mtz files.



Dear Paul,

There seems to be a problem with the automatic asignment for F and 
SIGF when using a file from phaser (processed by autoproc). The FCTR 
column seems to be used instead of F but there is no reference what 
has been used in the logfile (sample attached). Unfortunately the only 
indication something went wrong is the high R-Factor, which in this 
case could also be due to the fact that the MR solution is incorrect.


Best rega <> rds,

Alexander

 
Mit freundlichen Grüßen / Best regards / Cordialement


Dr. Alexander Schiffer

Sanofi-Aventis Deutschland GmbH
R&D CAS Structural Biology FFM
Industriepark Hoechst
Bldg. G877, Room 029
D-65926 Frankfurt am Main
t: +49 69 305 24896
f: +49 69 305 80169
w:www.sanofi-aventis.de

* 

Sanofi-Aventis Deutschland GmbH ·  Sitz der Gesellschaft: Frankfurt am 
Main · Handelsregister: Frankfurt am Main, Abt. B Nr. 40661
Vorsitzender des Aufsichtsrats: Hanspeter Spek - Geschäftsführer: Dr. 
Martin Siewert (Vorsitzender), Ulf Bialojahn, Dr. Matthias Braun, 
Peter Guenter, Prof. Dr. Dr. Werner Kramer, Dr. Klaus Menken, Dr. 
Heinz Riederer
* 

  

Re: [COOT] Release 0.6

[Kevin Cowtan]

Looks like 2540:
http://www.biop.ox.ac.uk/coot/devel/svn.log

Tim Fenn wrote:

On Fri, 4 Dec 2009 02:56:49 +
Paul Emsley  wrote:


We are please to announce the release of coot-0.6

Source here:

http://www.biop.ox.ac.uk/coot/software/source/releases/coot-0.6.tar.gz

Binaries from here:

http://www.biop.ox.ac.uk/coot/software/binaries/releases/



Grats!  Which SVN tag corresponds to the 0.6 release?

-Tim

--
-

Tim Fenn
f...@stanford.edu
Stanford University, School of Medicine
James H. Clark Center
318 Campus Drive, Room E300
Stanford, CA  94305-5432
Phone:  (650) 736-1714
FAX:  (650) 736-1961

-

Re: [COOT] Mask the map

[Kevin Cowtan]

Yes, Paul's analysis of the problem is correct.

Coot is the wrong tool for this job. You can do the job in CCP4 using 
NCSMASK and MAPMASK.


Open Map & Mask Utilities.

Use Create/Edit Mask to make a mask about your model. Enter the grid and 
extent values from your current map. Use a pdb file containing only 
chain B. Turn off the 'trim mask' option.


Use Edit/Rotate maps and masks and select 'solvent flatten a map using a 
mask' to flatten the unmasked region.


Kevin


pebbleped...@gmail.com wrote:

hi all,

I have a question about how does coot mask the electron density map.

I have a ccp4 electron density map file with parameters like this:

 Parameters as read from the map file
 Origin ..   -167   -36   -35
 Extent ..10974   113
 Grid 15652   112
 Cell axes ... 100.74 32.81 72.69
 Cell angles .  90.00 90.71 90.00
 UVW (fast, medium, slow)   Y X Z

So this electron density map has 109*74*113=911458 grid points and its
origin located at point -167   -36   -35

After I mask part of the density map (around chain B) and only leave
electron density around chain A, I export it.

Now its parameters are like this:

 Parameters as read from the map file
 Origin ..  0 0 0
 Extent ..15652   112
 Grid 15652   112
 Cell axes ... 100.74 32.81 72.69
 Cell angles .  90.00 90.71 90.00
 UVW (fast, medium, slow)   Y X Z

So now the masked map has 156*52*112=908544 grid points with origin
locate at  point 0 0 0

 Before I do tests, I guess how coot to do mask is: to find out grid
points around selected atoms from model and set the density value to
be zero then save the map like this:

1.11.1
2.12.1
3.1 > 0.0
4.14.1
5.15.1

So then I can compare the two maps to check out at which point the
mask is placed.

But actually, the masked map have different points with the initial map.

Does anyone know how can I get a masked map with same grid points as
the initial map and the only differences are density values at some
grid point were set to be zero?

Re: [COOT] new (2010) coot *article*

[Kevin Cowtan]

Should appear in the Feb issue.

K

Bryan W. Lepore wrote:
is there a timeframe we can know about for the new coot reference to 
appear in acta d "forthcoming articles"?


http://journals.iucr.org/d/services/forthcoming.html

...(empty today... usually full...?)

-bryan

Re: [COOT] Dock sequence

[Kevin Cowtan]

To expand on that:

If it chose not to dock sequence, then that basically means that the 
electron density doesn't provide compelling evidence for a particular 
sequence being right.


A score of 0.5 means that the next best sequence dock had exactly the 
same score as the best one. In practice, that means that you would do 
just as well docking random sequences into the density. Your score of 
0.508934 basically says that.


In practice I'd only expect an 18 residue trace to dock if the density 
is quite good and the C-alpha positions correspondingly good. That will 
vary a lot depending on resolution and the quality of the density. For a 
clear region in a 2.5A map, you've got a good chance, for a mobile loop 
then no chance. If it is mistraced of course, all bets are off.


Did you RSR everything first?

Also, the algorithm in Coot uses much of the same code, but run in a 
rather different manner from buccaneer, in order to achieve interactive 
speed. It might be worth trying buccaneer on it, but getting a longer 
fragment is more likely to make a difference.


If you want a test, get a known structure, convert to poly-ala, and chop 
it up a bit, and try sequencing the fragments of different length.


Kevin

Paul Emsley wrote:

Phil Evans wrote:

How does the Extensions->Dock sequence command work?

I've got a polyAla model, so I open the dialog, import a sequence 
file, click the "Sequence closest fragment" or "Sequence all fragments!"


Then I get in the terminal window something like

Sequence: ??QKDIGVKPEFSFN??
Confidence: 0.508934

From: LQQKDIGVKPEFSFNIP
Chain id: 0 Offset: 114


but nothing seems to have happened.
has it failed? or worked?
  


OK, well that interface could do with improving.   As could the 
documentation - thanks for prodding me.


It has failed.  It needs 0.9 or greater confidence before it will add 
the sidechains (this basically Kevin's buccaneer code).


Paul.

Re: [COOT] garbled terminal output

[Kevin Cowtan]

This happens to a terminal when it trys to display ascii code 14 
(ctrl-N), which switches the display to the top 128 ascii characters.


To check this, save the attached text file and then cat or more it from 
a terminal. It should have the same effect. (In a gnome terminal, you 
can do Terminal/Reset to restore it.)


Now, I've never seen this happen for anyone else. So I'm guessing there 
is something in your saved session or config files which is causing this 
to happen. We might be able to work out what if you can send the full 
coot log output.


If you do

coot >& coot.log

and wait for the program to start up, then quit and mail the log file, 
then that might provide some more clues.


Kevin


Paul Emsley wrote:

Ben Eisenbraun wrote:

Hi Cooters,

I have a user running Coot from the official binaries (coot-0.6-pre-1-
revision-2486-binary-Linux-i386-centos-4-python-gtk2) on Red Hat Linux 
4.6.


Using Gnome Terminal, when coot runs, the shell output is garbled.  It
looks like this:

(⎽␊├-⎽≤└└␊├⎼≤-␌⎺┌⎺┤⎼  0.10  0.20  0.80)
(⎽␊├-⎽≤└└␊├⎼≤-▒├⎺└-┌▒␉␊┌⎽-␊│⎻▒┼␍␊␍ 0)
(⎽␊├-▒␌├␋┴␊-└▒⎻-␍⎼▒±-°┌▒± 1)
(␤▒┼␍┌␊-⎼␊▒␍-␍⎼▒┬-└⎺┌␊␌┤┌␊-┬␋├␤-⎼␊␌␊┼├⎼␊ 
"/┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉" 1)

R␊▒␍␋┼± ␌⎺⎺⎼␍␋┼▒├␊ °␋┌␊: /┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉
 PDB °␋┌␊ /┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉ ␤▒⎽ ␉␊␊┼ ⎼␊▒␍.
S⎻▒␌␊±⎼⎺┤⎻: P 1
C␊┌┌: 45.09 45.08 49.43 68.82 64.74 62.63
INFO:: F⎺┤┼␍ 1 └⎺␍␊┌⎽
   M⎺␍␊┌ 1 ␤▒␍ 0 ┌␋┼┐⎽
S≤└└␊├⎼≤ ▒┴▒␋┌▒␉┌␊ °⎺⎼ ├␤␋⎽ └⎺┌␊␌┤┌␊
INFO:: NCS ␌␤▒␋┼ ␌⎺└⎻▒⎼␋⎽⎺┼ 146/226

Coot sets LANG=C in the coot start up script, so I don't think it's a
character set issue per se.  It _doesn't_ happen on a build of revision
2439, so some change in between 2439 and 2486 seems to be causing this.
I went through the commit log on Google Code, but didn't see anything
obvious.

If the user does a hard reset of Gnome Terminal, it apparently fixes the
issue, and it's happening on multiple machines in their lab.

To add another data point, if we capture stdout to a file and view the
file, the text looks normal.

Uh, any ideas?  I'm mostly out at this point.
  


Hi Ben,

I don't know what could have happened between those revisions. Please 
try adding to you ~/.coot


(set-console-display-commands-state 0)

or perhaps

(set-console-display-commands-hilights 0 0 0)

Paul.








Re: [COOT] garbled terminal output

[Kevin Cowtan]

OK, and I got a couple more reports too.

And thanks to Mitchell Miller who sent a full diagnostic for us to study.


chern wrote:

Hi,
I saw garbled terminal output many times. When it happens, I usually 
close Coot and start it again from a new terminal.



- Original Message - From: "Kevin Cowtan" 
To: 
Sent: Thursday, December 17, 2009 8:23 AM
Subject: Re: garbled terminal output



This happens to a terminal when it trys to display ascii code 14
(ctrl-N), which switches the display to the top 128 ascii characters.

To check this, save the  attached text file and then cat or more it from
a terminal. It should have the same effect. (In a gnome terminal, you
can do Terminal/Reset to restore it.)

Now, I've never seen this happen for anyone else. So I'm guessing there
is something in your saved session or config files which is causing this
to happen. We might be able to work out what if you can send the full
coot log output.

If you do

coot >& coot.log

and wait for the program to start up, then quit and mail the log file,
then that might provide some more clues.

Kevin


Paul Emsley wrote:

Ben Eisenbraun wrote:

Hi Cooters,

I have a user running Coot from the official binaries (coot-0.6-pre-1-
revision-2486-binary-Linux-i386-centos-4-python-gtk2) on Red Hat Linux
4.6.

Using Gnome Terminal, when coot runs, the shell output is garbled.  It
looks like this:

(⎽␊├-⎽≤└└␊├⎼≤-␌⎺┌⎺┤⎼  0.10  0.20  0.80)
(⎽␊├-⎽≤└└␊├⎼≤-▒├⎺└-┌▒␉␊┌⎽-␊│⎻▒┼␍␊␍ 0)
(⎽␊├-▒␌├␋┴␊-└▒⎻-␍⎼▒±-°┌▒± 1)
(␤▒┼␍┌␊-⎼␊▒␍-␍⎼▒┬-└⎺┌␊␌┤┌␊-┬␋├␤-⎼␊␌␊┼├⎼␊
"/┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉" 1)
R␊▒␍␋┼± ␌⎺⎺⎼␍␋┼▒├␊ °␋┌␊: /┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉
 PDB °␋┌␊ /┤⎽⎼1/≤±⎺┌␍±┤⎼/␋┼├␊±⎼▒⎽␊/1BIS.⎻␍␉ ␤▒⎽ ␉␊␊┼ ⎼␊▒␍.
S⎻▒␌␊±⎼⎺┤⎻: P 1
C␊┌┌: 45.09 45.08 49.43 68.82 64.74 62.63
INFO:: F⎺┤┼␍ 1 └⎺␍␊┌⎽
   M⎺␍␊┌ 1 ␤▒␍ 0 ┌␋┼┐⎽
S≤└└␊├⎼≤ ▒┴▒␋┌▒␉┌␊ °⎺⎼ ├␤␋⎽ └⎺┌␊␌┤┌␊
INFO:: NCS ␌␤▒␋┼ ␌⎺└⎻▒⎼␋⎽⎺┼ 146/226

Coot sets LANG=C in the coot start up script, so I don't think it's a
character set issue per se.  It _doesn't_ happen on a build of revision
2439, so some change in between 2439 and 2486 seems to be causing this.
I went through the commit log on Google Code, but didn't see anything
obvious.

If the user does a hard reset of Gnome Terminal, it apparently fixes 
the

issue, and it's happening on multiple machines in their lab.

To add another data point, if we capture stdout to a file and view the
file, the text looks normal.

Uh, any ideas?  I'm mostly out at this point.



Hi Ben,

I don't know what could have happened between those revisions. Please
try adding to you ~/.coot

(set-console-display-commands-state 0)

or perhaps

(set-console-display-commands-hilights 0 0 0)

Paul.










 







Re: [COOT] map coefficient labels

[Kevin Cowtan]

I would expect something like
 /*/*/[F,PHI]
to work.

The reason for this notation was indeed that the dataset extension to 
the MTZ format was designed to allow multiple columns with the same 
names but different datasets. However, everyone else except for me 
ignored the new spec, so in practice the feature seems to be redundant.


I've started implementing a 'legacy column mode' in the other clipper 
apps - to allow something like F,PHI. We could extend that to coot.


Having said that, I've never used --data and don't know how it works, so 
I may be talking out of my hat!



Nathaniel Echols wrote:
Is there a way to open map files from a script with the actual column 
labels alone, instead of /crystal/dataset/F, etc.?  I tried /*/*/F, but 
this doesn't work in 0.6.  One of my coworkers claims that MTZ files 
don't allow duplicate column names regardless of which crystal or 
dataset ID they're associated with, and in practice none of the programs 
I've used output columns for more than one crystal/dataset anyway. 
 However, some of them *do* produce very different crystal or dataset 
IDs - in some cases, it appears to be nearly random!  Right now I have 
to open up the MTZ file separately and figure out what they are, which 
is a little more overhead than I'd like.


thanks,
Nat

[COOT] Coot greetings

[Kevin Cowtan]

Happy new year!

(And for 0.6 users, here is a little treat to go with the splash screen.)
<>

Re: [COOT] Autosave

[Kevin Cowtan]

Victor Alves wrote:
But what I was expecting was for Coot to save the PDB file with the same 
name. That is, if I open xxx.pdb I wanted it to use this same name and 
write over it, instead of using the default name, adding -coot-0.pdb.


But then you can't revert to your original model if you really screw up!

(Maybe that's just me?)

Re: [COOT] americanisms in 0.6.1....

[Kevin Cowtan]

Ezra Peisach wrote:
I move that the names in the scheme scripts be changed to the american 
names and that a new script "British.scm" be put in place.


Well, that's just crazy talk. The scripting interface should clearly use 
the established language of science, which transcends national 
boundaries and has been the lingua franca for the bulk of the history of 
science.


I therefore propose that Coot scripting interface be translated to Latin.

There may be some technical neologisms which do not yet have appropriate 
Latin equivalents. I'm sure these people will be glad to help...

http://www.vatican.va/roman_curia/institutions_connected/latinitas/documents/index_en.htm

[COOT] Anyone got Coot to build on Fedora 12?

[Kevin Cowtan]

I'm trying to set up a Fedora 12 build machine, and running into problems.

I keep running into the c preprocessor problem when building guile 
listed here:

http://www.mail-archive.com/guile-de...@gnu.org/msg04783.html

It seems to be specific to Fedora's gcc 4.2.2, not to the upstream 
version. I tried using mcpp ( with ln -s /usr/bin/mccp 
/usr/local/bin/cpp ), but got the same result.


Is there any way to downgrade to a pre-F12 gcc?

Kevin

Re: [COOT] Anyone got Coot to build on Fedora 12?

[Kevin Cowtan]

Yes, but that means I have to mess with the build script. Given that I'm 
doing multiple nightly builds across multiple platforms using the build 
script from cvs, that's a problem. (Possible, but hard - and need to 
check it doesn't break the other builds.)


If there is anyway of doing it by messing with the setup of the F12 
virtual machine, that would make life a lot easier.


Ah - looking at the patch again, I might get away with setting $CPP to 
cpp -P in the .bashrc for the F12 machine. Will try that next.


Ezra Peisach wrote:

On 2/1/2010 10:30 AM, Kevin Cowtan wrote:
I'm trying to set up a Fedora 12 build machine, and running into 
problems.


I keep running into the c preprocessor problem when building guile 
listed here:

http://www.mail-archive.com/guile-de...@gnu.org/msg04783.html

It seems to be specific to Fedora's gcc 4.2.2, not to the upstream 
version. I tried using mcpp ( with ln -s /usr/bin/mccp 
/usr/local/bin/cpp ), but got the same result.


Is there any way to downgrade to a pre-F12 gcc?

Kevin


The patch in the thread did the trick:

diff -Nur guile-1.8.7.orig/libguile/guile-snarf-docs.in
guile-1.8.7/libguile/guile-snarf-docs.in
--- guile-1.8.7.orig/libguile/guile-snarf-docs.in   2009-07-03
18:19:00.0 -0400
+++ guile-1.8.7/libguile/guile-snarf-docs.in2009-11-19 
12:55:32.487266268

-0500
@@ -23,4 +23,4 @@
 ## Let the user override the preprocessor autoconf found.
 test -n "${CPP+set}" || CPP="@CPP@"

-${CPP} -DSCM_MAGIC_SNARF_DOCS "$@"
+${CPP} -P -DSCM_MAGIC_SNARF_DOCS "$@"

Re: [COOT] Anyone got Coot to build on Fedora 12?

[Kevin Cowtan]

That's a fair question. Two reasons:
1. we are not Fedora centric, and
2. we need the nightly test data

The Fedora builds may be useful for Fedora users, however there are lots 
of non-Fedora users who rely on the same builds for distros of a similar 
age. A tar.gz package with all the dependencies is much more useful for 
such people.


The nightly tests are vital for ensuring the stability of the software. 
I have no idea if the Fedora RPMs even run the full test suite, let 
alone whether they do it nightly and where I can see the results. To be 
honest, I don't trust any Coot build for which I can't see the test 
results. There are too many things which can go wrong in subtle ways.


Kevin

Tim Fenn wrote:

Why do you need to build guile?  yum install will give you 1.8.7?  And
if you want to build coot, an "official" coot submission for fedora is
here (where you can find a srpm to build from):

https://bugzilla.redhat.com/show_bug.cgi?id=472150

-tim

On Mon, 1 Feb 2010 16:24:56 +
Kevin Cowtan  wrote:


Yes, but that means I have to mess with the build script. Given that
I'm doing multiple nightly builds across multiple platforms using the
build script from cvs, that's a problem. (Possible, but hard - and
need to check it doesn't break the other builds.)

If there is anyway of doing it by messing with the setup of the F12 
virtual machine, that would make life a lot easier.


Ah - looking at the patch again, I might get away with setting $CPP
to cpp -P in the .bashrc for the F12 machine. Will try that next.

Ezra Peisach wrote:

On 2/1/2010 10:30 AM, Kevin Cowtan wrote:
I'm trying to set up a Fedora 12 build machine, and running into 
problems.


I keep running into the c preprocessor problem when building guile 
listed here:

http://www.mail-archive.com/guile-de...@gnu.org/msg04783.html

It seems to be specific to Fedora's gcc 4.2.2, not to the upstream 
version. I tried using mcpp ( with ln -s /usr/bin/mccp 
/usr/local/bin/cpp ), but got the same result.


Is there any way to downgrade to a pre-F12 gcc?

Kevin


The patch in the thread did the trick:

diff -Nur guile-1.8.7.orig/libguile/guile-snarf-docs.in
guile-1.8.7/libguile/guile-snarf-docs.in
--- guile-1.8.7.orig/libguile/guile-snarf-docs.in   2009-07-03
18:19:00.0 -0400
+++ guile-1.8.7/libguile/guile-snarf-docs.in2009-11-19 
12:55:32.487266268

-0500
@@ -23,4 +23,4 @@
 ## Let the user override the preprocessor autoconf found.
 test -n "${CPP+set}" || CPP="@CPP@"

-${CPP} -DSCM_MAGIC_SNARF_DOCS "$@"
+${CPP} -P -DSCM_MAGIC_SNARF_DOCS "$@"

Re: [COOT] coot dumps when moving around in a map in which it can't find a coordinate for.

[Kevin Cowtan]

No, that's not the problem. Coot maps are infinite, so it doesn't matter 
how big you make them.


The problem here is that you've made a P21 map whose grid sampling isn't 
even numbers, and thus the grid sampling is inconsistent with the 
symmetry operators. How did you make your map?


(If at all possible, it is safer to read in reflection data than a map, 
but that is not always possible).


Kevin

Francis E Reyes wrote:

I'm guessing I'm not calculating my map big enough because when I translate 
around my current map I get a crash.

Failure to find grid coordinate uvw = ( -14,  34,  21)
Xmap: Internal map ASU error - P 2ac 2ab Nuvw = (  68,  69,  75)
terminate called after throwing an instance of 'clipper::Message_fatal'
/sw/bin/coot: line 5: 14085 Abort trap  /sw64/bin/coot-real "$@"

Can we have an error message pop  up in the console but not have a crash? 
Unless this has been changed in the most current version. The one I'm running 
is Coot 0.6-pre-1 revision 2396.

Thanks

F


-
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] Windows user

[Kevin Cowtan]

This page will do what you want!
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=coot

I'll try doing to for you, I guess you'll need to respond to a confirmation.

Nicholas C. Payne wrote:

Please delete my name from the COOT mailing list.
I'm transferring to Linux at last.  Thanks -Nick

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

[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.

Re: [COOT] What kind of maps produced in coot when refmac is run?

[Kevin Cowtan]

Paul Emsley wrote:
What kind of maps are produced in coot when refmac is run from within  
it? Sigma-weighted 2fo-fc's ?


  


SigmaA, yes, Standard refmac maps: 2mFo-DFc, mFo-DFc.


Well, maybe.

The maps from refmac are sigmaa-weighted 2mFo-DFc and mFo-DFc maps only 
if you are not using phased constraints. If you are, the actual 
coefficients are a bit more complex than that, although they are 
conceptually equivalent.


This paper described the situation for density modification in parrot, 
which is the same method as used in refmac, but I have attempted to 
provide a non-mathematical explanation as well.

  http://journals.iucr.org/d/issues/2010/04/00/ba5136/ba5136.pdf

Re: [COOT] Fedora 12 binary problem

[Kevin Cowtan]

Confirmed.

Looks like there was a problem in my VM build scripts, as a result of 
which Paul was not picking up some of my builds. The F12 build should 
now be available, the F10 build soon.


David Schuller wrote:

  I downloaded the Latest Binary Tar for Fedora 12:

http://www.biop.ox.ac.uk/coot/devel/build-info.html

binary-Linux-i386-fedora-12-python-gtk2 
  * 
2927 *



When I attempted to gunzip the file, I got this:
# gunzip 
coot-0.6.2-pre-1-revision-2927-binary-Linux-i386-fedora-12-python-gtk2.tar.gz 



gzip: 
coot-0.6.2-pre-1-revision-2927-binary-Linux-i386-fedora-12-python-gtk2.tar.gz: 
unexpected end of file


--
===
All Things Serve the Beam
===
   David J. Schuller
   modern man in a post-modern world
   MacCHESS, Cornell University
   schul...@cornell.edu 

Re: [COOT] mon_lib_list.cif?

[Kevin Cowtan]

Well, I think I can make a guess.

Having been the target of a great deal of whingeing at the CCP4 
developers meeting for hydrogen naming being in a mess (albeit not of 
his making), Paul finally caved in and agreed to do the wrong thing and 
kludge it in coot.


Unfortunately it is now broken for the rest of the world.

Is that fair, Paul?

Scott Classen wrote:

Hi all,

I just updated to 0.6.2-pre-1 (build 2965) via fink
I am using the PDB v3 atom names for DNA so I copied over my custom cif files 
to replace:

 /sw/share/coot/lib/data/monomers/list/mon_lib_list.cif
 /sw/share/coot/lib/data/monomers/a/AD.cif
 /sw/share/coot/lib/data/monomers/c/CD.cif
 /sw/share/coot/lib/data/monomers/g/GD.cif
 /sw/share/coot/lib/data/monomers/t/TD.cif

coot fires up OK. no complaints about the cif files, but coot is renaming my 
DNA atoms to version 2 atom names when it reads the PDB in.

help,
Scott




~
Scott Classen, Ph.D.
SIBYLS Beamline 12.3.1
http://bl1231.als.lbl.gov
Advanced Light Source
Lawrence Berkeley National Laboratory
1 Cyclotron Rd
MS6R2100
Berkeley, CA 94720
C) 510.206.4418
O) 510.495.2697
Beamline) 510.495.2134
~

Re: [COOT] mon_lib_list.cif?

[Kevin Cowtan]

Failure to read for comprehension. Sorry, wrong problem, ignore me.

Kevin Cowtan wrote:

Well, I think I can make a guess.

Having been the target of a great deal of whingeing at the CCP4 
developers meeting for hydrogen naming being in a mess (albeit not of 
his making), Paul finally caved in and agreed to do the wrong thing and 
kludge it in coot.


Unfortunately it is now broken for the rest of the world.

Is that fair, Paul?

Scott Classen wrote:

Hi all,

I just updated to 0.6.2-pre-1 (build 2965) via fink
I am using the PDB v3 atom names for DNA so I copied over my custom 
cif files to replace:


 /sw/share/coot/lib/data/monomers/list/mon_lib_list.cif
 /sw/share/coot/lib/data/monomers/a/AD.cif
 /sw/share/coot/lib/data/monomers/c/CD.cif
 /sw/share/coot/lib/data/monomers/g/GD.cif
 /sw/share/coot/lib/data/monomers/t/TD.cif

coot fires up OK. no complaints about the cif files, but coot is 
renaming my DNA atoms to version 2 atom names when it reads the PDB in.


help,
Scott




~
Scott Classen, Ph.D.
SIBYLS Beamline 12.3.1
http://bl1231.als.lbl.gov
Advanced Light Source
Lawrence Berkeley National Laboratory
1 Cyclotron Rd
MS6R2100
Berkeley, CA 94720
C) 510.206.4418
O) 510.495.2697
Beamline) 510.495.2134
~

Re: [COOT] Failure to mount /home/emsley delays coot startup

[Kevin Cowtan]

Paul Emsley wrote:
It may help if I made SuSe-specific binaries - one day I'll get a SuSe 
box (or virtual machine).


Or you could build the binaries yourself.

Paul.


If anyone has any luck with this tell me. I've tried building SuSe 
binaries on a couple of occasions - in real machines and VMs - without luck.


--
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [COOT] Output maps

[Kevin Cowtan]

The ccp4 program mapmask does what you want. From ccp4i, select:
Map and Mask Utilities/Edit-Rotate Map & Mask/Extend a map-mask file

Andy Torelli wrote:

Hi everyone,

I produced an NCS-averaged map in COOT that I would like to output 
and load into PyMOL to make a figure.  The map loads successfully into 
PyMOL, but of course the density only covers a portion of my molecule 
that is fully covered when viewed in COOT.  I know/believe this is 
because COOT generates maps with electron density that is only defined 
explicitly for certain regions of the unit cell and dynamically displays 
electron density (based on symmetry) for the regions that are not defined.


I e-mailed the PyMOLbb regarding this issue some time ago and 
learned that symmetry-expansion was in the works, but it doesn't seem to 
be working in version 1.2r3pre.  I was wondering if there is any way to 
tell COOT to output a map with electron density values explicitly 
defined for a given region (e.g. a protein chain, defined region of 
space or a ligand/ion).


Things I've tried:
 - making a mask (Extensions->Maps->Mask Map by Atom Selection) and 
loading that map into PyMOL based on a previous post suggestion, but the 
(lack of) coverage was the same.
 - loading the map into MAPMAN and converting to a different file 
format.  The map was too big to be loaded and I'm not sure if I can 
re-define the area for which electron density will be defined.


Thanks for your help and suggestions,
-Andy Torelli



--
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [COOT] almost off-topic : dn6/brix<->ccp4 maps discrepancies

[Kevin Cowtan]

Lepore, Bryan wrote:

if surface normals of a dn6/brix map are zero in some places, is there a 
specific reason it would look OK as a solid mesh in coot in ccp4 format?
 
i used some USF programs to write out a ccp4 map that looks like a nice closed tube in coot. its dn6 or brix counterparts (which i admit are not for coot), however, have surface normals equal to zero at the end of the tube, making it look like the end of an open pipe.


not sure where to start on this - any pointers appreciated,

-bryan (with thanks to T.Fenn)


Not sure I understand the question. In the absence of sufficient 
information, I'll make a guess based on FAQs in the past, which leads to 
this, possibly irrelevent, answer...


Does the tube extend to the limits of the map, and is your map grid 
defined such that the size of the map is exactly one unit cell?


If so, then the problem you are seeing is that Coot handles data in a 
repeating crystallographic space, which many other programs ignore.


K

--
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [COOT] coot dumps when moving around in a map in which it can't find a coordinate for.

[Kevin Cowtan]

This message is generated by clipper if you ask for the electron density 
at a coordinate in the map and give the coordinate as NaNs.


Now why the coordinate should be NaNs is another question - presumably 
coot or mmdb related.


K

Peter Simone wrote:

Thanks for the reply.  Here's the exact message:

Failure to find grid coordinate uvw = (2147483647,2147483647,2147483647)
Xmap: Internal map ASU error - P 2ac 2ac Nuvw = (  48,  80, 160)
terminate called after throwing an instance of 'clipper::Message_fatal'
/sw/bin/coot: line 6: 2399 Abort trap /sw/bin/coot-real "$@"

I made a few discoveries while trying to recreate the error which may or may 
not be helpful.  When only planar restraints is selected there is no problem, 
but the error occurred when either torsion restraints or Ramachandran 
restraints is selected.  The error only seems to occur for certain residues.  
I've only tested a few residues in my structure and so far it has only occurred 
with one of them (a Leu).  I tested another Leu and it worked fine.  I also 
thought it might be specific to residues with bad rotamers, but I tested 
another one and had no error.  I've tested with two maps (mtz files) so far and 
both had the same problem.  One was a 2Fo-Fc map and the other was a Fo-Fc map, 
if that makes a difference.  I'm using Coot 0.6.2-pre-1 on OS X 10.6.6 and Coot 
0.6.1 on CentOS 5.5.

Something else I noticed which isn't really related: on Coot 0.6.2-pre-1 on OS X when I select only torsion 
and planar restraints, "Torsions" shows up in the "Accept refinement" window.  However, 
when torsion, planar, and Ramachandran restraints are all selected, "Torsions" no longer appears.

Thanks again,

Peter Simone



--
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [COOT] interpreting --self-test output

[Kevin Cowtan]

It works for me, but only as part of the build-it-gtk2-simple script and 
when I have put the data/greg-data directory in place by an external 
script. Do you have data/greg-data under the directory from which you 
are running your tests?


Not sure what the official source for the test data is. In fact IIRC 
some of it may be undistributable. My autobuild scripts grab it from 
Paul's areas here and copy it into the build VMs.


Kevin

On 07/20/2011 05:15 AM, Ben Eisenbraun wrote:

On Mon, Jul 18, 2011 at 01:38:52PM -0400, Ben Eisenbraun wrote:

On Mon, Jul 18, 2011 at 01:35:26PM -0400, Ben Eisenbraun wrote:

Is this a successful result? The "OK" output and then the check for the
core dump combined with the 0 exit make things a bit ambiguous to me.


Following up to myself a second time...

I have tested the official 32/64-bit CentOS/Red Hat 4/5 builds, and they
all crash during the self-test. Does this actually work for anyone on
linux? Is there something weird about my environment?

On a related note, I have been trying to capture cores for these crashes,
and despite coredumps being set to unlimited, coot-real is not producing
cores.

Is there some other setting I need to tweak? It looks like the debug
symbols are not stripped, so presumably a core might be actually be useful.

-ben

--
| Ben Eisenbraun
| SBGrid Consortium  | http://sbgrid.org   |
| Harvard Medical School | http://hms.harvard.edu  |

Re: [COOT] WinCOOT export-map radius not adjustable?

[Kevin Cowtan]

This is presumably the issue of map asymmetric unit.

Unlike some older programs, Coot doesn't store a map covering some 
predefined volume - say a model. It stores a single unique asymmetric 
unit, and generates density for any position in crystal space on the fly 
by use of the cell repeat and symmetry (and some fancy optimisation).


When you export the map, you get exactly what coot has - an asymmetric unit.

I'm guessing from your report that Chimera doesn't do the on-the-fly 
repeat and symmetry. If that's correct, then you'll need to expand the 
map before reading it into Chimera. One tool for doing this is the ccp4 
utility 'mapmask' - in ccp4i go to 'Map and Mask Utilities', select 
'Edit/Rotate map & mask', and pull down the first menu to pick 'Extend a 
map/mask file'. Enter your map and pdb, and you'll get a map out 
covering the model to the given radius.


Hope that helps
Kevin

On 07/21/2011 01:50 PM, Joachim wrote:

Hello!

I use wincoot. For reasons of importing an electrod density map into Chimera, I 
export the map first form WinCoot:
Extensions>Maps...>Export Map...
However, i find that the exported map(.map) has fixed dimensions although I set 
the Map radius to a higher value. This doesn't influence the exported map ,the 
filesize is always the same.
Now I cannot see the whole ED map in Chimera. Is there a way to adjust the map 
export parameters in WinCoot (or also in a Coot version for Linux)?

Many thanks for suggestions

best regards
Joachim

[COOT] Keybindings to change contour map?

[Kevin Cowtan]

Hi!

We are using WinCoot 0.8.9 in an undergraduate workshop, and for
accessibility reasons we can't guarantee everyone will be using a
scrollwheel mouse.

We can manage almost everything with keybindings, but unfortunately the
contour level keybindings don't seem to work. Is there anything we can do
easily?

Regards,

-- 
Professor Kevin Cowtan
Email:  kevin.cow...@york.ac.uk
Pronouns:   Please use he/him or they/them when referring to me in
professional contexts
Address:York Structural Biology Laboratory, Department of Chemistry
University of York, York, YO10 5DD, UK
ORCiD:  -0002-0189-1437 <https://orcid.org/-0002-0189-1437>
Web:https://www.york.ac.uk/chemistry/staff/academic/a-c/kcowtan/
Disclaimer: http://w <http://www.york.ac.uk/docs/disclaimer/email.htm>
ww.york.ac.uk/docs/disclaimer/email.htm
<http://www.york.ac.uk/docs/disclaimer/email.htm>



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] Keybindings to change contour map?

[Kevin Cowtan]

Hi all!

I've been experimenting with versions, but as far as I can tell this isn't
a general Coot or WinCoot problem.

The problem seems to be that +/- don't work on WinCoot 0.8.9 when used on a
Parallels windows virtual desktop server. The rest of the keybindings work.

It's weird and unfortunate, but probably specific to me.

On Tue, 15 Dec 2020 at 17:13, Kevin Cowtan  wrote:

> Hi!
>
> We are using WinCoot 0.8.9 in an undergraduate workshop, and for
> accessibility reasons we can't guarantee everyone will be using a
> scrollwheel mouse.
>
> We can manage almost everything with keybindings, but unfortunately the
> contour level keybindings don't seem to work. Is there anything we can do
> easily?
>
> Regards,
>
> --
> Professor Kevin Cowtan
> Email:  kevin.cow...@york.ac.uk
> Pronouns:   Please use he/him or they/them when referring to me in
> professional contexts
> Address:York Structural Biology Laboratory, Department of Chemistry
> University of York, York, YO10 5DD, UK
> ORCiD:  -0002-0189-1437 <https://orcid.org/-0002-0189-1437>
> Web:https://www.york.ac.uk/chemistry/staff/academic/a-c/kcowtan/
> Disclaimer: http://w <http://www.york.ac.uk/docs/disclaimer/email.htm>
> ww.york.ac.uk/docs/disclaimer/email.htm
> <http://www.york.ac.uk/docs/disclaimer/email.htm>
>


-- 
Professor Kevin Cowtan
Email:  kevin.cow...@york.ac.uk
Pronouns:   Please use he/him or they/them when referring to me in
professional contexts
Address:York Structural Biology Laboratory, Department of Chemistry
University of York, York, YO10 5DD, UK
ORCiD:  -0002-0189-1437 <https://orcid.org/-0002-0189-1437>
Web:https://www.york.ac.uk/chemistry/staff/academic/a-c/kcowtan/
Disclaimer: http://w <http://www.york.ac.uk/docs/disclaimer/email.htm>
ww.york.ac.uk/docs/disclaimer/email.htm
<http://www.york.ac.uk/docs/disclaimer/email.htm>



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] Keybindings to change contour map?

[Kevin Cowtan]

Yes, it looks like I can successfully bind to [ and ] from the python level.

I'll give that as an option for anyone who can't change contour level any
other way.

On Thu, 17 Dec 2020 at 09:03, Bernhard Lohkamp 
wrote:

>
> Hi Kevin,
>
> I have seen oddness with keybindings (esp for map contour) as well.
> However, this is usually related to different keyboard mappings
> (language). You can try different keys in the "vicinity" of "+" and "-".
> You may find the "right" ones. What does the console output say?
> BTW (python) function to use may be:
>
> get_contour_level_in_sigma(imap)
>
> and
>
> set_contour_level_in_sigma(imap, sigmalevel)
>
> You could make new key bindings map to another key but the question is
> if there isnt a general problem with the keybinding in general.
>
> B
>
> On 15/12/2020 20:25, Kevin Cowtan wrote:
> > Hi all!
> >
> > I've been experimenting with versions, but as far as I can tell this
> > isn't a general Coot or WinCoot problem.
> >
> > The problem seems to be that +/- don't work on WinCoot 0.8.9 when used
> > on a Parallels windows virtual desktop server. The rest of the
> > keybindings work.
> >
> > It's weird and unfortunate, but probably specific to me.
> >
> > On Tue, 15 Dec 2020 at 17:13, Kevin Cowtan  > <mailto:kevin.cow...@york.ac.uk>> wrote:
> >
> > Hi!
> >
> > We are using WinCoot 0.8.9 in an undergraduate workshop, and for
> > accessibility reasons we can't guarantee everyone will be using a
> >     scrollwheel mouse.
> >
> > We can manage almost everything with keybindings, but unfortunately
> > the contour level keybindings don't seem to work. Is there anything
> > we can do easily?
> >
> > Regards,
> >
> > --
> > Professor Kevin Cowtan
> > Email: kevin.cow...@york.ac.uk <mailto:kevin.cow...@york.ac.uk>
> > Pronouns:   Please use he/him or they/them when referring to me in
> > professional contexts
> > Address:York Structural Biology Laboratory, Department of
> Chemistry
> >  University of York, York, YO10 5DD, UK
> > ORCiD: -0002-0189-1437
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.org%2F-0002-0189-1437&data=04%7C01%7CBernhard.Lohkamp%40KI.SE%7C83df52bab9fc4c58754008d8a12f35ed%7Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C0%7C637436572160196924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=II1AtyEmRjwRZ3EfFyBYqx0rK2Vglb42SIZ93luP8Y4%3D&reserved=0
> >
> > Web: https://www.york.ac.uk/chemistry/staff/academic/a-c/kcowtan/
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.york.ac.uk%2Fchemistry%2Fstaff%2Facademic%2Fa-c%2Fkcowtan%2F&data=04%7C01%7CBernhard.Lohkamp%40KI.SE%7C83df52bab9fc4c58754008d8a12f35ed%7Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C0%7C637436572160196924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bambsQWX4lFUUBWRZ8QeBepNbaMWJ0RQNxt7lQ0zXBc%3D&reserved=0
> >
> > Disclaimer: http://w
> > <
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.york.ac.uk%2Fdocs%2Fdisclaimer%2Femail.htm&data=04%7C01%7CBernhard.Lohkamp%40KI.SE%7C83df52bab9fc4c58754008d8a12f35ed%7Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C0%7C637436572160206919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vWa5LVs81lZ26oPXalf8uVS9WVkakbdTOYhuPtAHJXA%3D&reserved=0
> >ww.york.ac.uk/docs/disclaimer/email.htm
> > <
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.york.ac.uk%2Fdocs%2Fdisclaimer%2Femail.htm&data=04%7C01%7CBernhard.Lohkamp%40KI.SE%7C83df52bab9fc4c58754008d8a12f35ed%7Cbff7eef1cf4b4f32be3da1dda043c05d%7C0%7C0%7C637436572160216914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ey9v4yX8AsrC6rEkAI1djBt72wg7IitFse7RtvT8ejM%3D&reserved=0
> >
> >
> >
> >
> > --
> > Professor Kevin Cowtan
> > Email: kevin.cow...@york.ac.uk <mailto:kevin.cow...@york.ac.uk>
> > Pronouns:   Please use he/him or they/them when referring to me in
> > professional contexts
> > Address:York Structural Biology Laboratory, Department of Chemistry
> >  University of York, York, YO10 5DD, UK
> > ORCiD: -0002-0189-1437
> > <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forcid.o

Re: [COOT] Coot Speed Run, Map 1

[Kevin Cowtan]

Do we need a separate category for unmodded ('vanilla') runs?

Also, we're going to have some gaming rooms for socializing at the study
weekend. If anyone wants to zoom stream a run, that might be fun? I've got
an MR case we use with students.


On Thu, 24 Dec 2020, 08:53 Paul Emsley,  wrote:

> > Done on a MacBook Pro with an i5, external mouse, and without the ligand.
> > I have Oliver Clarke's scripts and the default keybindings.
> >
> > No prior knowledge version I guess? Except having used Coot for 10+
> years?
>
> "Prior knowledge" runs are allowed (expected, actually). It's OK to know
> (and therefore avoid the use of the
> validation tools or reading the tutorial to discover):
>
> The ligand is 3GP
> The missing sequence is QTC and adds a disulfide bond
> There are 2 sulfates (one more clear than the other)
> Use Ctrl-D to delete residue 72 and "Add Terminal Residue" (Y) to replace
> it
>
> 
>
> 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/
>



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/

[COOT] Fwd: Segfault again

[Kevin Cowtan]

Hi all

I don't know if this segfault is of use...

-- Forwarded message -
From: Theodor Everley Röhrkasten 
Date: Wed, 17 Mar 2021 at 12:32
Subject: Segfault again
To: Kevin Cowtan 


Somehow I appeared to be in Rigid Body Fit mode, but there was no dialog
box and I couldn't exit the mode. I tried to use Real Space Refine, and
Coot crashed. I'm not sure how far back to go, so some of this might be
irrelevant. Also, I think in the crash report at the end, it's supposed
to be printing the output of uname and ls, not the paths of the binaries.
Here's my uname, in case it helps: Linux p50 5.11.2-1-default #1 SMP Fri
Feb 26 10:11:13 UTC 2021 (ee0b277) x86_64 x86_64 x86_64 GNU/Linux

Begin output:

--- FAIL, ENOPROG ---
DEBUG::  free/delete/reset m_s and x
addition of target position restraints: pre and post sizes: 682 683
debug:: thread_for_refinement_loop_threaded() restraints locked by
refinement_loop_threaded
INFO:: Clear pull restraint on atom: [spec: model 1 "A"2 "" " CA " ""]
debug:: thread_for_refinement_loop_threaded() restraints locked by
refinement_loop_threaded
Minimum found (iteration number 2) at -4.21e+03
 Final Estimated RMS Z Scores:
bonds:  1.02
angles: 2.39
improper-dihedrals: N/A
torsions:   N/A
trans-peptide: 19.4 (non-sqrt)
planes: 0.852 from 7 restraints
parallel planes: N/A
non-bonded: -0.532
chiral vol: 1.39
rama plot:  N/A
start_pos:  N/A
target_pos: 0 (non-sqrt)
GemanMcCl:  N/A
DEBUG::  free/delete/reset m_s and x
INFO:: backup file name
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_6.pdb.gz
INFO:: replace_coords: 21 atoms updated.
debug:: in clear_all_atom_pull_restraints() 0
click on 2 atoms to define a zone
(do-rot-trans-setup 1)
click on an atom of a terminal residue
(do-add-terminal-residue 1)
(7) " CA "/1/chainid="A"/2/SER, AA occ: 1 with B-factor: 58.8 element: "
C" at (-26.4,33.2,2.74) : 0.0922
(7) " CA "/1/chainid="A"/2/SER, AA occ: 1 with B-factor: 58.8 element: "
C" at (-26.4,33.2,2.74) : 0.0922
INFO:: fitting terminal residue with 5000 random trials
WARNING:: No symmetry available for this molecule
WARNING:: No Symmetry for this model
INFO:: done mutating residue [spec: 1 "A" 1 ""] in add_cb_to_terminal_res
INFO:: backup file name
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_7.pdb.gz
(do-add-terminal-residue 0)
(7) " OG "/1/chainid="A"/2/SER, AA occ: 1 with B-factor: 60.6 element: "
O" at (-26.8,31.1,1.59) : 0.13
(7) " CB "/1/chainid="A"/2/SER, AA occ: 1 with B-factor: 58.2 element: "
C" at (-26.6,31.7,2.86) : 0.114
(7) " C  "/1/chainid="A"/2/SER, AA occ: 1 with B-factor: 57.1 element: "
C" at (-25,33.6,2.22) : 0.124
(7) " CA "/1/chainid="A"/3/THR, AA occ: 1 with B-factor: 49.6 element: "
C" at (-23.4,33.6,0.408) : 0.0896
(7) " OD1"/1/chainid="A"/4/ASP, AA occ: 1 with B-factor: 31 element: "
O" at (-23,37,3.3) : 0.316
DEBUG:: in find_atom_in_moving_atoms: here are the 1 qualifying atoms...
   0  1/A/4 {ASP}/ OD1 altLoc :: segid :AA: pos: (-23,37,3.3)
B-factor: 31
DEBUG:: not doing refinement - no restraints.
(rot-trans-reset-previous)
INFO:: backup file name
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_8.pdb.gz
restoring from backup 9 9
INFO:: Reading coordinate file:
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_7.pdb.gz
INFO:: file
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_7.pdb.gz

has been read.
Spacegroup: P 61
INFO:: Found 1 models
Model 1 had 0 links
in add_molecular_symmetry_matrices() made 0 biomt matrices
DEBUG:: apply_undo: (end) history_index: 7 max_history_index: 9
(apply-undo)
restoring from backup 9 7
INFO:: Reading coordinate file:
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_8.pdb.gz
INFO:: file
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_8.pdb.gz

has been read.
Spacegroup: P 61
INFO:: Found 1 models
Model 1 had 0 links
in add_molecular_symmetry_matrices() made 0 biomt matrices
(apply-redo)
click on 2 atoms to define a zone
(do-rot-trans-setup 1)
DEBUG:: not doing refinement - no restraints.
restoring from backup 9 8
INFO:: Reading coordinate file:
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_7.pdb.gz
INFO:: file
coot-backup/coot-refmac_model_refmac0_refmac1.pdb_Wed_Mar_17_12:35:42_2021_modification_7.pdb.gz

has been read.
Spacegroup: P 61
INFO:: Found 1 models
Model 1 had 0 links
in add_molecular_symmetry_matrices() made 0 bi