Movatterモバイル変換

• 1. Foundations
• 2. Analysis of experimental data
• 3. Substructure determination, phasing and molecular replacement
• 4. Model building, ligand fitting and nucleic acids
• 5. Model, and model-to-data, validation
• 6. Structure refinement
• 7. Integrated structure determination
• 8. Conclusions
• References

• 1. Foundations
• 2. Analysis of experimental data
• 3. Substructure determination, phasing and molecular replacement
• 4. Model building, ligand fitting and nucleic acids
• 5. Model, and model-to-data, validation
• 6. Structure refinement
• 7. Integrated structure determination
• 8. Conclusions
• References

PHENIX: a comprehensive Python-based system for macromolecular structure solution

Macromolecular X-ray crystallography is routinely applied to understand biological processes at a molecular level. How­ever, significant time and effort are still required to solve and complete many of these structures because of the need for manual interpretation of complex numerical data using many software packages and the repeated use of interactive three-dimensional graphics.PHENIX has been developed to provide a comprehensive system for macromolecular crystallo­graphic structure solution with an emphasis on the automation of all procedures. This has relied on the development of algorithms that minimize or eliminate subjective input, the development of algorithms that automate procedures that are traditionally performed by hand and, finally, the development of a framework that allows a tight integration between the algorithms.

Keywords:PHENIX;Python;macromolecular crystallography;algorithms.

1.1.PHENIX architecture

ThePHENIX (Adamset al., 2002) architecture is designed from the ground up as a hybrid system of tightly integrated interpreted (`scripted') and compiled software modules. A mix of scripted and compiled components is invariably found in all major successful crystallographic packages, but often the scripting is added as an afterthought in anad hoc fashion using tools that predate the object-oriented programming era. While suchad hoc systems are quickly established, they tend to become a severe maintenance burden as they grow. In addition, users are often forced into many time-consuming routine tasks such as manually converting file formats. InPHENIX, the scripting layer is the heart of the system. With only a few exceptions, all major functionality is implemented as modules that are exclusively accessedvia the scripting interfaces. The object-oriented Python scripting language (Lutz & Ascher, 1999) is used for this purpose. In about two decades, a large developer/user community has produced millions of lines of highly uniform, interoperable, mature and openly available sources covering all aspects of programming ranging from simple file handling to highly sophisticated network communication and fully featured cross-platform graphical interfaces. Embedding crystallographic methods into this environment enables an unprecedented degree of automation, stability and portability. By design, the object-oriented programming model fosters shared collaborative development by multiple groups. It is routine practice to hierarchically recombine modules written by different groups into ever more complex procedures that appear uniform from the outside. A more detailed overview of the key software technology leading to all these advances, presented in the context of crystallography, can be found in Grosse-Kunstleveet al. (2002).

In addition to the advantages outlined in the previous paragraph, the scripting language is generally most efficient for the rapid development of new algorithms. However, run­time performance considerations often dictate that numerically intensive calculations are eventually implemented in a compiled language. The first choice of a compiled language is of course to reuse the same language environment as used for the scripting language itself, which is a C/C++ environment. Not only is this the mainstream software environment on all major platforms used today, but with probably hundreds of millions of lines of C/C++ sources in existence it is an environment that is virtually guaranteed to thrive in the long term. An in-depth discussion of the combined use of Python and C++ can be found in Grosse-Kunstleveet al. (2002) and Abrahams & Grosse-Kunstleve (2003). This model is used throughout thePHENIX system.

1.2. Graphical user interface

A new graphical user interface (GUI) forPHENIX was introduced in version 1.4. It uses the open-source wxPython toolkit, which provides a `native' look on each operating system. Development has focused on providing interfaces around the existing command-line programs with minimal modification, using the same underlying configuration system (libtbx.phil) as used by mostPHENIX programs as a template to automatically generate controls. Because these programs are implemented primarily as Python modules, complex data including models, reflections and other viewable data may be exchanged with the GUI without resorting to parsing log files. The currentPHENIX release (version 1.5) includes GUIs forphenix.refine (Afonineet al., 2005),phenix.xtriage (Zwartet al., 2005), theAutoSol (Terwilligeret al., 2009),AutoBuild (Terwilliger, Grosse-Kunstleve, Afonine, Moriarty, Adamset al., 2008) andLigandFit (Terwilligeret al., 2006) wizards, the restraints editorREEL, all of the validation tools and several utilities for creating and manipulating maps and reflection files. More recent builds ofPHENIX contain a new GUI for theAutoMR wizard and future releases will include a new interface forPhaser (McCoyet al., 2007).

Intrinsically graphical data is visualized with embedded graphs (using the free matplotlib Python library) or a simple OpenGL viewer. This simplifies the most complex parameters, such as atom selections inphenix.refine, which can be visual­ized or picked interactively with the built-in viewer. The GUI also serves as a platform for additional automation and user customization. Similarly to theCCP4 interface (CCP4i; Pottertonet al., 2003),PHENIX manages data and task history for separate user-defined projects. Default parameters and input files can be specified for each project; for instance, the generation of ligand restraints from thephenix.refine GUI gives the user the option of automatically loading these restraints in future runs.

The popularity of Python as a scientific programming language has led to its use in many other structural-biology applications, especially molecular-graphics software. ThePHENIX GUI includes extension modules for the modeling programsCoot (Emsley & Cowtan, 2004) andPyMOL (DeLano, 2002), both of which are controlled remotely fromPHENIX using the XML-RPC protocol. This allows the interfaces to integrate seamlessly; any model or map inPHENIX can be automatically opened inCoot with a single click. In programs that iteratively rebuild or refine structures, such asAutoBuild andphenix.refine, the current model and maps will be continually updated inCoot and/orPyMOL as soon as they are available. In the validation utilities, clicking on any atom or residue flagged for poor statistics will recentre the graphics windows on that atom. Remote control of thePHENIX GUI is also simple using the same protocol and simple extensions to theCoot interface provide direct launching ofphenix.refine with a model pre-loaded.

3.1.Substructure determination

The substructure-determination procedure implemented asphenix.hyss (Hybrid Substructure Search; Grosse-Kunstleve & Adams, 2003) combines the multi-trial dual-space recycling approaches pioneered byShake-and-Bake (Milleret al., 1994) and laterSHELXD (Sheldrick, 2008) with the use of the fast translation function (Navaza & Vernoslova, 1995; Grosse-Kunstleve & Brunger, 1999). The fast translation function is the basis for a systematic search in thePatterson function (performed in reciprocal space), in contrast to the stochastic alternative ofSHELXD (performed in direct space).Phenix.hyss is the only substructure-determination program to fully integrate automatic comparison of the substructures found in multiple trialsvia a Euclidean Model Matching procedure (part of thecctbx open-source libraries). This allowsphenix.hyss to detect if the same solution was found multiple times and to terminate automatically if this is the case. Extensive tests with a variety of SAD data sets (Grosse-Kunstleve & Adams, 2003) have led to a parameterization of the procedure that balances runtime considerations and the likelihood that repeated solutions present the correctsubstructure. In many cases the procedure finishes in seconds if thesubstructure is detectable from the input data.

3.2. Phasing

Phaser, available inPHENIX asphenix.phaser, applies the principle ofmaximum likelihood to solving crystal structures bymolecular replacement, by single-wavelength anomalous diffraction (SAD) or by a combination of both. The likelihood targets take proper account of the effects of different sources of error (and, in the case of SAD phasing, their correlations) and allow different sources of information to be combined. In solving a molecular-replacement problem with a number of different components, the information gained from a partial solution increases the signal in the search for subsequent components. Because the likelihood scores for different models can be directly compared, decisions among models can readily be made as part of automation strategies (discussed below).

3.3.Noncrystallographic symmetry (NCS)

Noncrystallographic symmetry is an important feature of many macromolecular crystals that can be used to greatly improve electron-density maps.PHENIX has tools for the identification of NCS and for using NCS and multiple crystal forms of a macromolecule in phase improvement.

Phenix.find_ncs andphenix.simple_ncs_from_pdb are tools for the identification ofnoncrystallographic symmetry in a structure using information from a heavy-atomsubstructure or an atomic model.Phenix.simple_ncs_from_pdb will identify NCS and generate transformations from the chains in a model in a PDB file.Phenix.find_ncs will identify NCS from either a heavy-atomsubstructure (Terwilliger, 2002a) or the chains in a PDB file and will then compare this NCS with the density in a map to verify that the NCS is actually present.

Phenix.multi_crystal_average is a method for combining information from several crystal forms of a structure. It is especially well suited to cases where each crystal form has its own NCS, adjusting phases for each crystal form so that all the NCS copies in all crystals are as similar as possible.

NCS restraints should normally be applied in density modification and model building in all cases except where there is clear evidence that NCS is not present. In density modification withinPHENIX the presence of NCS is identified from the heavy-atom sites or from an atomic model if available. The local correlation of density in NCS-related locations is then used automatically to set variable restraints on NCS symmetry in the map. Inrefinement, NCS symmetry is applied through coordinate restraints, targeting the positions of each NCS copy relative to those of the other NCS-related chains. The default NCS restraints inPHENIX are very tight, with targets of 0.05 Å r.m.s. At resolutions lower than about 2.5 Å these tight restraints on NCS should usually be applied. At higher resolutions it may be appropriate to use looser restraints or to remove them altogether. Additionally, if there are segments of the chains that clearly do not obey the NCS relationships they should be excluded from the NCS restraints. Normally this is performed automatically, but it can also be specified explicitly.

4.1. Model building

Phenix.find_helices_strands will rapidly build a secondary-structure-only model into a map or very rapidly trace the polypeptide backbone of a model into a map. To build secondary structure in a map,phenix.find_helices_strands identifiesα-helical regions andβ-strand segments, models idealized helices and strands into the corresponding density, allowing for bending of the helices and strands, and assembles these into a composite model. To very rapidly trace the main chain in a map, phenix.find_helices_strands finds points along ridgelines of high density where C_α atoms might be located, identifies pairs and then triplets of these C_α atoms that have density between the atoms and plausible geometry, constructs all possible connections of these C_α atoms into nonamers and then identifies all the longest possible chains that can be made by joining the nonamers. This process can build a C_α model at a rate of about 20 residues per second, yielding a backbone model that can readily be interpreted visually or automatically to evaluate the quality of the map that it is based on.

Phenix.fit_loops will fit missing loops in an atomic model. It usesRESOLVE model building (Terwilliger, 2003a,b,c) to extend the chain from either end where a loop is missing and to connect the chains into a loop with the expected number of residues.

4.2. Ligand fitting

Phenix.ligandfit is a tool for fitting a flexible ligand into an electron-density map (Terwilligeret al., 2006). The key approaches used are breaking the ligand into its component rigid-body parts, finding where each of these can be placed into density, tracing the remainder of the ligand based on the positions of these core rigid-body parts and recombining the best parts of multiple fits while scoring based on the fit to the density.

Phenix.find_all_ligands is a tool for finding all the instances of each of several ligands in an electron-density map.Phenix.find_all_ligands finds the largest contiguous region of unused density in a map and usesphenix.ligandfit to fit each supplied ligand into that density. It then chooses the ligand that has the highest real-space correlation to the density (Terwilliger, Adamset al., 2007). It then repeats this process until no ligands can be satisfactorily fitted into any remaining density in the map.

Phenix.ligand_identification is a tool for identifying which ligands are compatible with unknown electron density in a map (Terwilliger, Adamset al., 2007). It can search using the 200 most common ligands from the PDB or from a user-supplied list of ligands.Phenix.ligand_identification usesphenix.ligandfit to fit each ligand to the map and identifies the best-fitting ligand using the real-space correlation and surface complementarity of the ligand and the atoms in the structure surrounding the ligand-binding site.

4.3. RNA and DNA

In common with most macromolecular crystallographic tools,PHENIX was originally developed with protein structures primarily in mind. Now thatnucleic acids, and especially RNA, are increasingly important in large biological structures, the system is being modified in places where subtle differences in procedure are needed rather than just the relevant libraries.

Model building inphenix.autobuild now has a preliminary set of nucleic acid procedures that take advantage of the relatively well determined phosphate and base positions, as well as the preponderance of double helix, and that make use of the RNA backbone conformers recently defined by the RNA Ontology Consortium (Richardsonet al., 2008). Nucleic acid structures benefit significantly from torsion-anglerefinement, which has recently been added to the options inphenix.refine. A principal problem in RNA models is getting the ribose pucker correct, although it is known to consist almost entirely of either C3′-endo (which is commoner and that found in the A-form helix) or C2′-endo (Altona & Sundaralingam, 1972).MolProbity uses the perpendicular distance from the 3′ phosphate to the line of the C1′—N1/9 glycosidic bond as a reliable diagnostic of ribose pucker (Daviset al., 2007; Chenet al., 2010). This same test has now been built intophenix.refine to allow the use of pucker-specific target parameters for bond lengths, angles and torsions (Gelbinet al., 1996) rather than the uneasy compromise values (Parkinsonet al., 1996) used in most pucker-agnosticrefinement. Currently, if an incorrect pucker is diagnosed it must usually be fixed by user rebuilding, for instance inCoot (Emsley & Cowtan, 2004) or inRNABC (Wanget al., 2008). A rebuilding functionality will probably be incorporated intoPHENIX soon, but in the meantime therefinement will now correctly maintain the geometry of a C2′-­endo pucker once it has been built and identified using conformation-specific residue names.

4.4. Maps, models and avoiding bias

Phenix.refine (and the graphical toolphenix.create_maps) can produce various types of maps, including anomalous difference,maximum-likelihood weighted (p*mF_obs −q*DF_model)exp(iα_model) and regular (p*F_obs −q*F_model)exp(iα_model), wherep andq are any user-defined numbers, filled and kick maps. The coefficientsm andD of likelihood-weighted maps (Read, 1986) are computed using test-set reflections as described in Lunin & Skovoroda (1995) and Urzhumtsevet al. (1996).

Data incompleteness, especially systematic incompleteness, can cause map distortions (Lunin, 1988; Tronrud, 1997). An approach to remedying this problem is to replace (`fill') missing observations with nonzero values. One can useDF<sub>model</sub> (similarly toREFMAC; Murshudovet al., 1997) to replace the missingF<sub>obs</sub> or use 〈F<sub>obs</sub>〉, where theF<sub>obs</sub> are averaged across a resolution bin around the missingF<sub>obs</sub> value. Based on a limited number of tests, both `filling' schemes produce similar results, reiterating the importance of phases. However, it is important to keep in mind that by replacing missingF_obs there is a risk of introducing bias and obviously the more incomplete the data is the larger the risk. At present it is advisable to use both maps simultaneously: filled and not filled.

An average kick map (AK map; Gunčaret al., 2000; Turk, 2007; Pražnikaret al., 2009) is the result of the following procedure. A large ensemble of structures is created where the coordinates of each structure from the ensemble are all randomly shaken. A map is then computed for each structure. Finally, all maps are averaged to generate one AK map. An AK map is expected to have less bias and less noise and to enhance the existing signal and can potentially clarify some initially bad densities.

A computationally intensive but powerful method of creating a very low-bias map is to carry out iterative model building andrefinement while omitting one region of the map from all calculations of structure factors (Terwilliger, Grosse-Kunstleve, Afonine, Moriarty, Adamset al., 2008). Thephenix.autobuild iterative-build OMIT map procedure carries this out automatically for either a single OMIT region or for overlapping OMIT regions to create a composite iterative-build OMIT map.

5.1. Model and structure-factor manipulation and analysis

PHENIX has a range of tools for displaying, analyzing and manipulating structure-factor and model information.Phenix.mtz.dump andphenix.cif_as_mtz display and convert structure-factor data.Phenix.print_sequence,phenix.pdb_atom_selection andphenix.pdbtools display and manipulate coordinate files.

Phenix.tls is a tool for the extraction and manipulation of TLS information. Using this tool, TLS matrices and selections can be extracted fromREFMAC- orPHENIX-formatted PDB file headers and the total or residual atomicB factors can be computed and output. Future functionality will include the complete analysis of TLS matrices and their graphical visual­ization.

Phenix.get_cc_mtz_mtz andphenix.get_cc_mtz_pdb are tools for analyzing the agreement between maps based on a pair of MTZ files or between maps calculated from an MTZ file and a PDB file. The key attributes of these tools are that they automatically search all allowed origin shifts that might relate the two maps and that they write out a modified version of one of the MTZ files or of the PDB file, shifted to match the other.

6.1. Ligand-coordinate and restraint-geometry generation

Theelectronic Ligand Builder and Optimization Builder (eLBOW; Moriartyet al., 2009) is a suite of tools designed for the reliable generation of Cartesian coordinates and geometry restraints for both novel and known ligands. In line with the rest of thePHENIX package, theeLBOW modules are written in Python, with the numerically intensive portions of the code written in C++.eLBOW is a flexible platform for converting a majority of common chemical inputs to optimized three-dimensional coordinates and geometry restraints forrefinement. Ligand geometries can be minimized using the semi-empirical AM1 quantum-chemical method (Stewart, 2004), a numerically efficient and chemically accurate technique for the class of molecules commonly complexed with or bound to proteins.

In addition, a graphical user interface for editing geometry restraints and simple geometry manipulation of ligands has been developed. TheRestraints Editor, Especially Ligands (REEL) removes the tedium of manually editing a restraints file by providing a number of commonly performed actionsvia pull-down menus and other interactive features. The effect of changes in the restraints can be immediately reflected in the molecule view to provide user feedback.

A tool that uses many of the features ofeLBOW to quickly and easier prepare a protein model forrefinement is known asReadySet! The flexibility of the Python interface is exemplified by the use ofReduce, eLBOW and several smaller portions of thecctbx toolkit to add H and/or D atoms to the model, ligands and water and to generate metal-coordination files and geometry restraints for unknown ligands. The files required for covalently bound ligands are also generated.

7.1. Why automation?

Automation has dramatically changed macromolecular crystallography over the past decade, both by greatly speeding up the process of structure solution, model building andrefinement and by bringing the tools forstructure determination to a much wider group of scientists. As automation becomes increasingly comprehensive, it will allow users to test many more possibilities forstructure determination, will allow improved estimation of uncertainties in the final structures and will allow the determination of ever more complex and difficult structures.

ThePHENIX environment has been developed with automation as a key and defining feature. Each tool withinPHENIX can seamlessly and nearly effortlessly be incorporated as part of any other tool or process inPHENIX. This means that very complex tasks can be built up from well tested and characterized tools and that tools and higher-level methods can be re-used in many different contexts. With a full automatic regression testing system as an integral part of thePHENIX environment, all these tasks and high-level methods are tested daily to ensure the integrity of the entirePHENIX system.

7.2. Automated structure solution

PHENIX has fully integrated structure-solution capability for both experimental phasing (MAD, SAD, MIR and com­binations of these), carried out byphenix.autosol, and formolecular replacement, performed byphenix.automr. Each of these automated procedures feeds directly into the iterative model building, density modification andrefinement ofphenix.autobuild.

Phenix.autosol is designed to allow complete automation of experimental phasing while allowing a high degree of flexibility for advanced users. Beginning with structure-factor amplitudes and the sequence of the macromolecule,phenix.autosol usesphenix.solve (Terwilliger & Berendzen, 1999) to scale all data sets,phenix.xtriage (Zwartet al., 2005) to analyze the data fortwinning and to correct any anisotropy in the data andphenix.hyss (Grosse-Kunstleve & Adams, 2003) to find potential heavy-atom or anomalously scattering atoms.Phenix.autosol carries out experimental phasing withphenix.phaser (McCoyet al., 2004, 2007) orphenix.solve (Terwilliger & Berendzen, 1999), density modification withphenix.resolve (Terwilliger, 1999) and preliminary model building using the methods inphenix.autobuild (Terwilliger, Grosse-Kunstleve, Afonine, Moriarty, Zwartet al., 2008).

A key step in automated structure solution is the identification of which of several possible space-group and heavy-atom or anomalously scattering-atom substructures is correct.Phenix.autosol uses a Bayesian scoring algorithm based on analysis of the experimental electron-density maps to identify which substructures lead to the best maps (Terwilligeret al., 2009). The main features of the maps that are used in this evaluation are the skewness of the electron density (non-Gaussian histogram of density with more density in the positive tail than the negative tail) and the correlation of local r.m.s. density (large contiguous regions of high variation where the molecule is located and separate large contiguous regions of low variation where the solvent is located).

Phenix.autosol is highly flexible, allowing any combination of experimental data, such as MAD + SIRAS or several SAD data sets. Although it is fully automated, the user can control nearly all aspects of the operation of the procedure, including the scoring criteria and decisions about how certainphenix.autosol should be that the correct solution is contained in the current lists of solutions.

Phenix.autosol can carry out phasing using a combination of experimental SAD data and molecular-replacement information. If a molecular-replacement model is available,phenix.autosol will usephenix.phaser (McCoyet al., 2004, 2007) to complete the anomaloussubstructure iteratively by con­structing log-likelihood gradient maps for the anomalous scatterers based on the model of the non-anomalous structure and any anomalous scatterers that have already been found. The anomaloussubstructure is then used along with the model to calculate phases withphenix.phaser.

Phenix.automr carries out automated likelihood-basedmolecular replacement usingphenix.phaser (Read, 2001; McCoyet al., 2005, 2007; McCoy, 2007). The procedure is highly automated, allowing several copies of each of several components to be placed in a single run, which can also test different possible choices ofspace group. If there are alternative choices of model for a component, the molecular-replacement calculation can try each of them in turn or combine them as a statistically weighted ensemble. Although the evaluation of the likelihood targets is slow (Read, 2001), the use of fast approximations for the rotation search (Storoniet al., 2004) and the translation search (McCoyet al., 2005) gives run times that are competitive with traditional Patterson-based methods. Likelihood has been demonstrated to be more sensitive to the correct solution, particularly in difficult cases (Read, 2001). When there are several copies or several components to place, the ability of the likelihood functions to take advantage of preliminary partial solutions can provide a crucial increase in the signal.

7.3. Iterative model building, density modification and refinement

Phenix.autobuild is a highly integrated and automated procedure for model building and model improvement through iterative model building, density modification andrefinement.Phenix.autobuild usesphenix.resolve (Terwilliger, 2003a,b) to carry out model building, model extension, model assembly, loop fitting and building outside existing models. It further usesphenix.resolve to improve electron-density maps with statistical density modification, including information from the newly built models as well as that obtained from experiment (e.g. phenix.autosol), from NCS (Terwilliger, 2002b) and from other expected features of electron-density maps such as a flat solvent (Wang, 1985), the presence of secondary-structural features (Terwilliger, 2001) and the presence of local patterns of density characteristic of macromolecules (Terwilliger, 2003c). To reduce model bias in the procedure, prime-and-switch phasing can also be used (Terwilliger, 2004).Phenix.autobuild usesphenix.refine (Afonineet al., 2005) throughout this process to improve the quality of the models that are built.

Phenix.autobuild provides two complementary approaches to model building. For cases in which no model or only a preliminary model has been built,phenix.autobuild will con­struct a new model considering the main chain of any supplied models as potential coordinates. In cases where a nearly final model is available,phenix.autobuild can apply a rebuild-in-place approach in which the polypeptide chain is rebuilt a few residues at a time without changing the register or the overall features of the model.

The rebuild-in-place approach inphenix.autobuild provides a powerful method for the assessment of uncertainties in an atomic model by repetitive rebuilding of the model using different random seeds for each iteration (Terwilliger, Grosse-Kunstleveet al., 2007). The variability in the coordinates of each atom in the ensemble that is created is a lower bound on the uncertainty of the position of that atom.