- phenixbb - phenix-online.org

Question about anisotropic refinement of selected waters during automatic solvent update
by Schubert, Carsten [PRDUS] 01 Apr '08

01 Apr '08

Hi, I am trying to refine a couple of waters in a structure anisotropically in the latest version of CCI-Apps (Feb-08) . The selection is: refine.adp.anisotropic = "chain W and (resid 25 or resid 54)" The refinement works fine if "main.ordered_solvent = False". When I enable "main.ordered_solvent" the refinement fails with: "Sorry: Bad (empty or mixed) selection in adp_individual.aniso" during the first update of the solvent in macrocycle 1. A workaround is easy to implement, but I think this kind of scheme should work. Although it has all kinds of tricky implication for the downstream handling of the selection if the residues/waters in questions are deleted.... Cheers, Carsten

1 0

gnomebreakpad error
by shivesh kumar 01 Apr '08

01 Apr '08

Dear all, We are trying to install phenix in Fedora Core 8.While installing it is showing the following error- Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory Please suggest what is wrong or missing. Thanx in advance. Shivesh

2 1

tls definitions
by PhilEvans 01 Apr '08

01 Apr '08

Sorry if this has been answered before, but I've only just joined this BB In phenix.refine, I'm trying to make TLS groups consisting of multiple chains, eg refinement.refine { strategy=individual_sites+tls+individual_adp adp { tls="chain A and chain B and chain Z" tls="chain C and chain D and chain Y" } } but it doesn't work: what should I do? Phil ================== Extract refinement strategy and selections ================= individual_sites = True rigid_body = False individual_adp = True group_adp = False tls = True individual_occupancies = False group_occupancies = False group_anomalous = False size = 1356 n_use = 1356 n_use_u_iso = 1356 n_use_u_aniso = 0 n_grad_site = 0 n_grad_u_iso = 0 n_grad_u_aniso = 0 n_grad_occupancy = 0 n_grad_fp = 0 n_grad_fdp = 0 n_anisotropic_flag = 0 total number of scatterers = 1356 Sorry: Empty selection in adp_tls selection.

4 4

question about refinement in a SAD data set
by Pascal EGEA 30 Mar '08

30 Mar '08

Dear All, I am trying to refine a seleno met structures at 2.2 Ang resolution I used Auto_Sol and Auto_Build and it worked great since it found the 4 semets with occupancies of about 0.85 to 0.95. and most of the model was built. Phenix generated an exptl_fp_phases.mtz with the Rfree flag. so far so good. I have a couple of questions because I am not quite to understand what phenix.refine is doing at this stage? 1- If I refine using the experimental phases mtz file generated by the auto_sol run, the occupancies for the seleniums change quite a bit and they drop to 0.75-0.80 and that does not sound right to me? What am I doing wrong? should I fix occupancies for the seleniums to the values evaluated at the end of the auto_build run (Rfree=27/ Rfac=24?) 2- This experimental phases mtz file contains FP and the HL coefficients for the phases but there are no more anomalous differences. If I try to refine f' and f" using it, Phenix tells me that there is no anomalous information contained in this file. So how do you refine f' and f"? and what is the practical reason for this AutoSol generated mtz file to not contain the anomalous differences that were used to locate the seleniums. Thanks in advance for the explanation Pascal F. Egea, PhD Post Doctoral Researcher University of California San Francisco Department of Biophysics and Biochemistry Robert Stroud Laboratory pascal(a)msg.ucsf.edu

3 2

Getting Residual Bs
by Frank von Delft 30 Mar '08

30 Mar '08

Hi Pavel, picking up on your point earlier: > and that there are tools available from both ends (phenix, ccp4) to easily > go from partial to total and back. What *is* the tool in phenix to from total to partial? I suspect it's one of the phenix.pdbtools adp commands, but the documentation is a bit sparse on that program. Cheers phx P.S. Pavel, despite my rant today: great program! :-)

2 1

Re: [phenixbb] refmac,tlsanl vs TLS, B and anisou
by Paul Adams 29 Mar '08

29 Mar '08

Some comments: - We (the PHENIX developers) are working with the PDB to come up with a more streamlined deposition of TLS information for PHENIX. There are some other issues that need to be resolved first that have slowed this down a little. - I am in agreement with George (not unusual). - As far as I remember Garib was supportive of the idea of no longer depositing residual B-factors in the atomic iso-B column. - What phenix.refine writes in the PDB file is almost exactly the same as you would get by running TLSANL on a REFMAC PDB file. - It is my understanding that the EBI runs TLSANL on REFMAC deposited PDB files to extract the ANISOU records so that R-factors can be calculated. It would seems that this information is then discarded. [I could be mistaken about this whole process though] - Allowing ANISOU records only when atomic anisotropic displacement parameters have been refined seems very restrictive. There may be multiple ways to arrive at anisotropic displacements other than the traditional method (TLS is one, George mentioned TLS restraints instead of constraints, and we have some ideas about ADP refinement that would also result in anisotropic displacements). - It is good to remember that TLS refinement is constrained anisotropic displacement parameter refinement. - If we want bioinformaticians to analyze our structures then we should be writing something in the iso-B column that they can understand - I favour the iso-B equivalent of the total atomic B-factor. This I assume they can handle. I very much doubt that anyone other than a crystallographer will go to the trouble of extracting the TLS information and recalculating atomic displacements. - The biologists looking at structures from the PDB do not care about TLS or ANISOU records. If they choose to look at anything it will be the iso-B column (probably by colouring the atoms by B-factor in a display program). I'd like to give them a fighting chance of seeing something meaningful such as the iso-B equivalent of the total atomic B-factor rather than a residual B-factor (which has no meaning to them). - I will not be holding my breath waiting for any of the popular display programs to start interpreting TLS header information. - I agree that it is best for everyone if we have some clear standards for deposition and tags that make it clear to anyone looking at files from the PDB what is meant by the contents. The PDB is very aware of this and I expect things to be straightened out fairly soon in collaboration with the developers of phenix.refine and REFMAC. -- Paul Adams Deputy Division Director, Physical Biosciences Division, Lawrence Berkeley Lab Adjunct Professor, Department of Bioengineering, U.C. Berkeley Vice President for Technology, the Joint BioEnergy Institute Head, Berkeley Center for Structural Biology Building 64, Room 248 Tel: 510-486-4225, Fax: 510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road BLDG 64R0121 Berkeley, CA 94720, USA. --

1 0

Rant: B vs TLS, anisou, and PDB headers
by Frank von Delft 29 Mar '08

29 Mar '08

Just spent an hour trawling docs, BBs (recent threads) and logs to figure out what the hell my B column is telling me (phenix vs refmac vs pdb). Oh dear, it's a disaster area, quite Heissenbergian... the most important number (uncertainty) is itself unknowable: * Phenix writes total ADP, Refmac writes residual ADP. * Refmac writes a remark -- pdbdep strips it (!?!!?) * Phenix writes no remark (I think?) * Refmac writes different numbers to TLSOUT and pdb header (trace of S) * Phenix duplicates the information in header (TLS) and ANISOU cards, the latter thereby making implicit what should be explicitly stored: how the ADPs are connected. * Refmac, given phenix TLS-originating ANISOUs, flattens them into first number, but does not remove them * PDB does not care I'd like to appeal for an urgent consensus -- which should be unusually easy, since it involves only two programs and one repository. My strong recommendation, from first principles of usability: residual B into ATOM, no TLS in ANISOU, and the rest into the header. I know it's religious, but here's the reasoning: ==> the end-user looks *locally*, that's what ATOM and ANISOU are for. ==> global stuff (cell, symmetry, NCS, and yes, TLS) belongs in the header -- as do what's still missing, namely twinning, lattice modulations, scatter factors, and restraints. Yes, we crystallographers want easy B-factor stats (phenix's reason), but then lets fix the analysis programs to look at the header as well. And yes, packing and internal motions (TLS) are all very important for analysis - but that is why it should be explicit in the header, so that graphics tools have easy access to it. End rant (but not end hope :) phx.

3 6

error when optimize_wxc w/o optimize_wxu turned on
by C. Briand, Biochemisches Inst. 28 Mar '08

28 Mar '08

Dear Phenix Users, We are currently using the last version of phenix in our lab. ------------------------------------------------------------------------------- PHENIX: Python-based Hierarchical ENvironment for Integrated Xtallography Version: 2008_02_08_1610 Release tag: rc6 User: briand ------------------------------------------------------------------------------- When we are using phenix.refine to refine a structure and we are turning on optimize_wxc w/o optimize_wxu, the job failed. Any ideas ? Many thanks Christophe =============================================== Dr. Christophe Briand Biochemisches Institut Universität Zürich, Winterthurerstrasse 190, CH-8057 Zürich, Switzerland http://www.bioc.uzh.ch/gruetter/ ===============================================

2 2

sugar links
by Alessandro Nascimento 27 Mar '08

27 Mar '08

Hi all, I'm trying to apply a cif link modification for MAN-MAN link and found this post explaining how to do that: http://www.phenix-online.org/pipermail/phenixbb/2007-July/000332.html However the syntax refinement.pdb_interpretation.apply_cif_link { data_link = NAG-NAG-b-D residue_selection_1 = chain A and resname NAG and resid 901 residue_selection_2 = chain A and resname ASN and resid 900 } gives me the following error *** apply_cif_link: data_link: NAG-NAG-b-D Sorry: Missing CIF link: data_link_NAG-NAG-b-D Please check for spelling errors or specify the file name with the link as an additional argument. *** Has the syntax changed or am I missing something? thanks a lot in advance, --alessandro phenix.refine --version: ------------------------------------------------------------------------------- PHENIX: Python-based Hierarchical ENvironment for Integrated Xtallography Version: 2008_02_08_1610 User: Alessandro -------------------------------------------------------------------------------

2 1

large ASU: problem with upper/lower case chain IDs
by Cherepanov, Peter P 26 Mar '08

26 Mar '08

Dear phenix developers, I am new to this list and apologize in advance if the following has been discussed before. Although, I must say, the problem is rather unusual... well, we are trying to refine a structure with 36 protein chains per asu (not much fun, but it is our best crystal form for this protein). The chains are labeled (by phaser) with UPPER and lower case characters. THE TROUBLE IS, phenix.refine confuses upper and lower case chain IDs. Now, although default refinement (no restraint_group definitions) works, it is very important for us to define groups of residues, in particular, for NCS. I tried defining chains using quotes (e.g chain "i"; or chain 'i', or "chain i", etc,etc), which did not help. Phenix chokes on our pdb file also after automatic NCS search (although it finds and defines ncs groups correctly). It is funny, because, the program does discriminate between upper and lower case characters when referring to an element (e.g. it does not accept "element Se" when coordinate file has got "SE" and vice versa). Analogous refinement (and NCS definitions) works great in Refmac; but would like to compare results and also take advantage of simulated annealing in phenix.refine. Is there a quick fix, without tedious relabeling the chains? In principle, we could use upper case characters, followed by digits 0-9 [that works], but this would make the whole process very difficult for a number of reasons; I hope there is way around it, thank you, Peter PS: we are using v1.3b

2 2