dataesr/scientific-paragraphs-categorization huggingface dataset:
We have improved plant genome support in OMA by adding and updating more plant genomes and by inferring and annotating homeology--genes related through polyploidization--in the wheat genome. The number of plant species in the OMA database has increased from 8 to 28 plants in recent years. In the latest release, we have added Selaginella moellendorffii (a lycophyte) as the deepest branching vascular plant and Physcomitrella patens (a bryophyte) as a representative of the non-vascular plants, thus widening the taxon set to cover ∼450 million years of plant evolution  (30). We have also added the important model grass species Brachypodium distachyon and Aegilops tauschii. Additionally, we have added a variety of crop species of practical and economic importance, which are especially useful to plant geneticists and breeders.
NEW SYNTENY VIEWER PROVIDING THE GENOMIC CONTEXT OF ORTHOLOGS In the absence of genome rearrangement, orthology relationships can be expected to be consistent across neighbouring genes--a concept commonly referred to as 'shared synteny'. Patterns of syntenic conservation or divergence can shed light on the evolutionary history of genomic loci of interest; they can also reveal sequencing artefacts, misannotations or orthology inference errors. Synteny visualization tools have been successfully developed in several comparative genomics databases such as Yeast Gene Order Browser  (39) , Genomicus  (40)  or GnpIS  (41). The OMA Browser now features a synteny viewer as well. The OMA synteny viewer uses a typical layout: genes are represented by boxes, with neighbouring genes displayed in adjacent columns and orthologous regions displayed in different rows.
However, until recently, the OMA Browser had been dynamically inferring these HOGs on user demand. Large families could take a few minutes to process. Furthermore, because of the non-deterministic nature of the inference algorithm, there could be small inconsistencies for requests at different taxonomic levels (e. g. one sequence included in an HOG defined at the level of vertebrates but not included at the level of all bilateria). Starting with the latest release, HOGs are precomputed thereby providing rapid user access and consistent inferences. HOGs can now be downloaded in Or-thoXML format  (43)  for further analyses. One potential use of the HOGs data is to map gene losses, duplications and gains onto species trees. Indeed, since HOGs are defined in terms of ancestral genomes at all internal nodes in the species tree, keeping track of the number of HOGs and their content whilst traversing the tree can yield these quantities.
EXPORT OF PROTEIN SETS AND THEIR ASSOCI-ATED ALL-AGAINST-ALL COMPUTATIONS As genome and transcriptome sequencing are becoming affordable and ubiquitous, there is an increasing need for orthology prediction on custom data. As a solution to this, we have developed OMA standalone, a downloadable open source implementation of the OMA pipeline for Linux and Mac (the details of the software are the focus of a forthcoming publication). To enable users to efficiently combine custom and public genomes, we have added the possibility of exporting OMA genomes, including all-against-all computations amongst them, as input files for OMA standalone. The function is accessible via the 'Download' menu in the navigation bar of the new OMA Browser interface. Users can select up to 50 genomes for export (Figure  7 ), which together with OMA standalone are packaged for download as a single compressed tar file.
OUTLOOK For just over a decade, the OMA database has provided orthology inference amongst complete genomes. It has remained true to its mission of providing reliable, high-quality orthology inferences across a broad taxonomic range. With 17 major releases, each including ∼100 additional and updated genomes, the project has been maintained with sustained endurance. At the same time it has also gained numerous functionalities, of which the most recent are highlighted in this update. So what awaits OMA in the coming decade? One major challenge facing many phylogenomic resources is to keep abreast of the rapid increase in sequencing data  (4). In OMA, the all-against-all protein comparison phase--the most time-consuming phase with >7 million CPU hours logged to date--grows quadratically with the number of sequences under consideration.
The maximum sensitivity to the true atmospheric state is located around ∼ 5 km altitude or 500 hPa pressure  (Deeter et al. , 2003). Here we use the level 2 data of the version 4 retrievals of MOPITT, which are validated extensively (e. g. ,  Emmons et al. , 2004 Emmons et al. , , 2007 Emmons et al. , , 2009;; Luo et al. , 2007; Deeter et al. , 2010, and references therein). More recently, version 5  (Deeter et al. , 2011)  and version 6 (only for 2008) of MOPITT CO data were released. MLS is an instrument on the EOS Aura satellite, which was launched on 15 July 2004. The EOS Aura satellite flies in a near polar, sun-synchronous orbit (in the "A Train" satellite constellation) at 98 • inclination with a period of approximately retrieval technique is described in detail by  Livesey et al. (2006)  and the validation of the MLS CO data product (in version 2.
The TROCCINOX campaign (including the M55-Geophysica research flights) was partially funded by the Commission of the European Community under the contract EVK2-CT-2001-00122 and by other TROCCINOX partners; the M55-Geophysica flights in the frame of the SCOUT-O3 campaign in Darwin in early 2005 have been supported by an European Community grant through the project SCOUT-O3 under contract COCE-CT-2004-505390; the M55-Geophysica campaign within the frame of AMMA was supported by the EEIG-Geophysica Consortium, CNRS-INSU, EC Integrated Projects AMMA-EU (Contract Number 004089-2), SCOUT-O3 and CNES. Discussion Paper | Discussion Paper | Discussion Paper | The service charges for this open access publication have been covered by a Research Centre of the Helmholtz AssociationDiscussion Paper | Discussion Paper | Discussion Paper | WMO: Scientific assessment of ozone depletion: 2010, Global Ozone Research and Monitoring Project-Report No.
Modelers compute ocean carbonate chemistry often based on code from the Ocean Carbon Cycle Model Intercomparison Project (OCMIP), last revised in 2005. Here we offer improved publicly available Fortran 95 routines to model the ocean carbonate system (mocsy 2. 0). Both codes take as input dissolved inorganic carbon C T and total alkalinity A T , tracers that are conservative with respect to mixing and changes in temperature and salinity. Both use the same thermodynamic equilibria to compute surface-ocean pCO 2 and simulate air-sea CO 2 fluxes, but mocsy 2. 0 uses a faster and safer algorithm (SolveSAPHE) to solve the alkalinity-pH equation, applicable even under extreme conditions. The OCMIP code computes only surface pCO 2 , while mocsy computes all other carbonate system variables throughout the water column.
The common modeling practice of neglecting alkalinity contributions from inorganic P and Si leads to substantial biases that could easily be avoided. With standard options for best practices, mocsy agrees with results from the CO2SYS package within 0. 005 % for the three inorganic carbon species (concentrations differ by less than 0. 01 µmol kg -1 ). Yet by default, mocsy's deep-water f CO 2 and pCO 2 are many times larger than those from older packages, because they include pressure corrections for K 0 and the fugacity coefficient.
One may also question use of the constant density approximation in waters affected by excess evaporation (e. g. , in the equatorial Pacific, Arabian Sea, and Mediterranean Sea) or by large freshwater input (e. g. , in the Arctic and coastal zones with heavy river influence). To fill these gaps, we provide here an improved set of routines to model the ocean carbonate system (mocsy 2. 0). This new package uses the classic approach, taking simulated A T and C T and computing all other carbonate system variables, while adding refinements. Relative to its predecessor (OCMIP model code), mocsy offers several ameliorations: (1) it no longer makes the three approximations mentioned above; (2) it computes all carbonate system variables, not only pCO 2 and pH; (3) it provides these variables at all model levels, not only at the surface; and (4) it uses, as a default, the constants and the pH scale recommended for best practices  (Dickson et al.
Basics The ocean carbonate system is well constrained. Any pair of carbonate system variables can be used to compute all others. Because only two carbonate system variables, C T and A T , are carried as passive tracers by all ocean carbon models, mocsy offers only that input pair. Thus it is unlike other public packages designed largely for observationalists. To calculate the remaining carbonate system variables, one only needs to provide additional input for temperature, salinity, P T , and Si T as well as pressure or depth. A precursor to mocsy was developed in 2004 and used to project future ocean acidification from simulated C T and A T in the OCMIP2 models  (Orr et al. , 2005). That precursor code was never released publicly and should not be confused with the preexisting OCMIP2 or OCMIP3 code, which only computes surface pCO 2.
Its development began by combining the Fortran code for equilibrium constants from OCMIP2 and an iterative algorithm to solve for pH  (Maier-Reimer, 1993; Aumont and Bopp, 2006). The precursor code was then modified to compute all carbonate system variables throughout the water column. Thus it included pressure corrections for equilibrium constants  (Millero, 1995)  with pressure-correction coefficients (some now known to be erroneous) taken from version 0. 95 of seacarb  (Proye and Gattuso, 2003; Lavigne and Gattuso, 2011) , which itself adopted code from csys (Zeebe and  Wolf-Gladrow, 2001). From the seacarb code, the precursor code also included the analytical formula for the Revelle factor from Frankignoulle  (1994). Our feedback from this early development led to bug corrections that were later implemented in seacarb.
Since 2005, this precursor code has continued to be improved. The first public version was denoted as mocsy 1. 0  (Orr and Epitalon, 2014). Here along with a revised version of that discussion paper, we provide an improved version of the code, mocsy 2. 0. The equilibrium constants and pH scale adopted in mocsy are those recommended by the Guide to Best Practices for Ocean CO 2 Measurements  (Dickson et al. , 2007). The equilibrium constants are generally on the total pH scale. There are four exceptions: the CO 2 solubility K 0 , the equilibrium constant for bisulfate K S , the solubility product for aragonite K A , and the analogous solubility product for calcite K C  (Mucci, 1983). By definition, K 0 , K A , and K C are independent of the pH scale: they do not involve H +. Although K S includes H + , it is maintained on the free scale, as needed to convert between the free and total scales.
Solver of the total alkalinity-pH equation In mocsy 2. 0, to solve the total alkalinity-pH equation, we have replaced the classic fixed-point iterative carbonate alkalinity scheme (ICAC) in mocsy 1. 0 with a new, universally convergent algorithm from  Munhoven (2013). We now call a cubic initialization routine followed by the standard safeguarded solver routine solve_at_general, both from Munhoven's SolveSAPHE package v1. 0. 1. Our tests using typical open-ocean conditions indicate that results from both are identical to at least the sixth digit after the decimal in terms of pH, but that SolveSAPHE is about 5 times faster than our former ICAC routine. Moreover, the SolveSAPHE routines allow mocsy 2. 0 to avoid any convergence problem under extreme conditions. The ICAC methods do not always converge, for example under low C T when A T /C T > 1  (Munhoven, 2013, Fig.
The mocsy 2. 0 package also differs substantially from other packages because it adjusts for effects of subsurface pressure on K 0 as well as C f. All packages compared by  Orr et al. (2014)  compute K 0 with the same standard equation  (Weiss, 1974, Eq. 12) , but none of them make the exponential pressure correction  (Weiss, 1974, Eq. 5) : CO * 2 = K 0 f CO 2 exp (1 -P ) vCO 2 /RT , (3) where P is the total pressure (atmospheric + hydrostatic, both in units of atm), vCO 2 is the partial molal volume of CO 2 (32. 3 cm 3 mol -1 ), R is the gas constant (82. 05736 cm 3 atm mol -1 K -1 ), and T is the absolute temperature (K). Thus the computed f CO 2 refers only to potential values considering the total pressure as that at the surface. The exponential pressure-correction term can be neglected but only when the total pressure is near 1 atm  (Weiss, 1974).
Evaluation There is no absolute reference for computed carbonate system variables. To validate mocsy, its computed variables were compared to those from CO2SYS-MATLAB  (van Heuven et al. , 2011)  run with identical input data. Although both packages could in principle be wrong even if both agree, we compare mocsy to CO2SYS because the latter is the first public package made available to compute these variables, it is used widely, and it was developed with great care  (Lewis and Wallace, 1998). Moreover, it has served as a base for other public packages to build on. A companion paper  (Orr et al. , 2015)  further details the reasons for our arbitrary choice of CO2SYS as the reference. The input data with which we compared the two packages include A T and C T from the three-dimensional, global gridded data product on a 1 • × 1 • grid known as GLODAP  (Key et al.
Evaluation Our evaluation reveals the extent to which mocsy's variables computed from the GLODAP-WOA2009 data dif-fer from those computed when the same data is used with the CO2SYS-MATLAB package. Relative differences remain within ±0. 005 % for computed concentrations of CO * 2 , HCO - 3 , CO 2- 3 , and H + , both for surface zonal means (Fig. 4 ) and global average vertical profiles (Fig. 5 ). Corresponding absolute differences are within 0. 01 µmol kg -1 for each of the three inorganic carbon species, and within 0. 0002 nmol kg -1 for H +. The latter translates into pH differences of less than 0. 00002 between the two packages. Tighter agreement cannot be expected because CO2SYS computes pH with a Newton-Raphson method that stops iterating once the change in pH from the previous iteration is less than 0.
0001. The slight difference in H + between packages explains the slight offsets in the three inorganic carbon species, because both packages yield identical results for the computed K 1 and K 2 equilibrium constants  (Orr et al. , 2015). Relative differences between packages are slightly larger for A and C , with a constant offset of 0. 018 % throughout the water column. Comparison of the source code of the two packages revealed that the offset is due to differences in the atomic weight of calcium: CO2SYS uses 40. 087, whereas mocsy uses 40. 078, the recommended value  (Dickson et al. , 2007, Chapt. 5 , Table  1 ). Nonetheless, these relative differences remain small. They correspond with differences in computed saturation states of less than 0. 001 unit between the two packages. Of similar magnitude are the relative differences for the Revelle factor R f of about 0.
g. , multiplying f CO 2 by 2 and pCO 2 by 18 when at 5000 m. The mocsy 2. 0 package offers the first choice as a default and the second as an option. Other public packages compared by  Orr et al. (2014)  offer neither option, computing f CO 2 and pCO 2 at 1 atm total pressure with in situ temperature. A second package, seacarb 3. 0. 6, also now offers all three approaches to compute subsurface f CO 2 and pCO 2  (Gattuso et al. , 2015; Orr et al. , 2015). For simplicity, modelers typically make ocean carbonate chemistry calculations assuming (1) that model density is constant, (2) that simulated potential temperature is equivalent to in situ temperature, and (3) that model depth is equivalent to pressure. None of the three approximations produces significant errors at the surface. Yet errors in computed variables grow with depth.
At 5000 m, the sum of the relative errors from the three approximations reach more than 3% for pCO 2 , A , and H + (pH shift of up to 0. 015). Yet they remain at less than 1 % for the three inorganic carbon species (<1 µmol kg -1 ). The mocsy modeling routines avoid these errors with little additional coding and trivial increases in computational time. The same code also offers two new options that have become available since the publication of the best-practices guide  (Dickson et al. , 2007). Those options concern an assessment that seawater contains 4 % more total boron than thought previously  (Lee et al. , 2010)  and new formulations for K 1 and K 2 designed to include low-salinity waters  (Millero, 2010). The new boron option leads to substantial shifts in computed surface variables, e.
git clone git://github. com/jamesorr/mocsy. git in an X terminal on Linux, Mac, or PC operating systems. If that fails, install Git and try again, or go to the main web page on GitHub (https://github. com/jamesorr/mocsy) and click on the link "Download ZIP". Once downloaded, mocsy can be compiled under Linux or Unix by typing make. More details on the code, its compilation, and examples of its use in Fortran or when called from Python can be found in the mocsy manual at http://ocmip5. ipsl. jussieu. fr/mocsy/. Acknowledgements. We thank the original OCMIP code developers (C. L. Sabine, R. M. Key, and R. G. Najjar) and those who provided subsequent corrections or comments (A. Mouchet, K. Lindsay, J. Christian, and G. McKinley). We are grateful to J. -P. Gattuso, E. Lewis, and D. Wallace, as well as S.
van Heuven, D. Pierrot, and J. Rae for coding and making public their packages (seacarb, CO2SYS, and CO2SYS-MATLAB), which have been no small inspiration for mocsy. We also thank P. Brockmann and Y. Meurdesoif for professional advice on coding and distribution strategies. The original manuscript and code have been improved because of three dedicated referees: G. Munhoven shared scientific and technical savvy while making his stable, efficient, and well-documented pH solver (SolveSAPHE) publicly available, allowing us to easily integrate it in mocsy; A. Dickson offered much critical expertise on carbonate chemistry, for instance inspiring us to include pressure corrections that dramatically alter computed subsurface f CO 2 and pCO 2 ; and an anonymous referee provided a wider modeler's perspective.
We are grateful to F. Perez for pointing out that formulations of K 1 and K 2 depend upon B T. The OCMIP code was first modified with support from the EU FP5 project NOCES (grant EVK2-CT-2001-00134) and the FP6 project CARBOOCEAN (grant 511176(GOCE)). More recent efforts to refine, document, and make the code publicly available were supported by the French ANR project MACROES (MACRoscope for Oceanic Earth System ANR-09-CEP-003) and two EU FP7 projects, CARBOCHANGE (grant 264879) and MedSeA (grant 265103).
Identification of chemical compounds with specific biological activities is an important step in both chemical biology and drug discovery. When the structure of the intended target is available, one approach is to use molecular docking programs to assess the chemical complementarity of small molecules with the target; such calculations provide a qualitative measure of affinity that can be used in virtual screening (VS) to rank order a list of compounds according to their potential to be active. rDock is a molecular docking program developed at Vernalis for high-throughput VS (HTVS) applications. Evolved from RiboDock, the program can be used against proteins and nucleic acids, is designed to be computationally very efficient and allows the user to incorporate additional constraints and information as a bias to guide docking.
This article provides an overview of the program structure and features and compares rDock to two reference programs, AutoDock Vina (open source) and Schro ¨dinger's Glide (commercial). In terms of computational speed for VS, rDock is faster than Vina and comparable to Glide. For binding mode prediction, rDock and Vina are superior to Glide. The VS performance of rDock is significantly better than Vina, but inferior to Glide for most systems unless pharmacophore constraints are used; in that case rDock and Glide are of equal performance. The program is released under the Lesser General Public License and is freely available for download, together with the manuals, example files and the complete test sets, at http://rdock. sourceforge. net/.
However, if the structure of the target is known and a druggable cavity has been identified  [1] , molecular docking can also be used to screen virtual chemical collections to identify those molecules that offer good shape and chemical complementarity  [2]. Such virtual screening (VS) offers opportunities for small research groups without access to HTS or FS to identify new hit compounds, as setting up a lowthroughput assay to test a few tens of compounds is relatively fast and inexpensive. Such VS has been successful, but it requires a docking program that is computationally efficient and can be finely tuned to achieve optimal performance  [3] [4] [5]. rDock is a molecular docking platform which has been optimised for such tasks. rDock has its origins in the program RiboDock  [6] , designed initially for VS of RNA targets.
Design and implementation The rDock platform is a collection of command-line programs and scripts (Table  1  and Figure  S1 ). The main tasks are carried out by the programs rbcavity (cavity generation) and rbdock(docking). rDock is written in ANSI C++ and compiles under the Linux operating system using the GNU g++ compiler. Apart from the C++ Standard Template Library (STL) there are minimal external dependencies (e. g. OpenBabel bindings for running sdtether and sdrmsd  [15] ). The core functionality is compiled into a single shared library, which is linked with each of the (light-weight) commandline applications. Scoring functions and docking protocols are assembled at run-time from well-defined C++ object class hierarchies, allowing for customisation at source code level by extending the base classes.
Preparation The receptor is provided in Tripos MOL2 format with standard atom typing. Amino acid ionisation states in the vicinity of the cavity must be defined, as the rDock scoring functions depend on formal charge assignments. Metal ions, cofactors and structural water molecules can be included as part of the receptor. The user should also resolve other structural issues such as alternate locations or missing atoms. The docking volume is defined by the rbcavity program which provides two mapping algorithms; the accessible volume within a specific distance of a reference ligand, and a two probe sphere method  [6]. In the examples presented in this paper, the reference ligand method is used with a distance of 6 A ˚. Ligands to be docked are read in the MDL SDFile format (SDF) and should have the correct topology and bond orders.
The program can protonate and deprotonate certain ionisable groups, but pre-processing the ligands with a dedicated program is preferable. Since the program only samples exocyclic dihedral angles, a correct input geometry is required for bonds, angles and rings. In the case of flexible rings, a variety of low-energy conformers should be pregenerated by a suitable program. We have used LigPrep  [16]  for all ligand preparation steps. The execution of the programs is controlled by a series of parameter (. prm) files; this allows user controlled tuning of the docking protocol and scoring functions (described in more detail in the Manual). The following sections describe the main characteristics of the program and the available options.