dataesr/scientific-paragraphs-categorization huggingface dataset:
Mathematical and computational methods FireFOAM is a fully compressible large eddy simulation (LES) code that discretizes the governing equations using the finite volume method (FVM). FireFOAM employs a Favre-filtered fully compressible flow formulation and solves for the Navier-Stokes Equations and transport equations for species mass fractions alongside sensible enthalpy (FM  Global, n. d. ). The FireFOAM code was developed by FM Global for modelling large scale fires, capturing fire growth and extinction. The sensible enthalpy equation is solved in its averaged form suitable for the large eddy simulation approach. The over-bars on the equation stand for spatial filtering while the tildes stand for Favre averaging. The filtered Fig. 1. A network representation of a ventilation duct showing branches between nodes  (Colella, 2010).
, 2019)  by implementing a banded approach of the weighted sum of grey gases (WSGG) model to account for gas thermal radiation absorption and emission. The modified radiation model, called "fvDOMBand" includes banded or nongrey WSGG solutions of the radiative transfer equation (RTE). The concept of the WSGG is to approximate the total emissivity of a real gas    2011 ). The parametric databases provide the WSGG pressure-absorption coefficients and the weighting coefficients, which are used in solving the RTE. In the present study, the parametric database of  Smith et al. (1982)  was used because it is the fastest and as accurate as other more recent databases  (Cassol et al. , 2014; Johansson et al. , 2011). It is worth noting that our in-house version of FireFOAM is different from the standard version used by  Le et al.
Conjugate heat transfer (CHT) Eqs. (  1 )-(3) represent the equations for the fluid region. In the solid region, only the energy equation, which is given as: ∂(ρh) ∂t = ∇. (λ s ∇T) + Q (5) is considered. The solid regions in the present study, based on the PRISME experimental scenarios, are concrete and rock wool while the fluid region is the gas phase where combustion takes place. CHT allows for coupling the thermal energy transport between the fluid and solid region. Using Eq. (  5 ) CHT is implemented as a 3D model in FireFOAM. The present study couples the CHT solver to the combustion process to represent accurately the heat transfer process in the walls of the fire  The heat transfer between solid and fluid, as a result of their interaction is stated mathematically using CHT. To solve CHT problems, the continuity of both temperature and heat flux at the interface of the fluid and solid region need to be ensured using the following two conditions: T f = T s (6) λ f ∂T f ∂y ⃒ ⃒ ⃒ ⃒ y=+0 = λ s ∂T s ∂y ⃒ ⃒ ⃒ ⃒ y=-0 (7) where the subscripts f and s are for fluid and solid respectively.
Conclusion This study aims to simulate fire behaviour in a mechanically ventilated nuclear compartment with particular attention to the pressure variation and the flow rate at the ventilation branches. An in-house version of FireFOAM, modified in the present study to implement conjugate heat transfer (CHT) and a ventilation model, is successfully used to simulate fire in a compartment with a mechanical ventilation network. The code has shown its capability to predict with relatively good agreements the pressure variations in the compartment and the flow rates at the inlet and outlet of the ventilation network. Table  6  shows the values of the pressure peaks between the experimental and simulation results. The percentage difference between the results ranges between 10 and 13% except for under-pressure peak for PRSID6a which was over 100%.
This kind of service makes high access demands on wireless networks, as every sensor reading that is collected from patients may be critical for that patient's safety and health. In addition, collected data need to be transmitted to the network periodically and in real time without delay or loss in order to prevent mortality. Furthermore, the life of the sensors must be taken into consideration, especially in smart hospital sensor networks. The authors proposed reducing the packet size of transmission links between sensor nodes to decrease the power used in the transmission of data  (Chen et al. , 2018). The authors proposed an intelligent diagnosis and treatment assistant program (nCapp) for the COVID-19 virus. nCapp is a software which provides questionnaires that are answered by potential patients  (Bai et al.
B. Service Completion Rate To validate our model, the equations has been introduced into square matrix and the code has been generated, therefore the service completion rate (SCR) is calculated as: ∑ 𝜇 ( ) (3) After solving the above linear system and introducing them into MATLAB which has been developed as per equation (  1 ), we can calculate and evaluate the SCR of the generated equation equilibrium as per equation (  3 ) and validates our mathematical model by Simulation model.
C. Validating Our Model with Mathematical Equations In order to validate our Simulink model, we proved our model mathematically using Markov Chain. Therefore, in order to make this test easier and simpler, we are going to assume that arrival rate for M2M is equal to 4 (M2M =4), an arrival rate for HCS equal to 4 (HCS =4) and an arrival for H2H equal to 4 (H2H =4) , with C=6 and their service rate equal to 1 (H2H= 1, M2M = 1 HCS = 1). Therefore, the results of the MATLAB code, as we mentioned earlier has been introduced into a matrix after the equation equilibrium has been generated using Markov Chain, is as follow: SCR_M2M = 100%, SCR_H2H= 50% and SCR_HCS= 0% Since, in MATLAB we can't set up priority, system has taken the procedure as First Input First Output (FIFO). Therefore, in Simulink we are going to give same parameters and give the highest priority for M2M, then H2H and finally HCS traffic and the result is shown in Figure  4.
IV. NETWORK SIMULATION FOR PERFORMANCE ANALYSIS The proposed system was evaluated using a simulation study. Different models were created using Markov chain methods to describe system variation. The OMNeT++ framework and MATLAB Simulink environment were used to create different simulation scenarios. For each scenario, different simulation runs were developed to test each possible network situation. Four simulation scenarios were created to represent four types of network settings: 1. Existing network; A hierarchical representation of simulation runs is shown in Figure  5.
RapGreen is a modular software package targeted at scientists handling large datasets for phylogenetic analysis. Its primary function is the graphical visualization and exploration of large trees. In addition, RapGreen offers a tree pattern search function to seek evolutionary scenarios among large collections of phylogenetic trees. Other functionalities include tree reconciliation with a given species tree: the detection of duplication or loss events during evolution and tree rooting. Last but not least, RapGreen features the ability to integrate heterogeneous data while visualizing and otherwise analyzing phylogenetic trees.
INTRODUCTION Phylogenetic analysis is a crucial step in many biology projects. The proper interpretation of a phylogenetic tree depends as much on the robustness of the algorithms involved in the analysis as on the sophistication of the user interface. The latter is critical since most end-users have noncomputer-science-related backgrounds. The forerunner to RapGreen, the RAP software (1), was developed to (i) automatically reconcile phylogenetic trees with the species tree, (ii) display phylogenetic trees and (iii) explore phylogenetic tree collections using FamFetch, the HOBACGEN interface  (2). Despite the effectiveness of the algorithms embedded in RAP, the learning curve to use FamFetch was steep; further, FamFetch was dedicated to exploring specific tree collections to which it was not possible to add user-created phylogenetic trees.
To offer a more comprehensive and user-friendlier service, we developed RapGreen. RapGreen is composed of three modules: (i) a Java package to compute analysis like tree reconciliation and rooting, and several statistics, (ii) a web interface (PHP, JS) to mine phylogenetic tree collections using tree patterns and (iii) a tree web visualization (PHP, JS) tool able to integrate heterogeneous data around tree topologies. This new implementation addresses the drawbacks of the previous RAP version as it is easy to install and comes with a web interface. RapGreen is dedicated to analyze, display and explore any tree or tree collection, as long as they are in the Newick format. In addition, great attention has been paid to the user experience in terms of performance and ease of use. First, the system responds well even with large trees (several thousand leaves): the improved response time provides users with expanded exploring capabilities.
InTreeGreat, an integrative tree visualization In the post-genomics era, datasets are becoming increasingly larger. Their analysis can be cumbersome and requires very efficient and easy-to-use interfaces so that users are able to drive the phylogenetic analysis of their own datasets in an autonomous fashion. InTreeGreat (Figure  1 , (3)) is a Javascript/PHP interface, compatible with every standard web browser without requiring any plugin nor add-on. Its functionalities include the display and exploration of any tree in Newick or Newick extended format (e. g. NHX), branch and leaf coloring, displaying of branch length and branch support (or any other branch labels), and the integration and visualization of heterogeneous data (e. g. annotations and expression profiles). As an example, https://github.
Tree pattern matching Tree pattern matching consists of the definition of an evolutionary scenario (called tree pattern) that is then searched for in a collection of phylogenetic trees (see Figure  1 ). It may be used, among other examples, to retrieve orthologous candidates in large comparative genomic datasets, and/or to construct queries to find recently duplicated genes in specific taxa or gene losses at a defined point of the species history. The pattern is defined as a subtree that is exhaustively mined for in the whole gene tree collection, and each of the pattern's node or branch can be constrained on its nature (duplication/speciation if inferred in trees by Rap-Green, or duplication/speciation/horizontal transfer if inferred in trees by another software), or by desired or undesired taxonomic levels.
A description of functionalities is available here: https://github. com/SouthGreenPlatform/ rap-green/wiki/Tree-pattern-matching-user-guide. The tree pattern search algorithm, initially available in the FamFetch software, has been implemented as (i) a Javascript/PHP user interface to edit patterns and explore results, and (ii) a Java daemon (part of the Java package described in the next section) that can be installed on any Java-compatible infrastructure to manage the computational part using a client/server architecture between for example a computing cluster and a webserver. The most important difference with the former FamFetch version is that any user-built tree collection can be added to the search space. Results may be visualized in the InTreeGreat interface or exported in Newick format to be used with other visualization clients or analysis tools.
Phylogenetic tree analyses A careful phylogenetic analysis requires finding the most reliable tree root and inferring events like gene duplications or losses which occurred during evolution. The RapGreen Java package meets these requirements as it allows the manipulation and comparison of phylogenetic trees. The main features are (i) the tree pattern matching daemon that handles the computational side of tree pattern matching on a computing cluster; (ii) the tree reconciliation module that allows the determination of gene duplications by comparison with a given corresponding species tree, and the prediction of paralogy and orthology relationships with several related statistics: https://github. com/SouthGreenPlatform/ rap-green/wiki/About-gene-pair-statistics Tree reconciliation also provides the ability to choose a root minimizing the number of predicted duplications and losses.
This file contains several columns identifying the family of the sequence, a mapping number with Figure  1. Top: the tree pattern edition interface, which allows to define an evolutionary scenario and search for it within a given phylogenetic tree collection. Bottom: the InTreeGreat interface shows an example of a phylogenetic tree of plant species, including the retrieved subtree (in dotted lines) matching the pattern shown on top (source: GreenPhylDB v5 (8,9)). Tree branches are colored following a color code defined in the species tree. The tree can be documented with heterogeneous related data, like functional annotations or gene expression profiles. Menus and related annotations are not displayed here to simplify the illustration. the pattern leaf, and the pattern number that can be greater than one if there is more than one matching pattern in the same tree.
This specific InTreeGreat interface is linked to a database dedicated to the nsLTP gene family for which manually curated annotations for each protein are provided (B). Users can explore Plant Ontology  (11)  or Gene Ontology (Gene Ontology Consortium 2021) annotations by a simple mouse-over the corresponding interactive texts. In this example, we choose to highlight several Plant Ontology keywords (leaf, seed, flower and root) with dedicated colors, as a colored board (B, to the right) aligned with tree leaves. Clades in the tree can also be collapsed in order to summarize the information contained in large trees (D). Here, nsLTP proteins have been colored and collapsed by types (3) using the last common ancestor to group all corresponding annotated sequences. This use case is reproducible using this website: https://github.
DISCUSSION Although the tree reconciliation algorithm was published in 2005, its functionalities (rooting, minimizing duplication and losses, collapsing incongruent and poorly supported branches, managing multifurcations) are comparable to recent methods like Treerecs  (5). Importantly, RapGreen is currently the only phylogenetic package offering a tree pattern search. The InTreeGreat phylogenetic tree viewer is one tool within an ecosystem of stand-alone and online interfaces that allow visualization of trees and correlated data. One example is the online tree viewer available on PLAZA  (6)  able to display the phylogenetic tree together with protein domains. Another example is Dendroscope  (7) : it allows full customization of the graphical rendering of a tree. Each of these examples addresses specific needs; for its part, InTree-Great highlights data correlations between phylogeny and heterogeneous annotations, and visualizations of the results from tree pattern matching.
ACKNOWLEDGEMENTS This work was technically supported by the  CIRAD-UMR AGAP HPC Data Center of the South Green Bioinformatics platform  (https://www. southgreen. fr/)and was financially supported by  French National Research Agency  ( ANR Genoplante ):  ANR-08-GENO118  and  ANR-10-BINF-03-04. We also acknowledge  Paulette Lieby  for her precious help in English writing.
DATA AVAILABILITY RapGreen is open-source and freely available on GitHub. The software consists of a Java package to analyze and compare phylogenetic trees, and two Javascript/PHP web interfaces: http://southgreenplatform. github. io/rap-green/ Graphical interfaces can be tested here: https: //github. com/SouthGreenPlatform/rap-green/wiki/ Examples-of-installed-services The whole documentation is available here: https:// github. com/SouthGreenPlatform/rap-green/wiki.
Predicting pharmacokinetic, pharmacodynamic and toxicity (ADMET) properties is even more difficult, as this involves the interactions of a candidate drug with the entire biological system, rather than a single protein target. Significant advances in computational methods can be gained through blinded benchmarking exercises, as evidenced by community progress in developing computational methods to predict protein structure from primary sequence. In 1993 when the "Critical Assessment of Techniques for Protein Structure Prediction" (CASP) exercise 1 (https://predictioncenter. org/) was launched, humans were often better at predicting protein structures than were computational methods. Leveraging high-quality and openly available experimental information in a well-organized database (the Worldwide Protein Data Bank [www.
2. Virtual libraries: CACHE will establish and host two virtual libraries; a make-on-demand library (REAL, ZINC20) and a library comprising compounds synthetically accessible by chemists in academia or industry (bespoke chemistry). 3. Participants predict chemical matter & CACHE experimentally tests compounds: Each participant will have opportunity to make two cycles of predictions per round. CACHE will procure and assay the predicted compounds. At this stage, structures of compounds will be made available to all participants, but screening data will be provided only to the specific participant and competition management, in order to serve as a starting point for an additional cycle of predictions. 4. Compounds, data placed in the public domain: Once the second cycle is complete, the data package, including all structures and screening data, as well as an assessment of each compound, will be made available to all, without restriction.
CACHE will publish in advance the success criteria (activity, selectivity, aqueous solubility, lipophilicity, novelty, etc. ) for each challenge, and how they will be combined into an overall multi-objective score  17, 18  , such as oralPhysChemScore (oPCS)  19. CACHE will provide the workflows and scripts that were used to calculate the different descriptors. In one possible scheme (TABLE  1 ), active compounds will not be ranked per se, but rather will be classified into 3 buckets (green, yellow, red) by summing up the traffic light values for each property (column). The scoring scheme used to assess a compound's physical and molecular properties will be similar across the challenges, but the values for potency and selectivity may change depending on the challenge. For example, compounds with weaker affinity might be acceptable for hard targets with no precedent, but higher affinities might be the aim if the challenge is to identify novel chemotypes for precedented targets.
As stated above, to facilitate comparison among methods, all predictions from all participants for a given target will be combined into a single small virtual library, and all participants will also be asked to rank these compounds. Top-scoring molecules will be further analyzed by a panel of experienced medicinal chemists in order to provide additional annotation to the molecules, including opinion on the suitability of the hits to serve as a starting point for potential drug discovery programs. Their reflections will not influence the score, but rather will help contextualize the output. SHARING THE CACHE OUTPUT CACHE will generate three main outputs for the community: screening data, chemical structures, and the performance of algorithms. CACHE's mandate is making available the screening data and the chemical structures to the community without intellectual property or other restrictions on use, and in a digitally readable format.
These data will also include the composition of the virtual libraries screened, all predicted small molecules including negative data, and all screening methods. As a condition of participation, CACHE will mandate that predictors disclose their approaches in sufficient detail to enable an expert in the area to understand the methodology and algorithms. These methodology descriptions will be double-blind peer-reviewed by other participants to ensure they contain sufficient information according to standards of the field. In the interest of encouraging participation from all sectors, participants will not be required to provide access to their code and can remain anonymous. However, CACHE will encourage participants to share their code and, as be responsible for making operational decisions, including target selection, participation rules, and use of funds.
ACKNOWLEDGEMENTS The  Structural Genomics Consortium  is a registered charity (no:  1097737 ) that receives funds from  Bayer AG, Boehringer Ingelheim ,  Bristol Myers Squibb ,  Genentech ,  Genome Canada  through  Ontario Genomics Institute  ,  Janssen ,  Merck KGaA  (aka EMD in  Canada and US) ,  Pfizer ,  Takeda  and the  Innovative Medicines Initiative 2 Joint Undertaking (JU)  under grant agreement No  875510. The JU receives support from the  European Union 's  Horizon 2020 research and innovation programme and EFPIA  and  Ontario Institute for Cancer Research, Royal Institution for the Advancement of Learning McGill University ,  Kungliga Tekniska Hoegskolan , Diamond Light Source Limited. This communication reflects the views of the authors and the JU is not liable for any use that may be made of the information contained herein.
Sampling the surveillance area OSM data is structured around four core entities: nodes, ways, relations and tags. Nodes represent points in the geodetic coordinate system while ways connect them to create polygonal shapes which can be combined with relations and tagged to represent complex pathways, buildings, open areas, and so on. For a more thorough description of this representation scheme, see  [37, 38]. The first step towards an OCP instance is to move into Cartesian space to simplify later computations. As we will be working on fairly localised areas (to the planet's scale), we propose to use a two-step conversion using a plane tangent to the Earth as our coordinate system (East-North-Up or ENU). The process first moves the data from geodetic to Earth-Centred, Earth-Fixed (ECEF) coordinates, and then to 1 m-based ENU using a reference point (φ 0 , λ 0 ) arbitrarily set to the centre of the surveillance area's bounding box.
The process is summarised in equations (3. 1)-  (3. 5) , where (φ, λ) are the geodetic coordinates of the point (node) being translated, a and b are the Earth's major and minor ellipsoidal axes, n its curvature radius at latitude φ and E = b a 2 its squared eccentricity. The second step involves using NASA's elevation data, as we have used a flat map for reference and have now moved into a 2D "plane" (z being near zero). The SRTM data provides us with an elevation value in meters for every 30×30 m square on Earth. For more precision, intermediary values are computed using a gradient between a node's SRTM cell and its neighbours. For every ground OSM entity, the sampling process can then begin. Line-based entities such as roads are sampled by hopping from node to node, dropping samples on the segments at a given ground frequency (f l g ) and across the width of the road (frequency f w g ).
r = R h 2P • tan F h 2 • (3. 6) Note that the first check does not take orientation into account. This is done by the second check, which computes the coordinates of the planes which delimit the candidate's frustum. This is achieved by first computing the plane which cuts the frustum in half vertically and rotating it around the vertical axis and the orientation vector to yield the sides of a 3D pyramid attached to the lens. All planes are represented in point-vector form with outward-facing normal vectors, meaning sample i must be at a "negative" distance of all of them to be visible. Note that pyramid-shaped frustums are rather common in the literature  [25]  although the computation method may vary. Finally, we propose the following approach to occlusion. We first use the OSM data to create a triangular mesh of the area which contains all possible sources of occlusion (buildings, walls, trees and so on).