dataesr/scientific-paragraphs-categorization huggingface dataset:
DAQ front-end components The complete data flow for the experiment, leveraging all components described so far, is shown in Figure  6. The system includes so far three categories of front-end equipment: (i) Regular PCs running any operating system, sending data either via the LabVIEW or the C++ support libraries. (ii) CERN-supported VME PCs. After a few years on an EL Pool Concurrent Technologies VP110, we are currently running a VP717, also by Concurrent Technologies. Low-level code to drive respectively the Tundra Universe II or TSI148 VME bridge was inherited by the ATLAS TDAQ project at CERN  [6] , extracted from the ATLAS environment and adapted for AEḡIS. All data-taking chores can so far be handled by running one 3-thread process that gathers data on VMEbus and sends it out through one 1 Gbit/s Ethernet interface with the help of the C++ library described in Section 3.
Web-based run control and data monitor All data acquired by the AEḡIS DAQ system end up on disk in the form of ROOT files containing a number of TTrees, each representing a collection of data atoms unwound into ROOT native data types (object storage is used for std::vector<std::string>s only). This includes calibration data, physics run data as well as data from continuous apparatus monitoring. Alongside analysis code accessing directly the ROOT files, data are also served through an HTTP server. A custom back-end serves queries for specific data series by properly accessing and decoding stored ROOT files. This service is accessed by three classes of clients: (i) LabVIEW code, where a VI is provided to retrieve and reconstitute data in the original data cluster format. (ii) A Javascript data browser with simple stripchart display capabilities.
Lessons learned and conclusions While the system described so far has been running and acquiring data continuously over the experiment lifetime (interrupted only by the occasional power outage), a few operational issues required adjustments to the implementation. We recollect them here for future memory: • While the need to transfer large (O(10 6 ) numeric members) arrays from LabVIEW to the DAQ did not emerge clearly at the time of system requirement collection, it imposed itself as a need at data-taking time. This required two corrections: (i) Most of the LabVIEW installations in the experiment are running the 32-bit package version. This includes a custom memory allocator that displays poor performance when copying arrays. As an update of LabVIEW was ruled out for fear of regression issues, alternative ways to funnel array data to the DAQ had to be explored.
In addition to the native GXML code, both a custom Windows DLL (C-language source, to be invoked within a "Call Library Function" node) and a standalone executable were developed. The latter was needed because the most effective technique to avoid bottlenecks in LabVIEW was found to be dumping data on disk in "LabVIEW SpreadSheet" format and invoking an external executable to convert and transmit them. (ii) For these very large arrays, the default GXML representation of data is too verbose and data bloating is excessive. So an additional transfer format (i. e. compressed, base64encoding of the array contents) was added into the system to handle large array data only. This led to the addition of a specialised class to model arrays in the C++ library (see Section 3). • In order to limit the set of code dependencies, we initially based the (G)XML parsing code on the Root::TDOMParser class packaged with ROOT.
(400k data atoms as defined in Section 2, or 3. 7k atoms/s with average uncompressed payload size of 8. 2 bytes) to an average of 29 MB compressed 2016 (1. 3M data atoms, 12k atoms/s with average uncompressed data payload size of 71. 0 bytes) in 2016. The compressed size of the full 2016 raw dataset is 534 GB.
MOTIVATION Models are now used not just for data analysis, but for knowledge representation integrating across a wide range of data sources and model types. 4 One fundamental problem is a lack of standards in expressing the model across different quantitative disciplines and across this breadth of scope. While the mathematical and statistical aspects of the model may be commonly understood, implementation typically varies across the various software tools employed by different users of a model. Sharing knowledge through sharing computer code becomes difficult because of this, hampering knowledge transfer and impacting reproducibility. MDL provides the means to describe models in a clear and consistent manner for modelers and those using the models, and, together with the other DDMoRe exchange standards-Pharmacometrics Markup Language (PharmML),  5  which defines the XML-based software interchange standard; probability distribution ontology and knowledge-base (ProbOnto),  6  which provides a consistent basis for definition of probability distributions across MDL and PharmML and how these distributions are encoded in various target software tools; and the Standard Output (SO) definition,  7  which defines a consistent XML representation of output from target software toolsprovides standards for model definition, software input, output and interoperability, and knowledge management through metadata annotation using suitable ontologies.
• The linear relationship (after transformation) between fixed and random effects in specifying the individual variables in the model is identified explicitly, rather than inferred based on equation structure. • The distribution of the observed outcome is explicit using the Pro-bOnto definition and is consistent regardless of whether estimating or simulating the outcome. The user does not need to write likelihood functions for distributions that are described via ProbOnto definitions. As a whole, the intention of MDL is for anybody reading the model to identify what the model does without having to understand tool-specific implementation tricks. This is a key feature of knowledge representation-the modeler does not have to know the target software program syntax in order to use it. MDL has been developed taking into account features that provide clarity in model description while retaining the flexibility to describe complex models.
MDL AND ITS IMPLEMENTATION IN THE DDMORE PLATFORM The DDMoRe Interoperability Framework (https://sourceforge. net/projects/ddmore/files/) has provided a proof of concept implementation and demonstrated the utility of interoperability without manual intervention. An MDL Editor 8 is provided to assist the user in writing valid MDL and software tools are provided to convert from MDL to target software and return results from modeling and simulation tasks as R objects using the DDMoRe software exchange standards PharmML and SO. An R package, "ddmore," distributed with the DDMoRe Interoperability Framework, has been written to allow the user to read, write, and work with the MDL Objects within a pharmacometrics workflow. Using an R script to define all tasks with a given model facilitates The Task Properties Object contains settings for the specific modeling and simulation task relevant to the target software tool for that task.
b For prediction or simulation, a Data Object can be used as an alternative to the Design Object. www. psp-journal. com an unbroken workflow and dataset ensures reproducibility of modeling steps. DDMoRe has achieved this aim, by demonstrating the following tasks within a single R script: exploration of data using R; estimation of parameters using NONMEM, Monolix, and BUGS; model qualification using PsN and Xpose; simulation of new outcomes using simulx (R package "mlxR"); optimal design using PFIM and PopED. The Supplementary Material shows an R script illustrating this workflow and associated output.
FUTURE PERSPECTIVE OF MDL The definition and evolution of the Systems Biology Markup Language (SBML) has revolutionized systems biology and quantitative systems pharmacology. 10 The DDMoRe exchange standards, including MDL, and DDMoRe model repository have the potential to be similarly transformative for pharmacometrics and MID3. The current implementation of MDL is only a first step, with the initial scope covering the majority of population pharmacokinetic (PK) pharmacokinetic/pharmacodynamic (PK/PD), and disease progression models. Since MDL, the DDMoRe exchange languages and associated tools are open-source standards, it is possible and desirable for the modeling and simulation community to suggest enhancements and contribute code for implementation of these enhancements. Source code for MDL, and the user guide, are available via a Github project (https://github.
com/Model-DefinitionLanguage/). MDL ensures accurate knowledge representation and facilitates model sharing across disciplines without the constraints or requirements of knowing software-specific implementations or tricks. The DDMoRe project has shown with the model exchange standards and the interoperability framework that there should be no major hurdles to technical implementation of the concept of interoperability. With sufficient interest and uptake of MDL by the community, it is hoped that software developers will adopt the model exchange standards to facilitate interoperability across an increasing number of software tools. There is considerable activation energy required to engage the modeling and simulation community to adopt these standards. However, the use of DDMoRe exchange standards in the model repository (http://repository.
CONCLUSION By creating a clear, modular, flexible, explicit, and unambiguous language for model description, MDL presents a step forward for improved accurate knowledge representation through models. This step represents a paradigm shift in pharmacometrics as a discipline, enabling knowledgebased decision making. It will also improve productivity of pharmacometricians and other modelers. Together with the other DDMoRe standards, MDL is anticipated to increase quality, efficiency, and cost-effectiveness of modeling in drug development and therapeutic applications such as those described by MID3.
7. 3), Monolix (v. 4. 3. 2), WinBUGS (v. 1. 4), PFIM (v. 4. 0), and PopED (v. 0. 3). Example models have been encoded in MDL and are provided with the DDMoRe Interoperability Framework software illustrating how to encode a variety of model features (https://sourceforge. net/p/ddmore/use. cases/ci/master/tree/ MDL/Product5. 1/). An MDL user guide is also available: https://modeldefinitionlanguage. github. io/MDLUserGuide/. Supplementary Material for this article shows one of the MDL example models, describing a Poisson count model. This model shows MDL's organization into named blocks of code defining each model component. The MDL shows how the Model Object clearly defines the model hierarchy, relationship of fixed and random effects, and the distributional properties of random effects and outcome.
Acknowledgments. The authors thank the many colleagues across the  DDMoRe  project who have contributed to developing, refining, implementing, and providing training for MDL. We also thank the constructive comments and contributions of an unknown reviewer whose suggestions have improved the article. This study received support from the  Innovative Medicines Initiative Joint Undertaking  under grant agreement no. 115156 , resources of which are composed of financial contributions from the  European Union 's  Seventh Framework Programme  ( FP7/2007-2013 ) and EFPIA companies' in kind contribution. The  DDMoRe  project is also financially supported by contributions from  Academic  and SME partners.
The risk of gradually adopting an informant's view and losing the ability to take the helicopter-view necessary to theorize from the data  (Gioia et al. , 2013)  is present in such circumstances. To encourage self-reflection, and to remain critical of the research findings, the second and third author often took on the role of the devil's advocate  (Gioia et al. , 2013) , constantly challenging and reflecting the first author's interpretations and assumptions based on the data collected. Besides, the first author remained an observer rather than becoming a participant-observer, not having any active role within the organization, nor being paid by the bank to study them or to provide consultancy. These considerations together allowed for the assembly of a rich and detailed dataset.
Data Collection As we highlight the development of the Energy Policy in this article, we selected a relevant subset of our data including observations, interviews, emails, and policy documents derived in the period of November 2011 up until January 2014, when the Energy Policy was approved. The entire dataset (November 2011-June 2015), including policy implementation, which is outside the scope of this article, offered additional contextual information. During the period of November 2011-January 2014, the first author was present at the bank with an average of 2 to 3 days a week. She observed meetings between individuals from the SD and four different BDs. These meetings were between groups of individuals from both departmental groups and evolved around discussing feedback from the BDs on draft versions of the policy the SD provided, and discussions about the scope of the policy and of the sustainability standards to be included.
Interview themes were determined beforehand to provide some structure to the conversation and to keep the interviews on topic. Themes were based on the expertise, role, and function of the respondent and policy development issues relevant at the time of the interview. In addition to the more formal interviews, we also conducted many informal, spontaneous interviews that usually had a conversational character and therefore were not recorded. Yet, keywords were written down and the conversation was transcribed afterward. Such interviews happened on multiple occasions throughout our fieldwork and took place across desks, during lunch, while having coffee or going for a walk outside the office. Our data further consisted of a wide variety of resources such as multiple versions of the policies, DUTCH Bank's annual sustainability reports  (2007, 2008, 2010, 2011, 2012, and 2013) , emails between (groups of) individuals from the SD to the BDs and vice versa, internal newsletters such as the employee magazine, news articles from Dutch and international newspapers and the Internet, the bank's intranet, chief executive officer (CEO) blog, and the bank's "insider" group on Facebook in which only sustainability-related topics were being posted, shared, and discussed.
Data collection and analysis were done simultaneously  (Corbin & Strauss, 1990). In analyzing data, we moved between induction and deduction, also known as "abduction," "the process by which a researcher moves between induction and deduction while practicing the constant comparative method"  (Suddaby, 2006, p. 639). Following a round of close reading, we started to code our data. First, the dataset was entered into MaxQDA, a software package for qualitative data analysis, suitable for (open) coding and analyzing large amounts of text. The first-order coding relied on open coding  (Corbin & Strauss, 1990 ). Here we found data excerpts with many references to how employees approached the policy development process, referred to the financial crisis, or interpreted sustainability. We identified expressions of tension and conflict.
Acknowledgments The authors thank  Dennis Schoeneborn ,  Janni Thusgaard-Pedersen , and three anonymous reviewers for reviewing earlier versions of this article. We also benefited from discussions and feedback by participants of  European Group for Organizational Studies (EGOS)   2012 , the  "Amsterdam Seminar on Sustainability, Society & Business" (ASSSB) , and a Paper Development Workshop in 2012 at the Organization and Management Theory Division of the Academy of Management annual conference. The authors give a special word of thanks to the handling editor,  Andy Crane , for his stimulating guidance throughout this lengthy process.
For the first two of these challenges, we consider how they might be addressed for four PBs: climate change, freshwater use, biosphere integrity and chemical pollution and other novel entities. Four key opportunities are identified: (1) development of a common system of metrics that can be applied consistently at and across different scales; (2) setting 'distance from boundary' measures that can be applied at different scales; (3) development of global, preferably open-source, databases and models; and (4) advancing understanding of the interactions between the different PBs. Addressing the scientific and technical challenges in operationalizing the planetary boundaries needs be complemented with progress in addressing the equity and ethical issues in allocating the safe operating space between companies and sectors.
The PREDICTS database represents the most complete coverage of biodiversity response to human activity currently available, advancing beyond previous meta-analyses (e. g. , GLOBIO)  [74] , but limitations remain, especially for facilitating future projections of biodiversity resulting from changes in land use or other changes arising from corporate decisions such as choice and sourcing of raw materials. First, further work is required to understand the behaviour and functioning of ecosystems globally (including native and non-native species) based on the empirical observations. This understanding is required to establish the sensitivity of different ecosystems to different drivers and identify the specific control variables for biodiversity loss in different systems  [75, 76]. Second, globally-generalised theoretical models for biodiversity are required to complement correlative models such as PREDICTS for predicting and mitigating future biodiversity loss and ecosystem functioning so that effects of novel changes can be predicted; a first attempt is presented by Harfoot et al.
[77]. Third, there are gaps in data coverage, especially across boreal forests, flooded grasslands, savannahs and mangroves, and across Africa in general, where much of the most rapid land-use change is occurring. Certain species (e. g. , those dwelling in soil and canopies) are also routinely under-represented in the literature and hence also in this database  [72, 78]. These gaps in geographic and species coverage currently limit the types of impacts from business decisions this approach is capable of representing.
Second, a key step in operationalising PBs, particularly for life cycle sustainability assessment, is to set 'distance from boundary' measures. This has been demonstrated for climate change, which manifests on the global scale and for which there is a scientifically agreed way to quantify the boundary, some consensus on its numerical value and an emerging international governance framework. In principle, a precautionary 'distance from boundary' approach could also be used for boundaries characterised by multiple scales. However, this necessitates measurement and decision-making processes that apply at local and regional scales but recognise global targets, as exemplified by the water use boundary. Third, continued and co-ordinated development of global, preferably open-source, databases and models is a priority, both to evaluate the current status of the earth's systems relative to local, regional and global thresholds and to project future responses to pressures from human activities.
Acknowledgments: This paper derives from discussion and analysis by the author group initiated at a workshop supported by  Unilever's Safety and Environmental Assurance Centre (SEAC)  and held in November 2014 at the  University of Surrey. Leo Posthuma 's attendance was funded by  RIVM 's strategic project  S/607020  under the auspices of RIVM's  CEO and Scientific Advisory Board. The views in this article represent a general consensus among the authors and do not necessarily reflect those of the various organizations to which they are affiliated.
This paper reports on the activities aimed at improving the architecture and performance of the ATLAS EventIndex implementation in Hadoop. The EventIndex contains tens of billions of event records, each of which consists of ~100 bytes, all having the same probability to be searched or counted. Data formats represent one important area for optimizing the performance and storage footprint of applications based on Hadoop. This work reports on the production usage and on tests using several data formats including Map Files, Apache Parquet, Avro, and various compression algorithms. The query engine plays also a critical role in the architecture. This paper reports on the use of HBase for the EventIndex, focussing on the optimizations performed in production and on the scalability tests. Additional engines that have been tested include Cloudera Impala, in particular for its SQL interface, and the optimizations for data warehouse workloads and reports.
The ATLAS EventIndex project The ATLAS EventIndex  [1]  is a metadata catalogue of all real and simulated data produced by the ATLAS experiment  [2] , one of seven particle detectors constructed for the CERN Large Hadron Collider  [3]. It was designed in 2012-2013 and implemented in 2014; the first data (all LHC Run 1 data collected in 2009-2013) were loaded at the beginning of 2015.
Current architecture The ATLAS EventIndex collects the data from distributed computer centres and stores them in a central storage at CERN. The system is divided into few functional packages that implement data acquisition, storage, access and monitoring: • The Data Collection system collects data from jobs at Tier-0 or on the Grid that produce new data. The EventIndex information for each permanent output file is transmitted to a central server at CERN where it is validated, reformatted and stored in the EventIndex storage system. • The Core Storage system accepts data from the Data Collection system and physically stores it in its own storage space, accepts queries from the front-end web server and returns the results. • The Query Server is a web service that acts as a front-end to the storage system.
It provides a command-line interface and a web interface that can be used to find and retrieve the stored information. • The Trigger Decoding service unpacks the trigger information of each event and makes it readily available in the event records. • The monitoring system provides continuous information on the health and load of all the servers involved, as well as on the data traffic and query response times. The Core Storage is one of the critical parts of the system as it integrates all other packages by consolidating the data and making them available to be accessed by users via the Query Server. Thus it is important that it is robust and delivers the required performance for both data ingestion and data access. Apache Hadoop [5] was chosen as the main backend technology for storing and accessing data.
It met all criteria from the project requirements (in section 1. 1) and, differently from other shared storage technologies like relational databases, in various tests at CERN  [6]  has proven that it is horizontally scalable. The rest of this paper elaborates on the internal design of the Core Storage and potential improvements that can bring the use of alternative approaches available in the Hadoop ecosystem for storing and accessing the data. In particular, the results evaluation of the most popular Hadoop file formats and storage engines with ATLAS EventIndex data and workloads are discussed and concluded.