Re: [ccp4bb] lsqkab
I noticed the same problem with more recent versions of CCP4 (up to and including 6.5.001) but failed to report it…. It seems that the problem occurs regardless of the atoms chosen for selection - main, side or all - and with both v2 and v3 PDB files. The 'LSQ Superpose’ in Coot can superpose nucleic acids, but it is seemingly not possible to define non-contiguous selections. Rob On 04 Feb 2015, at 17:30, Carter, Charlie car...@med.unc.edu wrote: I'm (still) using ccp4.6.1.1. Scripts that used to superimpose one tRNA on another now all return the error YOU HAVE FAILED TO FIND ANY ATOMS TO FIT I've looked high and low for a reason for this and failed. The pdb files themselves look normal and behave well in PYMOL. They have CRYST1 cards. I cannot even superimpose a file on itself! Anyone have any suggestions? Thanks so much, Charlie here is what I'm trying to implement: lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log END-lsqkab FIT RESIDUE MAIN 2 TO 6 MATCH 2 to 6 FIT RESIDUE MAIN 68 TO 72 MATCH 68 to 72 OUTPUT XYZ END END-lsqkab
Re: [ccp4bb] off topic pymol
Hi Almudena, some graphic programs connect atoms based on distance only (draw a line between two atoms that represents the covalent bond). I suspect this is what PyMol does. Some may employ more information such as one encoded in Monomer Library CIF files. Some try to do both. I suspect this is what Coot does. However, none of the two can represent exactly what refinement program thinks of bonding because refinement programs may employ even more (often quite sophisticated) heuristics to decide what's bonded and what's not bonded and how, including user specified custom bonds. This is why not seeing a line between to seemingly bonded atoms in a graphic program does not necessarily mean that these atoms were not bonded during refinement. This is exactly the reason why phenix.refine, for example, outputs a *geo file that lists absolutely all restraints (bonds, angles, planes, etc etc) making it absolutely clear what was restrained and how, for each and every atom. I guess Shelxl ins files do the same. Pavel On Wed, Feb 4, 2015 at 9:07 AM, Almudena Ponce Salvatierra maps.fa...@gmail.com wrote: Dear all, does anyone know why if I open a pdb in pymol (that appears normal and fully connected in coot) it appears as if it was broken into pieces? Thanks, Almudena. -- Almudena Ponce-Salvatierra Macromolecular crystallography and Nucleic acid chemistry Max Planck Institute for Biophysical Chemistry Am Fassberg 11 37077 Göttingen Germany
Re: [ccp4bb] lsqkab
On 04/02/15 17:21, Robert Byrne wrote: The 'LSQ Superpose’ in Coot can superpose nucleic acids, but it is seemingly not possible to define non-contiguous selections. Admittedly there's no clicky-clicky interface, but you can do it and it's described in the manual. https://www2.mrc-lmb.cam.ac.uk/Personal/pemsley/coot/web/docs/coot.html#index-Least-Squares-Fitting-113 Paul.
[ccp4bb] off topic pymol
Dear all, does anyone know why if I open a pdb in pymol (that appears normal and fully connected in coot) it appears as if it was broken into pieces? Thanks, Almudena. -- Almudena Ponce-Salvatierra Macromolecular crystallography and Nucleic acid chemistry Max Planck Institute for Biophysical Chemistry Am Fassberg 11 37077 Göttingen Germany
Re: [ccp4bb] skin on crystal
Try adding b-ME/DTT/TCEP in your crystallization conditions, if its not there already in your protein buffer. On Mon, Jan 13, 2014 at 2:02 PM, Debasish Chattopadhyay debas...@uab.edu wrote: We crystallized a protein at 4 and 22 deg C in different conditions: from ammonium sulfate in acetate buffer pH 5 and PEG4000 in Hepes buffer at pH 7.5 In both cases the drops have a slimy skin (almost feels like DNA). We therefore think that the skin is generated from the protein. I am sure some of you have had similar experiences. I would like your suggestions about how to avoid the skin. Please note that we are *not* asking for suggestions on how to handle the skin (such as using various tools) *we are only interested in knowing if there is a way to prevent the formation of the skin*. Thank you so much Debasish Ph: (205)934-0124; Fax: (205)934-0480 -- Gyanendra Kumar, PhD St. Jude Children's Research Hospital, Department of Structural Biology, 262, Danny Thomas Place, MS-311 Memphis, TN 38105 Phone: 901-595-3839 Cell: 631-875-9189 ---
[ccp4bb] lsqkab
I'm (still) using ccp4.6.1.1. Scripts that used to superimpose one tRNA on another now all return the error YOU HAVE FAILED TO FIND ANY ATOMS TO FIT I've looked high and low for a reason for this and failed. The pdb files themselves look normal and behave well in PYMOL. They have CRYST1 cards. I cannot even superimpose a file on itself! Anyone have any suggestions? Thanks so much, Charlie here is what I'm trying to implement: lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log END-lsqkab FIT RESIDUE MAIN 2 TO 6 MATCH 2 to 6 FIT RESIDUE MAIN 68 TO 72 MATCH 68 to 72 OUTPUT XYZ END END-lsqkab
Re: [ccp4bb] lsqkab
Dear Charlie,
could it be related to that furanose atoms now have primes (') instead
of asterisks (*) in their names?
Best,
Tim
On 02/04/2015 05:30 PM, Carter, Charlie wrote:
I'm (still) using ccp4.6.1.1.
Scripts that used to superimpose one tRNA on another now all return the error
YOU HAVE FAILED TO FIND ANY ATOMS TO FIT
I've looked high and low for a reason for this and failed. The pdb files
themselves look normal and behave well in PYMOL. They have CRYST1 cards. I
cannot even superimpose a file on itself!
Anyone have any suggestions?
Thanks so much,
Charlie
here is what I'm trying to implement:
lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log END-lsqkab
FIT RESIDUE MAIN 2 TO 6
MATCH 2 to 6
FIT RESIDUE MAIN 68 TO 72
MATCH 68 to 72
OUTPUT XYZ
END
END-lsqkab
--
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen
GPG Key ID = A46BEE1A
signature.asc
Description: OpenPGP digital signature
Re: [ccp4bb] Mosflm Error Msg
Hi
This problem is almost certainly* because there is an orphan
ipmosflm.exe still running (this can happen when you get a Tcl error
and iMosflm stops unexpectedly {some people might call this a
crash}). At the moment you do have to kill the orphaned
ipmosflm.exe process from the MS-Windows task manager - which I agree
is a bit of a pain.
I haven't seen this problem where the old mosflm.lp file is open in
an editor, but I guess that could happen.
Unfortunately, the fix for this is not in the recently released
version 7.1.2 (we have a partial fix for this problem but it doesn't
seem to work all the time, so needs more testing/debugging before we
can release it - it will be in version 7.2.0, which should be ready
for release RSN**).
* I haven't seen it happen under other circumstances - please let us
know directly if you know otherwise.
** = Real Soon Now, i.e. once we're confident all the new features
are robust enough for most users and we've fixed a significant
proportion of the known bugs.
On 4 Feb 2015, at Wed4 Feb 06:20, Frank von Delft wrote:
It would be nice though if imosflm did the killing for you - it
happens to me a large fraction of the time on windows. (I imagine
windows doesn't make mosflm's life easy, mind you.)
phx
On 04/02/2015 05:11, Keller, Jacob wrote:
No--but thanks to you I just found it hanging in the process
manager and killed it, which seems to have done the trick. Guess I
should have thought of that sooner...
Thanks for the help,
Jacob
-Original Message-
From: Edward A. Berry [mailto:ber...@upstate.edu]
Sent: Tuesday, February 03, 2015 11:51 PM
To: Keller, Jacob; CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Mosflm Error Msg
Is the old mosflm.lp open in an editor?
Some editors will put a lock on the file which would prevent
mosflm from overwriting or renaming it.
On 02/03/2015 11:38 PM, Keller, Jacob wrote:
Dear Crystallographers,
Has anyone come across this message before with imosflm in Win7?
I think restarting cures it, but I've got other jobs going...
JPK
***
Jacob Pearson Keller, PhD
Looger Lab/HHMI Janelia Research Campus
19700 Helix Dr, Ashburn, VA 20147
email: kell...@janelia.hhmi.org
***
Harry
--
Dr Harry Powell, MRC Laboratory of Molecular Biology, Francis Crick
Avenue, Cambridge Biomedical Campus, Cambridge, CB2 0QH
Chairman of International Union of Crystallography Commission on
Crystallographic Computing
Chairman of European Crystallographic Association SIG9
(Crystallographic Computing)
Re: [ccp4bb] proton scattering by X-rays
Tim Well if you google for proton scattering by x-rays, the most relevant thing you find are these emails! d=0.26A would be well within the limit for a silver source. Most charge density studies seem to be around d=0.5A - 0.7A, including the crambin studies. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC16211/ At these resolutions, the form factor for atoms break down and one has to include multipoles around the atoms to describe the bonds - the point of doing this. The proton itself will also have a Debye Waller factor, weakening its contribution However, for an isolated hydrogen atom (at 0 kelvin), as an intellectual exercise, I think your analysis is correct. The next question is, if adopting a modified form factor, whether the proton scattering acts coherently with the electron scattering (i.e. sum then square) or incoherently (square then sum). Also how does one handle the opposite charges when doing this? Perhaps one should let this rest! Colin -Original Message- From: Tim Gruene [mailto:t...@shelx.uni-ac.gwdg.de] Sent: 03 February 2015 22:57 To: Nave, Colin (DLSLtd,RAL,LSCI); ccp4bb Subject: Re: [ccp4bb] proton scattering by X-rays Hi Colin, I understood the jest, of course. Now I got curious: At 2theta=0, the scattering from H is 1e, so I assume the the scattering length for its nucleus is 1e/1860 = 0.00054. According to the data from Phil Coppens web site, the atomic scattering factor for H reaches this value at sin theta / lambda = 1.95, i.e. d=0.26A. That's far away from the wavelength 'we' use, but not too far off from the resolution limit on a Silver source (0.31A), is it? I am not sure this can be totally neglected. Am I wrong? Cheers, Tim On 02/03/2015 04:03 PM, Colin Nave wrote: Hi Tim Although my SHELX comment was in jest, your point illustrates the programs versatility. You are also right about the flat(ish) form factor for the proton. To get to a resolution where there is a cross over would require a very short wavelength. Other processes would then dominate. A nice source for this is the x-ray data booklet from LBL, in particular the chapter on scattering of x-rays from electrons and atoms. http://xdb.lbl.gov/Section3/Sec_3-1.html Interestingly fig 3-1 in this does not include coherent scattering from nuclei presumably because it is negligible compared with the other processes - in practice Ian was correct in saying that a proton is effectively invisible to x-rays of the energy we usually use. Colin -Original Message- From: Tim Gruene [mailto:t...@shelx.uni-ac.gwdg.de] Sent: 02 February 2015 22:08 To: Nave, Colin (DLSLtd,RAL,LSCI); ccp4bb Subject: Re: [ccp4bb] proton scattering by X-rays Hi Colin, you can add f' for every atom type in SHELXL yourself, so in that sense, it has been incorporated in SHELX. Bear in mind that the nucleus is point-like to X-rays at ordinary wavelengths so that it should not have a form factor like the electron cloud but a constant scattering length - just as they do for neutron scattering. You can do the maths at what resolution the form factor and the constant 1:1860 scattering length contribution cross. It is not ridiculously small but nowhere near 0.8A. Charge density people may need to take this into account, but I don't know if they do. Cheers, Tim On 02/02/2015 04:03 PM, Colin Nave wrote: “As you say the proton itself is invisible to X-rays.” Not quite! The ratio of scattering between electrons and protons should go as the inverse square of the masses. Ratio of mass 1:1860, ratio of scattering 1:3459600. A small correction but doubtless it has been incorporated in to SHELX. Colin From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Ian Tickle Sent: 02 February 2015 13:35 To: ccp4bb Subject: Re: [ccp4bb] proton scattering by X-rays Peter, if it's a covalently-bonded H atom it surely can't be a bare proton, it must have at least some partial electron around it for the (possibly partial) covalent bond, enough to diffract X-rays anyway. As you say the proton itself is invisible to X-rays. Cheers -- Ian On 2 February 2015 at 13:08, Peter Moody pcem1bigfi...@gmail.commailto:pcem1bigfi...@gmail.com wrote: Dear BB I have (again) realised how limited by understanding of our subject is. In Nature’s online site http://www.nature.com/nature/journal/vaop/ncurrent/full/nature14110.html?WT.ec_id=NATURE-20150129 there is a paper describing an X-ray structure determined with sub-atomic data (nice!). The figures show density for H+ as well as H-. In my simple way I had assumed that any X-ray scattering from the nucleus was negligible, and that the electrons are responsible for this. I would expect a proton (i.e. H+) alone to be invisible to X-rays, and certainly not to look similar to a hydride (with two electrons in (electron density) maps. What have I missed? Could someone please explain, or
Re: [ccp4bb] MrBump Behaves Strangely
Dear Jacob, Thanks for reporting this problem. Can you tell me what version of CCP4 you are using? As an alternative, you can use MrBUMP via the CCP4-online service which is available from here: www.ccp4.ac.uk/ccp4online It's still in development and only goes as far as the Refmac step but it does process the search models in parallel so it can be a lot quicker than running MrBUMP locally. Best wishes, Ronan On 03/02/15 17:22, Keller, Jacob wrote: Dear Crystallographers, I am trying to get MrBump to complete a partial solution, but on my windows7 machine, the CCP4i interface essentially freezes (cannot see logfiles therein, nothing responds, although it does not completely die), and those log files which I think are the correct ones have ceased changing. Nevertheless, the process continues on 2 cores and 800 MB RAM as phaser.exe. Is something broken here, maybe phaser has gone incognito mode, or something else? It's happened the last few days any time I've tried to run MrBump. Any thoughts? ...And please spare me any parathyrophobia--we don't need to beat that dead horse! JPK *** Jacob Pearson Keller, PhD Looger Lab/HHMI Janelia Research Campus 19700 Helix Dr, Ashburn, VA 20147 email: kell...@janelia.hhmi.org ***
Re: [ccp4bb] Bulk solvent correction in Phaser MR LF
Hi Sacha, I was imprecise. With unplaced I meant neither rotated nor translated. Once you become post-rotationally SF based, you can in fact compute a F(env) whole inclusion should improve the TF score. What is not evident to me is how to use a mask and compute the Fs if the orientation (rotation) is yet to be determined? Thx, BR From: Alexandre OURJOUMTSEV [mailto:sa...@igbmc.fr] Sent: Dienstag, 3. Februar 2015 22:19 To: b...@hofkristallamt.org; CCP4BB@JISCMAIL.AC.UK Subject: RE:[ccp4bb] Bulk solvent correction in Phaser MR LF Dear Bernhard, For the unplaced model, it can only be a Babinet model to improve the scaling, This is not fully true, and the flat mask correction can be used as well. Please look : Fokine, A. Urzhumtsev, A.G. (2002) On the use of low resolution data for translation search in molecular replacement. Acta Cryst., A58, 72-74 Fokine, A., Capitani, G., Grütter, M.G. Urzhumtsev, A. (2003) Bulk-solvent correction for fast translation search in molecular replacement: service programs for AMoRe and CNS. J. Appl.Cryst., 36, 352-355. Best regards, Sacha Urzhumtsev _ De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Bernhard Rupp (Hofkristallrat a.D.) [hofkristall...@gmail.com] Envoyé : mardi 3 février 2015 14:49 À : CCP4BB@JISCMAIL.AC.UK Objet : [ccp4bb] Bulk solvent correction in Phaser MR LF Hi Fellows, I cannot find the proper reference for the implementation of bulk solvent corrections in the Phaser Molecular replacement likelihood functions. For the unplaced model, it can only be a Babinet model to improve the scaling, and I believe that is implemented via a Babinet rescaled function for sigma A including the coordinate error. Can anybody help me where to find that? Thx, BR
