dataesr/scientific-paragraphs-categorization huggingface dataset:
It is very tempting to speculate that both types of environments (CF or VAP (ventilator-associated pneumonia) in ICU) are selective pressure conditions that result in the changes observed in these P. aeruginosa strains. The examination of these genomes at the different levels (contigs, locus, gene) questions the reliability of genotyping methods used to classify strains in a clonal lineage. The availability of genome sequencing facilities would probably help in redefining the clonal notion. From our dataset, we would like to go further in depth into the relationship between genetic or genomic events that we observed and phenotypic traits of our strains. This is illustrated for example for KK strains by the Rsm-independent T6SS regulation in KK14 and KK72 strains which can probably be attributed to AlgU in KK14 or to an unknown mechanism in KK72; the role of KK_8 region in antifungal defense in CF airways; the absence of the KK_2 region in CF strains, a region described as essential for increased ability to persist in a chronic pulmonary animal model; the contribution of K218R in LasR in KK72 strain to the absence of proteolytic activity of this strain and the role of G235V mutation in ExsD in deregulated T3SS in KK72 strain or of S232R mutation in ExsA in T3SS defective phenotype of KK14.
CPN was chosen because of the substantial set of tools available and its expressive power in the APEX context. The integration of physical components in the physical layer, for example smart phones, allows exploration of how the evolving design would work. In summary APEX supports: • the design of ubicomp environments and the exploration of design alternatives, with a particular emphasis on how users will experience these designs; • analysis either by animation (similar to program execution) or by more formal analysis of behaviour; • multi-layered development, in which analysis can be combined with evaluation of virtual simulations and actual implementations of components of the proposed design; • the whole prototyping cycle (design, experience, test and analysis); • multiple users with collaborative features (e.
The behaviour of the device is modelled using statecharts. The statecharts can be animated for user testing and behaviour can also be analysed. Activity Studio, in contrast, is a tool for prototyping and in-situ testing of context aware software applications. It supports the testing of low-cost prototypes in experimentally relevant environments over extended periods. It is possible to explore prototypes over time involving several users, either using real sensors or gathering data from users. Topiary, on the other hand, allows users to explore context aware prototypes using a storyboarding approach. Several other tools use Wizard of Oz techniques to avoid the need for physical sensors and actual physical spaces. These evaluation and prototyping techniques are valuable but they do not address the interplay between device and environment in situ  [6].
This interplay is crucial to understanding how the system works as a whole. Displays, devices and sensors form an integrated whole that, together with the physical characteristics of the environment, contribute to the texture of the resulting system. UbiWise and UbiREAL simulate ubiquitous systems using virtual environments. The simulation acts as a development test bed for the devices and software. The APEX framework, in contrast, supports the design of the environment itself, with a particular emphasis on how users will experience it.
Simulation using virtual environments Virtual environments enable the exploration of a proposed ubicomp environment. It does this by means of navigation and interaction within a 3D simulation. These simulations can immerse users. They make it possible to achieve user experience closer to that of the proposed target system. The environment must be sufficiently rich and textured to address usability requirements that depend on the target environment. The simulated environment must produce an impression of what it would be like to use systems once deployed. 3DSim  [10] , UbiWorld  [11] , the work of O'Neill and others  [13] [24]  and VARU  [14]  all develop simulations of actual environments. 3DSim and UbiWorld use programming languages to build prototypes. The advantage of an approach such as APEX is that modelling, and its associated analysis, can be combined with simulation.
Vanacken and others  [25] , for example, use such techniques to model multimodal interaction techniques. O'Neill and others combine 3D simulation with models to identify occurrences of unwanted system behaviours. APEX, in contrast, aims to provide exhaustive analysis support. Other approaches, for example VARU, provide user experience without supporting analysis. VARU can be used to develop a tangible space, combining virtual and augmented reality. A rendering game engine built on OpenSceneGraph 3  is used to achieve this. APEX is unique in supporting analysis of ubicomp environments, combining simulation (similar to program execution) and formal analysis (State Space analysis). It also allows evaluations of hybrids of virtual and physical elements.
g. stereoscopic 3D visualisation) or specific hardware configurations (e. g. multiple display usage). Viewers provide limited support for virtual object creation compared with game engines. However, most OpenSimulator viewers do allow the creation and editing of objects and textures. A more detailed explanation of how object editing can be achieved is presented in Section 5. They also enable the description of behaviours using Open-Simulator scripts (written in Linden Scripting Language). Environments are generated as OAR (Opensim ARchive files) reusable packages. Viewers such as the SecondLife viewer and Cool VL Viewer 10  provide further support for polygon meshes using the widely available ". collada" format. These polygon meshes can be downloaded from online repositories. Hence thousands of developed objects can be used off-the-shelf including buildings, furniture, everyday household objects, cars and planes.
Behavioural Component The behaviour model coordinates the behaviours of dynamic objects and sensors that compose the environment. The model specifies flows of information and represents the generic structure of the ubiquitous environment. Behaviours can be selected from a collection of predefined modules from the APEX library. These can be combined with tailor-made modules as necessary. A generic CPN base model is provided to aid the development of the model of the virtual ubiquitous computing environment. This base model creates a generic CPN style that is relevant to the modelling of virtual environments. It contains modules that: • initialise the simulation, and establish the connection between the CPN model, as represented by CPN Tools, and OpenSimulator; • receive data (for example sensors' data) from OpenSimulator and use it to update appropriate tokens; • describe the behaviour of each device in the system.
Each dynamic object/sensor in the simulation layer contains a unique identifier, used to represent it in the modelling layer. The predefined behaviour of sensors can be configured using the viewer (detailed description in Section 5). A script is used to define dynamic objects behaviour. Data is exchanged between the layers, as strings that carry the identification of the relevant object, as well as the event that is being communicated. This information enables the update of the receiver component to reflect the changes in the sender component. Information exchange occurs in both directions. The scripts linked to the dynamic objects are designed to both react to changes in the environment, and to effect changes in the object, to assure consistency with the state of the CPN model.
Additionally, the Alert Parent transition moves the child's token into the Child parent Alerted place. During this transition carers are alerted using the sendUserInfo function. This function, with the respective user and message as parameters, enables the communication/execution component to trigger a script in the relevant objects(s) in the virtual environment. When the child is no longer close to an asthma trigger, indicated by not(userNearPresenceSensor(ps,u)), the token is removed from the Child parents Alerted place. The earlier warning is then removed from the relevant carers using updateUserValues(REM,u1,ACK). The module described in Figure  12  sends an alert when the environment reaches one of its alert states (e. g. air polluted). The environmental sensor (E sensor) models environmental air quality as an integer.
Patterns A pattern captures a known solution to a given recurring problem. The use of verification patterns has already been established in other fields of software engineering  [31]. Indeed, a specific set of patterns, inspired by usability heuristics  [26] , has already been selected for use in analysing interactive devices  [32]. Applying patterns, in the context of APEX, raises fresh challenges. Property templates, developed for other purposes, may not be relevant to ubiquitous systems. If the template is to be of value then developers should be able to understand how properties, instantiated from the template, can be checked using CPN tools. Property instances must be translated into a form that is meaningful for analysis. Guidance should be provided about how the CPN Tools algorithms are created.
The APEXi tool, a component of APEX (see Figure  22 ) facilitates the selection of values for relevant tokens to make up the scenario. This tool reduces configuration effort prior to analysis. The APEXi tool allows automatic insertion of values to construct the deterministic model. The model can then be evaluated. The selection of adequate values for analysis is an important step that the analyst must consider carefully. The APEXi tool reuses part of the APEX communication/execution component responsible for exchanging information with CPN models. Modules that receive values, sent by the tool, also use functions of the Comms/CPN library  [34]  that connects CPN Tools with external processes. Figure  23  illustrates how APEXi is connected to the remaining components.
ACKNOWLEDGMENTS Work carried out in the context of the  APEX  project, funded by  ERDF -European Regional Development Fund  -through the  COMPETE Programme  (operational programme for competitiveness) and by  National Funds  through the  FCT -Fundacão para a Ciência e a Tecnologia (Portuguese Foundation for Science and Technology ) -within project reference  FCOMP-01-0124-FEDER-015095. José Luís Silva  was supported by  Fundacão para a Ciência e Tecnologia (FCT, Portugal)  through PhD Grant  SFRH/BD/41179/2007. Thanks to GaTech members for collaboration, especially  Gregory Abowd  for hosting and  Mario Romero  for having provided the Aware Home 3D model.
The effort involved in making simultaneous comparisons to large numbers of experimental distributions, and to keep those up to date, previously meant that this kind of exercise was restricted to a small set of people, mostly Monte Carlo authors and dedicated experimental tuning groups. The aim with the mcplots. cern. ch (MCPLOTS) web site is to provide a simple browsable repository of such comparisons so that anyone can quickly get an idea of how well a particular model describes various data sets 2. Simultaneously, we also aim to make all generated data, parameter cards, source codes, experimental references, etc, freely and directly available in as useful forms as possible, for anyone who wishes to reproduce, re-plot, or otherwise make use of the results and tools that we have developed.
It currently relies on the following basic prerequisites, • The HEPDATA database  [15]  of experimental results. • The RIVET Monte Carlo analysis tool  [16]  which contains a large code library for comparing the output of MC generators to distributions from HEPDATA. RIVET in turn relies on the HEPMC universal event-record format  [17] , on the FASTJET package for jet clustering  [18, 19] , and on the LHAPDF library for parton densities  [20, 21]. • Monte Carlo event generators. Currently implemented generators include ALPGEN  [22] , EPOS  [23]  HERWIG++  [24] , PHOJET  [25] , PYTHIA 6  [26] , PYTHIA 8  [27] , SHERPA  [28] , and VINCIA  [29]. Some of these in turn use the Les Houches Event File (LHEF) format  [30, 31]  to pass partonlevel information back and forth. • The LHC@HOME 2. 0 framework for volunteer cloud computing  [32] [33] [34] [35].
LHC@HOME 2. 0 in turn relies on CERNVM  [36, 37]  (a Virtual-Machine computing environment based on Scientific Linux), on the COPILOT job submission system  [37, 38] , and on the BOINC middleware for volunteer computing  [39, 40]. The basic procedure to include a new measurement on MCPLOTS is, first, to provide the relevant experimental data points to HEPDATA, second to provide a RIVET routine for the corresponding analysis, and lastly to provide a very small additional amount of information to MCPLOTS, essentially specifying the placement of the observable in the MCPLOTS menus and summarizing the cuts applied in a LaTeX string, as e. g. exemplified by the already existing analyses on the site. This is described in more detail in section 4. To update MCPLOTS with a new version of an existing generator, the first step is to check whether it is already available in the standard CERN Generator Services (GENSER) repository  [41] , and if not announce the new version to the GENSER team.
The MCPLOTS steering scripts should then be updated to run jobs for the new version, as described in section 5. To add a new generator to MCPLOTS, the first step is to check that it can run within CERNVM. CERNVM provides a standardized Scientific-Linux environment that should be appropriate for most high-energy physics (HEP) applications, including several commonly used auxiliary packages such as the GNU Scientific Library (GSL), the C++ BOOST libraries, and many others. A standalone version of CERNVM can be downloaded from  [36]  for testing purposes. To the extent that dependencies require additional packages to be installed, these should be communicated to the MCPLOTS and CERNVM development teams. The code should then be provided to the GENSER team for inclusion in the standard CERN generator repository.
The complete procedure is described in more detail in section 6. The main benefit of using CERNVM is that this has enabled MCPLOTS to draw on significant computing resources made available by volunteers, via the BOINC and LHC@HOME 2. 0 projects. Through the intermediary of CERNVM, generator authors can concentrate on developing code that is compatible with the Scientific Linux operating system, a fairly standard environment in our field. This code can then be run on essentially any user platform by encapsulating it within CERNVM and distributing it via the BOINC middleware. (The latter also enabled us to access a large existing BOINC volunteer-computing community. ) The resulting "TEST4THEORY" project  [35, 42]  was the first application developed for the LHC@HOME 2. 0 framework, see  [32, 35] , and it represents the world's first virtualization-based volunteer cloud.
Histogram and Data Format On MCPLOTS, a common numerical file format is used for both experimental data and MC generator results. The format is based on RIVET's "flat format" for histograms  4  with modifications to store additional information which is necessary for histograms merging. The format itself is a plain text ASCII file which has the advantage of being both human and machine readable and writable. Each file is divided into sections with the format # BEGIN type param1=value1 param2=value2 bin1 contents bin2 contents. # END type The following types of sections have been defined: • PLOT -description of plot parameters, for example axis labels or scale type (linear/logarithmic). • HISTOGRAM -plot data (bin contents), used by the plotting tool to produce the plots. • HISTOSTATS, PROFILESTATS -additional histogram (or profile) statistical data, used to merge histograms from different subruns.
Directory Structure MCPLOTS is structured as a directory tree, with separate subdirectories for different purposes (WWW content, MC production scripts, documentation,. ). In the following, we assume that this directory structure has been installed in a global home directory, which we call $HOME = /home/mcplots # MCPLOTS home directory The location /home/mcplots corresponds to the current implementation on the mcplots. cern. ch server. There are five important subdirectories in the home directory: The $DOC directory contains documentation and help content that extends and updates this writeup and should be consulted by future developers. The $PLOTTER directory contains the C++ source code and Makefile for the small plotting utility used to generate the plots on the mcplots web pages. It only depends on ROOT and takes histogram/data files in the format used on the mcplots site as input.
It can be copied and/or modified for personal use, if desired, as e. g. , in  [46]. Any changes to the code located in the $PLOTTER directory itself, on the MCPLOTS server, will be reflected in the plots appearing on the site, after the plotter has been recompiled and the browser cache is refreshed. The $POOL directory contains the MC data sets generated by the Test4Theory BOINC cluster. The $RELEASE directory contains MC data sets generated manually and combinations of data sets (so-called releases). For example typically the data visible on the public site mcplots. cern. ch is a combination of BOINC data sets (which have large statistics) and a number of manually generated data sets applied on top, for distributions that cannot be run on the BOINC infrastructure, or to add new versions of generators which were not yet available at the time of generation of the BOINC data set.
The following is an excerpt from rivet-histograms. map which concerns a CDF analysis of differential jet shapes  [48] , in which two different generator-level p⊥ cuts are invoked to ensure adequate population of a much larger number of jet p ⊥ bins (here ranging from 37 to 112 GeV): After changing rivet-histograms. map, it is necessary to run the available MC generators in order to produce the new histograms, and then update the MCPLOTS database in order to display the results. We will describe how to include new generator tunes, run the generators and update the database in section 5. For now, we will assume that the results of MC runs are already available, and continue by discussing how to translate the language of rivet-histograms. map into the labels that are displayed on the mcplots.
Updating the MCPLOTS site The previous section described how to add new processes and new analyses to the MCPLOTS framework, and how to modify their organization and labelling on the web site. After a new analysis has been implemented, or when updating the site with new tunes, generators, or RIVET versions, the next step is to update the database with new MC generator runs. In this section, we will briefly discuss how to update existing MC generators by including new generator versions and tunes. (How to implement a completely new event generator is described separately, in section 6). This is followed by a description of how to manually produce MC results, and how to update the database of the development page mcplots-dev. cern. ch (which is publicly visible but updates can only be done by MCPLOTS authors), which serves as a pre-release testing server for MCPLOTS.
Updating the MCPLOTS database To display the results of new MC runs, it is necessary to update the database with the new histograms. MCPLOTS has both a development area (with plots shown on mcplots-dev. cern. ch) and an official release area (with plots shown on mcplots. cern. ch). The development pages are updated as follows. Let us assume that we have produced new EPOS results  9  , and these new results are stored in ˜/myResults. Then, log into mcplots-dev by $ ssh myUserName@lxplus. cern. ch $ ssh mcplots-dev Then copy the new information and to the directory $HOME/release on this machine. It is encouraged to include the mcplots revision number (e. g. 2000) into the directory name. For example $ mkdir $HOME/release/2000. epos $ cd $HOME/release/2000. epos $ cp ˜/myResults/info. txt. $ find ˜/myResults/ *.
tgz | xargs -t -L 1 tar zxf Now, the new results are stored in the directory $HOME/release/2000. epos/dat. To display these (and only these) new histograms on mcplots-dev. cern. ch, re-point and update the database by $ cd $WWW $ ln -sf $HOME/release/2000. epos/dat $ $SCRIPTS/updatedb. sh These actions update the database, and the new plots will be visible on the mcplots-dev. cern. ch pages. The last step is to update the HTML file $WWW/news. html including any relevant new information similarly to what has been done for previous releases. Updating the development web pages is a fairly common task while working on mcplots. Updating the official web pages (mcplots. cern. ch) should of course only be done with great caution. For completeness, we here briefly describe the procedure. The contents of a specific revision of the development web page can be transferred to the official site by executing a simple script.
Implementing a new event generator In this section, we provide guidelines for adding a new generator to the MCPLOTS framework. An up-to-date set of instructions is maintained in the MCPLOTS documentation files  10. The guidelines are accompanied by concrete examples and comments, drawn from the experience obtained by the implementation of the ALPGEN generator in the framework. When adding a new generator, one should note that the MCPLOTS framework relies on the libraries with the code needed for the event generation being available in the format and with configurations as used by the GENSER project. The generator libraries are accessed from the CERN-based AFS Figure  11:  A schematic representation of the path from the Event Generation to the Physical Distributions produced within the MCPLOTS framework.
The sequential steps are labelled 1 -4. Their technical implementation in the MCPLOTS framework is described in section 6. location accordingly 11  : /afs/cern. ch/sw/lcg/external/MCGenerators * or from the CVMFS replica which is used by CernVM virtual machines running in the BOINC cluster: /cvmfs/sft. cern. ch/lcg/external/MCGenerators * Runs of MCPLOTS scripts with a generator not supported by GENSER is currently not implemented. For generator not supported by GENSER user can only run the MCPLOTS scripts by checking them out, making private modifications and private generation runs. We explain the updates needed for implementation of the new generator supported by GENSER with the help of the figure figure  11. The figure shows the schematic representation of the path from the Event Generation to the Physical Distributions produced within the MCPLOTS framework.
sh and runRivet. sh. As discussed in section 4. 3, the physics process-configuration files for each event generator should reside in the directory $SCRIPTS/mcprod/configuration. (See also the discussion of "tune groups" in section 4. 4. 1. ) The location of the $SCRIPTS directory was defined in section 3. 2. Additional generator-specific files may be needed. Examples are linking against the generator libraries of the GENSER project, parsing the generator configuration scripts, or providing generator-level event filters, used by some of the analyses in order to enable efficient filling of the histograms. (Some concrete examples are given below. ) Such generator-specific files should be put into a dedicated directory $SCRIPTS/mcprod/(generator). Using ALPGEN as an example, the ALPGEN-specific files reside in the directory $SCRIPTS/mcprod/alpgen.