dataesr/scientific-paragraphs-categorization huggingface dataset:
Nanterre 2 CESI Project The Nanterre 2 CESI project is composed of: (i) a ground floor of 800 m 2 : coworking and catering space; (ii) the first floor to the third floor (800 m 2 per floor): teaching spaces; (iii) the fourth floor (600 m 2 ): Living Lab. (i. e. , BIM modelling, RA/RV, and digital simulation spaces); (iv) parking for employees, professors and/or researchers, and green spaces. Construction works were planned for a 12-month period (between 5th May 2018, and 31st May 2019). CESI, as client, specified the use of BIM for the design and construction of the Nanterre 2 building. Apart from its intrinsic commitment to the use of the latest available technologies, CESI also wanted to use the project as a case study that provided data for teaching and research programmes in digital construction.
• Site modelling; Ultimately, however, for the works to proceed, it was agreed that the appointed delivery team could omit several (marked as *, above) of the BIM use cases. The main reasons for this were the deficiency of certain aspects of the requirement specifications as well as the diversity in the level of BIM expertise and maturity within the delivery team. One such omission was the requirement to provide 4D BIM. For this use case in particular, the BIM specification document only stated that a 4D software must be mastered, indicating Navisworks as an example. The mistake made was to only cite the type of software without specifying its capabilities. In this case, Navisworks was not capable of managing the construction site and monitoring, in real time, construction work progress. These were precisely the two uses of 4D BIM expected by CESI.
Thereafter, 4D planning will enable the optimisation and the validation of the planning generated. At this stage, all of the 4D parameters related to the analysis of occupied spaces (4D BIM Objective N • #1) are known. As for the 4D objective linked to monitoring construction work progress, it is up to the OPC, possibly with the support of the BIM manager, to choose their own method. For the Nanterre 2 project, the initial schedule already included the links between the tasks. It therefore remains to determine the 4D parameter to be created so as to link the schedule to the BIM models, and to increase the level of the project tasks flowchart in order to optimise the precision of the progress monitoring process. Since the BIM model was created using Autodesk Revit software, a simple and straightforward solution is to create a text parameter and name it 'BIM_WBS'.
Primary 4D BIM Planning First, the 4D parameter 'BIM_WBS' is created and integrated into the BIM model of structural works. Then, the BIM model is exported from the authoring platform using the Synchro Plug-in. The project schedule is also imported and the links between the tasks are preserved. Finally, the objects of the BIM model are assigned to the corresponding tasks. This first summary 4D BIM schedule, which can be exported in video format (. AVI) or in phasing form (. JPEG), allows project teams to check that the project workflow is correct. It is now possible to work directly on the 4D planning software to make changes to the project schedule. However, the BIM objectives of the project have not been achieved yet.
g. , photovoltaic panels, solar collectors). Each 'Renovation Activity' is temporally constrained by activities that should start and finish before it, whereas some others will be triggered and executed after its completion. It also requires a set of 'Material', 'Workforce', and 'Equipment' so it can be executed and may cause 'Disruption' to the building occupants. The 'Disruption' concept is beyond the scope of this paper and will be detailed in future research, since its estimation and simulation is one of the RINNO project targets. The ontology proposed was populated into a database using the SQL Server. This database included several tables, and each one enabled the implementation of a concept from the ontology. The tables describe in detail data related to renovation activities, their sequencing rules, constraints, duration, cost, equipment, etc.
[99]  developed an ontology restricted to the installation of common renovation products, such as windows, HVAC components, and external thermal insulation panels. The 4D BIM ontology proposed in this paper considers the general case of renovation projects and so includes all related activities: innovative products installation as well as general activities, such as 'façade insulation with cavity insufflation'. Furthermore, to improve interoperability and interfacing between the BIM authoring tool (Autodesk Revit), the BIM management tool (Synchro Pro), and the scheduling tool (MS Excel), the RINNO Renovation Engine was developed as a plugin using the C# programming language, and the ontology was implemented as a knowledge base and populated using both the SQL Server tool and the RINNO partners' expertise and knowledge.
JINST 17 P10019 ATHENA will make, with high precision, the challenging measurements required to extract Generalized Parton Distributions (GPDs) and Transverse Momentum Distributions (TMDs), which encode the full structure of the nucleon and nuclei. Measurements of GPDs via DVCS are enabled by ATHENA's excellent photon measuring capability. Novel TMD measurements to study the valence region are facilitated by highly effective jet and hadron measurements, identification capabilities, and complementary event reconstruction in the hadron-going direction. Spectroscopy measurements are optimized by the superior tracking resolution and PID reach in the barrel region. Hadronization studies utilize ATHENA's comprehensive hadron PID capabilities for jet fragmentation studies, along with precision measurements of jet substructure.
Structure of the Proposal In section 2 we present the detailed ATHENA Detector concept and motivate its design and technology choices. Section 3 contains an assessment of the impact of ATHENA on EIC science. The results presented in this article fall into three categories: 1) based on Analytical Calculations (AnaCal), 2) on full GEANT4 based simulations, where we implemented the complete ATHENA baseline geometry, including the material needed for detector services and a realistic reconstruction framework in a newly developed software environment (section 2. 9) leveraging modern developments from the HEP community (FullSim), and 3) from fast simulations based on calculations or parameterized smearing of detector resolution validated by full simulations or comparison with full simulation samples (FastSim).
The ATHENA detector 2. 1 Design considerations The ATHENA detector will meet the goals of the EIC physics program over the full range of center-of-mass energies from 20 to 140 GeV with the largest acceptance practically possible. The following principles guided the design: Overall size: ATHENA benefits from using all the available space for experimental equipment at Interaction Point 6 (IP6) and respects all constraints imposed by the existing detector hall. Our -8 -design accommodates all subsystems without compromising on performance, eases routing of services and leaves room for future upgrades.
Software and computing Software and computing will be critical to the success of any EIC experiment. ATHENA chose to already now lay the foundations for a long-term software strategy for the EIC. To accomplish this, we focused on modern scientific computing practices: we developed a toolkit of modular, orthogonal components designed for performance in heterogeneous computing environments in the -31 -context of both HTC and HPC. Furthermore, we emphasized modern development practices built around the use of a dedicated GitLab server with a continuous-integration backend for reproducible containerization and automated tests and benchmarks. We leverage mature, well-supported, and actively developed software components allowing us to focus our limited resources on those parts of the toolkit requiring custom development work.
ATHENA benefits from cutting-edge CERN-supported software developed for the (HL-)LHC. We implemented our detailed detector geometries  [48] [49] [50]  in DD4hep  [51] , which provides geometry services for both the full GEANT4 simulation and our reconstruction algorithms (figure  19 ). For the reconstruction framework, we chose Gaudi  [52] , as it supports modern task-based concurrency ideally suited for heterogeneous computing environments. On top of Gaudi, we built Juggler  [53] , our library of digitization, reconstruction, and analysis routines, where we used ACTS  [54]  for highly performant tracking, and Tensorflow  [55]  for AI. These modular components communicate through a robust flat data model, EICD  [56] , implemented using the PODIO data model library  [57]. The maturity and robustness of the software components in the toolkit enabled us to build out, from scratch, a performant simulation and reconstruction software stack over the short timeline since the call for detector proposals.
This toolkit implements the ATHENA detector in all its details, including the far-forward and far-backward, accelerator, magnet, and detector components. This setup allowed us to conduct effective detector optimizations for the proposal and prepare ATHENA for the road towards the Technical Design Report (TDR). The simulation results in this proposal were obtained using our new software environment, deployed on an extensive range of systems, including the Open Science Grid (OSG), Jefferson Lab, BNL (including S3 storage), Compute Canada, ALCF (ANL), LCRC (ANL), NERSC (LBNL), INFN-CNAF, and a dedicated continuousintegration cluster at ANL. We strongly believe that this innovative approach, introduced within ATHENA, represents a significant step forward for the EIC community. -32 -.
• Due to the compactness of the IR and the detector design, the first valve on the outgoing hadron side can only be integrated after the first bending magnet in the hadron beamline downstream of the IP at approximately 7 m. In the outgoing electron side, such a valve can be placed after the nHCal at approximately 4. 5 m from the IP. Figure  20  shows ATHENA fully integrated into the interaction region and the experimental hall at IP6, obeying all the above listed constraints. Because of the stringent space constraints, it is important to keep the assembly procedure of the detector as a design consideration. As a consequence, the central part of the detector is installed from the outside in and the electron and hadron endcaps from the inside out. Figure  21  left shows the overall concept for the ATHENA detector as implemented in ProE-Creo, the computer-aided design program used for the EIC Project.
R&D needs R&D on many ATHENA subsystems was initially conducted through the EIC Generic Detector R&D Program  [6]  that ran from 2011 until September 2021. Several subsystems matured to levels where little basic R&D remains and the focus is shifting to the construction and testing of full chain prototypes (detector, electronics, supplies, and DAQ) in test beams. These developments will be supported by EIC project funded R&D  [58]  that will start in FY22. Project funds will also support R&D of components that have not reached their full potential yet and need further optimization. Only a limited number of technologies still need substantial R&D and have been selected because of the performance benefits they offer. Here we give a brief summary of ATHENA's R&D needs. -34 -.
The size of the markers show the uncertainties of the corresponding datasets. At each point the data and theory relative uncertainties are shown where the data has the relative highest impact. Right: projected Sivers asymmetries extracted from ATHENA pseudodata compared to projections from the Pavia extraction  [78]  for charged pions. Pseudodata with  2 > 1. 0 GeV 2 , 0. 2 <  < 0. 7,  > 0. 05,   / < 1. 0 were selected. The ATHENA data will be powerful in constraining the shape of this TMD as well as its evolution. The uncertainties of the individual datasets were scaled to 100 fb -1 of 10 GeV electron collisions with 275 GeV protons assuming equal data taking time for each center-of-mass-energy. Based on previous experience, we assumed 2% point-to-point uncertainty and 1. 5% scale uncertainty (FastSim).
ATHENA will measure nuclear PDFs (nPDFs), or nuclear modification ratios, which encode the deviations of nPDFs from simple scaling of nucleon PDFs with atomic mass. The sensitivity to non-linear QCD effects in inclusive DIS is closely related to the precision and kinematic acceptance of the nuclear modification ratios proposed to be measured by ATHENA. The impact of ATHENA on nuclear PDFs has been studied in the xFitter framework  [115]. Pseudodata from ATHENA only are used as input to fits in which the PDFs evolve according to the NLO DGLAP equations, with minimum  2 = 3. 5 GeV 2 , and a parameterization at the starting scale taken from the HERA2PDF studies. Figure  42  shows the results for the pivotal case of the gluon density, as well as the sea and valence up quark densities. The low- precision on the gluon density is ∼ 5% for protons and 10% for gold.
The ATHENA-only projections for the nuclear modification ratio are compared with the precision of a representative current global fit, EPPS16  [116] , which includes data from fixed target DIS and Drell-Yan experiments, hard processes in p+A collisions at the LHC and  0 data from PHENIX. The precision on the gluon for  ∼ 0. 1 is improved by around a factor of two when using ATHENA data. The minimum  of data points included in the EPPS16 fit is 0. 008, whereas in the ATHENA fits it is approximately 0. 001. ATHENA measurements will constrain the nuclear gluon density with a precision of approximately 10%. Inclusive DIS data can be complemented at the EIC by SIDIS production of heavy flavor pairs, that are sensitive to the gluon density and its shape through photon-gluon fusion. The large -range explored at the EIC should allow for testing current understanding of gluon shadowing at  0.
Figure31. Projected statistical and systematic uncertainties for   for charged kaons. The curves are based on DSSV helicity PDFs [67]  combined with DSS FFs [69]. The bands reflect only the helicity PDF uncertainties. Left: the expected results for 15. 5 fb -1 of 18 GeV electrons colliding with 275 GeV protons. Right: results combining pseudodata from 5 GeV electrons colliding with 41 and 100 GeV protons, 10 GeV electrons colliding with 100 GeV and 275 GeV protons, and 18 GeV electrons colliding with 275 GeV protons. The uncertainties of the individual datasets were scaled to the dataset with 18 GeV electrons colliding with 275 GeV protons assuming equal data taking time for each center-of-mass-energy. Pseudodata with  2 > 1 GeV 2 ,  > 0. 2,  > 0. 01 and a depolarization factor  () > 0. 1 were selected.
Pseudodata with  2 > 1. 0 GeV 2 , 0. 2 <  < 0. 7,  > 0. 05,   / < 1. 0 were selected. The ATHENA data will be powerful in constraining the shape of this TMD as well as its evolution. The uncertainties of the individual datasets were scaled to 100 fb -1 of 10 GeV electron collisions with 275 GeV protons assuming equal data taking time for each center-of-mass-energy. Based on previous experience, we assumed 2% point-to-point uncertainty and 1. 5% scale uncertainty (FastSim).
Acknowledgments We thank  Xiaocong Ai  (DESY),  Corentin Allaire  (CERN),  Nestor Armesto  ( Universidade de Santiago de Compostela ),  Ignacio Borsa  ( Universidad de Buenos Aires ),  Paul Gessinger-Befurt  (CERN),  Graham Heyes (JLab), Charles Hetzel (BNL) ,  Jerome Lauret  (BNL),  Renuka Rajput-Ghoshal (JLab) ,  Andreas Salzburger  (CERN),  Rodolfo Sassot  ( Universidad de Buenos Aires ),  Nobuo Sato (JLab) ,  Marcy Stutzman  (JLab),  Katarzyna Wichmann  (DESY),  Roland Wimmer  (BNL),  Holger Witte  (BNL), and  Yiyu Zhou  ( William & Mary and JLab ) for fruitful discussions, constructive suggestions, and contributions. This work was supported in part by the  Office of Nuclear Physics within the U. S. DOE Office of Science , the  U. S. National Science Foundation , the  ULAB-EIC LDRD program  at  Argonne National Laboratory , the  MRPI program  of the  University of California Office of the President , the  LDRD program  at  Los Alamos National Laboratory , the  Natural Sciences and Engineering Research Council of Canada (NSERC) , the  National Natural Science Foundation (NSFC)  and  Ministry of Science and Technology of China , the  Chinese Academy of Sciences , the  Czech Science Foundation and Ministry of Education, Youth and Sports (MEYS) , the  European Union 's  Horizon 2020 Research and Innovation program  under Grant Agreement No.
101004761  ( AIDAInnova ) and Grant Agreement No. 824093  ( STRONG2020 ), the  French Centre National de la Recherche Scientifique , the  French Commissariat à l'Energie Atomique, GSI Helmholtzzentrum für Schwerionenforschung GmbH , the  Department of Atomic Energy and Department of Science and Technology of the Government of India , the  Italian Ministry of Foreign Affairs and International Cooperation (MAECI) as Projects of Great Relevance within Italy/US Scientific and Technological Cooperation  under Grant No  MAE0065689-PGR00799 , the  Ministry of Education and Science of Poland , the  United Kingdom Science and Technology Facilities Council (STFC) , and the  Ministry of Education of Taiwan. The simulation studies have been performed making use of the computer resources of  ANL-PHY, OSG, JLab, BNL, Compute Canada, ALCF ,  LCRC ,  NERSC , and  INFN-CNAF.
Acknowledgments R. A. and P. J. gratefully acknowledge the funding received through the  European Union 's  Horizon 2020 research and innovation programme  under Grant Agreements No. 666221  (HELIS) and No. 957189  ( BIG-MAP ), the latter being part of Battery  2030+ , and from the  Swedish Energy Agency through "Batterifonden "; grants  P43525-1  and P39909-1. R. A. and P. J. have conflict of interest w. r. t. Compular 29 as co-founders and co-owners. P. J. acknowledges the immense support from the  Swedish Research Council 's  Distinguished Professor Grant  and from  Sweden's Innovation Agency (VINNOVA)  through  Battery Alliance Sweden (BASE). We also acknowledge the support from the  Theory and Modelling scheme of Advanced User Support from Chalmers Areas of Advance :  Materials Science  to R.
Objective: Waiting time for a consultation for chronic pain is a widespread health problem. This paper present the design of an ontology use to assess patients referred to a consultation for chronic pain. Methods: We designed OntoDol, an ontology of pain domain for patient triage based on priority degrees. Terms were extracted from clinical practice guidelines and mapped to SNOMED-CT concepts through the Python module Owlready2. Selected SNOMED-CT concepts, relationships, and the TIME ontology, were implemented in the ontology using Protégé. Decision rules were implemented with SWRL. We evaluated OntoDol on 5 virtual cases. Results: OntoDol contains 762 classes, 92 object properties and 18 SWRL rules to assign patients to 4 categories of priority. OntoDol was able to assert every case and classify them in the right category of priority.
In order to ensure explainability and adherence to guidelines, the first step consisted in building a knowledge base of expert rules based on a domain ontology. The ontology provides formal definitions of concepts and their relationships using the Web Ontology Language (OWL 2)  [4] , as well as inference capabilities to classify patients. In this paper, we present the design of our ontology, called OntoDol, as well as the results obtained on virtual patients' cases of complex regional pain syndrome.
Reuse of existing ontologies We explored the National Center for Biomedical Ontology (NCBO) Bioportal and OBO Foundry repositories to search for existing resources. We found that 'Pain' was a class present in 71 ontologies, and 'Neuropathic pain' in 31 ontologies. None of the corresponding ontologies provided a complete coverage for patient triage for a first consultation in a pain clinic. We decided to use SNOMED CT® as reference ontology since it is the most comprehensive international clinical terminology. The 2021-01-31 release contains more than 350 000 concepts. and is broadly used to document patients' signs, symptoms, and diagnoses in EHRs. We also imported the TIME ontology to model temporal aspects such as duration of symptoms, the date of onset of a disease, or demographic data like date of birth and age.
Design of OntoDol We used Python module Owlready 2 to create our ontology from the key clinical concepts and SNOMED-CT  [6]. Owlready 2 uses the release 2020AB-full of the Unified Medical Language System (UMLS) to import Metahthesaurus terms. Every term is mapped to SNOMED CT® Terminology. The PyMedTermino module from Owlready 2 mapped a list of terms with SNOMED CT® identifiers. Axioms were generated using object properties of interest. When some terms were not mapped within SNOMED CT®, experts had to map them manually to the closest concept, using the SNOMED CT® browser. Experts were asked to choose the smallest level of granularity with a significant clinical definition. We developed a bottom-up method to extract the parents in SNOMED-CT® and integrate them in OntoDol. When the level of granularity of the mapped concept was too coarse, we used a top-down a to collect the descendants.
Thus Owlready 2 created an automatic hierarchy with an is_a relationship between classes. Object properties, i. e. , relations between classes are defined in the SNOMED CT® as attributes of the Concept Model Object Attribute top class. Starting from the list of concepts obtained from the SNOMED CT®, we selected a set of object properties of interest. Then, a Python script using Owlready was used to retrieve all axioms using all defined classes and object properties. When relations between concepts were missing, new object properties were created, e. g. the relation between a disease and its phase. Data properties are relations between an individual and a primitive data type. In OntoDol, they are used to describe time and duration data using TIME i. e. 'Date of symptom onset' and 'Time since symptom onset' and value of pain assessment i.
OntoDol ontology We used the open source editor Protégé developed by Stanford in its version 5. 5. 0. We chose Pellet as the reasoner, as it supports Semantic Web Rule Language (SWRL) and SPARQL queries  [7]. OntoDol ontology is encoded in OWL 2 file format using Protégé 5. 5. 0. Metrics are listed in Table  1. Owlready imported understandable rdfs: label, rdfs:Prefered US Terms and rdfs: Synonym US Terms. We provided textual rdfs:definition. Top hierarchy of OntoDol is shown on Figure  1 , it reuses the hierarchy of SNOMED CT® so it could be interoperable with EHR data. TIME, as a recommandation of W3C, infered temporal concept from SNOMED CT® as time:instant or time:duration.
Acknowledgements Authors have no disclosure or disclamers to declare. Protégé 5. 5. 0 is available on http://protege. stanford. edu/We thank  J. B. Lamy  for his help in Owlready 2. The Python package is available at: https://pypi. python. org/pypi/Owlready2(stable version). UMLS was downloaded on: https://download. nlm. nih. gov/umls/kss/2020AB/umls-2020AB-full. zip.
Most aspects of the model are handled by the PhysiCell software  [9] , this includes cell division and progression through the cell cycle, cell adhesion and repulsion, substrate diffusion, and cell exchanges with the environment (secretion and consumption). Cells are modeled with the shape of a sphere that cannot deform; adhesion and repulsion are implemented using a potential function. The cell division process is implemented as a cycle, where the user can define each step and progress between them. There is no condition in the neighborhood, a cell will divide even if it is surrounded by other cells as long as there are sufficient nutrients. As a consequence, certain regions of the tumor will exhibit a higher cell density. We implemented in PhysiCell a heterogeneous diffusion with respect to local cellular density.