dataesr/scientific-paragraphs-categorization huggingface dataset:
Conceptual Mapping The conceptual mapping aimed at aligning the MIMIC local terminologies to OMOP's standard ones. It consisted of 3 phases: integration, alignment, and evaluation. The integration phase consisted of loading both types of terminologies into the OMOP vocabulary tables. The OMOP terminologies are provided by the Athena tool and were loaded with the associated programs. We used export with all terminologies without licensing limitations. The local terminologies were extracted from the multiple MIMIC tables and loaded into the OMOP CONCEPT table. When possible, relevant information from the original MIMIC tables was concatenated in the concept_name column. MIMIC local concepts were loaded with a concept_id identifier starting from 2 billion. In the OMOP CONCEPT table, MIMIC concepts could be distinguished with the vocabulary_id identifier equal to "MIMIC code" and a domain_id identifier targeting the OMOP table in which the corresponding data were stored.
Section templates (eg, "Illness History") were automatically extracted from text with regular expressions and then filtered to keep only the most frequent (frequency >1%). A 48-hour open access datathon was set up in the Assistance Publique des Hopitaux de Paris (Paris AP-HP) in collaboration with the Massachusetts Institute of Technology (MIT), once the MIMIC-OMOP transformation was ready for research. This datathon was organized to evaluate OMOP as an alternative data model for accessing and analyzing MIMIC data during a real event. Scientific questions were prepared in an online forum where participants could introduce themselves and propose a topic or choose an existing one. OMOP was loaded into Apache HIVE 1. 2. 1 in ORC format. Users had access to the ORC data set from a web interface Jupyter Notebooks with Python, R, or Scala.
A SQL web client allowed teams to write SQL queries from Presto to the same data set. The hadoop cluster was based on 5 computers with 16 cores and 220 GB of RAM. The MIMIC-OMOP data set was loaded from a Postgres instance to HIVE through Apache SQOOP 1. 4. 6 directly in ORC format. Participants also had access to the Schemaspy database physical model to access the OMOP physical data model with both table/column comments and key primary/foreign relationships materializing the relationships between the tables. All queries were logged.
Data Transformation All transformation processes are freely accessible to the public via the MIMIC-OMOP git repository maintained by MIT-LCP  [8]. The git repository centralizes the various resources of this work, such as documentation, source code, unit tests, and questioning examples, discussions, and problem issues. It also indicates web resources, such as the physical data model for MIMIC and OMOP data sets and the Achilles Heel web client. The MIMIC-OMOP conversion was performed by 2 developers (a data engineer and an intensivist) for 500 hours. This included ETL, git documentation, concept mapping, contributions, and unit tests. ETL (with unit tests and generation of ready-to-load archive) on a subset of 100 patients lasted 5 minutes and enabled fast development cycles. ETL lasted 3 hours to process the whole MIMIC database.
Conceptual Mapping The results of the conceptual mapping's completeness are presented in Table  5. We have often mapped many source concepts to a unique standard concept_id because MIMIC provides a large number of equivalent concepts. For example, MIMIC provides 6 distinct concepts for body temperature: temperature C, temperature C (calc), temperature F, temperature F (calc), temperature Fahrenheit, and temperature Celsius. All of them were mapped to the LOINC "Body temperature", and numerical values were normalized. OMOP's terminology coverage has already been rated as excellent  [24]. We used the OMOP terminology mappings (National Drug Code [NDC]-RxNorm, ICD9-SNOMED, Common Procedural Terminology Fourth Revision [CPT4]-SNOMED) to standardize a consequent set of MIMIC nonstandard terminologies.
The automatic OMOP terminology mapping was evaluated by an intensivist. The results are in favor of good integration of the model. We checked 100 elements for each mapping used (NDC, ICD9, and CPT4). ICD9 and CPT4 were correctly mapped to SNOMED (100%). However, only 85% of NDCs were linked to a correct RxNorm code. This was partly due to an incorrect NDC drug code (from MIMIC) and partly because only 78% of NDC codes are mapped to RxNorm. Moreover, even if this does not seem to have affected our ETL, we know that some of ICD-9-CM codes can have a one-to-several match with SNOMED (28%)  [35]. In several cases, OMOP had no suitable concepts for the ICU-specific cases. In particular, the VISIT_DETAIL  table  does not yet introduce relevant information and duplicate information from the VISIT_OCCURRENCE table.
The extracted sections were not mapped to standard terminologies, such as the LOINC clinical document ontology (CDO). The reason for this is that the LOINC CDO decided not to keep these sections up to date, considering that they are not widely used  [36]. The Paris AP-HP organized a datathon with MIMIC-OMOP, in which 160 participants from 25 teams had 48 hours to undertake a clinical project using the MIMIC-OMOP database. They launched around 15,000 queries, with a maximum duration of 1 minute. They got an opportunity to create mixed teams: clinicians brought the issues that required data mining, as well as their data expertise, while data scientists judged the technical feasibility and finally implemented the various analyses needed. Writing standard queries (ie, with standard concepts) requires knowing the organization of relational models (SQL) and also mastering the graphical nature of certain terminologies, such as SNOMED-CT, in order to capture all potential codes that might be related to the one analysts think of first.
Principal Results In this paper, we presented the transformation of the MIMIC database into the OMOP CDM and its evaluation. The first major contribution of this study is to provide a freely accessible data set in OMOP format that could be useful to researchers. The second major contribution is to share with the OMOP community some useful transformations dedicated to intensive care that can be reused on any OMOP data set. The last contribution is to evaluate the implementation of MIMIC into the OMOP CDM.
Lessons Learned We observed that the OMOP CDM can be implemented at low cost and downstream of an existing architecture, since the scripts are freely available on the project's GitHub, for 8 different database management systems. The rationale of the data model can be understood through the numerous resources made available by the OHDSI community: tutorials, forums, working groups, and documentation. The structural mapping is carried out without difficulty as question marks can be raised with the community. The main difficulty remains the step of semantic mapping, especially in countries or institutions using local terminologies and vocabularies. Since the CDM model proposes to store both international and local vocabulary codes for each table, it is possible to start conducting studies using only the local codes.
Choosing a public GitHub repository for documentation and source code support allows analysts to learn more about the project and also learn how to contribute. The highly active OMOP forum is full of details and training. In contrast, the implementation guide suffers from not being as detailed and maintained. We believe that the OMOP community would greatly benefit from a systematic and concise synchronization between the forum, mailing lists, source code repository, and end-user documentation. Any data transformation is likely to generate bugs that can later have an impact on medical research. The foundations of the relational database management system (RDBMS), such as transactions, standardization, and integrity constraints, are integrated safeguards that have been useful throughout the process.
That said, a solution such as the HL7 FHIR is a great way to implement real-time inference from EHR data, and that is how the FHIR and OMOP are complementary. This has already been studied but needs further optimization  [39]. The MIT regularly organizes datathons using their open-access databases  [40] [41] [42] [43]. From a human point of view, these events enable teamwork and collaboration between different specialties (ie, physicians, computer scientists, statisticians, data scientists), which can benefit from each other's expertise. This time, the datathon was also an opportunity for these profiles to collaborate, and it allowed novices to be introduced to the OMOP CDM and its analytical tools. The critical point in the conducting of such an event is related to the IT architecture, which must allow dozens of users to run large queries at the same time and to share scripts and results.
We used a platform similar to the one used by Celi et al  [41] , with several analytical tools (Jupyter Notebook, Python, R, Scala). The datathon showed that distributed platforms with basic hardware provide SQL tools for online analytical processing (OLAP) with excellent performance that overcomes RDBMS weaknesses. Therefore, OLAP takes advantage of SQL language analysis functions, such as grouping, windowing, assembling, and mathematical functions, that are often missing in NoSQL databases. Although some are open source, these distributed technologies are not easily accessible; however, cloud-based solutions are increasingly affordable for researchers. The real-life test of the datathon revealed the strong need to make the physical data model accessible, including comments on columns and tables, and we discovered that an open source tool called schemaspy is helpful.
We present a new version of PyR@TE, a Python tool for the computation of renormalization group equations for general, non-supersymmetric gauge theories. Its new core relies on a recent paper by Poole & Thomsen [1]  to compute the β-functions. In this framework, gauge kinetic mixing is naturally implemented, and the Weyl consistency relations between gauge, quartic and Yukawa couplings are automatically satisfied. One of the main new features is the possibility for the user to compute the gauge coupling β-functions up to the three-loop order. Large parts of the PyR@TE code have been rewritten and improved, including the group theory module PyLie. As a result, the overall performance in terms of computation speed was drastically improved and the model file is more flexible and user-friendly.
RGEs for general gauge theories have been known for almost forty years at two-loop accuracy  [2, 3, 4, 5, 6, 7, 8]. Since the derivation of the RGEs for specific models is often tedious and error prone in practice, these general expressions were implemented in the Mathematica package SARAH  [9]  and in the Python software PyR@TE  [10, 11]  allowing for an automatized computation of the β-functions. Over the years, the formalism was extended to take into account Abelian kinetic mixing  [12, 13]  and scalar mixing  [14]. The application of the dummy field method, allowing for the determination of dimensionful couplings RGEs, was carried out rigorously and extensively reviewed in  [14]. In addition, various mistakes and misprints were uncovered. Recently, a new formalism for the RGEs of a general gauge theory was presented in  [1].
For these reasons we believe that this modern formalism might become the new paradigm in the field, thus motivating its implementation in the new version of PyR@TE. For this purpose, it is also necessary to know the RGEs for the dimensionful parameters in this formalism which can be found in  [22]. In addition to the possibility of computing the gauge couplings RGEs up to the 3-loop order, inherent to the formalism described above, many improvements were made to the PyR@TE code. The latter was essentially rewritten, driven by the intention of improving its performances and overall ease of use. Several new features were also developed and will be extensively reviewed in the following. The rest of this paper is organized as follows. Section 2 provides an introduction to the theoretical framework implemented in the new version of the software.
Download and installation The new version of PyR@TE may be downloaded from the following GitHub web page: https://github. com/LSartore/pyrate No further installation procedure is needed and the user may start working in PyR@TE's main folder. However, PyR@TE relies on a number of Python modules which need to be installed by the user if not already present on his/her machine. We show here the full list of dependencies: • Python ≥ 3. 6 • PyYAML ≥ * 5. 3 • Sympy ≥ 1. 5 • h5py ≥ * 2. 10 • Numpy ≥ * 1. 18 • Scipy ≥ * 1. 4 • Matplotlib ≥ * 3. 1 Version requirements marked with an asterisk are not critical requirements, in the sense that PyR@TE is likely to work properly with older versions of these modules. However, we note that during its development, PyR@TE was only tested with the above listed versions.
Definition of the model The information on the particle physics model is contained in the so-called model file, which is the starting point of any computation performed by PyR@TE. The overall structure of the model file is essentially based on the previous versions  [10, 11]  of the software. However, a number of improvements were made that we will review in the following. Let us begin this discussion with, as usual, the example of the Standard Model. The full SM model file is provided in Appendix B. In the following we will go through this model file step by step, making comments wherever useful. General information -Three fields can be provided in this section, namely the Author , Date of creation and Name of the model file. The first two are essentially informative while the last one will be used by PyR@TE to generate its output (see section 3.
The Mathematica output consists in a single file, containing the expressions of the β-functions. In addition, if the MathematicaSolver default setting is set to True, the file is enhanced with a ready-to-use RGE solver. To solve the RGEs, the first thing that the user needs to do is to define the boundary conditions, that is the value of the couplings of the model at some initial energy scale. Then, after having defined the running scheme (the loop level for each type of couplings), the user may solve the system of RGEs using the RGsolve[] function and finally plot the results using the RGplot[] function. Finally, the Python output consists of three files, gathered in a PythonOutput folder. For instance, in the case of the SM: • RGEs. py contains the expressions of the β-functions in the form of Python functions.
(C1) of  [32]. In addition, we compared the results of PyR@TE 3 against those of PyR@TE 2 for some of the models presented in  [10]  and  [11]. Doing so, we were able to compare the performance of the two versions of the software in terms of execution time, as illustrated in Table  3. We first present the comparison of the results for some of the models listed in  [10] : • Standard Model with a real scalar singlet : full agreement at 2-loop. • Standard Model with a complex scalar doublet : full agreement at 2-loop. • Standard Model with Majorana triplet fermion and Dirac doublet : full agreement in the gauge, Yukawa and quartic sectors at 2-loop. Agreement is found for the scalar mass RGEs after correcting a mistake in the latest version of the PyR@TE 2 code. For the fermion mass RGEs, we find agreement once the corrected formulae presented in  [14]  are taken into account.
Full agreement is found at 2-loop, after an obvious error in the model file from PyR@TE 2 is corrected (an additional lepton doublet was unintentionally included). Finally, we validated the output of PyR@TE 3 for the U(1) B-L extension of the SM described in  [11]. In the gauge, Yukawa and quartic sector, full agreement is found between the two versions of the code in presence of kinetic mixing in the Abelian sector. However, there.
Conclusion and outlook In this paper, we have presented a new version of PyR@TE, a Python tool for the computation of renormalization group equations for general, non-supersymmetric gauge theories. Compared to the previous versions PyR@TE 1  [10]  and PyR@TE 2  [11] , an important number of improvements have been realized. First of all, the new PyR@TE 3 is now compatible with Python 3. This is an important step since Python 2 has reached "End Of Life status" as of January 2020 and it is officially recommended to switch to Python 3 now. Furthermore, large parts of the code have been rewritten. Its new core relies on a new formalism developed by Poole & Thomsen  [1]  to compute the β-functions for all dimensionless couplings. The corresponding expressions for the dimensionful couplings have recently been derived in  [22]  completing the set of expressions in this formalism.
In all examples presented in Tab. 3, PyR@TE 3 just needs a couple of seconds to compute the RGEs -even in the case of three-loop gauge couplings. For more involved models, in particular ones with widely extended scalar sectors, the typical running times are at most of a few minutes at the maximum loop-orders. There is a number of other improvements which are noteworthy: (i) We have worked to make the model file more flexible and user-friendly (albeit largely but not entirely backward compatible). (ii) The PyLie module has been modified not only to improve its speed performance but also to include some new features. For example, PyR@TE 3 can now handle all simple Lie algebras including the symplectic and exceptional ones. There is also now the option to rotate the basis in the target space of the representation such that the generators for a real representation are imaginary and skew-symmetric.
(iii) The two-loop RGEs for VeVs  [23, 24]  have been implemented in PyR@TE 3. (iv) We also note in passing that an interface between PyR@TE 3 and the Mathematica package Feynrules  [35]  is under development which will be described elsewhere. We have validated PyR@TE 3 against the literature for several models (see Sec. 4) and found complete agreement. We have also compared the results of PyR@TE 3 with the ones of PyR@TE 2 for some of the models already discussed in  [10, 11]. Again, we have found largely agreement up to two problems which could be associated with the PyR@TE 2 code. For several reasons we recommend to use PyR@TE 3 in the future: PyR@TE 2 (and Python 2) are no longer developed/maintained, the new formalism in the PyR@TE 3 code has a very clear structure with a natural implementation of kinetic mixing, there are several new features which make PyR@TE 3 more user-friendly and efficient.
This appendix is dedicated to the description of the group theoretical functionalities available in PyR@TE 3. All the group theory related computations are handled, since the previous version of PyR@TE, by the PyLie module. PyLie is essentially a Python rewrite of the group theory module of SUSYNO  [36]. Such computations comprise for instance the possibility of computing the generators of a given representation, the structure constants of the Lie algebra, or the Clebsch-Gordan coefficients (CGCs) of a given set of representations. A lot of effort was put in the development of PyR@TE 3 to improve the performances of PyLie's main functions. This concerns in particular the three kinds of calculations listed above. However, despite these efforts, some calculations may be quite time-consuming when it comes to high-dimensional representations.
Therefore, based on the previous version of PyLie, we developed a database in which the results of the group-theoretical computations are systematically stored for any later use. At various steps of the computation of the RGEs, PyR@TE 3 interacts with this database through the PyLieDB module. The user may interact as well with this database through an interactive IPython session or a Jupyter notebook in order to access the results of PyLie's computations. After a discussion about the Dynkin labels as a way to uniquely identify the representations of a given gauge group, we introduce the use of CGCs to build a Lagrangian in PyR@TE 3. A short tutorial (in the form of an interactive Python notebook) available in the doc/ repository of PyR@TE 3 is dedicated to the interaction with PyLie's database.
Acknowledgements We are indebted to  Florian Lyonnet  from whom we have taken over the development of PyR@TE. This work would not have been possible without the foundations laid by him in the previous versions of the code. We are also grateful to  Colin Poole  and  Anders Eller Thomsen  for many useful discussions. Finally, we would like to thank  Jan Kwapisz ,  Aaron Held  and  Fabien Besnard  for their helpful contributions in testing and validating PyR@TE 3. We also wish to thank  Tom Steudtner  for his help with the validation of the SUSY toy model from [14]. This work was supported in part by the  IN2P3  project " Théorie -BSMGA ". Appendix  A. Kinetic  mixing in the Abelian sector.
Density driven flow coupled with heat transfer In this section, we pursue the study of Section 3 on the interaction between flow and transport in porous medium and we take heat transfer into account. The model problem is proposed in the SEAWAT documentation  [10]. The SEAWAT code is a computer program for the simulation of a multi-species solute and heat transport  [10]. It combines the software codes MODFLOW and MT3DMS which solve t=500 seconds t=1000 seconds t=1500 seconds t=2000 seconds t=4000 seconds t=6000 seconds  the flow and the solute-transport equations respectively. The coupling between flow and transport is performed through a synchronous time-stepping approach that cycles between MODFLOW solutions of the flow equation and MT3DMS solutions of the transport equation. SEAWAT includes both explicit and implicit methods for coupling the flow and the solutetransport equations.
the explicit method, a lagged approach is used for assigning fluid densities in the flow equation. With the implicit coupling method, solutions of the flow and transport equations are repeated interactively solved, and concentrations and densities are updated within each time-step until the maximum difference in fluid density at each single cell for consecutive iterations is less than a user-specified value. As for the numerical methods, SEAWAT uses finite differences for solving the variable-density flow equations. The numerical methods used by the MT3DMS program to simulate solute transport in a constant-density flow field are directly used in SEAWAT to simulate the solute transport in a variable-density flow field. Both MODFLOW and MT3DMS use cell-centered grids. In this formulation, the dependent variables obtained in the finite-difference solution represent average values (assumed to be given at the cell center) for the respective cells.
The same block-centered grid is used by SEAWAT, MODFLOW and MT3DMS. We propose a uniform code using the generalized finite volume method SUSHI. The structure is much simpler since we deal with a single code instead of two codes which are coupled with each other. We refer to  [2]  for the study of a related problem by means of a Voronoi box based finite volume method. We apply mesh refinement and show the results of three test cases. Our results are very close to those obtained by SEAWAT.
Design of Scaffold A perfusable 3-D interconnected scaffold was designed as previously reported by our group  [12]. The CAD model was designed in such a way to ensure continuity from inlet to outlet using AutoCAD software. It had 2 truncated cones joined at the center with a maximum diameter of 30. 30 mm. The outlets at 2 opposite ends were connected through 3-D branched flow channels. The diameter of flow channels inside the device could be sectioned into 3 different layers, and each layer had varied inner diameters of flow channels as follows: 2 mm, 1. 5 mm, and 1 mm, respectively, starting from outlet toward the center. The height of the device was 46. 46 mm and the total volume was 11. 02 cm 3.