dataesr/scientific-paragraphs-categorization huggingface dataset:
F. Last-meter SG Architecture The last-meter SG is a part of the SG that is closer to the home, i. e. , the part with which the consumers interact. An architecture for the last meter SG embedded in the IoT is proposed in  [155] ,  [156]  and is presented in Fig. 9. This architecture is comprised of three main components, sensor and actuator networks, an IoT server and user interfaces. 1) Sensor and Actuator Networks for Various SG applications: The sensor and actuator networks enable the realization of various SG applications and contain two main components: sensor and actuator nodes, and IP gateways. a) Sensor and actuator nodes: The sensor and actuator nodes can be part of wired or wireless networks. This architecture can accommodate heterogeneous sensor networks, as the data management unit in the IoT server translates information into the format required by the SG database.
The sensor and actuator networks consist of sensor and actuator nodes, and IP gateways. The IoT server consists of a message dispatcher, an SG database, a data management unit, a configuration database, a configurator unit, a user database and a secure access manager. The user interfaces consist of a visualization interface, a configuration interface and a web service API. addresses in sensor and actuator networks are generally only unique within a single network and may change over time. Therefore, the IoT server assigns a unique ID to each node of the network and maintains the mapping of each ID and its corresponding network address, provided by the local network coordinator. Subsequently, when a node sends a message to the IoT server, the gateway node translates its network address into a unique ID, and vice versa.
It only has to ensure an IP connection, encapsulate the messages into TCP/IP packets and ensure the security level required by specific applications. Secondly, new functionalities and applications can be developed and added without modifying the gateway. 2) IoT Server: The IoT server has four main components: the first one is a message dispatcher, the second one is a data management unit and database storage, the third one is a configurator unit and database, while the fourth one is a secure access manager and user database. a) Message dispatcher: To perform bi-directional communication between each gateway and the rest of the system, the message dispatcher will be used. The message dispatcher will listen to new connections from IP nodes that want to join the system for uplink communication.
It decrypts incoming packets for every connection and forwards them to the data management unit for storage and interpretation. For downlink communication, it encrypts the messages from the configurator unit into a TCP message and then forwards them to the destination gateway. b) Data management unit and database storage: The data management unit is a collection of software modules. In this unit, each software module is able to manage the messages of a specific sensor/actuator network. These modules receive messages in their native format and then extract their payload. Two storing mechanisms are performed based on the payload. Firstly, the messages are stored in a unique format in the SG database if the payload contains either measurement data from a sensor node or a notification from an actuator node.
Secondly, the message is stored in the original format into the configurator database if the payload contains specific network messages (such as configuration, management information, a node address or a communication channel). The SG database decouples the data collection from the data processing and visualization so that the users do not have to interrogate the nodes directly. The decoupling allows the nodes to stay in sleep mode most of the time and to only wake up periodically to receive commands and configuration messages, as well as to send measurement and status data. This approach is very useful when the sensor networks are heterogeneous, as well as when nodes are battery powered. The sensors' data in a SG database is represented by a unique format that is associated with the physical nodes through the unique node ID, independent of the local sensor network protocol.
In this manner, data can be processed and visualized independently of the characteristics of the physical source. c) Configurator unit and database: The configurator unit is a collection of software modules, where each module is dedicated to a specific type of sensor/actuator network. This unit configures the nodes and networks according to the inputs from applications and users, as well as according the stored system status in the configurator database. d) Secure access manager and user database: This component coordinates all the communication between the end users and the IoT server by ensuring privacy and data protection. It only allows authorized users and third-party applications to access the stored information and the network configuration based on the user database, and the users' access permission for each resource.
Firstly, initializing the Internet connection, i. e. , mapping a MAC address to the IP address with access to the world wide web (www). Secondly, connecting to the Internet in order to transmit or to receive data. Thirdly, terminating the connection upon completion of a transmission or reception. The software includes a Graphical User Interface (GUI) for accessing the web services and user account management. A consumer can access web services via the web browser (any sort) of any device connected to the Internet. A consumer initially registers himself, and after the required verification and authentication, the administrative staff adds the consumer's home to the system. Subsequently, the consumer can monitor his home's average power consumption, making it possible to keep track of energy consumption and plan the scheduling of power sources.
Load control was implemented using a single-pole bistable 12V relay which can support up to 16A. The power supply unit in the board can supply 12V for the relay and 3V for the ADE7953 IC and MC13224 SoC. BeeStack, a Freescale ZigBee stack, is used to implement the firmware, running on the smart plug. Since the smart meter is a ZigBee device, a ZigBee/IP gateway is used for the communication with IoT server. The ZigBee/IP gateway is comprised of a micro controller, an Ethernet interface and a ZigBee RF transceiver. The Freescale Kinetis K60 is used as a micro controller which is based on an ARM Cortex M4 processor with hardware encryption. The message dispatcher is implemented as a multi process application on a Linux machine. It continuously listens to new connections from the gateways. The data collection unit is implemented using CoMo software  [161].
It is designed for fast prototyping of network data mining applications and it is used in large testbed deployments, e. g. , PlanetLab  [162]. Hence, it is scalable to very large systems with high data rates. The CoMo architecture provides an abstraction between the IoT server and the network interface. It follows a modular approach and it is comprised of several modules. Each CoMo module interprets the packets of a specific type of sensor network that belongs to the households and extracts data for inclusion in either the SG database or a configuration database. The configurator and user databases are implemented with MySQL. After the required authentication, the Tornado implements direct access to the home appliances data using HTTP. The user interface is implemented as a web interface. The web interface, the secure access module and the configurator unit are based on an open source non-blocking web server, known as Tornado  [163].
The graphical interface is based on Twitter Bootstrap  [164]. The web interface mainly consists of five functionalities, home appliances' energy consumption data visualization, registration and configuration of new networks, privileges management, registration of new sensors for home appliances, and sending commands. Firstly, the visualization of energy consumption of the home appliances provides a time range selector and a graph where energy consumption data is plotted as a function of time. The time option allows the desired measurement period to be selected. Secondly, there are dedicated web interfaces that administrators use to register and configure new networks. The network configuration is stored in the configurator database. Thirdly, the administrators can manage privileges by assigning or removing different privileges to different users and third-parties.
The iPRP is implemented as a transport layer solution in Linux OS of PDC and PMUs, which offers the advantage of not needing any modification to any network devices or PDC/PMU applications. The PDC collects the data of synchrophaser, nodal absorbed/injected powers, frequency and rate of change of frequency which is estimated by PMUs and forwards it to other applications (e. g. , state estimator or visualization tools). The PDC communicates with PMUs and decapsulates their datagrams. The synchrophasers are time aligned and aggregated in a circular buffer. Subsequently, a subset of these measurements is forwarded to the state estimator. While handling with communication networks and devices, the nondeterministic nature of network traffic, varying reporting rates among devices and data streaming can cause the measurements to be delayed which make it difficult to identify the accurate amount of reception time of the data packets.
Hence, the authors use adaptive algorithm in this prototype that identifies the time each dataset need to wait for the rest of phasors based on an event timeout with the same timestamp. The arrival of more recent measurement identified by its timestamp expires the timeout. On event triggering, the current dataset is transmitted to the state estimator application. This approach guarantees that the available measurements will be forwarded in an acceptable time range (e. g. , around 20ms for PMUs streaming at 50fps), increasing the determinism of the process. Since machine hosting the PDC and state estimator are GPS synchronized, the bottlenecks in the whole chain causing higher delay can be identified and solved. The state estimator receives data from the PDC and estimates the system state. This prototype adopted discrete Kalman Filter as it provides more accurate estimations as compared to the weighted least squares  [169].
B. Platforms Cloud computing provides a service-driven model which can be categorized into three types, namely Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS)  [177]. IaaS offers the provisioning of computer infrastructure as a service, generally via Virtual Machines (VMs), such as Amazon EC2, Flexiscale, GoGrid and Joyent. PaaS provides the support of operating system and software development to the developers to deploy their applications within the Cloud, such as Microsoft Windows Azure, Force. com and Google app engine. SaaS is a multitenant platform and can be referred as on-demand services over the Internet. It provides a ready to use application for the end users, such as IBM, Microsoft, Oracle and SAP. Hence, the utility companies can transfer their SCADA systems entirely to the Cloud and utilize the storage, processing and other services offered by Cloud computing.
It is optimized for reliable and low-latency communication of small data packets. It is also very scalable and can control up to 232 devices  [200]. It can also support whole mesh networks without needing any coordinator. Disadvantages: The main disadvantage of Z-wave is that since it is mainly designed for small data packets, it is not much suitable for NAN and WAN because NAN and WAN have large aggregated data packets. Additionally, it is a short range and low data transmission rate communication technology. Moreover, there is only one company, Sigma Designs, for developing the chips of Z-Wave, unlike multiple sources for other wireless technologies (e. g. , ZigBee)  [200]. c) 6LowPAN: 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks)  [201]  is a key IP-based communication technology.
Moreover, one of its disadvantages are similar to Z-Wave, i. e. , it is designed for small link layer frames, and it has short range and low data transmission rate communication technology, therefore it is not much suitable for NAN and WAN. d) LoRaWAN: LoRAWAN  [202]  is a Low Power Wide Area Network (LPWAN) communication technology which is designed for wireless battery-operated devices in Internet of Things  [203]. It is mainly designed for wide area network coverage in IoT and it can be applied in NAN and WAN of SG. It provides mobility, secure bi-directional communication and localization services, as well as interoperability. It offers a data rate of 0. 3 Kbps to 50 Kbps and coverage range of 2-5km in urban environment and 15km suburban environment. Most of the existing wireless communication technologies have been designed to maximize their peak data rate, however LoRa is mainly designed for low-power consumption and long communication range by sacrificing its peak data rate  [204].
WirelessHART is a centralized and realtime protocol for industrial process monitoring and control  [210]. It is a low power communication protocol that is based on IEEE 802. 15. 4 and operates on 2. 4GHz band  [208] ,  [210]. It has a range of 200m, offers 115 Kbps data rate  [211]  and it uses 128-bit AES encryption for security  [208]. WirelessHART was included in the HART protocol suite in June 2007 after approval by the HART communication foundation as part of the HART 7 Specification  [212]. In SG, WirelessHART can be used in power generation for sensors deployment  [213]. Emerson introduced WirelessHART power meter that overcomes the limitations of wired meters that require a power source and handwiring to the monitoring and control system  [214]. The required power for WirelessHART power meter is provided from the main electrical supply to the monitored equipment that eliminates the requirement of a dedicated power source.
Network or Graph of Interactions The first input into ETG modeling is a list of biological events as well as the consequences of these events. For the sake of illustration, when representing the nitrogen cycle, the events are reactions (e. g. , nitrification, denitrification, etc. ) and their consequences are the respective production and consumption of metabolites (e. g. , NH 4 + NO 3 -). This knowledge is a mechanistic description of an event and is necessary to estimate the "cost, " or effect when one event occurs over another. Here we derive a nitrogen network composed of a hypothetical series of reactions (i. e. , fixation, nitrification, denitrification and anammox), as laid out in the Kyoto Encyclopedia of Genes and Genomes (KEGG) database map00919  (Kanehisa and Goto, 2000) , without assigning taxonomy to the microorganisms that mediate these reactions.
The combination of the graph of events and the effect of each event represents a mechanistic description of the modeled biological system. The effect of each event is additive to simulate an effect of stoichiometry, but, as proposed in  Bourdon et al. (2011) , a multiplicative effect could also be used to represent exponential behaviors. Notice herein, for closing the system (i. e. , no transition must point out), the hypothetical model considers a central reaction. It depicts an artificial reaction that points toward reactions linked to the nitrogen cycle but involved in other metabolic pathways, such as carbon or phosphate, as mentioned in the KEGG database. For consistency with other reaction descriptions, its mechanistic description considers only major nitrogen metabolites.
Formating the Quantitative Data as Training Dataset ETG modeling estimates probabilities associated with interactions between events (herein reactions) such that the succession of events reproduce quantitative experimental data. For illustration, we use chemical variables from  Bouskill et al. (2011) , which describes a time series of ammonia, nitrite, and nitrate (see Table  1 ). In order to fit such quantitative experimental data with ETG, one must transform quantitative variations as rates, which necessitates the assignment of a time-step. For instance, when considering a time-step of two hours, a variation from 8. 4    these quantitative rates. They imply to consider predefined timesteps, but also allow to not constraints the cost units or even considering the costs of distinct units simultaneously.
Probability Estimate for Simulating the Nitrogen Cycle Ammonia oxidizing organisms (AOO) mediate the rate-limiting step of nitrification (i. e. , NH 3 → NO 2 ), a rate-limiting step in the Nitrogen cycle  (Ward et al. , 2007; Bouskill et al. , 2011 Bouskill et al. , , 2012)). Analyzing the dynamic of the nitrogen cycle in a given ecosystem and, in particular, the impact of this reaction allows to evaluate the putative role of these organisms in the same ecosystem. Herein, we describe a schematic nitrogen cycle within a unique ETG of quantitative chemical variables and simulate the corresponding metabolic network to assert the role of the typical reaction of AOO. Following an automatic extraction from KEGG database  (Kanehisa and Goto, 2000) , ETG that covers the whole set of reactions associated to the nitrogen pathways represents 41 nodes and 67 edges.
e. , the null assumption). To estimate probabilities between reactions and train the ETG, we used an existing environmental dataset representing variations in Chesapeake Bay ammonia, nitrite, and nitrate concentrations (µM) between 2001 and 2004  (Bouskill et al. , 2011). The optimization process emphasized a set of probabilities that reproduce observed variations in ammonia and nitrate despite the use of a simple graph that strongly reduce the nitrogen cycle. To test our model, we simulated variations in chemical factors using a Markov Chain simulation algorithm parameterized with computed probabilities, and compared the predictions with the available time series data (see Figure  1B ). The model accurately replicates ammonia and nitrite chemical variables over the period between 2002 and 2004, but fails to reproduce the observed nitrate dynamics.
Learning on a Random Network The general criticism about probabilistic models concerns their use as a statistical protocol that reproduces observed data with no biological specificity. Contrary to other probabilistic modelings, ETG considers a mechanistic interpretation of the systems via the use of a graph of events. The use of a description of events allows specifying the model to perform a given (biological) behavior and to test it regarding experimental data. For an illustration of the interest of ETG specificity, we propose to build a counterexample by randomizing the model and training it on the same dataset. The randomized model consists of building a graph similar to the nitrogen cycle graph for which all edges have been shuffled by permutation. The randomized model is then similar to the ETG nitrogen cycle model regarding the numbers of nodes and edges.
Non-invasive estimation of brain microstructure features using diffusion MRI (dMRI)-known as Microstructure Imaging-has become an increasingly diverse and complicated field over the last decades. Multi-compartment (MC)-models, representing the measured diffusion signal as a linear combination of signal models of distinct tissue types, have been developed in many forms to estimate these features. However, a generalized implementation of MC-modeling as a whole, providing deeper insights in its capabilities, remains missing. To address this fact, we present Diffusion Microstructure Imaging in Python (Dmipy), an open-source toolbox implementing PGSE-based MC-modeling in its most general form. Dmipy allows on-the-fly implementation, signal modeling, and optimization of any user-defined MC-model, for any PGSE acquisition scheme.
Dmipy is freely available under open-source MIT license at https://github. com/AthenaEPI/dmipy, where detailed tutorials and implementations of many MC-models in literature are provided in the form of Jupyter Notebooks. As for dependencies, Dmipy's dynamic modeling design is based on numpy  (Oliphant, 2006) , non-linear optimization on scipy  (Jones et al. , 2001) , convex optimization on cvxpy  (Diamond and Boyd, 2016; Agrawal et al. , 2018)  and for signal-based subroutines (e. g. , DTI) and visualization we use dipy  (Garyfallidis et al. , 2014). As optional dependencies, we speed up code use Numba's just-intime compilation  (Lam et al. , 2015) , and allow multi-core CPU processing using pathos  (McKerns et al. , 2012). The structure of this paper is as follows: in section 2, we explain the theory and basic interaction behind generalizing MC-modeling over the three modeling frameworks, for any PGSE acquisition scheme and biophysical model composition.
Representing Any PGSE Acquisition Using a DmipyAcquisitionScheme To allow Dmipy to interact with any PGSE acquisition scheme, the DmipyAcquisitionScheme module takes the raw PGSE acquisition scheme parameters and prepares them to be used for signal generation. A DmipyAcquisitionScheme can be instantiated in three ways: • For clinical data, using b-values [s 2 /m] and gradient directions (and optionally δ/ /TE [s]);  • Using G [T/m], gradient directions, δ and (and optionally TE); • Using q [m -1 ], gradient directions, δ and (and optionally TE). We show how to create a scheme for a clinical acquisition in python Snippet 1. Notice that pulse duration, pulse separation, and TE can be given as a single number (it does not change throughout the acquisition), or an array the same size as b-values, potentially changing for every single measurement.
Tissue Response Models (TR) Tissue Response (TR) models are non-parametric representations of the measured signal, which are recovered by averaging the signal in segmented voxels of specific tissue types. These models differ from the previously described parametric models in that they are not related to the "true" underlying EAP of the tissue. In Snippet 4 we provide the code to produce isotropic (TR1) and anisotropic (TR2) tissue response models, given some data segmentation. Formally, let X iso and X aniso be segmented voxels of isotropic and anisotropic diffusion profiles. Tissue response models are then created by first representing the signal in each voxel as rotational harmonics coefficients r with order l using a rotational harmonics transform (RHT)-see the Supplementary Material-and then averaging those coefficients.
In doing so, we can separate the segmented tissue-specific S 0 signal response and its shell-wise shape, allowing for so-called multi-tissue modeling  (Jeurissen et al. , 2014). Snippet 4 | Instantiation of anisotropic and isotropic tissue response models, given some data segmentation. Notice that we can produce an isotropic or anisotropic TR-model regardless of the data, and that we also recover the mean signal amplitude S 0 of the input data, which we can use later when setting up MC-models in Snippet 5. 1 from dmipy. signal_models import tissue_response_models 2 # We have some dataset with some binary segmentation mask 3 data_seg = data[segmentation_mask] # of shape (N_segmented_voxels, N_DWI) 4 S0_response, TR1 = tissue_response_models. IsotropicTissueResponseModel(dmipy_scheme, data_seg) 5 S0_response, TR2 = tissue_response_models.