dataesr/scientific-paragraphs-categorization huggingface dataset:
All SAXS data were simulated at ambient pressure and temperature, at pH 2. 3, and at 100 mM ionic strength. The structures of the BLG monomer and dimer are depicted using the Rasmol software  (Bernstein et al. , 2000). The best fit values of the dissociation free energy and the relative mass density of the hydration shell are ÁG dis /(k B T) = 8. 22 AE 0. 08 and 1. 08 AE 0. 01, respectively. (Right) BLG monomer fraction in solution versus BLG concentration as obtained from the dissociation free energy. In this example, we simulated a set of SANS curves for BLG dissolved in D 2 O at a fixed concentration but with an increasing content of urea (see Fig. 4 ). The SANS contribution of BLG monomers in their native conformation was simulated according to the form factor derived from PDB entry 1beb  (Brownlow et al.
Guanosine association SAS has also been used to monitor complex aggregation/fragmentation processes in solution  (Mariani et al. , 2009 (Mariani et al. , , 2010;; Gonnelli et al. , 2013). In particular, the possibility of defining link functions and global parameters in the GENFIT data analysis process allowed several guanosine aggregate species formed by self-assembly in solution to be resolved in terms of concentration and composition. Here we describe the case of the temperature behaviour of 2-deoxyriboguanosine 5 0 -monophosphate, d(pG), which autoassembles in aqueous solution in the form of quartets, octamers and pseudo-polymeric quadruplexes characterized by the absence of a covalent axial backbone  (Mariani et al. , 2009). As contradictory findings have been reported in the literature, the effect of temperature on d(pG) self-assembly was investigated in particular  (Mariani et al.
Summary, conclusions and outlook GENFIT is a software package to analyse sets of SAS curves recorded from nanosized macromolecular systems using one or more suitable models, which contain both form and structure factors. The parameters of the models are optimized in a versatile manner, enabling the user to easily impose constraints or to express them through suitable functions. Such functions can be simple phenomenological relationships or chemical-physical laws. This approach is particularly useful when a set of SAS curves has been obtained for the system of interest by varying one or more external conditions. In such cases, the GENFIT analysis of the whole set of SAS curves can extract relevant physical information (for example thermodynamic parameters) that describes the behaviour of the system under the investigated conditions.
GENFIT can be useful for optimizing the steps of a SAS study and for exploiting fully the complementarity between SAXS and SANS. It allows the simulation of SAS curves and testing of whether, by analysing them as single measurements or as a whole set of measurements, it is actually possible to recover the information the user is interested in. A GUI has been developed to assist the user in exploiting all the GENFIT characteristics in a simple and intuitive way. GENFIT runs under Windows, Linux and MacOS and is freely available from the distribution web site  (Spinozzi, 2013). It is open source for registered users (registration is free of charge). GENFIT is modular software, and new models and features are continually integrated into it by the authors. It should be noted that a set of guidelines for the presentation of SAS results in structural molecular biology has recently been published  (Jacques et al.
, 2012). Such guidelines would ensure adequate SAS data reporting and analysis, but would also give a warning about the risk of model overparameterization (i. e. the introduction of more parameters into the model used to fit the SAS data than can be justified). It is evident that GENFIT is not concerned with data reduction or presentation, but the use of GENFIT can certainly reduce the risk of overparameterization. In fact, the extended use of link functions, which add restraints based on complementary physical-chemical and/or thermodynamic information, as well as the global fit approach  (Ortore et al. , 2011) , should help the user in reducing the number of parameters and providing a proper justification for the specific modelling protocol employed. The authors acknowledge Flavio Carsughi, Domenico Gazzillo, Achille Giacometti and Raffaele Sinibaldi for useful discussions focused on the code development.
In this way, animation makes direct use of the hierarchical description, since e. g. , to animate the forearm, appropriate transformations have to be applied at the elbow joint only. One can see that to animate the whole body requires applying geometrical transformations at the joints (i. e. , the nodes of the hierarchy). The entire scene is thus represented by a database describing the hierarchical arrangement of all the objects in the scene. The VR module amongst other things includes the management of this scene hierarchy. This includes the animation of virtual objects and other dynamic changes to the environment. Because this module is responsible for updating the internal state of the scene and rendering the result, it serves as the integration point for the other modules. Table  1  presents the main characteristics of the VR module in terms of hardware and software dependencies as well as in terms of required inputs and produced outputs.
The scene is rendered onto displays from a pair of viewpoints in the scene (for stereo), representing the positions of the two eyes of an observer. Rendering requires resolving visibility (i. e. , what can and cannot be seen from the viewpoint), and typically the process of a computer program traversing the scene data base and producing output onto the displays should occur at least 30 times a second. The location and the gaze direction are typically determined by head-tracking -i. e. , a device that sends to the computer responsible for rendering information about the participant's head position and orientation at a high data rate. Thus the scene is displayed from the current viewpoint of the participant's head position and orientation. What does (visual) embodiment require? A virtual human body can form part of the scene database -it is an object just like any other.
g. , scientific visualization, games, interaction, modeling, visual simulation, etc. ). Unlike game engines, these toolkits are not specialized for a single use, and thus may not offer all of the modules offered by a game engine, such as a character-animation engine. Most of these graphics toolkits are open source, so it is typically possible to extend them in order to add specific features. As in the case of game engines, graphics toolkits usually do not provide VR-specific features such as direct HMD or tracking support. Since graphics toolkits are often open source, this enables a high degree of customizability. OpenSceneGraph, OpenSG, and Irrlicht are freely available open source while there are both open and closed source versions of Open-Inventor. The commercial version of Open-Inventor is more expensive but has better user support.
Virtual reality toolkits. Virtual reality toolkits, such as XVR 10  (Tecchia et al. , 2010), VR Juggler 11   (Bierbaum et al. , 2001) , 3DVia When choosing an engine for a VR module of a virtual embodiment system, one should take the following important characteristics into account: • Trade-off between extensibility (i. e. , possibility to add specific features) and built-in functionality. • Ease of tracking system integration (see"Head-tracking module" and "Full body motion capture module"). • Reliable workflow for loading 3D file formats. • Support for virtual mirrors, often used to enhance BOIs.
Our solution. We have successfully used both the XVR platform and the Unity game engine for a number of virtual embodiment experiments (see "Results"). XVR is attractive due to its low cost, extensibility via plug-ins, and built-in cluster rendering support (largely used for non-embodiment VR applications). Additionally, it is straightforward to render in stereo to a HMD. XVR also provides a software interface to access tracking data via network connections. Unity is available for free with a reduced feature set, although a license is necessary for plug-in support. HMD stereo rendering can also be added quite easily in Unity. Unity is especially attractive due to its integrated development environment, which simplifies the creation of interactive VEs for individuals with limited computer programing experience.
It also includes a character-animation library, which is useful for virtual embodiment. Extending XVR and Unity is made possible by the development of external dynamically linked libraries (DLLs) in C++ that can be loaded at runtime. XVR provides direct support for OpenGL, whereas Unity has a built-in high-quality graphics engine including real-time shadows and dynamic particle systems. The flexibility of the plug-in approach enables the easy integration of our custom avatar animation mapping library  (Spanlang et al. , 2013) , which supports mapping the movements of a tracked participant to virtual characters, discussed in Section "Full Body Motion Capture Module". In addition, for high-quality visualization of virtual characters we have developed the HALCA hardware-accelerated library for character-animation  (Gillies and Spanlang, 2010)  that we have integrated with a virtual light field approach for real-time global illumination simulation in VR  (Mortensen et al.
, 2008). This enables us to simulate light interactions so that the participant can see reflections and shadows of their virtual avatar, which is quite common in virtual embodiment scenarios (see Results). In Unity, we create virtual mirrors via virtual cameras, whereas in XVR this is achieved via the use of OpenGL stencil buffer or frame buffer object mirrors. One additional feature of the VR module is integration with modeling programs for the creation of the VE. XVR provides a 3DS Max 14  exporter plug-in that makes the importing of objects created in 3DS Max quite straightforward. Unity enables the user to import from a number of modeling tools, and enables interactive editing of the VE within the Unity editor. We have used virtual characters from AXYZ Design 15 , Daz3D 16 , Mixamo 17 , Poser 18 , Rocketbox 19 , and the Open-Source Software MakeHuman 20.
On the other hand, owing to the use of LCoS, some red and blue vertical lines may appear during rapid head movements. With a weight of 1. 3 kg the SX111 is also quite heavy, due in large part to the size of the displays. We are currently evaluating consumer-based HMDs to hopefully achieve a good balance between FOV, resolution, weight, and price. An overview of HMD properties is given in Table  3. Incorporating different HMDs into both XVR and Unity has proven to be quite straightforward, but it should be noted again that each HMD has different characteristics, and the virtual cameras used to render for the HMD must be set up correctly to match the HMD specifications. In Figure  3 , we show OpenGL code for the specifications of the SX111 and in Figure  4  for the Wide5 HMDs. For the Oculus Rift, Oculus provides an SDK for correct rendering in game engines such as Unity.
Polhemus 39  offers a set of electromagnetic-based tracking devices. Regardless of the tracking technology used, the tracking data must be transferred to the VR module to animate the virtual character. Often the skeletal structure used to represent the joint angles of the participant in the tracking system will differ from that used to represent the participant in the VE, so some mapping from one to the other must be performed. Apart from our system we only know of Vizard in combination with Autodesk Motion Builder that provides a solution to deal with different tracking systems in a VR system. This comes at a considerable cost just for the plugin that reads Motion Builder data into Vizard. We have therefore developed our own interface, described below. Important characteristics when choosing a full body motion capture system include: • Latency: as for head-tracking, displaying delayed movements in the VE can induce breaks-in-presence for the participants.
We have developed an avatar mapping library that enables such mappings from a number of tracking systems (e. g. , OptiTrack, Xsens, and Kinect) to humanoid skeletons by specifying which bones are related between the two skeletons, and what the coordinate system transform and rotational offset is per bone mapping. Once specified, this mapping can be applied in realtime. This library has been successfully incorporated as a plug-in to both XVR and Unity  (Spanlang et al. , 2013). Additionally, while performing virtual embodiment experiments with HMDs, we realized that head-tracking was far more robust and stable when using a separate head-tracker (see Headtracking module) instead of relying on the full body tracking software to provide head movements. The head movements from the full body motion software induced more jitter and jerkiness and as a consequence, the participants were more prone to suffer from simulation sickness and we would sometimes have to interrupt and stop the experiment.
QUANTITATIVE MEASUREMENT MODULES The ability to induce the illusion of ownership over virtual bodies raises the question of how to measure such illusions both qualitatively and quantitatively. Nearly all BOI studies explicitly address illusory ownership feelings through questionnaires originally adapted from  Botvinick and Cohen (1998). Many studies of the RHI use proprioceptive drift -the difference between the participant's estimation of the location of their hidden hand before and after visuo-tactile stimulation -as a more objective measure indicating a spatial shift toward the visible fake hand as an owned body part  (Botvinick and Cohen, 1998; Tsakiris et al. , 2005 Tsakiris et al. , , 2010;; Costantini and Haggard, 2007; Slater et al. , 2008). In our virtual embodiment system, we additionally employ various quantitative physiological measurements that can be correlated with qualitative questionnaire data to determine the degree of the induced BOI.
Typically manufacturers provide APIs/SDKs for C++ , Java, and/or MATLAB. The major drawback is the need of programing skills to use this solution. Open-Source software toolkits can also be used for viewing, analyzing, and simulating physiological signals. The Phy-sioNet research resource  (Goldberger et al. , 2000)  provides a comprehensive list of free toolkits. Important characteristics that should be taken into account before deciding upon a physiological measurement module include: • Flexibility: capability to support a wide variety of biosignal amplifier devices as well as communication protocols. • Capabilities: the module should be able to measure and extract a wide spectrum of physiological signals in real-time. • Extensibility: experimenters should be able to add custom functionalities to the physiological module.
• Ease of integration with the VR module: network communication, programing interfaces (API, SDK), etc. Our solution. We have adopted a MATLAB Simulink 50 -based software architecture that is highly flexible and supports: (i) wired and wireless biosignal amplifiers from different companies, (ii) different physiological measures and extracted features, (iii) complementary devices to record additional measures (e. g. , Nintendo Wii Balance Board to record body balance measures), and (iv) communication with other applications. In addition, we can easily include existing functions from MATLAB toolboxes and proprietary Simulink blocks (e. g. , g. HIsys 51 from g. tec), along with our own functions. We have different wired and wireless biosignal amplifiers that we use depending on the needs of the experiment, such as gUS-Bamp 52 , gMOBIlab 53 , Nexus-4 54 , and Enobio 55.
Common physiological sensors used in our experiments include ECG, surface electromyography, galvanic skin response, and respiration sensors. Although many different devices may be used, we have found 50 http://www. mathworks. co. uk/products/simulink/index. html 51 http://www. gtec. at/Products/Software/High-Speed-Online-Processing-under-Simulink-Specs-Features 52 http://www. gtec. at/Products/Hardware-and-Accessories/g. USBamp-Specs-Features 53 http://www. gtec. at/Products/Hardware-and-Accessories/g. MOBIlab-Specs-Features 54 http://www. mindmedia. info/CMS2014/en/products/systems/nexus-4 55 http://neuroelectrics. com/enobio using a common software interface makes the integration more straightforward and easy to use. We selected the Simulink platform because it provides several customizable blocks and libraries.
Also, the user can create new functions for data processing and add them as new blocks. Another important advantage of Simulink is that it is fully integrated with MATLAB, which provides several useful toolboxes for signal processing, machine learning, communication with other computers and devices with built-in support for TCP/IP, UDP, and Bluetooth serial protocols, etc. Figure  6  illustrates the implementation of a Simulink model used to record respiratory, cardiovascular, electrodermal, and muscular measures with the gUSBamp device from g. tec. For offline analyses of the physiological signals we typically use either gBSanalyze 56 from g. tec or custom MATLAB scripts. The advantages of gBSanalyze are the wide range of functions available to analyze physiological data and the possibility of including your own functions.
, 1975). Motor-imagery works by thinking about moving a limb, producing an activation similar to when performing the real action  (Pfurtscheller and Neuper, 2001). SSVEPs are produced as a result of visual stimulation at specific frequencies, and can be used to detect when the participant looks at specific areas or objects  (Cheng et al. , 2002). gUSBamp is connected to the PC via USB whereas the gMobiLab uses Bluetooth. To deliver physiological data to the VE and to synchronize these data with events from the VE we use the UDP network protocol both in MATLAB and in XVR/Unity. These BCI paradigms can be classified according to the mental activity that leads to specific brain patterns. Those referred to as active strategies (based on voluntary mental actions, e. g. , motor-imagery) facilitate asynchronous BCI, i.
Our solution. We have typically used the g. tec g. USBAmp for recording up to 32 EEG channels. When a wireless solution is required, then the g. tec g. Mobilab, a Bluetooth-based amplifier with up to eight channels, was used. Other hardware solutions include those from BrainProducts 57 and Neuroscan 58. In particular, BrainProducts amplifiers offer efficient synchronization between the generated event triggers and the data acquisition during the recording, and may be easily combined with the Open-Source software BCILab  (Delorme et al. , 2011). We use various software packages, mainly from gtec and EEGLab  (Delorme et al. , 2011). For real-time (in particular BCI) applications, the gtec software packages are modular and flexible, thus appropriate for research purposes. The High-Speed Online Processing toolbox running under Simulink/MATLAB is used for real-time parameter extraction and saving.
In order to counterbalance the underestimation of dispersion of the ensemble, an on-line inflation ( :10%) of the ensemble perturbations has been applied during each cycle, as described by  Raynaud et al. (2012)  but including the humidity variable. This ensemble was run for the need of the HYMEX program  (Ducrocq et al. , 2013)  that studies high impact weather events in the Mediterranean (like the Medicane).
ANNs with CPPNs (minimal HyperNEAT): The first generative encoding scheme evaluated is a simplified version of HyperNEAT indirect encoding 2   (Stanley et al. , 2009; Clune et al. , 2011; Yosinski et al. , 2011). The CPPNs encode the weights of a fixed topology, single-layer feedforward ANN, featuring 2-D cartesian grids of inputs, hidden and output neurons (Fig. 2 ). Neurons are placed in a geometric space termed the substrate, so that each neuron in a layer has a distinct (x, y) coordinate. In addition, the placement of the input and output neurons is meant to reflect the hexapod robot morphology. The CPPN is iteratively input the positions of all source (x 1 , y 1 ) and target (x 2 , y 2 ) neurons in proximal layers, along with a constant bias, and it outputs the corresponding weights of the input-hidden and hidden-output neuron connections (see Fig.
Our simulations show that an instrument like MAGEAQ-TIR would be able to retrieve the surface-6 km ozone column with more than 1. 0 DOF, on average, and a maximum sensitivity at about 3. 0 km, so at the centre of the nominal column, which indeed means that the information on the lower tropospheric ozone would be independent on ozone concentrations at higher altitudes. In addition, these results show that the MAGEAQ-TIR measurements also have a significant sensitivity to the surface-3 km TOC, with 0. 57 DOF on average, and a peak of sensitivity at about 2. 5 km. Fig. 3. Mean integral averaging kernel functions for the surface -3 km (blue (green) TOCs, for all pixels in the dataset having thermal contrast between 0 Fig. 2. Histograms of the DOF for surface-6 km (top left), the DOF for surface-3 km (top right), the altitudes of the maximum of the integrated AK for the surface-6 km TOC (bottom left), and the altitudes of the maximum of the integrated AK for the surface-3 km TOC (bottom right), for MAGEAQ-TIR.
Mean values and standard deviations are also reported in red (mean/SD). The data cover the whole period of study, on a 1 h revisit time basis. To further investigate the sensitivity of the MAGEAQ-TIR observations, we have studied the DOFs and the peaks of sensitivity for a number of different situations. We have then partitioned our data set into different subsets: day and night observations, and land and sea pixels. Observations during daytime hours (hereafter referred to as the DT subset) are those taken in the interval 08:00-19:00 UTC and, conversely, observations during night time hours (hereafter referred to as the NT subset) are those taken in the interval 20:00-07:00 UTC. Tables  2  and 3  summarise the mean values of the DOFs for surface-6 km and surface-3 km, and the altitude of the peak of the sensitivity for the surface-6 km and surface-3 km TOCs, respectively, for all possible combinations of land/sea and DT/NT.
To further investigate the vertical sensitivity, especially in terms of the surface-3 km TOC, Fig. 3  shows the integrated AKs for the surface-3 km, 4-6 km and surface-6 km TOCs, averaged over all pixels of our data set having thermal contrast between 0. 0 and 1. 0 K. The integrated AKs for the surface-3 km and the 4-6 km TOCs are partially overlapped, thus indicating that, on average, the MAGEAQ-TIR would not be able to completely separate the surface-3 km column information. In any case the AKs are not completely overlapped, and therefore it is possible to retrieve partially independent information. This result is coherent with the average DOF of 0. 57, as shown in Fig. 2. The AKs for a strongly positive thermal contrast (> 5 K) are only a little more separated (not shown here). Fig. 3. Mean integral averaging kernel functions for the surface -3 k (green) TOCs, for all pixels in the dataset having thermal contrast be 25 Fig.
Our goal is to evaluate all these components together, thus, the uncertainties coming from both the limited vertical sensitivity and the propagation of the radiometric (measurement noise) error. Tables  4  and 5  report the mean absolute and percent biases and RMSEs (root mean square errors) of the surface-6 km, and the surface-3 km TOC pseudo-observations, respectively. For both columns, the statistical parameters of the comparison are calculated for the whole ensemble of the data, and, as done previously for the vertical sensitivity, for DT/NT and land/sea surface subsets, with all different possible combinations. The MAGEAQ-TIR surface-6 km TOC pseudo-observations show biases generally smaller than 1 % in magnitude. Also for the MAGEAQ-TIR surface-3 km TOC pseudo-observations the mean biases are small, with an average underestimation of -2 % over the whole data set.