dataesr/scientific-paragraphs-categorization huggingface dataset:
But these approaches often lack details on the underlying physics and additional information on the type and composition of matter. For EoS with a dependence on more than one variable, such representations are more difficult to develop, in particular when thermodynamic consistency should be satisfied. On the other hand, results from most theoretical models are usually given only on a grid of certain variables. Data from these approaches are collected in tables of various forms that cannot provide simple functional representations. In this case, a change of model parameters is not easily accomplished. CompOSE focuses on this tabular EoS approach and provides a unified format for disseminating the data. Nevertheless, the incorporation of EoS data using functional representations into CompOSE is under discussion.
CompOSE has three major purposes: • CompOSE is a repository of EoS tables in a common format for direct usage with information on a large number of thermodynamic properties, on the chemical composi-tion of dense matter and, if available, on microphysical quantities of the constituents. • CompOSE allows to interpolate the provided tables using different schemes to obtain the relevant quantities, selected by the user, for grids that are tailored to specific applications. • CompOSE can provide information on additional thermodynamic quantities, which are not stored in the original data tables, and on further quantities, which characterize an EoS, such as nuclear matter parameters and compact star properties. The format of the files, as well as the calculational mesh, is mainly determined according to the needs of scientific groups performing extensive numerical simulations of astrophysical objects.
We try to provide the tables in a large parameter space to cover most applications. We cannot offer an online service for all features of Com-pOSE, e. g. to run all codes online. This is mostly due to limitations in storage and computation times, but also gives better control on avoiding unphysical input parameters. However, we offer several computational tools that allow the user to extract the data from the tables that are relevant for her/him. These tools can be downloaded from the CompOSE website https://compose. obspm. fr.
How to read this document While reading this document please always keep in mind: this document was written by physicists for physicists. It is divided into three major parts. The first one is relevant both to providers and users of equations of state, as it serves as a basis for the discussions in the following parts of the manual and the web site. Both, contributors and users, should first of all have a look at the introductory chapter 3 where we will discuss general conventions and the notation used throughout CompOSE. In addition, we give definitions and details on the system of units that is used within CompOSE and on physical constants that should be used in order to standardise the generation of new equations of state. The second part concerns those persons who wish to contribute to an extension of the CompOSE data base by the active development of an EoS.
CompOSE allows them to make their favourite EoS available for a broad range of astrophysical and nuclear physics applications. In part II, detailed instructions, minimal requirements and recommendations are specified for the preparation of EoS tables that can be incorporated in future versions of the CompOSE data base. If you plan to contribute your EoS, you should contact the CompOSE core team (develop. compose@obspm. fr), see Appendix D. A summary of possible future extensions of the CompOSE data base are summarized in chapter 5. The third part concerns the users of EoS data, that are provided by CompOSE, who want to test various equations of state in their simulations of core-collapse supernovae, neutron-star mergers, and other scenarios, e. g. , the calculation of mass-radius relations of cold neutron stars.
The different families of provided EoS data thereby distinguish different preferred applications. In general, they can safely skip the second part and go directly to the third one. This part gives a brief introduction on nuclear matter properties relevant for the construction of an EoS, as well as a classification of different types of EoS models in chapter 6. The models can be distinguished either by using different techniques to treat the many-body system of strongly interacting particles or by assuming a different particle composition. The main aim is to give the relevant information for the interpretation of the data sheets, provided with each available EoS table on the web site. You will find remarks on the range of applicability of the various models, i. e. the range of parameters where the code is tested and/or the made approximations are still valid.
7. 5. 2 was adapted to the new version and the description of the files eos. parameters (with a change of the structure) and eos. quantities was moved to Appendix B; • Section 7. 4. 3 was moved to Appendix C and the corresponding tables with the (sub-)routines and functions were updated; • Tables  10, 13 , and 17 were amended and a new Table  12  was introduced; • new Appendices B and C were introduced; • Appendix D and the Acknowledgements were updated; • the bibliography has been updated. The main changes to the compose program are • most vectors and matrices are allocated dynamically with the appropriate size for the particular EoS used for generating a user-defined EoS table; • the program compose runs by default in a standard version that guides the user through the selection of output data and the tabulation scheme; • the input files eos.
Units and conventions We use natural units h = c = k B = 1 throughout this document as is customary in nuclear physics. Energies and temperatures are measured in MeV, lengths in fm. Units are given in parentheses [. ] for all quantities when they are defined within this chapter. For conversion among your favourite units, the use of the CODATA values  [7]  (http://physics. nist. gov/cuu/Constants/index. html, www. codata. org) is recommended, see Table  1. 1  They should also be used in the preparation of new EoS tables to be incorporated in the CompOSE data base. In astrophysical applications of equations of state it is often customary to change from nuclear units to units that are traditionally used in that field, in particular for temperature, pressure and energy densities. See Sect. 3. 5 for examples.
Physical conditions Predictions for the properties of dense matter can differ considerably depending on the employed model, the considered constituents and interactions. In the CompOSE database, the equation of state is considered to describe dense matter in thermodynamic equilibrium, a short denotation of the fulfillment of several equilibrium conditions. Each of them corresponds to the existence of an intensive thermodynamic vari-able that applies to the full system under consideration. First of all there are the thermal and mechanic equilibrium that allow to define the temperature T and the pressure p. Chemical equilibrium means equilibrium with regard to strong, electromagnetic and weak reactions. For the latter, one has to distinguish several cases, i. e. , reactions within a generation of particles, e.
Microscopic quantities Most EoS models are based on microscopic models that can give information on microscopic particle properties in addition to the thermodynamic and compositional quantities. Only few models are just simple parameterizations of thermodynamic quantities without recurrence to the underlying microphysics. The CompOSE database allows to store these microscopic values, too, such that they can be used in applications. In the present version, we consider a small set of quantities that are discussed in the following. It can be easily extended if required. In particular, we consider the effective masses of the particles in which case one has to distinguish between different definitions. The effective Landau mass m L i [MeV] (3. 54) of a particle i is related to the single-particle density of states and defined as 1 m L i = 1 p F i d E i dp p= p F i , ( 3.
(3. 60) The effective Dirac mass depends on the scalar self-energy S i = i [MeV] (3. 61) that enters the relativistic single-particle Hamiltonian together with the vector self-energy V i = 0 i [MeV] (3. 62) that is the time-component of the general four-vector selfenergy μ i. In certain parameter regions of an EoS, the phenomena of superconductivity or superfluidity can be found. In this case, it is worthwhile to know the size of the pairing gaps i [MeV] , (3. 63) e. g. in the i = nn( 1 S 0 ) channel in case of neutron pairing. In the general case, it can be energy and momentum dependent and cannot be easily tabulated in the present format. In many cases, it is given for specific conditions defined in the EoS data sheet.
g. , the RNS code  [19] [20] [21]  and the LORENE library  [22]. The latter has an interface to directly employ EoS data from CompOSE, see Sect. 7. 5. 2. It can compute initial data for binary neutron stars, too. Another interesting quantity for neutron stars with respect to cooling is the threshold density for the operation of the direct Urca process. For a neutron-star EoS with only electrons as leptonic degrees of freedom, the threshold charge fraction is given by Y dUrca q = 1 9 (3. 86) 123 or Y dUrca q = ⎧ ⎨ ⎩ 1 + 1 + Y e Y e + Y μ 1/3 3 ⎫ ⎬ ⎭ -1 (3. 87) if both electrons and muons are accounted for  [23, 24]. The direct Urca process can only operate if Y q is larger than these threshold values. Otherwise the neutrino generating direct Urca reactions such as for example n → p + e -+ νe  (3.
Part II. For contributors The success of the CompOSE data base depends on the support of nuclear physicists providing tables with their favourite EoS. Some well known EoS used extensively in astrophysical applications are already incorporated in the CompOSE data base and are ready for use. However, a larger collection of EoS from different models is highly desirable. In order to be suitable for a simple usage, contributors should follow the guidelines specified in this part of the manual.
Extending CompOSE CompOSE is meant to be under constant development. The main aim is to enlarge the data base by adding EoS tables of more and more models. The most simple way is to convert tables of existing model calculations to the generic Com-pOSE scheme of tabulation in the data files. A more involved task is to develop a new EoS model and to provide the results in the appropriate format. In either case, we ask you to contact the CompOSE core team by sending an email to develop. compose@obspm. fr. All questions will be clarified by them on how your results can be incorporated in the CompOSE data base and made accessible to the public. For the future, it is foreseen that the functionality of the CompOSE database will be extended in order to make even more results of EoS model calculations available that are not included in the present sets of data.
This assumption simplifies the calculation significantly in case of spatially inhomogeneous charge distributions. Details on the treatment of electrons and muons are given for each EoS separately on the data sheet. At finite temperatures, photons contribute to the thermodynamic properties of the system. Their treatment is discussed in Sect. 3. 9. For each EoS in the database, a remark is given whether photons are considered or not. The definition of commonly used nuclear matter parameters is given in Sect. 6. 1. They characterize the essential properties of nuclear matter and can serve in a first comparison of the various models. Be, however, careful since these parameters are only valid in the vicinity of saturation for symmetric, i. e. same number of protons and neutrons, matter. Specific values of these parameters are given in the data sheet for the individual models and in a summary table on the CompOSE website.
Acknowledgements CompOSE would not be possible without the financial and organisatorial support from a large number of institutions and individual contributors. We gratefully acknowledge support by  CompStar ,  NewCompStar , and  PHAROS, Research Networking Programs of the European Science Foundation (ESF)  and the birthplace of the  CompOSE  project, by a grant from the  Polish Ministry for Science and Higher Education (MNiSW)  supporting the "CompStar"-activity, by the  Instytut Fizyki Teoretycznej of the Uni-wersytet Wrocławski , the  National Science Centre Poland (Narodowe Centrum Nauki, NCN)  within the  "Maestro"-programme  under contract No. DEC-2011/02/A/ST2/00306 , by the " hadronphysics3" network within the seventh framework program  of the  European Union , by the  GSI Helmholtzzentrum für Schwerionenforschung GmbH , by the  Helmholtz International Center for FAIR  within the framework of the  LOEWE program  launched by the state of Hesse via the  Technical University Darmstadt , by the  Helmholtz Association (HGF)  through the  Nuclear Astrophysics Virtual Institute  ( VH-VI-417 ), by the  ExtreMe Matter Institute EMMI  in the framework of the  Helmholtz Alliance 'Cosmic Matter in the Laboratory' , by the  DFG cluster of excellence "Origin and Structure of the Universe" , by the  DFG  through grant SFB  1245 , by the  SN2NS  project  ANR-10-BLAN-0503  and by the  MPNS COST  action  MP1304  "Exploring fundamental physics with compact stars (NewCompStar)" within the  EU framework programme.
Background As of 2017, >95% of the hospitals in the United States adopted an electronic health record (EHR), and >80% are collecting electronic clinical notes  [1]. Clinical decision support (CDS) and intelligent data-driven alerts are part of federal incentive programs for Meaningful Use  [2, 3]. With the increasing capacity of EHR data and financial incentives to improve quality care, hospitals are increasingly well equipped to leverage computational resources to improve case identification and care throughput  [4]. The unstructured narrative of EHRs provides a rich source of information on patients' conditions that may serve as CDS tools. Detailed medical information is routinely recorded in providers' intake notes. However, this information is neither organized nor prioritized during routine care for augmented intelligence at the bedside.
Hospital Setting and Study Period The NLP CDS tool was implemented at the University of Wisconsin (UW) Hospital across the surgical and medical hospital inpatient wards. The EHR system used at the UW Health is Epic (Epic Systems Corp). The tool was designed for hospitalized adults (aged ≥18 years) and was assessed using a pre-post quasi-experimental study design over 30 months (24 months of usual care and 6 months for the implementation of automated screening). The study was a quality improvement initiative by the health system to provide an automated hospital-wide screening system for opioid misuse and was registered on ClinicalTrials. gov (NCT05745480).
Overview The technical architecture that enabled the real-time NLP CDS tool incorporated industry-leading and emerging technological capabilities. Figure  1  details the overall NLP CDS infrastructure that exported the notes from the EHR, organized them, and fed them into an NLP pipeline; input the processed text features into the opioid screener deep learning model; and delivered the resultant scores back to the bedside EHR as a BPA. The final architecture was a real-time NLP CDS tool, and the 6 components of the architecture are further detailed in the subsequent sections. Step-by-step implementation of clinical natural language processing (NLP) pipeline. Step 1 ran a scheduled program to ingest notes from the EHR for each patient organized the notes, and relayed them via an HL7 data feed (Cloverleaf) into the cloud computing environment and data lake (Microsoft Azure and Databricks) onto a VM (Step 2).
The NLP engine (cTAKES) processed the text stored on the VM and mapped them to medical concepts from the National Library of Medicine's metathesaurus (CUIs). The machine learning model received the CUIs as inputs and stored the results in DataBricks. At regular intervals, a custom Python script in Databricks performed the text extraction and linguistic feature engineering via cTAKES and stored CUIs with the appended data of patient identifiers. The CUIs served as the input to the machine learning model (SMART-AI) at the encounter level. The output of prediction probabilities and classification was stored in a Databricks table (Step 3). An API call from the EHR cloud is made to determine whether the cutpoint threshold from the machine learning model was met to trigger a BPA. In Step 4, the EHR cloud made an HTTP call to Databricks to request the score.
Component 1: Transferring Clinical Notes From the EHR to Cloud Computing Health Level 7 (HL7) refers to the standards for transferring health care data between data sources. Cloverleaf (Infor Cloverleaf Integration Suite) was the UW's vendor solution that served as an application programming interface (API) gateway for accessing the clinical narratives in the EHR using HL7 version 2. To initialize the data feed, a UW Health interface analyst created a new entry in the Cloverleaf vendor software detailing the desired record information, which included clinical note text and identifiers. The analyst then "activated" the data feed, which began a continuous Transmission Control Protocol message-generating process. The Transmission Control Protocol messages were communicated using the HL7 application protocol to the Azure Virtual Machine (version 2022; Microsoft Corp) host at a port designated by the data science engineering team.
This port was reserved by a NET program (the "TCP listener"), which wrote the message to the cloud file system and replied to the Cloverleaf server with acknowledgment messages, conforming to the HL7 version 2 specification. Ultimately, the API extracted clinical notes from Epic and transferred them to a Microsoft Azure cloud computing environment that was under a business associate agreement with the UW. On-premise relays with the File Transfer Protocol were used to transfer the clinical notes to a specified location in the Azure cloud environment.
Component 2: Cloud Analytic Computing Platform In the Microsoft Azure framework  [8] , the UW Health invoked the Databricks (Databricks Inc) analytic resources and services for scalable computing, data storage, and querying. The open-source tools from the NLP engine and our trained, publicly available machine learning model were hosted in Databricks. The machine learning model life cycle management (MLFlow) tool in Databricks supported the data flow for the deep learning model. MLFlow created and scored models when clinical notes were received and subsequently reported the results upon request. The final infrastructure was a scalable and failure-resistant environment for analytic computations.
Component 3: NLP Pipeline The Clinical Text Analysis and Knowledge Extraction System (cTAKES; Apache Software Foundation) was built on multiple open-source Apache projects and incorporated technologies with the Unstructured Information Management Architecture framework and the Apache OpenNLP NLP toolkit  [20]. This configuration contained several engines for sentence detection, tokenization, part-of-speech tagging, concept detection, and normalization to extract information from the clinical narrative in the EHR. We did not use the negation module because it was not used in the current use case; however, this can be turned on for other use cases. cTAKES is one of the most ubiquitous NLP engines used in the clinical domain  [21]. cTAKES provided named entities from the free text that were mapped from the National Library of Medicine's Unified Medical Language System (UMLS), which is a repository of groups of words with relevant clinical contexts (eg, drugs, diseases, symptoms, anatomical sites, and procedures).
Each named entity was mapped to a concept unique identifier (CUI) using the UMLS Systemized Nomenclature of Medicine-Clinical Terms and medical prescription normalized ontologies. For instance, "heroin misuse" from the text was assigned C0600241 as its CUI, which was different from the CUI assigned to "history of heroin misuse," C3266350. For generalizability, we used the default cTAKES pipeline  [22]. As clinical notes were entered into the EHR for an individual patient, Cloverleaf relayed the notes via HL7 from the Epic EHR and used the Azure File Transfer Protocol server running on a virtual machine to place them at a known location within the Azure cloud environment. In 15-minute intervals, Databricks triggered a custom Python script to extract the text and fed it into the cTAKES pipeline to map and extract the CUIs.
Component 5: Real-time Delivery of the Prediction Results The Nebula Cloud Platform was Epic's Software as a service platform for integrating new technology and specifically supported clinical prediction modeling. Nebula capabilities included the deployment of machine learning models, including a library of Epic-curated models for health care and custom algorithms. Our solution leveraged the latter to facilitate triggers from Epic to call out to the Databricks environment and provided the predictions for BPAs. In the case of SMART-AI, we designed a BPA (Figure  2 ) to trigger once a clinician opened a patient chart in the EHR. Epic called its Nebula component to determine whether a BPA should be generated. Nebula made an HTTP call to Databricks to request the score. The RESTful HTTP API provided the SMART-AI model score that was serviced using MLFlow.
During pilot implementation, we will collect and summarize clinical performance data during PDSA cycles to guide clinicians and administrators in monitoring, evaluating, and modifying provider behavior. Using the Consolidated Framework for Implementation Research-Expert Recommendations for Implementing Change matching tool  [29] , we will tailor relevant implementation strategies to enhance provider uptake and use of the tool. In addition, during the pilot phase, we will interview providers on the hospital units beyond the pilot units to identify and explore their determinants for the use of the BPA. After a pilot implementation period of 3 months, we will optimize provider training, enhance educational materials, and institute quality monitoring preparatory to a hospital-wide rollout.
Acknowledgments The authors acknowledge support from the  University of Wisconsin Institute for Clinical and Translational Research , which, in turn, is supported by the  Clinical and Translational Science Award program  through the  National Institutes of Health National Center for Advancing Translational Sciences  grant ( 2UL1TR002373 ). The research was also supported by the  National Institute on Drug Abuse of the National Institutes of Health  ( R01DA051464 ; CJ, DD, MA, and RB),  National Library of Medicine Temporal Histories of Your Medical Event (THYME)  project ( R01LM010090 ; DD), and  National Institute of Diabetes and Digestive and Kidney Diseases   R01DK126933 ). The content is solely the responsibility of the authors and does not necessarily represent the official views of the  National Institutes of Health  or the other funding sources listed in this section.
Location and orientation Some applications combine location and orientation information to implement spatial interactions. Virtual shelves  (Li et al. , 2009)  is an interface that allows users to execute commands by spatially accessing predefined locations in the air. Pure Land AR (Land Augmented Reality Edition)  (Chan et al. , 2013)  is an installation that allows users to visit virtually the UNESCO World Heritage-listed Mogao Caves. Interactive Lighting  (Hakulinen et al. , 2013)  is a multilevel software framework that allows the creation of user interfaces to control lighting. Slab  (Rateau et al. , 2014)  is an interactive tablet for exploring 3D medical images. Jaguar  (Zhang et al. , 2018)  is a mobile AR system with flexible object tracking for context awareness.