- phenixbb - phenix-online.org

output of labelit.check_pdb_symmetry
by "Weiergräber, Oliver H." 15 Jul '12

15 Jul '12

Hello, I am using labelit.check_pdb_symmetry in order to evaluate a crystal structure with sg P21 (2 copies/asu) and all angles indistinguishable from 90 degs for potential higher (i.e. orthorhombic) symmetry. Comparison of refinement statistics clearly indicates that the most likely scenario is perfect pseudomerohedral twinning of a true P21 crystal (Rfree=0.21). Accordingly, labelit.check_pdb_symmetry reports a striking discrepancy between Rsymop(Iobs) and Rsymop(Icalc): 8 % vs 31 %, i.e. there is an additional (apparent) 2-fold symmetry in the data which cannot be explained by the model. In an attempt to force a solution for comparison and visualization purposes, I have increased the r_symop_tol parameter to 0.35; the program starts to evaluate possible space groups with fTF, yielding scores (these are correlation coefficients, right?) way above 90 %. Still, in the end it reports there are no higher symmetry solutions. Why is this? Does the program check for the contrast between the best solution and the others? Changing peak_cutoff to a "discriminative" value did not help... Best regards, Oliver ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unseren neuen Film? http://www.fz-juelich.de/film Kennen Sie schon unsere app? http://www.fz-juelich.de/app

6 9

Re: [phenixbb] phenixbb Digest, Vol 80, Issue 6
by Yuri 13 Jul '12

13 Jul '12

On Fri, 13 Jul 2012 12:13:15 -0700, phenixbb-request(a)phenix-online.org wrote: > Send phenixbb mailing list submissions to > phenixbb(a)phenix-online.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://phenix-online.org/mailman/listinfo/phenixbb > or, via email, send a message with subject or body 'help' to > phenixbb-request(a)phenix-online.org > > You can reach the person managing the list at > phenixbb-owner(a)phenix-online.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of phenixbb digest..." > > > Today's Topics: > > 1. Re: segmented rigid body refinement (Nathaniel Echols) > 2. Re: segmented rigid body refinement (Pavel Afonine) > 3. Re: average temperature factor (David Cobessi) > 4. Re: segmented rigid body refinement (Gino Cingolani) > 5. Re: average temperature factor (Pavel Afonine) > 6. Re: output of labelit.check_pdb_symmetry (Nicholas Sauter) > 7. Re: average temperature factor (Nathaniel Echols) > > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Jul 2012 09:40:41 -0700 > From: Nathaniel Echols <nechols(a)lbl.gov> > To: PHENIX user mailing list <phenixbb(a)phenix-online.org> > Subject: Re: [phenixbb] segmented rigid body refinement > Message-ID: > <CALeAa1NE=F6Quwvsm=ijGf_j-QMxwN1KqStpwiE6NJ7bmyKnsw(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, Jul 12, 2012 at 9:33 AM, Gino Cingolani < > Gino.Cingolani(a)jefferson.edu> wrote: > >> The latter....something more analytical to split individual chains >> into >> smaller groups >> (e.g. like to define tls groups). >> > > Airlie McCoy just added some functionality to do this in Phaser using > normal mode analysis. It is still somewhat experimental and in flux > (i.e. > the program name isn't even finalized), but I will email you off-list > with > details. > > -Nat >

1 0

segmented rigid body refinement
by Gino Cingolani 12 Jul '12

12 Jul '12

Hi all, I'm refining a large oligomeric structure at low res (~6A). I'd like to define groups to use for 'segmented rigid body refinement'. Is there any rational way to define 'segments'? My macromolecule is already an oligomer on its own, so, intuitively, each protomer is a segment. Thanks, 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 Website: http://www.cingolanilab.org ****************************************************************************** "Nati non foste per viver come bruti, ma per seguir virtute e canoscenza" ("You were not born to live like brutes, but to follow virtue and knowledge") Dante, The Divine Comedy (Inferno, XXVI, vv. 119-120) ________________________________________ From: phenixbb-bounces(a)phenix-online.org [phenixbb-bounces(a)phenix-online.org] on behalf of Nathaniel Echols [nechols(a)lbl.gov] Sent: Thursday, July 12, 2012 7:44 AM To: PHENIX user mailing list Subject: Re: [phenixbb] RFZ is higher than TFZ On Thu, Jul 12, 2012 at 12:38 AM, 周文昌 <wenchangyu2006(a)gmail.com> wrote: > I had one problem using phaser-MR to solve my structure. Phaser-MR gives me > one solution with TFZ=15.4 and LLG=165 which seems to be promising but > phenix.refine does not give me a low R values (0.4884/0.5424). I went back > and checked the solution from phaser-MR, I found RFZ=18.8, higher than TFZ. > Does anyone think this is a problem to solve my structure? > > The space group is C121, I believe there are 4 copies of my search model in > ASU. What is the resolution, and what is the sequence identity of the search model? I don't know whether the high RFZ means anything, but the first thing I would check is whether the packing of the MR solution makes sense; Phaser will do a good job preventing molecules from overlapping (unless you changed it to use much less conservative criteria), but it won't guarantee that the molecules pack into a nice continuous lattice. If there are big gaps, it may not be a real solution. I think we need to add an entire FAQ page for high R-factors. However, there are an increasing number of tools and/or tricks in Phenix to deal with problems like this - in approximate order of runtime: - run phenix.refine for more cycles - at least 20. See this paper for an example of why this can be important: http://journals.iucr.org/d/issues/2012/07/00/kw5044/index.html - use phenix.morph_model (refer to previously mentioned paper) - use phenix.den_refine (or DEN in CNS) - use MR-Rosetta Also, if you're willing to share your data with us, we're collecting difficult-to-refine structures for benchmarking new methods. (It will of course be kept confidential.) -Nat _______________________________________________ phenixbb mailing list phenixbb(a)phenix-online.org http://phenix-online.org/mailman/listinfo/phenixbb

3 5

v1.8 bug ? memory allocation crash in map calculation (phenix.refine, phenix.maps)
by Phil Jeffrey 12 Jul '12

12 Jul '12

This is in F432 in a=b=c=340A at 2.85A resolution. Mac OSX 10.5.8, the machine has 8Gb memory of which something like 6Gb is hanging around begging to be used. 1,327,104,000 if that's in bytes doesn't seem all that excessive. On the other hand, 340*340*340= 39,419,600 so it's perhaps a little greedy. Limits set by shell: phil% limit cputime unlimited filesize unlimited datasize unlimited stacksize 65532 kbytes coredumpsize 0 kbytes memoryuse unlimited descriptors 256 memorylocked unlimited maxproc 266 phenix.refine does the same thing right at the end, which is kind of a shame since it takes quite a long time to run. phenix.maps does the same thing even if I ask it just to generate F,phase in MTZ format. [snip] Compute maps. Python(632) malloc: *** mmap(size=1327104000) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug show_stack(1): /usr/local/phenix-1.8-1069/cctbx_project/cctbx/miller/__init__.py(3067) double_step_filtration show_stack(2): /usr/local/phenix-1.8-1069/cctbx_project/mmtbx/maps/__init__.py(416) map_coefficients_from_fmodel show_stack(3): /usr/local/phenix-1.8-1069/cctbx_project/mmtbx/maps/__init__.py(543) __init__ show_stack(4): /usr/local/phenix-1.8-1069/build/mac-intel-osx/../../cctbx_project/mmtbx/command_line/maps.py(325) run show_stack(5): /usr/local/phenix-1.8-1069/build/mac-intel-osx/../../cctbx_project/mmtbx/command_line/maps.py(402) <module> Bus error (Python call stack above) This crash may be due to a problem in any imported Python module, including modules which are not part of the cctbx project. To disable the traps leading to this message, define these environment variables (e.g. assign the value 1): BOOST_ADAPTBX_FPE_DEFAULT BOOST_ADAPTBX_SIGNALS_DEFAULT This will NOT solve the problem, just mask it, but may allow you to proceed in case it is not critical.

3 8

RFZ is higher than TFZ
by 周文昌 12 Jul '12

12 Jul '12

Dear all, I had one problem using phaser-MR to solve my structure. Phaser-MR gives me one solution with TFZ=15.4 and LLG=165 which seems to be promising but phenix.refine does not give me a low R values (0.4884/0.5424). I went back and checked the solution from phaser-MR, I found RFZ=18.8, higher than TFZ. Does anyone think this is a problem to solve my structure? The space group is C121, I believe there are 4 copies of my search model in ASU. thanks, Wenchang

2 1

sigma_iobs_rejection_criterion
by Yarrow Madrona 10 Jul '12

10 Jul '12

Hello, I am refining a structure using a.eff file that I generated in Phenix version 1.7 GUI and later ran in the command line. When I try to run the same refinement in Phenix V.1.8 I get the following error: For French and Wilson scaling, sigma_iobs_rejection_criterion must be set between -4.0 and -1.0 I see that it was set to zero previously. My questions are: 1. Is this the same observed criterion that is reported in the RCSB Deposition? 2. To be honest I don't understand what this is. Is it a limit for the error in Iobs, below which the reflection will be discarded? 3. What is a reasonable setting for this input and how does it change the refinement? Thank you (I appreciate your help as I know these may be very basic questions). -Yarrow -- Yarrow Madrona Graduate Student Molecular Biology and Biochemistry Dept. University of California, Irvine Natural Sciences I, Rm 2403 Irvine, CA 92697

3 4

Phenix autosol error 2L MAD
by Graeme Winter 10 Jul '12

10 Jul '12

Hi Folks, 2L MAD data set where SHELXC/D/E works fine I (repeatedly) get this error, through GUI or scripts... resolution: 1.7 recommended_resolution: 1.9 datafile_for_hyss: /Users/graeme/projects/test/12287_build/AutoSol_run_10_/TEMP0/ANISO_subset_PHX_I(+)_WAVE1.sca_ano_1.sca aniso_corrected: True aniso_b_min: 13.2 aniso_range_of_b: 6.8 RUNNING HYSS on ANISO_subset_PHX_I(+)_WAVE1.sca_ano_1.sca from PDS as miller arrays *************ERROR ENDING ******************* ******************************************************************************** Failed to carry out AutoSol_hyss: HYSS failed...Probably no iso or ano differences... ******************************************************************************** *************ERROR ENDING ******************* The data set works fine with a third (radiation damaged) data set. There is also a massive anomalous signal in the data (2L) as it stands. here's the PHIL: autosol { seq_file = 12287.seq sites = 8 atom_type = Se crystal_info { unit_cell = 51.59 51.59 157.69 90 90 90 space_group = "P 43 21 2" solvent_fraction = 0.52 chain_type = PROTEIN resolution = 0 change_sg = True } wavelength { data = subset.mtz lambda = 0.97966 f_prime = -9.9 f_double_prime = 3.9 labels = 'I(+)_WAVE1 SIGI(+)_WAVE1 I(-)_WAVE1 SIGI(-)_WAVE1' } wavelength { data = subset.mtz lambda = 1.00000 f_prime = -3.3 f_double_prime = 0.5 labels = 'I(+)_WAVE2 SIGI(+)_WAVE2 I(-)_WAVE2 SIGI(-)_WAVE2' } } Have I done something wrong? Thanks, Graeme

2 1

special position
by Karolina Michalska 09 Jul '12

09 Jul '12

Hi all, I'm refining a structure with a phosphate ion on a 3-fold axis. I set occupancy manually to 0.33 and after refinement the ion has huge B-factor (close to 100) and there is a lot of positive electron density. I found somewhere that phenix recognizes special positions and there is not need to adjust occupancy manually. so I set it to 1 again and re-refined. This time my phosphate sits in a mixture of negative and positive density with B factor around 90 (for comparison Refmac refines it to ~20). Now I'm confused which procedure to follow. Karolina

2 1

I/O error in writing very large B-factors
by Phil Jeffrey 09 Jul '12

09 Jul '12

This occurs at the end of refinement. Quite why it's trying to *read* from a string with Fortran-esque overflow formatting while in a writing step I don't know, but the PDB file gets truncated at REMARK IF THIS FILE IS FOR PDB DEPOSITION: REMOVE ALL FROM THIS LINE UP. The structure is not idyllic, clearly, but I'd like to see the extent of the problem rather than just the first atom. Got to be pretty easy to trap for and map to 999.99 either on the way in or out. Writing refined structure to PDB file: /Users/phil/Structures/reference_models/start_refine_001.pdb n_use = 21264 n_use_u_iso = 21264 n_use_u_aniso = 0 n_grad_site = 0 n_grad_u_iso = 21264 n_grad_u_aniso = 0 n_grad_occupancy = 0 n_grad_fp = 0 n_grad_fdp = 0 total number of scatterers = 21264 Traceback (most recent call last): File "/usr/local/phenix-1.7.3-928/build/mac-intel-osx/../../phenix/phenix/command_line/refine.py", line 11, in <module> command_line.run(command_name="phenix.refine", args=sys.argv[1:]) File "/usr/local/phenix-1.7.3-928/phenix/phenix/refinement/command_line.py", line 105, in run refine_object.write_refined_pdb(f_pdb) File "/usr/local/phenix-1.7.3-928/phenix/phenix/refinement/driver.py", line 1379, in write_refined_pdb ignore_hd = not self.neutron_refinement) File "/usr/local/phenix-1.7.3-928/cctbx_project/mmtbx/model_statistics.py", line 589, in __init__ ignore_hd = ignore_hd) File "/usr/local/phenix-1.7.3-928/cctbx_project/mmtbx/model_statistics.py", line 504, in __init__ molprobity_scores=True) File "/usr/local/phenix-1.7.3-928/cctbx_project/mmtbx/model.py", line 1063, in geometry_statistics molprobity_scores = molprobity_scores) File "/usr/local/phenix-1.7.3-928/cctbx_project/mmtbx/model_statistics.py", line 112, in __init__ self.clashscore_obj.analyze_clashes(hierarchy = pdb_hierarchy) File "/usr/local/phenix-1.7.3-928/cctbx_project/mmtbx/validation/clashscore.py", line 182, in analyze_clashes self.pdb_hierarchy = pdb.hierarchy.input(pdb_string=input_str).hierarchy File "/usr/local/phenix-1.7.3-928/cctbx_project/iotbx/pdb/hierarchy.py", line 1044, in __init__ source_info=source_info, lines=flex.split_lines(pdb_string)) File "/usr/local/phenix-1.7.3-928/cctbx_project/iotbx/pdb/__init__.py", line 582, in input return ext.input(source_info=source_info, lines=lines) ValueError: string, line 5148: ATOM 17 N ILE A 268 -16.878 -22.262 49.415 1.00****** A N ------------------------------------------------------------^ not a floating-point number. Phil Jeffrey Princeton

2 1

Iridium hexamine problems with eLBOW
by Benoît Masquida 07 Jul '12

07 Jul '12

I experience problems generating a correct CIF file for iridium hexamine (IRI in the eLBOW database). The geometry is supposed to be octahedral and eLBOW outputs a prism regardless of the options checked in the GUI. eLBOW actually does the same for the octahedral Mg(OH2)6. Does someone know how to rule this out? Thanks to everybody. Ben -- Benoît Masquida Chargé de Recherche CNRS IBMC Strasbourg UPR 9002 ARN b.masquida(a)ibmc-cnrs.unistra.fr +33 (0)3 88 41 70 45 +33 (0)6 70 23 79 50 +33(0)3 88 60 22 18 (fax)

5 6