- phenixbb - phenix-online.org

Molprobity percentile statistic
by hari jayaram 19 Oct '09

19 Oct '09

Hi i just started using the phenix GUI front-end to Molprobity . Its really nice the way it plugs into coot and displays all the statistics etc. Is there any place that it also reports the percentile clashscore and percentile Molprobity score for overall model quality a la the webserver at molprobity.biochem.duke.edu Thanks Hari

3 2

Re: [phenixbb] pseudo-merohedral twinning or pseudo-symmetry?
by Gino Cingolani 17 Oct '09

17 Oct '09

Laurie, I had a similar problem. Scaling statistics in P212121 were OK, and - of course - no twinning was detected ... but nothing made sense during refinement. Looking at the data more carefully I found that if one rescales in P21, the b-angle was stably refined to 90.20 with ~30% better Rsym than in orthorhombic. When running xtriage on the P21 data, I found the data were indeed "pseudomerohedrally-twinned" with twinning fraction ~0.38. Good luck! Gino

3 2

pseudo-merohedral twinning or pseudo-symmetry?
by Laurie Betts 16 Oct '09

16 Oct '09

Hi - We have a data set that seems to process well in primitive orthorhombic. a=80, b=87, c=114. The data has overall Rsymm around 10% to 2.6 Angstrom, where I/sigI > 2, and Chi-squared is around 1.4. Phenix.xtriage shows some pathology in intensity statistics such that the L-test indicates <|L|> = 0.414 and <L^2> = 0.241, with the L-test Z score = 7.334. The Wilson ratio for acentric refls is 1.774. According the xtriage, There were no "pseudomerohedral" twin laws found, and the comments at the end say "As there are no twin laws possible given the crystal symmetry, there could be a number of reasons......" Is it more likely that this is a case of pseudo-symmetry, or would one not expect the intensity statistics to have the values they do in that case. Also, is the absence of twin laws defined by the fact that proper merohedral twinning is not possible for P222 space groups? Still confused, Laurie Betts

2 1

autobuild
by Colin Levy 16 Oct '09

16 Oct '09

Hi, can autobuild be setup to use kicked maps when starting from a molecular replacement model? Thanks Colin

2 1

Re: [phenixbb] grouped occupancy definitions
by Dr. Mark Mayer 15 Oct '09

15 Oct '09

Hi Pavel, I'm digging in docs and list serv but could not find out, and figured you probably know faster. I need to make an occ.params file for some groups of non adjacent side chains which interact with each other, and associated waters. 1) How do I select ACs 2) How do I constrain water occupancies so that their Q + that of coupled protein atomes does not exceed 1. If I match the AC flags for the waters and side chains will this take care of it. e.g. if residues 2 and 21 have coupled ACs and waters 101 and 102 move in when residue 21 is in one of its ACs how would I define below? refinement { refine { occupancies { constrained_group { selection = chain A and resseq 2 selection = chain A and resseq 21 selection = chain W and resseq 101 selection = chain W and resseq 102 } } Thanks !!! -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Mark Mayer Ph.D.

2 2

low resolution refinement question
by Peter Grey 15 Oct '09

15 Oct '09

Dear Phenix users, I refine a large complex with three monomers in ASU at very low resolution - 4.5A - and would like to ask two questions. - Could you give some tips about refinement at this resolution other than rigid body refinement - Can TLS and grouped B-factors work at this poor resolution ? - I would really prefer that rigid body refinement will strictly obey the NCS that was found in the molecular replacement solution. I understand constrained NCS does not exist yet in phenix but is there something approximate that can be used in rigid body refinement ? I tried the conventional restrained NCS and the result was just like without restrains. Thank you for your time , Peter.

3 2

Why is CIF monomer data split into individual files?
by Joe Krahn 14 Oct '09

14 Oct '09

Is there a good reason not to merger all monomer data into a single file, similar to PDB's components.cif? My first thought is that it is a performance issue. However, I wrote a simple CIF parser in Tcl, and found that carefully designed regexp processing can index data segments very fast. The entire components.cif takes just a few seconds. (The key is to use a regexp that matches an entire data block, and not tokenize the whole file.) So, I am thinking that a single merged file might be better. With separate files, there is already a need for a list of residues (mon_lib_list.cif) which could just as well be file offsets. So, even if parsing is not so fast, it is not an issue because we already have an index file. One problem with separate files is that it relies on the 3-letter residue name to be unique. With a merged file, a different database key can be used without concern for filename restrictions. The PDB format was originally designed so that HET 3-letter codes only need a file scope, where HETNAM defines the full name of each HET residue in a file. Everyone has been using HET codes the same as standard residues, which has cause the 3-letter codes to become meaningless database keys rather than useful abbreviations. Eventually, we will run out of 3-letter codes, and will have to change. Why not start sooner rather than later? Even now, there are potential conflicts. For example, CCP4 has DNA residues using a lower-case d, which may not provide a unique filename for non-POSIX case-insensitive operating systems. If anyone actually wants a Tcl CIF parser, I can share it. I only wrote it as a simple and efficient way to read CIF files from a CCP4i script. Joe Krahn

1 0

Re: [phenixbb] Autobuild for very elongated models
by Gino Cingolani 14 Oct '09

14 Oct '09

Thanks Tom! Gino ****************************************************************************** Gino Cingolani, Ph.D. Associate Professor Thomas Jefferson University Dept. of Biochemistry & Molecular Biology 233 South 10th Street - Room 826 Philadelphia PA 19107 Office (215) 503 4573 Lab (215) 503 4595 Fax (215) 923 2117 E-mail: gino.cingolani(a)jefferson.edu ****************************************************************************** "Nati non foste per viver come bruti, ma per seguir virtute e conoscenza" ("You were not born to live like brutes, but to follow virtue and knowledge") Dante, The Divine Comedy (Inferno, XXVI, vv. 119-120) ---- Original message ---- >Date: Wed, 14 Oct 2009 08:28:09 -0600 >From: Tom Terwilliger <terwilliger(a)lanl.gov> >Subject: Re: [phenixbb] Autobuild for very elongated models >To: Gino.Cingolani(a)jefferson.edu,PHENIX user mailing list <phenixbb(a)phenix-online.org> > >Hi Gino, > >Here is how to specify a mask in phenix.autobuild (see https://www.phenix-online.org/documentation/faqs.htm >#anch68): > >----------------- >How can I specify a mask for density modification in AutoSol/AutoBuild? >If you want to specify a mask, add this command: > >resolve_command_list=" 'model ../../coords.pdb' 'use_model_mask' " >where there are " and ' quotes and coords.pdb is the model to use for >a mask. Note the "../../" because coords.pdb is in your working >directory but when resolve runs the run directory is 2 directories >lower, so relative to that directory your coords.pdb is at "../../ >coords.pdb". You will know it is working if your resolve_xx.log says: >"Using model mask calculated from coordinates" >----------------- >I am not so sure this is the problem, however. I would suggest that >you do a quick composite omit map before refinement on your mr model: >phenix.autobuild data=data.mtz model=MR.1.pdb >composite_omit_type=simple_omit >It is important that this start with you MR unrefined model so that >you have no worries about model bias. This procedure will omit a >region, refine, calculate a 2Fo-Fc map for the omitted region, then >repeat for all other parts of your model and paste them all together >and put it in >AutoBuild_run_1_/OMIT/resolve_composite_map.mtz >which you can use to calculate a map with LABIN="FP=FP PHIB=PHIM >FOM=FOMM" (you need to include the FOM). >If this map shows density for your whole model...you are in great >shape and the problem may indeed be the mask. If it does not...then >the model may not be very close and it may be difficult to proceed. >All the best, >Tom T > >On Oct 14, 2009, at 7:57 AM, Gino Cingolani wrote: > >> Hi Everyone, >> >> I am trying to solve a very elongated structure (~180A-long) formed >> by two long a-helices. I have a good MR solution (Log-Likelihood >> Gain ~168.537 to 3.0A resolution), which refines OK immediately >> after MR (Rfactor/Rfree 46/50%). The electron density has clear side >> chain features and high res data is available to ~2.1A resolution. >> >> Logically, I should be able to plug everything into Autobuild and >> get a good final model (or at least something better than my input >> MR solution). I have tried a million time using different parameters >> and datasets, but Autobuild always breaks up my long helical model >> into short helical bundles, that refine to random Rfree. In other >> words, if my starting MR model is a continuous >> 80aa-long helix, Autobuild fragments it into three helices of ~30aa >> each packed laterally (I see back my initial model if I visualize >> symmetry-related atoms in Coot). >> >> In parallel, I have made the following observation. >> If I use DM to improve my phases, prior to Autobuild, I noticed that >> something similar happens. DM gives great density for less than half >> of my long helix while the rest is flattened. >> If I look at the solvent mask generated by DM, it basically flattens >> half of my elongated model. It seems that at least DM fails to >> generate a solvent mask that makes sense with such an elongated >> structure (by the way, the unit cell is a=25, b=37, c=220 in >> P212121). This problem can be circumvented in DM where >> an outside solvent mask can be inputted, but what about in phenix? >> >> Is it possible that Autobuild is failing because Resolve also makes >> a poor solvent mask? Is there a way to see and/or edit the solvent >> mask generated by Resolve? Or even better, can I input a new solvent >> mask in Autobuild? >> >> Thanks in advance for the feedback! >> >> Gino >> >> >> ****************************************************************************** >> Gino Cingolani, Ph.D. >> Associate Professor >> Thomas Jefferson University >> Dept. of Biochemistry & Molecular Biology >> 233 South 10th Street - Room 826 >> Philadelphia PA 19107 >> Office (215) 503 4573 >> Lab (215) 503 4595 >> Fax (215) 923 2117 >> E-mail: gino.cingolani(a)jefferson.edu >> ****************************************************************************** >> "Nati non foste per viver come bruti, ma per seguir virtute e >> conoscenza" >> ("You were not born to live like brutes, but to follow virtue and >> knowledge") >> Dante, The Divine Comedy (Inferno, XXVI, vv. 119-120) >> _______________________________________________ >> phenixbb mailing list >> phenixbb(a)phenix-online.org >> http://www.phenix-online.org/mailman/listinfo/phenixbb > > >Thomas C. Terwilliger >Mail Stop M888 >Los Alamos National Laboratory >Los Alamos, NM 87545 > >Tel: 505-667-0072 email: terwilliger(a)LANL.gov >Fax: 505-665-3024 SOLVE web site: http://solve.lanl.gov >PHENIX web site: http:www.phenix-online.org >ISFI Integrated Center for Structure and Function Innovation web site: http://techcenter.mbi.ucla.edu >TB Structural Genomics Consortium web site: http://www.doe-mbi.ucla.edu/TB >CBSS Center for Bio-Security Science web site: http://www.lanl.gov/cbss > > > > >_______________________________________________ >phenixbb mailing list >phenixbb(a)phenix-online.org >http://www.phenix-online.org/mailman/listinfo/phenixbb

2 1

Autobuild for very elongated models
by Gino Cingolani 14 Oct '09

14 Oct '09

Hi Everyone, I am trying to solve a very elongated structure (~180A-long) formed by two long a-helices. I have a good MR solution (Log-Likelihood Gain ~168.537 to 3.0A resolution), which refines OK immediately after MR (Rfactor/Rfree 46/50%). The electron density has clear side chain features and high res data is available to ~2.1A resolution. Logically, I should be able to plug everything into Autobuild and get a good final model (or at least something better than my input MR solution). I have tried a million time using different parameters and datasets, but Autobuild always breaks up my long helical model into short helical bundles, that refine to random Rfree. In other words, if my starting MR model is a continuous 80aa-long helix, Autobuild fragments it into three helices of ~30aa each packed laterally (I see back my initial model if I visualize symmetry-related atoms in Coot). In parallel, I have made the following observation. If I use DM to improve my phases, prior to Autobuild, I noticed that something similar happens. DM gives great density for less than half of my long helix while the rest is flattened. If I look at the solvent mask generated by DM, it basically flattens half of my elongated model. It seems that at least DM fails to generate a solvent mask that makes sense with such an elongated structure (by the way, the unit cell is a=25, b=37, c=220 in P212121). This problem can be circumvented in DM where an outside solvent mask can be inputted, but what about in phenix? Is it possible that Autobuild is failing because Resolve also makes a poor solvent mask? Is there a way to see and/or edit the solvent mask generated by Resolve? Or even better, can I input a new solvent mask in Autobuild? Thanks in advance for the feedback! Gino ****************************************************************************** Gino Cingolani, Ph.D. Associate Professor Thomas Jefferson University Dept. of Biochemistry & Molecular Biology 233 South 10th Street - Room 826 Philadelphia PA 19107 Office (215) 503 4573 Lab (215) 503 4595 Fax (215) 923 2117 E-mail: gino.cingolani(a)jefferson.edu ****************************************************************************** "Nati non foste per viver come bruti, ma per seguir virtute e conoscenza" ("You were not born to live like brutes, but to follow virtue and knowledge") Dante, The Divine Comedy (Inferno, XXVI, vv. 119-120)

2 1

use get_cc_mtz_pdb to calculate the cc between model and map
by 丁玮 14 Oct '09

14 Oct '09

Hi, everyone: When I use get_cc_mtz_pdb to calculate the cc between model and map, two values is output: （1）Overall map correlation: （2）Map correlation in region of model: What is the different between them? Whether the "Map correlation in region of model" is the correlation between model and the density map superimposing on it and the "Overall map correlation" is the correlation between model and the overall density map? Thanks a lot! dream dingding830106(a)sina.com 2009-10-14

2 1