[ccp4bb] alternate confirmations of residues
Hi all Sorry for a non CCP4 question. I m using CNS for structure refinement. The structure is having few residues in alternate confirmations. i can see the density for those alternate confirmations. i m defining those alternate confirmations in the pdb but while generating the topology file, the information of alternate confirmations is getting lost. how can i define the alternate confirmations in generate.inp n minimize.inp. the way i m defining the alternate confirmations in pdb : ATOM 6101 1N LYS D 9383.029 39.489 93.510 0.50 42.90DN ATOM 6101 2N LYS D 9383.028 39.495 93.498 0.50 42.90DN ATOM 6102 1CA LYS D 9382.366 40.672 93.101 0.50 41.09DC ATOM 6102 2CA LYS D 9382.391 40.686 93.075 0.50 41.09DC ATOM 6103 1CB LYS D 9383.019 41.834 93.797 0.50 41.27DC ATOM 6103 2CB LYS D 9383.119 41.836 93.691 0.50 41.27DC ATOM 6104 1CG LYS D 9382.331 42.627 94.824 0.50 43.61DC ATOM 6104 2CG LYS D 9382.419 42.747 94.517 0.50 43.61DC ATOM 6105 1CD LYS D 9381.797 42.040 96.162 0.50 43.24DC ATOM 6105 2CD LYS D 9382.004 42.209 95.769 0.50 43.24DC ATOM 6106 1CE LYS D 9382.265 40.647 96.659 0.50 43.68DC ATOM 6106 2CE LYS D 9380.982 43.099 96.495 0.50 43.68DC ATOM 6107 1NZ LYS D 9382.884 40.390 97.999 0.50 43.36DN ATOM 6107 2NZ LYS D 9380.832 44.665 96.562 0.50 43.36DN ATOM 6108 1C LYS D 9382.478 40.825 91.578 0.50 39.28DC ATOM 6108 2C LYS D 9382.477 40.826 91.567 0.50 39.28DC ATOM 6109 1O LYS D 9382.412 41.847 91.106 0.50 38.72DO ATOM 6109 2O LYS D 9382.408 41.844 91.093 0.50 38.72DO Thanks in advance vineet gaur
Re: [ccp4bb] refmac and ramachandran troubles
You havent got an incorrect CISPEP definition lurking in the PDB file have you - COOT does NOT correct these so if you rebuild something which has been previously flagges as CISPEP ( and that can happen if a very ugly omega angle falls to 89.999 ) then it stays that way in the PDB output from COOT, and REFMAC struggles valiantly to reconstruct a CISPEP.. Eleanor Jan Abendroth wrote: Hi all, along the lines of a recent discussion: At the final stages of the refinement of a structure which a whole bunch of ncs (2x4chains) at 2.2A resolution in P1, I run into the following very annoying and persistent problem. The Ramachandran plot shows a whole bunch of ugly outliers. While some of them appear to be "true", ie. the same outliers in all chains w/o application of ncs, loop region, H-bonds that make sense, ..., there are a number of "misbehaving" outliers: After reciprocal space refinement some residues violate the Ramachandran plot for one or two chains only. Both 2FoFc and FoFc density clearly show that the main chain is supposed to be at a slightly different position. Real space refinement in coot puts the mainchain nicely in place on top of the ncs mates' position. Refmac then pulls things back into the forbidden region. For an illustration see here: http://picasaweb.google.com/Jan.Abendroth/RefmacAndRamachandran/ I have tried to tie down the violators with tight ncs restrains - no success. I am running refmac 5.3.0037, with TLS refinement. Rfactors seem really decent (20%/25%) as does geometry. Refmac complains about "MAKE_U_POSITIVE" problems. Any ideas? Cheers Jan
Re: [ccp4bb] calculating molecular dimensions
Well - PDBSET gives you the X Y and Z dimensions. ( pdbset xyzin thismol.pdb end If you want to align the protein along its principal axes, I usually run the TABLING function of Amore. That takes a model, moves its CofM to the origin and aligns it in such a way. Eleanor Vineet Gaur wrote: Hi All is there any programme available that can calculate the parameters like length of longest and shortest axis passing through the center of mass of a protein mlecule thanx in advance vineet gaur
[ccp4bb] CNS setup file for bash users?
Dear colleagues, although not a CCP4 question, does anyone has a CNS setup file for bash users, analogous to the "cns_setup_env" file for (t)csh users? Best regards, Dirk Kostrewa. *** 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: [EMAIL PROTECTED] ***
Re: [ccp4bb] CNS setup file for bash users?
Dirk Kostrewa schrieb: Dear colleagues, although not a CCP4 question, does anyone has a CNS setup file for bash users, analogous to the "cns_setup_env" file for (t)csh users? Best regards, Dirk Kostrewa. Hi Dirk, I find in $CNS_SOLVE (as distributed with CNS 1.2) both a cns_solve_env (for csh) and a .cns_solve_env_sh (the first letter of the filename is a dot so you have to use "ls -la" to see the file). The latter should be what you can use for bash. HTH, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: [EMAIL PROTECTED]Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz smime.p7s Description: S/MIME Cryptographic Signature
Re: [ccp4bb] Crystals to go
Hi Graeme, I suppose you refer to the poster that was presented by Annette Faust, Andrea Schmidt, Victor Lamzin and Manfred Weiss from EMBL Hamburg with the title: Lysozyme crystals - ready to use. In this poster they present crosslinking of lysozyme crystals with styrene and/or glutaraldehyde and show that they still diffract at RT after several months. The (i.m.h.o. simplest) recipe is: Soak overnight in 25% (v/v) glutaraldehyde Dip into nail polish (It didn't say which brand) Dry and store at RT. The crystals of Mo2P4O15 that James is referring have a unit cell of a = 24.133(2), b =19.579(2), c = 25.109(2)A° , beta=99.962(3)u with a cell volume of 11685(1)A°, but I suppose that most molecular biologists are better in preparing lysozyme crystals then in heating a 3 : 1 molar ratio of (NH4)2HPO4 and MoO3 in a Pt crucible to 873 K followed by washing to remove excess P. (see http://www.rsc.org/delivery/_ArticleLinking/DisplayArticleForFree.cfm?doi=b408413f&JournalCode=CC) for the entire article, which is freely available. Cheers, Bram Winter, G (Graeme) wrote: Hi All, I heard about a way of preparing crystals - presented at the BSR recently as "Crystals to go" - which allows them to be carried at room temperature then cooled for data collection i.e. for beamline testing. Please could someone point me in the right direction for the instructions on how to do this, as I didn't get a chance to see the poster! Thanks, Graeme -- Bram Schierbeek Application Scientist Structural Biological Solutions Bruker AXS BV Oostsingel 209,P.O.Box 811 2600 AV Delft, the Netherlands T: +31 (0)152 152 508 F: +31 (0)152 152 500 E: [EMAIL PROTECTED] W: www.bruker-axs.com
Re: [ccp4bb] Solvent content of membrane protein crystals
Saavas and Tommi, The questions of what is the detergent content of a membrane protein crystal and how to explicitly determine the amount of detergent in a crystal are extremely difficult to address. Moreover, is it worthwhile to even attempt to correct the Matthews coefficient? I personally don't for a number of reasons. However, one point I would like to make in this discussion is that ANYTHING concerning micellar structure or behavior cannot be naively extrapolated to a protein- detergent complex without firm experimental data. Moreover, when the protein-detergent complex is in a crystal, it gets even worse. Very little quantitative work has been done on what is the detergent structure and behavior in a protein-detergent complex. Peter Timmins has done the most using neutron diffraction with me and Wolfram Welte on crystalline systems, as well as in solution (one paper is below). Pebay-Peyuola, E., Garavito, R.M., Rosenbusch, J.P., Zulauf, M., and Timmins, P.A. (1995) "Detergent structure in tetragonal crystals of porin from the outer membrane of E. coli." Structure 3, 1051-1059. One immediate take home message is that a membrane protein IS NOT in a micelle, even by definition from surfactant chemistry, nor does a membrane protein insert into a micelle. In many of the experiments on detergent binding in surfactant chemistry using styrene beads, detergent adsorbs onto a hydrophobic surface from single monomer accretion, and perhaps by micelle fusion. Hence, one should forget about micelles when talking about a protein-detergent complex. My rule of thumb from experience is that an "average" membrane protein of about 50 KD binds about a micelle's worth of detergent, but it would be a mistake to assume it has all the characteristics of a free and pure detergent micelle. Getting back to the amount of detergent in a crystal and the Matthews coefficient, the detergent layer of protein-detergent complex can behave like a hard sphere in a crystal or it can fuse with its neighbors, depending on the detergent used. Changing the detergent concentration around the crystal, as we do when manipulating a crystal for many experiments, will change the detergent concentration in the crystal and can impact the detergent layer of protein- detergent complex. Thus, efforts to get accurate, detergent- corrected Matthews coefficients for membrane proteins, may not be worth worrying about. Regards, Michael R. Michael Garavito, Ph.D. Professor of Biochemistry & Molecular Biology 513 Biochemistry Bldg. Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: [EMAIL PROTECTED] On Sep 24, 2007, at 2:29 AM, Tommi Kajander wrote: Quoting Edward Berry <[EMAIL PROTECTED]>: Savvas Savvides wrote: Indeed, but wouldn't consideration of micelle size affect our estimation of the number of molecules in the asu, in some cases significantly? Good point- I think now that is taken into account by just saying "membrane proteins tend to have a high solvent content" and taking that into consideration when you guess the number of molecules. But it would be nice to account for the detergent explicitly. Say by analyzing detergent content of the crystals, or in some ideal cases neutron diffraction with perdeuterated detergent. with regard to this has anyone actually checked how the micelle properties with or without protein "embedded" might differ?? are we assuming empty micelle and the protein-added micelle are the same size/Mw? is this really so? --- of course this may further vary depending on the oligomeric state of the protein --suppose some neutron scattering studies on model systems might give the answer --havent looked. just wondering.. -tommi -- Tommi Kajander, Ph.D. Macromolecular X-ray Crystallography Research Program in Structural Biology and Biophysics Institute of Biotechnology PO box 65 (Street address: Viikinkaari 1, 4th floor) University of Helsinki FIN-00014 Helsinki, Finland Tel. +358-9-191 58903 Fax +358-9-191 59940
Re: [ccp4bb] arp/warp in p22121: what to do in Pointless
I think this is only a problem in the primitive orthorhombic system (at least I assume people don't want hexagonal axes along a, A & B centred lattices etc, although there is no reason in principle why not). Following some earlier discussions with Ian, Pointless now honours (and preserves) a reference file (HKLREF) in eg P 2 21 21, and also explicit reindex operations, but an initial indexing will still enforce the "standard" setting eg P 21 21 2, because I accept the "reference" setting from the cctbx library ie suppose you have a crystal which when indexed with a <= b <= c and Pointless decides unambiguously for the sake of argument) that the axis along a is a 2-fold and the other two are 2(1) screws, ie space group P 2 21 21. At present this will be reindexed to the "standard" setting P 21 21 2, but is that what you want, or should it be left as acriterion takes precedence? Phil On 19 Sep 2007, at 17:54, Ian Tickle wrote: Hi Sue It's certainly true that the convention in the 1935 and 1952 editions of IT Volume 1 *appeared* to be the 'standard setting' convention that you describe because only the 'standard' settings were listed, and this was the way that many crystallographers interpreted it (actually only macromolecular crystallographers, the small molecule people stick to the IUCr convention), so this is probably where you're coming from. However the 1983 edition of Volume A clarified the situation and made it clear that this was never the intention, so all the conventional settings are now shown on the SG diagram pages. P22121 & P21221 certainly are defined in IT Vol. A - look on the diagram page for SG no. 18 & you'll see them. The 'standard symbol' for a space group is merely the heading on the page used only for indexing purposes, so space groups P22121, P21221 and P21212 all have the same standard symbol P21212; hence the standard symbol is not unique and can't be used to unambiguously define the space group. The 'standard setting' is merely the space group setting that has the same name as the standard symbol. Even if that weren't true do we really want to be still sticking to a convention that was abandoned 25 years ago and doesn't a later convention override an earlier one anyway? Actually the convention in use is not the issue anyway, I don't care which convention is used as long as all programs use the same convention! - then I'll never need to permute axes (just as fundamentally I don't care which co-ordinate format is used as long as all programs use the same one, then I'll never need to reformat). So Mosflm uses the IUCr convention (i.e. a<=b<=c for primitive orthorhombic), and therefore any program which doesn't support that convention for any space group forces you to permute the axes completely unnecessarily. -- Ian -Original Message- From: Sue Roberts [mailto:[EMAIL PROTECTED] Sent: 19 September 2007 16:38 To: Ian Tickle Subject: Re: [ccp4bb] arp/warp in p22121 Hi Ian But there's an older convention, which is to use the space groups settings defined in the International Tables - and P22121 is not a standard setting. Sue On Sep 19, 2007, at 8:18 AM, Ian Tickle wrote: I'm confused now, sticking to the IUCr convention should not require any axis permutation. My beef is specifically against unnecessary axis permutations! Surely it's when the program doesn't support the convention that you are forced to permute the axes? Besides I did solve a structure in P22121 with Phaser so I'm even more confused! -- Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Airlie McCoy Sent: 19 September 2007 15:09 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] arp/warp in p22121 The problem is specifically that ARP/wARP *doesn't* support the IUCr convention as given in IT (Vol. A, >= 1983 edition, Table 9.3.4.1, p.758 in 5th ed.) regarding choice of cell in primitive orthorhombic space groups, and I suspect in centred monoclinic ones also. AFAIK ARP/wARP and pointless are the only two CCP4 programs that currently don't fully support the IUCr convention Phaser doesn't "support" the IUCr convention, and if it was used for the original MR in this case (I don't know whether it was or not), then it would have caused the "problem". We have had user requests to change the output to the IUCr convention, but other people get confused if the axes are permuted. So the choice will be made an output option - Frank von Delft suggested the keyword "IUCR [ON/OFF]"! Vote for your choice of default now... Airlie McCoy Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have r
Re: [ccp4bb] alternate confirmations of residues
Hi Vineet,
I am not sure that you are defining things as expected in the CNS
documentation. If you haven't
already, please read the CNS FAQ page with description of how to define and
include alternate
side-chains for refinement.
In any case, I summarise the steps for you-
1. Run generate.inp with your pdb file. This will make, say, files start.pdb
and start.mtf.
2. Next, run alternate.inp specifying which residues you want alternate
side-chain conformations
for. This will give you, say, alt.pdb and alt.mtf. The alt.pdb file will
contain the following
definitions: the 1st conformation as *AC1* and will list the 2nd conformer at
the end of the file
with ID *AC2*. From the coordinates, you will see that CNS has simply made a
copy of the side chains.
3. Copy the *AC2* conformations into a new pdb file since I found that the
program 'O' seems to have
trouble recognizing AC2, if AC1 exists in the same pdb file. Don't know how
Coot handles this. Read
this into O. Fix all AC2 to their correct conformation in O. Read out the
conformations.
4. Replace new AC2 conformations at the end of alt.pdb. Say, we call it
alt_new.pdb. Use this pdb
file for refinement. Throughout refinement, you need to specify the new atom
definitions in
minimize.inp and other input files.
Example:
{* select atoms in alternate conformation 1 *}
{===>} conf_1=(segid AC1 AND RESID 46);
{* select atoms in alternate conformation 2 *}
{===>} conf_2=(segid AC2 AND RESID 46);
5. Most importantly, use *alt.mtf* throughout this refinement cycle.
6. Also, make sure the occupancies for AC1 and AC2 are distributed - some folks
split occu as 0.5
and 0.5. Some split it as 0.65 and 0.35. You may have other intelligent
criteria to determine the
occupancies.
7. Remember, you need to carry out all of the above steps at every round of
refinement. So, keep
alternate side-chain addition to the very final rounds of structure
determination.
8. If it still remains a black box, switch to Refmac.
Hope that helps.
Raji
-Included Message--
>Hi all
>
>Sorry for a non CCP4 question.
>I m using CNS for structure refinement. The structure is having few residues
>in alternate confirmations. i can see the density for those alternate
>confirmations. i m defining those alternate confirmations in the pdb but
>while generating the topology file, the information of alternate
>confirmations is getting lost. how can i define the alternate confirmations
>in generate.inp n minimize.inp.
>
>the way i m defining the alternate confirmations in pdb :
>
>
>
>ATOM 6101 1N LYS D 9383.029 39.489 93.510 0.50 42.90DN
>
>ATOM 6101 2N LYS D 9383.028 39.495 93.498 0.50 42.90DN
>
>ATOM 6102 1CA LYS D 9382.366 40.672 93.101 0.50 41.09DC
>ATOM 6102 2CA LYS D 9382.391 40.686 93.075 0.50 41.09DC
>ATOM 6103 1CB LYS D 9383.019 41.834 93.797 0.50 41.27DC
>ATOM 6103 2CB LYS D 9383.119 41.836 93.691 0.50 41.27DC
>ATOM 6104 1CG LYS D 9382.331 42.627 94.824 0.50 43.61DC
>ATOM 6104 2CG LYS D 9382.419 42.747 94.517 0.50 43.61DC
>ATOM 6105 1CD LYS D 9381.797 42.040 96.162 0.50 43.24DC
>ATOM 6105 2CD LYS D 9382.004 42.209 95.769 0.50 43.24DC
>ATOM 6106 1CE LYS D 9382.265 40.647 96.659 0.50 43.68DC
>ATOM 6106 2CE LYS D 9380.982 43.099 96.495 0.50 43.68DC
>ATOM 6107 1NZ LYS D 9382.884 40.390 97.999 0.50 43.36DN
>ATOM 6107 2NZ LYS D 9380.832 44.665 96.562 0.50 43.36DN
>ATOM 6108 1C LYS D 9382.478 40.825 91.578 0.50 39.28DC
>
>ATOM 6108 2C LYS D 9382.477 40.826 91.567 0.50 39.28DC
>
>ATOM 6109 1O LYS D 9382.412 41.847 91.106 0.50 38.72DO
>
>ATOM 6109 2O LYS D 9382.408 41.844 91.093 0.50 38.72DO
>
>
>Thanks in advance
>
>vineet gaur
>
>
-End of Included Message--
Re: [ccp4bb] arp/warp in p22121: what to do in Pointless
Phil, For the record, the program XPREP - widely used by small molecule crystallographers but also useful for macromoleculess - always makes the conventional cell (in this example P 21 21 2) the default (i.e. what you get if you always hit ), and writes out new .hkl and .ins files in this setting unless the user forces it to do otherwise (the .ins file is used for solving the structure with direct methods and contains the cell corresponding to the new .hkl file). There are three cases where it is intentionally made less awkward for the user to choose an alternative setting if she/he so wishes: 1. Primitive rhombohedral rather than the hexagonal cell with three times the volume. Unlike the situation for macromolecules, where some older programs do not work with the primitive rhombohedral cell, the primitive cell is quite often chosen for small molecules. 2. The space group I2 rather than C2 if it results in a beta angle much closer to 90 degrees (or when it is desired to compare the structure with a structure - possibly another crystalline phase of the same compound - in say I222). The same applies to other C-centred monoclinic cells, e.g. Cc <-> Ia etc. (but Fd is discouraged). 3. The setting P21/n rather than P21/c if it results in a beta angles much closer to 90 etc. These three 'unconventional' settings are also generally accepted by the checking software, databases and journals. To cover all reasonable non-standard settings, XPREP actually understands 413 different space groups! Best wishes, George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-2582 On Mon, 24 Sep 2007, Phil Evans wrote: > I think this is only a problem in the primitive orthorhombic system (at least > I assume people don't want hexagonal axes along a, A & B centred lattices etc, > although there is no reason in principle why not). > > Following some earlier discussions with Ian, Pointless now honours (and > preserves) a reference file (HKLREF) in eg P 2 21 21, and also explicit > reindex operations, but an initial indexing will still enforce the "standard" > setting eg P 21 21 2, because I accept the "reference" setting from the cctbx > library > > ie suppose you have a crystal which when indexed with a <= b <= c and > Pointless decides unambiguously for the sake of argument) that the axis along > a is a 2-fold and the other two are 2(1) screws, ie space group P 2 21 21. > > At present this will be reindexed to the "standard" setting P 21 21 2, but is > that what you want, or should it be left as a precedence? > > Phil > > > On 19 Sep 2007, at 17:54, Ian Tickle wrote: > > > Hi Sue > > > > It's certainly true that the convention in the 1935 and 1952 editions of > > IT Volume 1 *appeared* to be the 'standard setting' convention that you > > describe because only the 'standard' settings were listed, and this was > > the way that many crystallographers interpreted it (actually only > > macromolecular crystallographers, the small molecule people stick to the > > IUCr convention), so this is probably where you're coming from. However > > the 1983 edition of Volume A clarified the situation and made it clear > > that this was never the intention, so all the conventional settings are > > now shown on the SG diagram pages. P22121 & P21221 certainly are > > defined in IT Vol. A - look on the diagram page for SG no. 18 & you'll > > see them. > > > > The 'standard symbol' for a space group is merely the heading on the > > page used only for indexing purposes, so space groups P22121, P21221 and > > P21212 all have the same standard symbol P21212; hence the standard > > symbol is not unique and can't be used to unambiguously define the space > > group. The 'standard setting' is merely the space group setting that > > has the same name as the standard symbol. Even if that weren't true do > > we really want to be still sticking to a convention that was abandoned > > 25 years ago and doesn't a later convention override an earlier one > > anyway? > > > > Actually the convention in use is not the issue anyway, I don't care > > which convention is used as long as all programs use the same > > convention! - then I'll never need to permute axes (just as > > fundamentally I don't care which co-ordinate format is used as long as > > all programs use the same one, then I'll never need to reformat). So > > Mosflm uses the IUCr convention (i.e. a<=b<=c for primitive > > orthorhombic), and therefore any program which doesn't support that > > convention for any space group forces you to permute the axes completely > > unnecessarily. > > > > -- Ian > > > > > -Original Message- > > > From: Sue Roberts [mailto:[EMAIL PROTECTED] > > > Sent: 19 September 2007 16:38 > > > To: Ian Tickle > > > Subject: Re: [ccp4bb] arp/warp in p22121 > > > > > > Hi Ian > > > > > > But there's an older co
Re: [ccp4bb] arp/warp in p22121: what to do in Pointless
Phil, It also affects centred monoclinic: to avoid some cases of beta > 120 you have to use the I121 setting instead of C121 (and it is a conventional setting, see IT vol. A pp.126-7). For example the conventional (but non-standard) I121 setting: a=50 b=60 c=51 beta=90.2 would I think be re-indexed by pointless to the unconventional (but standard) C121 setting: a=71.3 b=60 c=50 beta=134.3. Trigonal, tetragonal & hexagonal settings with a or b unique are definitely not only non-standard but also non-conventional: they violate Table 9.3.4.1 in IT Vol. A and they don't appear in the diagrams, so let's not go there! The point about the IUCr convention is that the cell is determined by the rules in Table 9.3.4.1 so you would never get into that situation. For the oP lattice the cell is determined once and for all by the rules in exactly the same way: the systematic absences are not taken into account because they are not always reliable, e.g. it may be only after you've solved the TF that you can assign the SG correctly, or at least beyond reasonable doubt, and re-indexing at that point makes no sense. To summarise my POV: I don't really care which convention you use, but I think gratuitous re-indexing (i.e. without the user specifically asking for it) is just very confusing, and this is what can happen if you stick to the standard settings. I'm all for educating users, and re-indexing 1 or 2 datasets can be very educational, but if you have lots of datasets to deal with it's no longer amusing! Sometimes re-indexing *is* needed, e.g. because you already have isomorphous protein-ligand structures and you want to be able to compare them easily, but this should *only* be done to conform to a reference dataset. I don't see any point in re-indexing just to conform to the 'standard setting' 'non-convention' which is derived from a mis-reading of the 1952 ed of IT (my guess is they didn't list all the conventional settings because the publisher wanted to save money! - but at least they saw sense for the 1983 ed.). In any case this will only affect users of Arp/Warp, all other CCP4 programs (and most non-CCP4 programs, e.g. Shel-X, CNS etc) can handle non-standard settings, and if you use Mosflm and always specify SG P222 for all oP cases (which I always do anyway), you would have to re-index anyway. -- Ian > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Phil Evans > Sent: 24 September 2007 16:58 > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] arp/warp in p22121: what to do in Pointless > > I think this is only a problem in the primitive orthorhombic system > (at least I assume people don't want hexagonal axes along a, A & B > centred lattices etc, although there is no reason in > principle why not). > > Following some earlier discussions with Ian, Pointless now honours > (and preserves) a reference file (HKLREF) in eg P 2 21 21, and also > explicit reindex operations, but an initial indexing will still > enforce the "standard" setting eg P 21 21 2, because I accept the > "reference" setting from the cctbx library > > ie suppose you have a crystal which when indexed with a <= b > <= c and > Pointless decides unambiguously for the sake of argument) that the > axis along a is a 2-fold and the other two are 2(1) screws, ie space > group P 2 21 21. > > At present this will be reindexed to the "standard" setting P 21 21 > 2, but is that what you want, or should it be left as a criterion takes precedence? > > Phil > > > On 19 Sep 2007, at 17:54, Ian Tickle wrote: > > > Hi Sue > > > > It's certainly true that the convention in the 1935 and 1952 > > editions of > > IT Volume 1 *appeared* to be the 'standard setting' > convention that > > you > > describe because only the 'standard' settings were listed, > and this > > was > > the way that many crystallographers interpreted it (actually only > > macromolecular crystallographers, the small molecule people stick > > to the > > IUCr convention), so this is probably where you're coming from. > > However > > the 1983 edition of Volume A clarified the situation and > made it clear > > that this was never the intention, so all the conventional > settings > > are > > now shown on the SG diagram pages. P22121 & P21221 certainly are > > defined in IT Vol. A - look on the diagram page for SG no. > 18 & you'll > > see them. > > > > The 'standard symbol' for a space group is merely the heading on the > > page used only for indexing purposes, so space groups P22121, > > P21221 and > > P21212 all have the same standard symbol P21212; hence the standard > > symbol is not unique and can't be used to unambiguously define the > > space > > group. The 'standard setting' is merely the space group > setting that > > has the same name as the standard symbol. Even if that weren't > > true do > > we really want to be still sticking to a convention that > was abandoned > > 25 year
[ccp4bb] coot--saving changes
Posted for my post-doc...for some reason her subscription is slow in starting...any off-line replies should go to [EMAIL PROTECTED] Dear Coot users out there, I am a new coot user and have tried many methods to save changes while rebuilding, short of "save coordinates". The manual says that coot saves changes automatically after every change and writes a new .pdb.gz file in coot-backup. I notice a new file appearing in coot-backup after every change alright but it does not have the changes I made. I could write out a .pdb every time I make a change but isn't there anything akin to File->save in O (writing out binary.o as the default file) that coot has? Or, to make the coot-backup files actually reflect the change I've made? I discovered that "save state" only saves the position in the molecule I am walking and not any changes made, much to my horror. Or is there something I am missing here too? Any help anyone, please? Thanks a million tons in advance, Sangeetha Vedula --- Patrick J. Loll, Ph. D. (215) 762-7706 Associate Professor FAX: (215) 762-4452 Department of Biochemistry & Molecular Biology Director, Biochemistry Graduate Program Drexel University College of Medicine Room 10-102 New College Building 245 N. 15th St., Mailstop 497 Philadelphia, PA 19102-1192 USA [EMAIL PROTECTED]
Re: [ccp4bb] arp/warp in p22121: what to do in Pointless
OK I'll try to change the default behaviour, after I've fixed the current round of bugs! Sometimes reindexing is required from the Mosflm indexing even without a reference set, if the Laue group assignment is wrong, or where there is pseudo lattice symmetry (eg we have a case which is really R3 but pseudo I-centred cubic, so Mosflm may choose the wrong 3-fold in its indexing) My POV was that on the first dataset, you don't care about the indexing, just about the space group, but this is undermined by the frequent uncertainty about systematic absences. I think the best thing to do is to choose the reindexing for the Laue group (or point group), and not to switch it for different possible space groups within the Laue group. I think this should be able to pick up the I121 setting of C2 (though I might have to make that a special case: similarly George's P21/n v. P21/c) Phil On 24 Sep 2007, at 17:59, Ian Tickle wrote: Phil, It also affects centred monoclinic: to avoid some cases of beta > 120 you have to use the I121 setting instead of C121 (and it is a conventional setting, see IT vol. A pp.126-7). For example the conventional (but non-standard) I121 setting: a=50 b=60 c=51 beta=90.2 would I think be re-indexed by pointless to the unconventional (but standard) C121 setting: a=71.3 b=60 c=50 beta=134.3. Trigonal, tetragonal & hexagonal settings with a or b unique are definitely not only non-standard but also non-conventional: they violate Table 9.3.4.1 in IT Vol. A and they don't appear in the diagrams, so let's not go there! The point about the IUCr convention is that the cell is determined by the rules in Table 9.3.4.1 so you would never get into that situation. For the oP lattice the cell is determined once and for all by the rules in exactly the same way: the systematic absences are not taken into account because they are not always reliable, e.g. it may be only after you've solved the TF that you can assign the SG correctly, or at least beyond reasonable doubt, and re-indexing at that point makes no sense. To summarise my POV: I don't really care which convention you use, but I think gratuitous re-indexing (i.e. without the user specifically asking for it) is just very confusing, and this is what can happen if you stick to the standard settings. I'm all for educating users, and re- indexing 1 or 2 datasets can be very educational, but if you have lots of datasets to deal with it's no longer amusing! Sometimes re-indexing *is* needed, e.g. because you already have isomorphous protein-ligand structures and you want to be able to compare them easily, but this should *only* be done to conform to a reference dataset. I don't see any point in re-indexing just to conform to the 'standard setting' 'non-convention' which is derived from a mis-reading of the 1952 ed of IT (my guess is they didn't list all the conventional settings because the publisher wanted to save money! - but at least they saw sense for the 1983 ed.). In any case this will only affect users of Arp/Warp, all other CCP4 programs (and most non-CCP4 programs, e.g. Shel-X, CNS etc) can handle non-standard settings, and if you use Mosflm and always specify SG P222 for all oP cases (which I always do anyway), you would have to re- index anyway. -- Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Evans Sent: 24 September 2007 16:58 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] arp/warp in p22121: what to do in Pointless I think this is only a problem in the primitive orthorhombic system (at least I assume people don't want hexagonal axes along a, A & B centred lattices etc, although there is no reason in principle why not). Following some earlier discussions with Ian, Pointless now honours (and preserves) a reference file (HKLREF) in eg P 2 21 21, and also explicit reindex operations, but an initial indexing will still enforce the "standard" setting eg P 21 21 2, because I accept the "reference" setting from the cctbx library ie suppose you have a crystal which when indexed with a <= b <= c and Pointless decides unambiguously for the sake of argument) that the axis along a is a 2-fold and the other two are 2(1) screws, ie space group P 2 21 21. At present this will be reindexed to the "standard" setting P 21 21 2, but is that what you want, or should it be left as a Hi Sue It's certainly true that the convention in the 1935 and 1952 editions of IT Volume 1 *appeared* to be the 'standard setting' convention that you describe because only the 'standard' settings were listed, and this was the way that many crystallographers interpreted it (actually only macromolecular crystallographers, the small molecule people stick to the IUCr convention), so this is probably where you're coming from. However the 1983 edition of Volume A clarified the situation and made it clear that this was never the intention, so all the convention
[ccp4bb] CALL FOR PROPOSALS FOR ESRF BEAMTIME WITH ONLINE MICROSPEC
CALL FOR PROPOSALS FOR ESRF BEAMTIME WITH ONLINE MICROSPEC There will be beamtime available from **15th to 18th November 2007** inclusive at the ESRF for MX data collection with a setup that allows online monitoring of UV/VIS spectral changes of the crystal during the X-ray diffraction experiment. Users who are interested in this beam time (including those who are members of BAG Groups) should apply /via/ the following mechanism: http://www.esrf.fr/UsersAndScience/UserGuide/Applying/ProposalGuidelines/MXnon-BAGproposal and it must be clearly indicated in the title of the proposal form that the online monitoring of spectral changes is necessary for the project. A brief description of the device is given below, however users are encouraged to consult the webpages for detailed information: http://www.esrf.fr/UsersAndScience/Experiments/MX/How_to_use_our_beamlines/Run_Your_Experiment/Microspectrophotometer_User_Guide As this is not a standard setup, it might take a significant amount of time to train users, align the device, and analyse the data in order to derive relevant data collection schemes. We will therefore schedule 24 hours for each project. The deadline for this specific application is *Monday 8th October 2007, 9:00am* Dates: 15th-18th November 2007 Storage Ring: Uniform Fill (200mA) Beamline: ID14-2 Specifications: UV/VIS-range: 250-800nm ODmax: 2-2.5 min integration time: 150ms Light source: OceanOptics DH2000, Halogen/D2-lamp Monitoring Light size: 0.03 (min) - 0.15mm (max) Sampling freq (to disk): 10Hz or lower
Re: [ccp4bb] arp/warp in p22121: what to do in Pointless
Hi Phil, Just in case anyone was used to the old default behaviour (and like to use the current version of Arp/wArp ;oD) could you ensure that there is an option which will allow the automatic reindexing to the old default setting? Thanks, Graeme From: CCP4 bulletin board on behalf of Phil Evans Sent: Mon 24/09/2007 6:18 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] arp/warp in p22121: what to do in Pointless OK I'll try to change the default behaviour, after I've fixed the current round of bugs! Sometimes reindexing is required from the Mosflm indexing even without a reference set, if the Laue group assignment is wrong, or where there is pseudo lattice symmetry (eg we have a case which is really R3 but pseudo I-centred cubic, so Mosflm may choose the wrong 3-fold in its indexing) My POV was that on the first dataset, you don't care about the indexing, just about the space group, but this is undermined by the frequent uncertainty about systematic absences. I think the best thing to do is to choose the reindexing for the Laue group (or point group), and not to switch it for different possible space groups within the Laue group. I think this should be able to pick up the I121 setting of C2 (though I might have to make that a special case: similarly George's P21/n v. P21/c) Phil On 24 Sep 2007, at 17:59, Ian Tickle wrote: > > Phil, > > It also affects centred monoclinic: to avoid some cases of beta > 120 > you have to use the I121 setting instead of C121 (and it is a > conventional setting, see IT vol. A pp.126-7). For example the > conventional (but non-standard) I121 setting: a=50 b=60 c=51 beta=90.2 > would I think be re-indexed by pointless to the unconventional (but > standard) C121 setting: a=71.3 b=60 c=50 beta=134.3. > > Trigonal, tetragonal & hexagonal settings with a or b unique are > definitely not only non-standard but also non-conventional: they > violate > Table 9.3.4.1 in IT Vol. A and they don't appear in the diagrams, so > let's not go there! The point about the IUCr convention is that the > cell is determined by the rules in Table 9.3.4.1 so you would never > get > into that situation. For the oP lattice the cell is determined > once and > for all by the rules in exactly the same way: the systematic absences > are not taken into account because they are not always reliable, > e.g. it > may be only after you've solved the TF that you can assign the SG > correctly, or at least beyond reasonable doubt, and re-indexing at > that > point makes no sense. > > To summarise my POV: I don't really care which convention you use, > but I > think gratuitous re-indexing (i.e. without the user specifically > asking > for it) is just very confusing, and this is what can happen if you > stick > to the standard settings. I'm all for educating users, and re- > indexing > 1 or 2 datasets can be very educational, but if you have lots of > datasets to deal with it's no longer amusing! Sometimes re-indexing > *is* needed, e.g. because you already have isomorphous protein-ligand > structures and you want to be able to compare them easily, but this > should *only* be done to conform to a reference dataset. I don't see > any point in re-indexing just to conform to the 'standard setting' > 'non-convention' which is derived from a mis-reading of the 1952 ed of > IT (my guess is they didn't list all the conventional settings because > the publisher wanted to save money! - but at least they saw sense for > the 1983 ed.). > > In any case this will only affect users of Arp/Warp, all other CCP4 > programs (and most non-CCP4 programs, e.g. Shel-X, CNS etc) can handle > non-standard settings, and if you use Mosflm and always specify SG > P222 > for all oP cases (which I always do anyway), you would have to re- > index > anyway. > > -- Ian > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Phil Evans >> Sent: 24 September 2007 16:58 >> To: CCP4BB@JISCMAIL.AC.UK >> Subject: Re: [ccp4bb] arp/warp in p22121: what to do in Pointless >> >> I think this is only a problem in the primitive orthorhombic system >> (at least I assume people don't want hexagonal axes along a, A & B >> centred lattices etc, although there is no reason in >> principle why not). >> >> Following some earlier discussions with Ian, Pointless now honours >> (and preserves) a reference file (HKLREF) in eg P 2 21 21, and also >> explicit reindex operations, but an initial indexing will still >> enforce the "standard" setting eg P 21 21 2, because I accept the >> "reference" setting from the cctbx library >> >> ie suppose you have a crystal which when indexed with a <= b >> <= c and >> Pointless decides unambiguously for the sake of argument) that the >> axis along a is a 2-fold and the other two are 2(1) screws, ie space >> group P 2 21 21. >> >> At present this will be reindexed to the "standard" setting P 21 21 >> 2, but is that
[ccp4bb] mosflm orientation matrix and symmetry
does the mosflm orientation matrix specify the crystal system and only the crystal system? i.e, given an orientation matrix from autoindexing, it would be correct to simply use keyword 'SYMMETRY SPACEGROUP' in mosflm to refine then integrate in any of the spacegroups within a given crystal system from autoindexing? -bryan
Re: [ccp4bb] Solvent content of membrane protein crystals
I would like to thank Michael Caravito and Gert Van den Berg for taking the time to share their knowledge and insights on protein-detergent/micelle complexes. A series of experiments I carried out using DLS some time ago showed that the protein-detergent/micelle complex (with LDAO as detergent) for the membrane protein I was studying had a hydrodynamic radius that was 20 angs larger than the empty-micelles. The experiments were done in the protein storage buffer: 20 mM Tris 8.0, 250 mM NaCl, 0.15 % LDAO, which is far from a crystallization condition! As Michael and Gert pointed out, it is a risky business to draw quantitative conclusions from such measurements due to the effects of so many factors. Nonetheless, it was quite informative to me at the time to see a marked difference between the protein-detergent complex and the empty-micelles. Aside form bringing home the concept that the interaction of the protein with detergent/micelle had a true physical meaning that could be translated to particle augmentation, it also helped me benchmark my gel-filtration runs. Best regards Savvas Savvas N. Savvides Unit for Structural Biology and Biophysics Laboratory for Protein Biochemistry - Ghent University K.L. Ledeganckstraat 35 9000 Ghent, BELGIUM Phone: +32-(0)9-264.51.24 ; +32-(0)472-92.85.19 Email: [EMAIL PROTECTED] http://www.eiwitbiochemie.ugent.be/units_en/structbio_en.html Quoting "R.M. Garavito" <[EMAIL PROTECTED]>: Saavas and Tommi, The questions of what is the detergent content of a membrane protein crystal and how to explicitly determine the amount of detergent in a crystal are extremely difficult to address. Moreover, is it worthwhile to even attempt to correct the Matthews coefficient? I personally don't for a number of reasons. However, one point I would like to make in this discussion is that ANYTHING concerning micellar structure or behavior cannot be naively extrapolated to a protein- detergent complex without firm experimental data. Moreover, when the protein-detergent complex is in a crystal, it gets even worse. Very little quantitative work has been done on what is the detergent structure and behavior in a protein-detergent complex. Peter Timmins has done the most using neutron diffraction with me and Wolfram Welte on crystalline systems, as well as in solution (one paper is below). Pebay-Peyuola, E., Garavito, R.M., Rosenbusch, J.P., Zulauf, M., and Timmins, P.A. (1995) "Detergent structure in tetragonal crystals of porin from the outer membrane of E. coli." Structure 3, 1051-1059. One immediate take home message is that a membrane protein IS NOT in a micelle, even by definition from surfactant chemistry, nor does a membrane protein insert into a micelle. In many of the experiments on detergent binding in surfactant chemistry using styrene beads, detergent adsorbs onto a hydrophobic surface from single monomer accretion, and perhaps by micelle fusion. Hence, one should forget about micelles when talking about a protein-detergent complex. My rule of thumb from experience is that an "average" membrane protein of about 50 KD binds about a micelle's worth of detergent, but it would be a mistake to assume it has all the characteristics of a free and pure detergent micelle. Getting back to the amount of detergent in a crystal and the Matthews coefficient, the detergent layer of protein-detergent complex can behave like a hard sphere in a crystal or it can fuse with its neighbors, depending on the detergent used. Changing the detergent concentration around the crystal, as we do when manipulating a crystal for many experiments, will change the detergent concentration in the crystal and can impact the detergent layer of protein- detergent complex. Thus, efforts to get accurate, detergent- corrected Matthews coefficients for membrane proteins, may not be worth worrying about. Regards, Michael R. Michael Garavito, Ph.D. Professor of Biochemistry & Molecular Biology 513 Biochemistry Bldg. Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: [EMAIL PROTECTED] On Sep 24, 2007, at 2:29 AM, Tommi Kajander wrote: Quoting Edward Berry <[EMAIL PROTECTED]>: Savvas Savvides wrote: Indeed, but wouldn't consideration of micelle size affect our estimation of the number of molecules in the asu, in some cases significantly? Good point- I think now that is taken into account by just saying "membrane proteins tend to have a high solvent content" and taking that into consideration when you guess the number of molecules. But it would be nice to account for the detergent explicitly. Say by analyzing detergent content of the crystals, or in some ideal cases neutron diffraction with perdeuterated detergent. with regard to this has anyone actu
Re: [ccp4bb] Solvent content of membrane protein crystals
Hi, There are at least 4 methods to try to estimate amount of detergent in a membrane protein crystal which may lead to a more accurate estimation of asu content, etc. At the minimum, this may serve academic curiosity. At the best, if one obtains membrane protein crystals that do not diffract well, any estimates gleaned from this can be used in attempts to improve crystal quality. These 4 methods are more useful for membrane protein solutions, but if one has sufficiently large crystals, they may be dissolved in buffer and subject to the same experiments. The techniques are TLC, ANS dye method, DLS (as Savvas mentioned) and FTIR (Fourier Transform Infra Red spec). All of them would require first obtaining a standard curve by first measuring values for buffer solutions with known amounts of detergent, say from 1x to 100x CMC. I have tried all 4 of these methods with several different detergents at different concentration and I think the FTIR comes closest to an accurate measurement. In my experience, DLS readings are difficult when working at or near CMC levels due to aggregation problems. However, none of the results were totally satisfying, probably due to the complexities of the system (as others have mentioned) which include presence of not only empty micelles along with protein-detergent complex but possibly also lipid-detergent complex and maybe also impurity protein-detergent complexes. Our case was also complicated by the fact that the protein under investigation was a highly elongated molecule and thus DLS estimates of hydrodynamic radius may not have been accurate. In summary, someone wanting to estimate amount of detergent in their crystals and have sufficiently large and numerous crystals, could try out any of the above methods. The above techniques are quite well documented in literature. The first 3 can be done in-house and so can FTIR. We were lucky enough to have access to an FTIR setup at ALS. Regards, Debanu. -- Debanu Das, JCSG @ SSRL. Forwarded message -- From: Savvas Savvides <[EMAIL PROTECTED]> Date: Sep 24, 2007 3:36 PM Subject: Re: [ccp4bb] Solvent content of membrane protein crystals To: CCP4BB@jiscmail.ac.uk I would like to thank Michael Caravito and Gert Van den Berg for taking the time to share their knowledge and insights on protein-detergent/micelle complexes. A series of experiments I carried out using DLS some time ago showed that the protein-detergent/micelle complex (with LDAO as detergent) for the membrane protein I was studying had a hydrodynamic radius that was 20 angs larger than the empty-micelles. The experiments were done in the protein storage buffer: 20 mM Tris 8.0, 250 mM NaCl, 0.15 % LDAO, which is far from a crystallization condition! As Michael and Gert pointed out, it is a risky business to draw quantitative conclusions from such measurements due to the effects of so many factors. Nonetheless, it was quite informative to me at the time to see a marked difference between the protein-detergent complex and the empty-micelles. Aside form bringing home the concept that the interaction of the protein with detergent/micelle had a true physical meaning that could be translated to particle augmentation, it also helped me benchmark my gel-filtration runs. Best regards Savvas Savvas N. Savvides Unit for Structural Biology and Biophysics Laboratory for Protein Biochemistry - Ghent University K.L. Ledeganckstraat 35 9000 Ghent, BELGIUM Phone: +32-(0)9-264.51.24 ; +32-(0)472-92.85.19 Email: [EMAIL PROTECTED] http://www.eiwitbiochemie.ugent.be/units_en/structbio_en.html Quoting "R.M. Garavito" <[EMAIL PROTECTED]>: > Saavas and Tommi, > > The questions of what is the detergent content of a membrane protein > crystal and how to explicitly determine the amount of detergent in a > crystal are extremely difficult to address. Moreover, is it > worthwhile to even attempt to correct the Matthews coefficient? I > personally don't for a number of reasons. However, one point I would > like to make in this discussion is that ANYTHING concerning micellar > structure or behavior cannot be naively extrapolated to a protein- > detergent complex without firm experimental data. Moreover, when the > protein-detergent complex is in a crystal, it gets even worse. Very > little quantitative work has been done on what is the detergent > structure and behavior in a protein-detergent complex. Peter Timmins > has done the most using neutron diffraction with me and Wolfram Welte > on crystalline systems, as well as in solution (one paper is below). > > Pebay-Peyuola, E., Garavito, R.M., Rosenbusch, J.P., Zulauf, M., and > Timmins, P.A. (1995) "Detergent structure in tetragonal crystals of > porin from the outer membrane of E. coli." Structure 3, 1051-1059. > > One immediate take home message is that a membrane protein IS NOT in a > micelle, even by definition from surfactant chemistry, nor does a > membrane protein insert into a
Re: [ccp4bb] Solvent content of membrane protein crystals
Das, Debanu wrote: Hi, There are at least 4 methods to try to estimate amount of detergent in a membrane protein crystal . In summary, someone wanting to estimate amount of detergent in their crystals and have sufficiently large and numerous crystals, could try out any of the above methods. The above techniques are quite well documented in literature. The first 3 can be done in-house and so can FTIR. I happen to have the reference for Ron Kaplan's TLC method at my fingertips: Eriks, L. R., Mayor, J. A. & Kaplan, R. S. (2003). A strategy for identification and quantification of detergents frequently used in the purification of membrane proteins. Anal Biochem 323, 234-41. Sensitivity is limited by the amount of aqueous solution you can spot on a TLC plate. Probably could improve sensitivity by speed-vac-ing an aliquot to near dryness and redissolving in 50% methanol or something.
Re: [ccp4bb] mosflm orientation matrix and symmetry
Bryan, I think it would be more correct to say that the orientation matrix file applies to the Bravais type (e.g., hP--hexagonal primitive). Within the Bravais type you can substitute a different space group prior to integration. Nick From: "Bryan W. Lepore" <[EMAIL PROTECTED]> > does the mosflm orientation matrix specify the crystal system and > only the > crystal system? > > i.e, given an orientation matrix from autoindexing, it would be > correct to > simply use keyword 'SYMMETRY SPACEGROUP' in mosflm to refine then > integrate in any of the spacegroups within a given crystal system > from > autoindexing? > > -bryan >
