dataesr/scientific-paragraphs-categorization huggingface dataset:
These static components are separate from the software that drives integration of the components, and all components and software are completely open source (Github, RRID:SCR_002630), allowing for collaborative specialization. A researcher interested in developing an experiment need only add a new paradigm to the experiments repository, and it will be available to all applications that use the Experiment Factory. A researcher primarily interested in further developing the software can do so without needing to touch static components. Currently the entire system is available for deployment by any researcher, either locally or using a cloud server; ultimately, we also hope to provide a hosted version as a service open to all researchers. An overview of the infrastructure is included in Figure  1.
Experiment Factory Software The controller of the Experiment Factory is the Experiment Factory Python software (https://github. com/expfactory/ expfactory-python) that provides functions for working with components, testing and validating experiments, and generating the final battery output based on the users specifications. For example, after installing this tool, a researcher can, in one line, specify experiments and an optional subject unique id, and a browser opens with the rendered battery. Behind this simple functionality, the software is obtaining experiment and battery files from Github, validating the experiments, and parsing configuration files to render the users selected experiments into the correct HTML syntax. The finished HTML syntax, along with experiment code and static files, is saved in a temporary directory, and a web server is opened to run the experiments as a sequence.
The tool is also useful to developers in that any function in the software can be used in an external application. By way of being a Python Flask application (see Table  3  for Term Glossary), running the executable also provides a RESTful API to serve experiment meta-data, which can be deployed in a local or cloud server environment. The application is easily installed with a package manager (https://pypi. python. org/pypi/expfactory), and developers can collaborate on this software to develop additional functions for use with the entire family of Experiment Factory components.
Experiment Factory Experiments and Surveys The Experiment Factory Experiments (https://github. com/ expfactory/expfactory-experiments) and Surveys (https:// github. com/expfactory/expfactory-surveys) are the core of the infrastructure: at the time of this publication there are more than 80 coded experiments and surveys available for deployment. Each experiment is a single folder in the expfactory-experiments Github repository that contains a data structure (config. json) file with a standard set of keyvalue relationships that provide meta-data on the experiment, and allow for its deployment. Table  1  provides an overview of fields, requirements, and examples, each of which is checked before an experiment is considered valid. For example, the definition of files necessary to run the experiment is essential for the expfactory-python tool to validate and deploy the experiments, and the definition of variables makes them available to the higher level applications.
The "template" field specifies the library (e. g. , JavaScript functions) that the experiment is coded in, such that the deployment template will be customized for the library. Although the initial release includes experiments coded using jsPsych, a Javascript library that simplifies experiment creation, the modular framework and specification of this template means that the infrastructure is ready to be extended to any web-based technology. This is extremely important to allow for development of experiments using the most up-to-date webbased technologies. Similar to experiments, each survey is a single folder in the expfactory-surveys Github repository. Surveys are fully specified by two files: a data structure (config. json) file identical to the one used for experiments and a TSV (survey.
Experiment Factory Battery The Experiment Factory Battery (https://github. com/expfactory/ expfactory-battery) is a simple skeleton into which Experiment Factory experiments can be deployed as a cohesive set of experiments, called a "battery. " The battery comes with a set of standard JavaScript and stylesheets common across the templates (e. g. , jsPsych), meaning that code that is consistently re-used across paradigms can be added to this repository. The design of the battery allows immediate deployment to multiple infrastructures, including Psiturk (locally or via a virtual machine), to a local machine to run on the fly, or a Django (RRID:SCR_012855) application that can be served locally or on a server (expfactory-docker). This Django application drives the (www. expfactory. org) interface.
Experiment Factory Docker One of the main goals of the Experiment Factory is to provide an ability to deploy experiments and collect data without any knowledge of programming, databases, or a command line. Under this requirement, download of a command line application is one step too many, and for this reason we developed a container-based application running at expfactory. org. The Experiment Factory Docker is a set of containers that serve a Django application that can be run locally or on a server to provide a login interface for labs to run experiments locally, or from the cloud. The application supports both http and https (secure connections). The application is also configured to deploy experiments to Amazon Mechanical Turk. The ease of deployment is thanks to Docker, an emerging container-based architecture that allows for development and deployment of applications in Linux containers (http://www.
docker. com). Docker Compose (http://docs. docker. com/compose) is a controller for running multi-container applications such as the Experiment Factory, which uses separate containers for a nginx web server (nginxproxy), a postgresql database (postgres), a Celery job manager worker to run time-intensive jobs (worker), a database for the jobs (redis), and the core application (expfactory), and protocol (uwsgi) for serving the application. An overview of these containers, along with the images on the Docker Hub, are provided in Table  2  and Figure 2 , and a summary of terms are provided in a glossary (Table  3 ). For a more secure deployment (e. g. , expfactory. org), it is recommended to link the application to a separate database with an encrypted connection over running the postgres container on the same server.
Experiment Factory VM Deployment of a battery to a virtual machine, whether locally or to the cloud, is made possible by the expfactory-vm repository. This repository contains Vagrantfiles that can be used with the Vagrant software (http://www. vagrantup. com) to run a local Virtual Machine, or one deployed via Amazon Web Services. The files can be used "as is" to deploy a battery with all experiments, or generated through the expfactorypython executable to allow a user to define a custom set of experiments.
Modular Framework for Open Science The choice to use Github, and to separate the Experiment Factory into its underlying components (experiments, battery, docker, documentation, and vm) was a specific choice to allow specialization and collaboration in development. Github offers version control, management of code, and collaboration between teams, along with features such as reporting issues, discussing changes, and managing documentation. All versions of code are archived, and multiple features can be worked on simultaneously by any researcher with an internet connection. Github also provides Continuous Integration, or automatic testing of code, both for the experiments and expfactory-python, discussed next.
Software Testing for the Experiment Factory An essential component of software development is continuous testing of all functions whenever changes are made to the software in the case that a change breaks an essential The container images are downloaded from the Docker hub. The container image "expfactory" corresponds to the expfactory-docker repository, and is built automatically from this source. For a more substantial deployment, the database can be external to the instance (e. g. , Amazon RDS) with an encrypted connection. FIGURE 2 | Docker containers: Expfactory-docker includes the main application container (expfactory), a database for storing application data (postgres), a job queue (redis) and worker (Celery) for running computationally intensive tasks, and a web server (nginx) to serve the application to the web.
The Cognitive Atlas The Cognitive Atlas  (Poldrack et al. , 2011)  is an ontology that represents current knowledge about cognitive science. Integration of standard terms to describe the tasks, and consequently, the cognitive concepts that are measured by them, allows for researchers to map all experiments into a common space, and use a common language to describe the behavior and phenomena that are being measured. This means that, for example, a researcher can quickly find experiments that are asserted to measure "risk seeking, " and such a feature is not only important for definition of these experiments, but also for meta-analysis and reproducible science. The expfactory. github. io experiment portal, along with documentation and testing of experiments, offers a view to browse experiments based on the cognitive concepts that are measured, as defined in the Cognitive Atlas.
Software Versioning A key challenge with any kind of deployment of this nature is software versioning. For example, the current experiments and battery are up to date with the most recent version of the JsPsych library, and upgrading this software would require developers to update current experiments. Thus, a standard in software development is to instill that care is taken to make available different versions of the software to support legacy implementations. Significant new releases of dependencies can be integrated when the developer community decides they are needed, and these same developers take responsibility for ensuring proper function of components. This is the rationale for Continuous Integration to run tests of the function of software, which has been implemented and provided by way of CircleCI (www.
Community Contributions A significant challenge with the release of any new technology is adoption by the community. While we cannot ensure that researchers will be motivated to contribute new experiments, we are optimistic that The Experiment Factory will be well utilized. We have built the Experiment Factory from the ground up for ease and accessibility for both users and developers. Additionally, several groups have started using our software, contributing experiments, or expressing interest prior to any efforts to publicize the work. A second point of concern is the quality of the implementations. We have developed the initial experiment set based on careful reading of published paradigms in the literature, along with significant feedback both from other groups of researchers and pilot studies.
The fields required in the standard config. jsonžforan Experiment Factory Experiment. The definition of files and a template are essential to validate the function of the experiments. The examples for each field above are limited and not in JSON, full config. jsonare available for inspection in the experiment folders (https://github. com/expfactory/expfactory-experiments). The Experiment Factory code is licensed under the MIT open source license, which is a highly permissive license that places few limits upon reuse. This ensures that the code will be usable by the greatest number of researchers, in both academia and industry. We welcome and encourage contributions for any of the Experiment Factory components from the larger community. Complete tutorials and further details are provided in our development documentation (http://expfactory.
Platforms Used Our goal is to quantify the overhead of linklayer security on a range of hardware platforms, and using different software strategies. Therefore, we choose to implement full link-layer security on platforms separated by a decade of hardware development: TelosB (in many ways obsolete but still very popular) and the OpenMote-CC2538 (a stateof-the-art platform). TelosB. The TelosB mote [34] (designed in 2004) features an MSP430 microcontroller (16-bit architecture, 8 MHz maximum CPU speed, 48 kB flash, 10 kB RAM), and a CC2420 radio chip. The CC2420 radio [35] chip provides hardware acceleration for both AES and CCM*. To execute an AES operation in hardware on the CC2420, one loads 16 bytes of cleartext into a buffer and a 16-byte key in a dedicated register, and issues a SAES command.
Software Implementation The "software" implementation strategy consists in implementing both AES and CCM* in software. We use a software AES implementation from Texas Instruments § , unmodified. This implementation is optimized for embedded devices, and features an execution time approximately 10 times shorter than a baseline AES implementation such as the one presented in  [38]. We implement CCM* from scratch. As indicated above, all software is available opensource. In the software implementation, we purposely do not use the hardware acceleration for AES/CCM* offered by both platforms in order to be able to (1) quantify how much shorter the timeslot can be when using hardware acceleration, and (2) have an idea of the performance of a platform which does not have hardware acceleration.
Memory Footprint The memory footprint is the amount of flash ¶ and RAM memory that needs to be reserved for link-layer security. Fig. 3  and 4  summarize the results. The security level does not impact the memory footprint, and is hence not presented. Since the TelosB and OpenMote-CC2538 have both different processor architectures and compilers, and since different toolchains are used to build their software, comparing the absolute value of the memory footprint is not appropriate. Focusing on a single platform, instead, the analysis of both ROM and RAM footprints is useful to compare different link-layer security implementations. On the TelosB mote, link-layer security occupies between 7% and 15% of the available flash memory, and 30-40% of RAM memory. On the OpenMote-CC2538, it occupies 1.
5-2. 5% of flash and 8% of RAM. As can be expected, the footprint of the software (resp. hardware) implementation is the largest (resp. lowest). In general, it is possible to observe that using hardware acceleration for link-layer security does not result in a drastically lower memory footprint. This is because (i) a software implementation of AES and CCM is relatively simple and (ii) even when hardware acceleration is used, software is still needed to drive the hardware. On the TelosB mote, the number of instructions needed to control AES and CCM algorithms in hardware is the same. Therefore, the hardware implementation registers a reduction of the ROM footprint with respect to the hybrid implementation because part of the software related to CCM operations (e. g. , instructions for CCM* vectors handling) is deleted.
Minimal Slot Length Figs. 5  and 6  present the resulting TsTxOffset, TsTxAckDelay and TsSlotDuration durations after tuning procedure, for the TelosB and OpenMote-CC2538 platforms, respectively. When the "software" implementation is used, TelosB and OpenMote-CC2538 executes security operations at different speeds of the CPU. For instance, TelosB runs at 8 MHz; OpenMote-CC2538 can run at a maximum speed of 32MHz. As a result, the software-based implementation of linklayer security in OpenMote-CC2538 will result in a timeslot duration reduced by a factor of 2 -3×. The hardware implementation strategy results in a shorter slotframe than the software implementation. Depending on the security level, a hardwarebased implementation of link-layer security will result in a timeslot duration reduced by 3 -4×.
The difference in timeslot duration between "software" and "hybrid" implementation strategies reflects the advantage of having AES execute in hardware. Similarly, the comparison between "hybrid" and "hardware" implementations reflects the advantage of a hardware-based CCM*. On slower platforms such as the TelosB (Fig. 5 ), the biggest gains are made by running AES in hardware. The most common security level in TSCH networks (including WirelessHART and 6TiSCH) is ENC-MIC-32, i. e. frames are encrypted and a 4byte MIC is used for authentication. We highlight that security level in Figs. 5  and 6. A full software implementation on an older platform such as the TelosB results in a minimal timeslot duration of 88 ms. Using hardware acceleration reduces the time duration by a factor of 4, down to 25 ms.
Energy consumption Figs. 7 and 8 reports the amount of energy consumed by TelosB and OpenMote-CC2538, respectively, for the three implementation strategies, and for all eight security levels. These results have been estimated (not experimentally measured) by taking into account the energy consumption related to each phase of the timeslot (TX, RX and CPU idle), as reported by reference datasheets. Link-layer security brings to an increment of the per-slot energy consumption because: (i) additional operations are executed for protecting the transmitted packet and decrypting the corresponding ACK and (ii) the radio chip is in charge of transmitting more data due to the ASH and the MIC. On the TelosB mote, hardware accelerators reduce energy consumption up to 27% (for the hybrid implementation) and 47% (for the hardware implementation).
We use two popular off-the-shelf platforms, separated by a decade of hardware development: the older but still popular TelosB and the state-ofthe-art OpenMote-CC2538. All implementations are done on the OpenWSN protocol stack, and available open-source under a BSD license. We show the benefits of hardware acceleration for two "atomic" link-layer security mechanisms: AES -a block cipher -and CCM* -a "wrapper" cryptographic primitive around AES. Overall, using hardware acceleration offers a 3 -4× reduction in timeslot duration. Using the latest generation hardware and full hardware acceleration allows a timeslot duration reduction of roughly 10×, from 88 ms on older hardware using a fully software implementation, down to 9 ms.
ACKNOWLEDGMENTS This work is supported by the  PON  project  RES NOVAE  funded by the  Italian MIUR  and by the  European Union (European Social Fund) , by the project  BONVOYAGE , which receives funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement  635867 , and by the project symbIoTe, which receives funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement  688156. The authors would like to acknowledge  Luigi Alfredo Grieco ,  Kris Pister ,  Bernard Tourancheau , and all the people actively working in the IETF 6TiSCH working group for their guidance and input.
Therefore, it is reasonable to assume that the cell potential drop is dictated by the cathode overpotential and as the latter is determined by inverting the overall current balance equation it also includes the mass transport and surface passivation effects, via our model's strong coupling of these phenomena. c Calculated based on the assumed inter-particular porosity and mesoporosity. Computational implementation. -The model was implemented in the in-house MS LIBER-T package coded in Matlab, i similar to our previously developed computational frameworks for fuel cells  50  and Li-O 2 batteries. 45 The coupled partial/ordinary differential equations were solved using the finite volume method (cf. Appendix). All simulations were carried out on a PC equipped with 4 3. 30 GHz processors Intel core i5-4590 with a typical simulation time of 1.
Acknowledgments The authors deeply acknowledge the  European Union 's  FP7 and Horizon 2020 research and innovation programmes  for the funding support through the  EUROLIS  project under grant agreement No. 314515  and the  HELIS  project under grant agreement No. 666221. Dr. Charles Delacourt  and  Garima Shukla  at LRCS are gratefully acknowledged for fruitful discussions.
We propose "Stereohaptics", a framework to create, record, modify, and playback rich and dynamic haptic media using audio based tools. These tools are well established, mainstream and familiar to a large population in entertainment, design, academic, and the DIY communities, and already available for sound synthesis, recording, and playback. We tune these audio-based tools to create haptic media on user's bodies, distribute it to multiple slave units, and share it over the Internet. Applicable to the framework, we introduce a toolkit, the Stereohaptics toolkit, which uses off-the-shelf speaker technologies (electromagnetics, piezoelectric, electrostatic) and audio software tools to generate and embed haptic media in a variety of multisensory settings. This way, designers, artists, students and other professionals who are already familiar with sound production processes can utilize their skills to contribute towards designing haptics experiences.
Learning goals Participants will first learn haptics by experience: they will feel how it affects their sensations, rather than having to guess or imagine the effects of such stimuli by watching video tutorials, where haptics is transduced by audio or visual workarounds and artifacts. After the studio workshop, attendees will have gained experience on how to design and prototype haptic media using off-the-shelf hardware and software. More about the toolkit, course material and up to date information on Stereohaptics, please visit: www. stereohaptics. com.
We present the prototype of a regional climate system model based on the COSMO-CLM regional climate model coupled with several model components, analyze the performance of the couplings and present a strategy to find an optimum configuration with respect to computational costs and time to solution. The OASIS3-MCT coupler is used to couple COSMO-CLM with two land surface models (CLM and VEG3D), a regional ocean model for the Mediterranean Sea (NEMO-MED12), two ocean models for the North and Baltic Sea (NEMO-NORDIC and TRIMNP+CICE) and the atmospheric component of an earth system model (MPI-ESM). We present a unified OASIS3-MCT interface which handles all couplings in a similar way, minimizes the model source code modifications and describes the physics and numerics of the couplings. Furthermore, we discuss solutions for specific regional coupling problems like handling of different domains, multiple usage of MCT interpolation library and efficient exchange of 3D fields.
95 In this study we present a detailed analysis of coupled COSMO-CLM performances on the IBM POWER6 machine Blizzard located at DKRZ, Hamburg. We calculate the speed and costs of the individual model components and of the coupler itself and identify the causes of reduced speed or increased costs for each coupling and reasonable processor configurations. We suggest an optimum configuration for different couplings considering costs and speed of the simulation and discuss the 100 current and potential performances of the coupled systems. Particularities of the performance of a coupled RCM are highlighted together with the potential of the new coupling software OASIS3-MCT. We suggest a procedure of optimization of an RCSM, which can be generalized. However, we will show that some relevant optimizations are possible only due to features available with the OASIS3-MCT coupler.
200 The initial conditions for potential temperature and salinity are taken from the Medatlas  (MEDAR-Group, 2002). The fresh-water inflow from rivers is prescribed by a climatology taken from the RivDis database  (Vörösmarty et al. , 1996)  with seasonal variations calibrated for each river by  Beuvier et al. (2010)  based on  Ludwig et al. (2009). In this context, the Black Sea is considered as a river for which climatological monthly values are calculated from a dataset of  Stanev and Peneva (2002).