dataesr/scientific-paragraphs-categorization huggingface dataset:
Hardware The hardware can be a standard computer with a parallel port (internal or external, PCI card recommended in this case), to be used with the computer code version available on GitHub (https://github. com/PyOpenProto/PyOpenProto/ blob/e-neuro2021/pyaudio_protocol/core_gui. py). A standardized, portable, and accessible system using a Raspberry Pi is also proposed. The Raspberry Pi3 B1 board was used, which natively has a low sound quality and a variable trigger-tone latency, as previously described by  Kuziek et al. (2017). To overcome those limitations, the HiFiBerry DAC1 pro [digital analog converter (DAC)] was used as an additional sound card. It has a dedicated 192 kHz/24 bit high-quality Burr Brown DAC coupled to an ultra-low-noise voltage regulator for best sound quality and a dual-domain clock circuit to produce low-jitter performance.
[THD1N (total harmonic distortion plus noise): À92 dB, signal-to-noise ratio = 112 dB]. This card, with its low-jitter clock generator and optimal audio performances, ensures access to most of the Raspberry Pi GPIO that could be used for other purposes. The Raspberry Pi3 itself uses the Raspbian OS (https:// www. raspberrypi. org/software/operating-systems/). This open source system is installed on a classic secure digital card and is easily replicable. A small number of specific configurations was adapted. Precisely, we included the HiFiBerry audio output, activated SSH (secure shell protocol for cryptographic networking) and automatic logging. In addition, we used an ARM I2C (microprocessor interintegrated circuit) interface and allowed for an automatic run of PyAudioProtocol starting script when the system switches on.
Comparison with other systems To compare these measures with other systems, it is very important to keep in mind that sound performances depend on the wide variety of materials and configurations. First, performance is based on the capacity of the used sound card (e. g. , sound fidelity, low jitter performances) and how the sound card interacts with the computer. Indeed, the OS (Windows, Mac, Linux), the selected driver, the software (e. g. , Presentation, MATLAB, Opensesame, Psychopy) used and the version used for each one will influence sound control performance. Moreover, hardware and software interactions are based on an API [application programming interface (also called the "back-end")] which defines how to manipulate   sound data and pilot the sound card. There is a wide range of APIs available within each OS (Windows: MME, DirectSound, WASAPI, ASIO; Linux: ALSA, ALSIHPI, JACK; Mac OS X: Core Audio, JACK).
Results Figure  6  shows the latency and jitter test results for the 12 tested configurations. Average latencies range from 0. 42 to 60 ms, and average jitter ranges between 0. 01 and 8. 24 ms in our tested setups. Different solutions showed good latency performance, but the results were not consistent in the case of OS or software version changes. The best tested setups were the Opensesame software running the pyaudioprotocol codes on Linux 20. 04 with an external sound card on a recent computer (jitter, 0. 42 ms; latency, 0. 03 ms) and the stimulation box itself (jitter, 1. 4 ms; latency, 0. 03 ms). Another good scoring setup was shown to be the Presentation software with exclusive mode on Windows 10 in a recent computer (latency, 1. 56 ms; jitter, 0. 011 ms). The same testing protocol was used with longer and variable duration audio stimuli (names and sentences) with very similar results.
Creation of your own box All software, as well as a user manual, can be found on GitHub (https://github. com/PyOpenProto/PyOpenProto) under a BSD (Berkeley Software Distribution) license (CNRS CeCill B). A detailed description of the fabrication of a stimulation box can be found on Hackaday (https://hackaday. io/ project/181042-stimbox), containing a step by step guide to create the box. A ready-to-use Raspbian operating secure digital card system is available on OSF (https://osf. io/ 3muqk/). For those who do not wish to create one themselves, you can contact us so that we may redirect you to our collaborators. Furthermore, a 3D version of the stimulation box container for 3D printing is available on Thingiverse (https://www. thingiverse. com/thing:4592271) or as the Extended Data 2.
Discussion This article describes a simple, inexpensive, and open source stimulation system for EEG auditory experiments. It combines hardware such as a Raspberry Pi3 and a HiFiBerry audio card with software for stimulus presentation. The software can be used together with the hardware or as a stand-alone software on a common computer. Both auditory stimulation and trigger timing are optimized when the hardware and software stimulation systems are combined. All information about the Python library, the The stimulation box combined with software showed short latency and limited jitters, compared with the 11 other methods. In fact, the results of the stimulation box are among the best for a significantly lower cost. Even if the tests performed were not entirely exhaustive and included only a selection of known configurations used in our research network, they underline the huge variability of possible configuration and associated timing performances.
Phase 2: Situation-Based Risk Assessment Based on the situations defined in the previous phase, all the risk assessment tasks defined in the MITIGATE methodology such as asset modeling, threat, vulnerability and impact assessment are properly adjusted to each situation, to output a fine-grained, situational risk assessment. As defined in  [5, 6] , MITIGATE is a maritime specific risk assessment methodology, built in compliance with international security and risk management standards such as ISO 27001 [28], ISO 27005 [29] and NIST SP800-30  [30]. In  In addition, new relationships are created by utilizing common characteristics that are utilized in the above datasets. For example, going through the CAPEC catalog, we identified attributes related with threat agent profiles, such as the resources, the skills and (iii) the motivation (consequences for CAPEC).
Situational Vulnerability Assessment Again, as in threat assessment, while in MITIGATE, vulnerability assessment is situation-agnostic, in the proposed methodology, the vulnerabilities are automatically assessed according to each situation, as described below. Step 1-Vulnerability Identification This step focuses on the identification and assessment of confirmed vulnerabilities of assets, which can be exploited and lead to successful attacks. Our methodology utilizes the National Vulnerability Database (NVD)  [32] , which contains over 160. 000 detailed entries in a structured format, along with other reliable online sources to identify the characteristics of vulnerabilities. Vulnerabilities are product-based, which means that they are targeted towards a specific asset, be it hardware, operating systems, or applications; such components are listed in the Common Platform Enumeration (CPE) catalog, while their connections to Common Vulnerabilities and Exposures (CVE) entries reside in NVD.
Therefore, the list of individual vulnerabilities of the assets from the asset modeling step can be created from existing connections between the two catalogs. Step 2-Vulnerability Scoring Once the vulnerabilities are identified, then it is necessary to determine its exploitability metrics. Our methodology utilizes the CVEs provided by the National Vulnerability Database (NVD), which are recorded along with part of their CVSS v3. 1 and v2. 0 attributes. The MITIGATE tool utilizes the CVSS v2 exploitability metrics to define a vulnerability level as illustrated in Table  1. By combining the available exploitability characteristics for each recorded vulnerability (i. e. , CVE) a single value is produced to express the vulnerability level based on the CVSS score, as defined in  [6]. Step 3-Vulnerability Score Assessment Changes in the asset model along with its interconnections from one situation to another may affect the vulnerability level of the assets.
Case 1. Situational Risks during Cargo Loading/Unloading (S1 & S2): Attacking Admin Applications Here, we examine attack scenarios involving systems that are accessible by admins while the vessel is on the port for loading/unloading. The Admin FTP client is vulnerable to CVE-2008-3734, which allows remote FTP servers to cause a denial of service (application crash) or possibly execute arbitrary code via format string specifiers in a connection greeting (response). Through this vulnerability the configuration of the FTP server can be changed to accept executable files. Furthermore, Adobe Reader has CVE-2011-2440, which allows attackers to execute arbitrary code via unspecified vectors. Finally, the Admin Operating System's font library has CVE-2016-0145, which allows attackers to execute arbitrary code via a crafted embedded font.
An attacker combining and utilizing these vulnerabilities can get initial access to the admin system and then elevate their privileges. In the scenario we built, a Corrupt Port Official could initially craft two malicious manifests and upload them to the FTP Manifest Database. Throughout the Cargo loading the ship is connected to the port's network for updates; in that time frame the admin ftp client's port is open to the adjacent network, and therefore vulnerable to arbitrary code execution. Utilizing this vulnerability, a Mobster group that cooperates with the Corrupt Port Official, notifies their Internal Spy to change the ftp configuration through its vulnerability so the ftp client accepts the malicious file. This is a viable attack in the context of the Cargo Loading and Unloading situations.
Situation-Based Policy Deployment in the Maritime Cargo Transfer Service Finally, situations and situational security controls must be refined in order to configure the situation manager and the command center of the dynSMAUG deployment architecture. The situation manager was implemented using Esper, a CEP engine developed by EsperTech (https://www. espertech. com/esper (accessed on 15 November 2021)) under an open source license. Esper includes a language called Event Processing Language (EPL) which is a SQL-standard language with temporal operators extensions (e. g. , windows definition and interaction, timed-data arithmetic definition, etc. ) Figure  6  depicts the EPL rule that specifies the beginning of situation S8 'the vessel is at sea in a dangerous area nearby an unknown vessel'. We hypothesize that the vessel can provide three sensors: a GPS, a proximity sensor that can provide information about nearby vessels, and a vessel workflow sensor that states the current step in the cargo transfer process.
Lines 2 and 3 take the GPS and proximity events in a 10 s time frame while lines 4 and 5 retrieve the last mission state and active situation events. Similarly to SQL, the where clause allows filtering the request to specific conditions. Here, the position shall be in an unsafe area (line 7), there is a nearby unknown vessel (lines 8 and 9) and the vessel is transferring the cargo (i. e. , at sea line 10). When the situation manager detects that situation S8 is starting, it generates a situation event informing that the current situation ends and S8 starts. The command center takes as input situation-based security policies in XACML v3 (eXtensible Access Control Markup Language [38]) or ALFA (Abbreviated Language for Authorization  [39] ) format. Figure  7  is the ALFA rule that refines the situational security control relating to applying strong password policy in situation S8.
Situation-Based Policy Deployment in the Maritime Cargo Transfer Service Finally, situations and situational security controls must be refined in order to configure the situation manager and the command center of the dynSMAUG deployment architecture. The situation manager was implemented using Esper, a CEP engine developed by Es-perTech (https://www. espertech. com/esper (accessed on)) under an open source license. Esper includes a language called Event Processing Language (EPL) which is a SQL-standard language with temporal operators extensions (e. g. , windows definition and interaction, timed-data arithmetic definition, etc. ) Figure  6  depicts the EPL rule that specifies the beginning of situation S8 'the vessel is at sea in a dangerous area nearby an unknown vessel'. We hypothesize that the vessel can provide 3 sensors: a GPS, a proximity sensor that can provide information about nearby vessels, and a vessel workflow sensor that states the current step in the cargo transfer process.
Lines 2 and 3 take the GPS and proximity events in a 10 s time frame while lines 4 and 5 retrieve the last mission state and active situation events. Similarly to SQL, the where clause allows filtering the request to specific conditions. Here, the position shall be in an unsafe area (line 7), there is a nearby unknown vessel (lines 8 and 9) and the vessel is transferring the cargo (i. e. , at sea line 10). When the situation manager detects that situation S8 is starting, it generates a situation event informing that the current situation ends and S8 starts. The command center takes as input situation-based security policies in XACML v3 (eXtensible Access Control Markup Language  [38] ) or ALFA (Abbreviated Language for Authorization  [39] ) format. Figure  7  is the ALFA rule that refines the situational security control relating to applying strong password policy in situation S8.
MITIGATE assets, threats, vulnerabilities and threat agents are instantiated with the use of datasets pulled from open sources provided by widely known organizations like MITRE and the National Institute of Standards and Technology (NIST). In particular, for each asset, we identify relevant vulnerabilities based on the Common Vulnerabilities and Exposures (CVE (https://cve. mitre. org/ (accessed on 1 September 2021)) database. As illustrated in Figure 5, threats are instantiated based on the Common Attack Pattern Enumeration and Classification (CAPEC (https://capec. mitre. org/ (accessed on 1 September 2021))) catalog and the Adversary Tactics Techniques and Common Knowledge (ATT&CK (https://attack. mitre. org (accessed on 1 September 2021))) framework, while security controls are D3FEND (https://d3fend.
We project this operator on the cellularized geometry and discretize it. Finally, we test our analysis with numerically generated data, illustrate it with experimental data from a coarsening foam, and discuss the potential applications of this framework. For simplicity, we present results for polygonal tilings of the Euclidean plane, but this method is broadly applicable to domains of any geometry and dimension. We also provide MATLAB (Mathworks) scripts implementing CFT that can be readily adapted to analyze any type of cellularized signal.
E. CFT illustrated with coarsening foam To illustrate the Cellular Fourier Transform, we analyzed data for a two-dimensional foam shown in Figure  1. We first obtained cell contours using the MATLAB imfill function which is based on morphological reconstruction. We ascribed pixels to cells; we calculated the discrete Laplacian from (  13 ) by summing over pixels and then computed the harmonics. Figure  9  shows the spectrum of areal growth and cell density. The spectrum for growth seems to be random and overall decay with wavenumber. Its resemblance with the spectrum shown in Figure 6C suggests long-range correlations for areal growth in foams. Knowing that, in a coarsening foam, relative areal growth of a cell of area S and number of neighbors n is proportional to (n-6)/(Se) with e average thickness of films, this could be associated with long-range correlations in any of these parameters.
ACKNOWLEDGMENT We thank  Pierre Borgnat  and  Chun-Biu Li  for fruitful discussions and  Jérôme Duplat  for sharing raw data of foam coarsening and for useful comments. This work was supported by the  Université de Lyon  through the program " Investissements d'Avenir"  ( ANR-11-IDEX-0007 ), and by the  French National Research Agency  through a  European ERA-NET Coordinating Action in Plant Sciences (ERA-CAPS) grant  ( ANR-17-CAPS-0002-01 ).
Introduction The HIBEAM/NNBAR program  [1]  for the European Spallation Source (ESS) is a future sequence of experiments to search for beyond Standard Model (BSM) physics appearing as baryon number violation (BNV). The primary goal of the experiment is to look for free neutron-antineutron transformations (n → n)  1. It is a two-stage program, the first stage being that of HIBEAM, which plans to utilize a fundamental physics beamline, ANNI  [2] , soon after ESS commissioning and without full beam power. A high precision phase would follow with a dedicated high-flux beamline at the already appropriated Large Beam Port. The HIBEAM/NNBAR experiment has an active collaboration  [1] , and is currently focused on research for a Conceptual Design Report (CDR) to be published by the end of 2023 as a part of a EU Horizon2020 infrastructure design program  [3].
The HIBEAM/NNBAR program will ultimately give a sensitivity increase of three orders of magnitude compared with previous neutron transformation searches  [1, 4, 5]. The HIBEAM/NNBAR experimental program is particularly interesting from a computational and simulation perspective as it is a cross-disciplinary experiment with a diverse membership. For example, the collaboration encompasses physicists from both the high-energy hadron collider and low-energy nuclear physics experiments, as well as scientists specializing in neutronics and magnetics. As such, synergies between the communities are continuing to foster solutions to technical problems, including in the computing area, focused upon the common goal of discovering physics beyond the Standard Model via the observation of neutron conversions.
Section 3 then gives an overview of the simulation chain, describing the various component programs. Following this, Section 4 outlines the neutron focusing planned for the experiment and simulation thereof. Section 5 describes the simulation of the signal and background processes. Section 6 describes the MCPL simulation format  [7]  which is used in this work but is not well known in the high energy physics (HEP) community. Section 7 outlines the planned detector for the measurement of the signal annihilation process together with its simulation. Section 8 then outlines trigger strategy. Section 9 then describes the data management plan for the work. This is followed by a short summary of the paper. Finally, an Appendix is provided which gives an overview of the various component software packages used in the HIBEAM/NNBAR simulation framework.
As the HIBEAM/NNBAR program is searching for a rare process, the average data taking trigger rate is mainly driven by natural and neutron beam-generated backgrounds. The target foil material will likely be carbon, a choice driven by its low neutron capture cross section within the expected cold neutron velocity range of the experimental program (averaging to ∼ 1000 m/s for the HIBEAM/ANNI beamline  [2] ). Given the high neutron fluxes reaching the target of the experiments, one still expects around 10 5 and 10 7 photons/s from neutron capture for HIBEAM and NNBAR, respectively. Such rates are quite manageable for a modern trigger system, but it can provide high counting rates within sub-detector elements, and can be a potential source of background to the signal in random coincidence with fast neutrons released during the spallation process, along with cosmic rays.
Neutronics and neutronics simulations Neutron source simulation studies for NNBAR are performed via the radiation transport code MCNP6  [10]  and currently focus on the optimization of the neutron intensity of the source, useful both to the standard mission of the ESS as well as the HIBEAM/NNBAR program. A geometric description of the ESS target and moderator system with the baseline concept for the high-intensity liquid deuterium moderator as implemented within MCNP6 can be seen in cross section in Fig. 2. Several moderator designs and configurations are currently being tested in order to provide the highest possible flux; this is a key output of the Horizon2020 HighNESS program  [3]. The source yields from MCNP6 are then fed into the neutron raytracing code McStas  [11] , thus allowing one to simulate and optimize the performance of various reflector geometries.
The model for NA interaction was systematically tested on available pA data, largely from LEAR and other antimatter experiments  [8]. Thus, one may now simulate extranuclear and intranuclear nA annihilations resulting from an n → n process for a free or bound neutron. The simulation uses proprietary Monte Carlo code and Fortran libraries. In principle, with foreknowledge of the radial dependence of the annihilation near the surface of the nucleus  [17] , such events may be simulated for any nucleus, though validation as well as data or model signal comparisons have only been considered for a few species, such as 12 C  [8]  (useful for HIBEAM/NNBAR) and 40 Ar  [9]  (useful in DUNE  [18] ). This is possible given the universal microscopic nA annihilation dynamics taken into account within the simulation.
As explained in Section 4, such simulations must make use of Monte Carlo radiation transport codes like MCNP6 or PHITS since the particles need to be transported over a long distance; to avoid untenably large amounts of processing, such codes also maintain several variance reductions features which can aid in the propagation of particles in the absence of high statistics. • The gamma background due to interaction of the cold neutron beam with the annihilation target (see  Section 7). Such backgrounds have been simulated with PHITS but do not require any kind of variance reduction. • The cosmic background due to charged and neutral cosmic rays can be simulated with the CRY software library  [20]  (see  Section 7). The use of MCPL as the common format for interfacing between different simulation codes deserves a special mention since it is not so well-known within the HEP) community.
In the case of the HIBEAM/NNBAR experimental program, one of the main advantages MCPL provides is an easy way to interface neutron transport codes' results obtained in PHITS, MCNP6, or neutron optics simulations performed with the neutron ray-tracing code McStas  [11]. It is equally simple to convert proprietary code results to an MCPL format via the use of simple loops and functions, most of which are directly provided within the MCPL documentation. MCPL can, therefore, be used to interface a large variety of codes, including many general purpose Monte Carlo simulation codes commonly used throughout HEP. Though arguably not necessary, having various codes and their output interfaced across a practically universal software tool is both pragmatic and efficient.
Detector components and simulation The simulation needs for the HIBEAM/NNBAR program are mostly driven by the reconstruction of the annihilation event in a detector, as well as computing of topological, kinematic, and timing characteristics of any backgrounds for their comparative rejection; neutron optics (for instance, the reflection of neutrons downbeam from reflective ellipsoidal mirrors), as well as magnetic and radiation shielding along the beamline, are also major contributors to the overall computational scheme. Detector design is guided by the need for a high signal efficiency for antineutron detection via a high multiplicity pion reconstruction, along with the ability to maintain a low background yield. The main detector components are: • An annihilation target, likely a 100 µm thick carbon disk, with a 1 m diameter for the initial HIBEAM stage, and 2 m diameter for the full NNBAR second stage.