dataesr/scientific-paragraphs-categorization huggingface dataset:
The ECMWF data contain also the water vapor and ozone profiles. Water vapor is very important, because it contaminates the spectrum in many wavelength domains, with a large number of lines (figure  2  ). Therefore, the input geolocation parameters that have to be entered by the TAPAS user are: -the UTC time of the observation -the location of the observer in longitude, latitude, and altitude (a list of selected observatories is available in a roll menu) -the RA and DEC of the astronomical target (RA, Right Ascension, DEC, Declination, in the J2000 system). From RA and DEC J2000, TAPAS computes the zenith angle, as an input parameter to the atmospheric transmission. Since an observer may wish to keep confidential its target (defined by RA and DEC), another available option is to give simply the zenith angle and the air mass will be computed by TAPAS.
In order to compute the atmospheric transmission, TAPAS makes use of LBLRTM (Line-By-Line Radiative Transfer Model)  (Clough and Iacono, 1995)  code and the 2012 HITRAN spectroscopic data base HITRAN (this is a high-resolution transmission molecular absorption database, www. cfa. harvard. edu/hitran/, (Rothman et al. , 2011)  for the HITRAN 2008 ). This HITRAN database provides six of the key parameters for each line (or transition), namely the line position, the intensity, the air-and self-broadened half-widths, the temperature-dependence of the air-broadened half-width, and the pressure shift of the line. LBLRTM makes use of all theses parameters. From the user-provided informations, TAPAS computes some other input parameters for LBLRTM , which are: -the zenith angle -the altitude of the observer -the Arletty p-T vertical profile -the H 2 O and ozone profiles from ECMWF.
The atmospheric refraction, which bends the light path and increases slightly the atmospheric path is taken into account. Output parameters: 1. Selection of wavelength reference system. The user may select various systems: Fig. 1. Illustration of data-model adjustment using TAPAS spectra: a high-resolution (R=65,000) stellar spectrum is shown in the region of the 628. 4 nm DIB (top). Data (in red) have been recorded from the Paranal Observatory with the FLAMES-UVES spectrograph at the VLT and adjusted to the convolved product (blue line) of three models shown at bottom: -a stellar model, computed for the appropriate stellar parameters (brown line), -a telluric transmission (blue) and a DIB empirical model (green). The use of the TAPAS transmission allows an optimal adjustment and estimate of the DIB equivalent width.
The atmospheric transmittance for the relevant atmospheric profile was calculated by TAPAS separately for H 2 O (blue) and O 2 (green) in the range 500-900 nm, at the highest possible resolution with HITRAN. The atmospheric absorption lines predicted by the TAPAS model are readily seen on the stellar spectrum. We examine on figure 3 a small 2 nm wavelength interval 627. 5-629. 6 nm where O 2 lines are prominent, by comparing first the star spectrum (black) with the TAPAS O 2 only transmittance (green), convoluted by a Gaussian profile with the FEROS resolution of 44,000. The O 2 atmospheric absorption lines are seen on the star spectrum, but there is an obvious wavelength shift between the two spectra. This is because the FEROS data reduction pipeline makes first an absolute wavelength calibration (with Thorium Argon spectral lines delivered by a dedicated lamp).
We have used three versions of the HITRAN data base, hoping that the observations would show an improvement with the latest versions. In some cases, later versions are obviously better. In many other cases, we found that the remaining spectral features were much larger than the differences between the various O 2 HITRAN data bases. The present version of TAPAS is therefore based, for O 2 , on the latest version contained in the HITRAN web site (December 2012) (except for the continuous absorption, as will be explained later). The three versions are: short name HI08: this is the original HITRAN 2008 data base. short name V10: HITRAN 2008 plus an update for H 2 O, O 3 , and for O 2 as discussed in  Gordon et al. (2011). short name V11: same as V10 plus a correction for the O 2 A band of isotopologue 16 O 16 O.
Conclusions and perspectives In this paper we have described the mechanism by which the TAPAS system provides a model of the atmospheric transmission to the user through a simple web interface. This was the main objective of the paper, and we hope that the users community will find useful this new service for their astronomical research. Their comments and suggestions will be greatly appreciated, and it is foreseen that TAPAS will evolve in response to the suggestions. As a validation exercise of TAPAS, we have  -all the lines predicted by TAPAS/ HITRAN are indeed present in the observed spectra (we have visually scanned the whole spectra with IGOR developed software). -the lines observed in the star spectra are all coming from telluric absorption, except for some well known stellar lines, and some interstellar absorption lines.
Acknowledgements. This work is being supported by  CNES  ( Centre National des Etudes Spatiales ) and  CNRS  ( Centre National de la Recherche Scientifique ) and its  Institut National des Sciences de lUnivers (INSU). It is a collaborative endeavor of LATMOS,  GEPI ,  ACRI  and  ETHER/IPSL. We acknowledge the use of HITRAN data base and the LBLRTM radiative transfer code, the use of ECMWF data and the ETHER data center. We acknowledge useful discussions with  Larry Rothman  and  Iouli Gordon , both in Reims and in Boston. Problems of TAPAS malfunctions should be addressed to  Cathy Boonne  (IPSL), cbipsl@ipsl. jussieu. fr. Other questions should be addressed to one of following e-mails: jean-loup. bertaux@latmos. ipsl. fr,or rosine. lallement@obspm. fr.
Collections of single-molecule restriction maps for each genome were assembled according to overlapping fragment patterns to produce a whole-genome optical-map assembly. The consensus opticalmap assemblies for each evolved clone were then compared to the predicted restriction map of the ancestral strain's genome (70) to identify large-scale rearrangements using the MapSolver software. Rearrangements smaller than ~5 kbp are too small to resolve. Thus, IS insertion events were not detected in this study. Characterization of rearrangement borders. The precise locations of the rearrangement borders were identified (see Table  S1  in the supplemental material) by analyzing the genome sequences of the evolved clones. The genomes of population Ara-1 clones from generations 2,000 to 40,000 were previously sequenced  (44, 71) , as were those of the 40,000-generation clones from populations Ara-3, Ara-5, Ara-6, Araϩ1, Araϩ2, Araϩ4, and Araϩ5  (72).
0. 9. 0), and the resulting FASTA files were analyzed using CLC Sequence Viewer software (v 7. 0. 2; CLC Bio). All sequences were compared to the ancestral genome sequence  (70)  and checked to confirm the rearrangements deduced from the optical maps. A Python script was written to construct FASTA files containing the reconstructed genome sequences of the evolved clones; we have deposited the script at the Dryad Digital Repository (doi:10. 5061/dryad. 283pp). Point mutations and deletions detected in the evolved clones were automatically inserted; other rearrangements were added by hand in CLC Sequence Viewer. The leading-strand branch length was calculated from the origin of replication oriC  (74)  to the middle of the terminus region defined by the dif locus  (75). For the evolved clones, the branch-length measurements were based on the rearranged genomes using the new locations of these two loci.
ACKNOWLEDGMENTS This work was supported by  European Union  program  FP7-ICT-2013-10 project EvoEvo  grant  610427  to D. S. , the  Université Grenoble Alpes (D. S. ) ,  Centre National de la Recherche Scientifique  (D. S. ),  U. S. National Institutes of Health  grant  R00-GM087550  to J. E. B. ,  U. S. National Science Foundation  grant  DEB-1019989  to R. E. L. , and  U. S. National Science Foundation  support ( DBI-0939454 ) for the  BEACON Center for the Study of Evolution in Action. C. R. was supported by a fellowship from the  French Ministry of Education and Research. D. E. D. was supported by a traineeship from the  Cancer Prevention Research Institute of Texas.
1993). According to that, the first crystallographic structures of the heparin and human FGF-1 complexes (pdb code: 1amx and 2amx) corresponded to dimeric structures linked by a regular heparin chain in its native helical structure  (DiGabriele AD et al. 1998 ). However, NMR data in solution corresponded to a 1:1 complex (pdb code: 2erm)  (Canales A et al. 2006). Remarkably, the dimers have two alternative symmetry relationships: while for 1amx the FGF-1 proteins are related by a centre of symmetry, in the case of 2amx, the symmetry element is a plane along the binding site  (DiGabriele AD et al. 1998 ). In addition, the ternary complexes of heparin and FGF with the extracellular domains of the membrane receptor FGFR are assembled into two different forms (pdb codes 1fq9 and 1e0o respectively)  (Schlessinger J et al.
2000)  ,  (Pellegrini L 2001 , Pellegrini L et al. 2000)  The analysis of these structures indicates that the Hep/HS binding site corresponds to a swallow depression on the surface of the growth factor that could be considered divided into two sub-binding sites  (Digabriele AD et al. 1998). Consequently, as heparin does not much change its helical 3D structure upon binding, in the monomeric case as is the NMR complex (pdb code: 2erm)  (Canales A et al. 2006 ) some of its sulfamate groups will be directed towards the solvent and will not interact with the FGF-1, as the structural studies have shown. In order to analyse the heparin-FGF-1 binding mode, 2, a hexasaccharide with axially non-symmetric sulphate groups distribution and unable to form FGF dimers was prepared  (Ojeda R et al. 2002).
The other flow cell was left untreated and served as negative control. For binding assays, 150 µl of FGF-1 (8. 8 nM), co incubated with a range of concentration of the different oligosaccharides, were simultaneously injected, at a flow rate of 50 µl/min, over the control and the HP surfaces. The formed complexes were washed with running buffer for 3 min and the sensorchip surfaces were regenerated with a 3 minute pulse of 2 M NaCl. Control sensorgrams were subtracted on line from HP sensorgrams. The protein data bank structures 1amx, 2amx and 2erm were used for the preliminary studies of docking described in this paper, performed with GLIDE  (Friesner RA et al. 2004 ). The monomer C from the 1amx complex was isolated from the rest of the aggregates and used to prepare the model of the hexasaccharide 3 with FGF-1 by superimposition of the trisaccharide of its reducing end with the one at the non-reducing end of the 1amx and/or 2erm complexes aligning the sulfate groups.
Hydrogens atoms were added to the crystallographic structure when it was necessary using the Maestro protein preparation module. The corresponding hexa-and pentasaccharides were prepared and named consistently and using partial charges from GLYCAM  (Kirschner KN et al. 2008) , ligand preparation module was run and the structure was minimized. A grid (10 x 10 x 10 Å) centered in the glycosaminoglycan was constructed. We first run an Induced Fit Docking with the standard conditions keeping the GLYCAM charges. The resulting structures were submitted to a Single Precision Docking, with a 10 Å grid using GLYCAM partial charges with an electrostatic cutoff of 2. 0. The minimization was performed using OPLS-2005 force field with a dielectric constant of 4r.
Gephi is a network visualization software used in various disciplines (social network analysis, biology, genomics…). One of its key features is the ability to display the spatialization process, aiming at transforming the network into a map, and ForceAtlas2 is its default layout algorithm. The latter is developed by the Gephi team as an all-around solution to Gephi users' typical networks (scale-free, 10 to 10,000 nodes). We present here for the first time its functioning and settings. ForceAtlas2 is a force-directed layout close to other algorithms used for network spatialization. We do not claim a theoretical advance but an attempt to integrate different techniques such as the Barnes Hut simulation, degree-dependent repulsive force, and local and global adaptive temperatures. It is designed for the Gephi user experience (it is a continuous algorithm), and we explain which constraints it implies.
Introduction This paper addresses two different audiences. To Gephi users, we offer a complete description of the ForceAtlas2 algorithm and its settings. To the researchers or engineers interested in the development of spatialization algorithms, we offer a discussion of our choices of features and implementation. If developing an algorithm is ''research'' and implementing it is ''engineering'', then a specificity of Gephi overall, is that it is based in engineering rather than in research. This is why it looks so different to a software like Pajek. This is also why ForceAtlas2 is more about usability than originality. Our contribution to the mathematics of network spatialization is limited to the benchmark of a specific implementation of adaptive speed (step length selection). This paper focuses more on how classical techniques fit together in the perspective of a rich user experience -and which techniques do not.
It is necessary to explain quickly how the user feedback led us to the specific orientation of ForceAtlas2 (a continuous algorithm). In the next sections we will explore the different techniques gathered in this layout, with some formal terminology and many illustrations. We will discuss our implementation of step length selection with examples and a benchmark. And finally we will offer a short discussion about the general design of the algorithm. In 2008 we started to develop Gephi  [1] , a software to visualize and manipulate networks, at the Maison des Sciences de l'Homme in Paris under the direction of Dana Diminescu  [2]. Our goal was to provide some network analysis methods to social scientists, that would not require learning graph theory. Three reference softwares inspired us: Pajek  [3] , GUESS  [4]  and TouchGraph.
TouchGraph offered a manipulative interface that we highly appreciated, but it had serious performance issues and the layout was not adapted to scale-free networks of a hundred nodes or more (high visual cluttering). Pajek is very powerful but not adapted to dynamic exploration (it is designed as a computation software, where visualization is a bonus). GUESS was the most adapted to our needs, being user-centric and implementing state-of-the-art spatialization algorithms such as GEM  [5]. We do not explore here the reasons why we created Gephi rather than just using GUESS, since it is a much larger discussion. However, an important point for this paper is that we wanted a continuous layout, that runs homogeneously and which can be displayed. Visualizing the ''live'' spatialization is a key feature of Gephi.
doi:10. 1371/journal. pone. 0098679. g013 convergence is reached. Even if the measure is not fully satisfying to evaluate the quality, it is a good way to evaluate the speed. Noack's measure has another drawback. It is better when it is lower, which may lead to interpretation issues. We decided to invert the measure to be clearer  (16) : Q(p)~1 Q Noack (p) ð16Þ At each step of the tested algorithm, we compute the quality for current positions. All the layouts, by definition, improve the quality of the spatialization. We compare the best quality they reach, and how many steps are needed to reach a good convergence (performance). Figure  8  pictures the impact of the adaptive local speed feature using this protocol. The featured network is ''facebook_ego_0'' from our dataset. We compare the actual implementation to variants where we fixed the local speed at different values (the algorithm is otherwise similar to the implementation described above).
We observe different scenarios. If the speed is too low (0. 001), the convergence is slow and we do not have enough steps to see the final quality. If the speed is too high (0. 1) the quality stagnates early on, because of oscillations. A medium value of 0. 01 has a good convergence and a good final quality, but the adaptive local speed achieves even better on convergence as well as on final quality. We reproduced this protocol on the other facebook ego-networks of the dataset and the results confirm this behavior, as pictured in Figure  9. We benchmarked our algorithm with a dataset of 68 networks from 5 to 23,133 nodes. We tried to gather varied networks corresponding to the actual use of Gephi (a lot of social networks, and scale-free networks in general). Most of these networks are from the Stanford Large Network Dataset Collection (http://snap.
stanford. edu/data/) and include social networks (Facebook and Twitter ego-networks), collaboration networks (from Arxiv) and autonomous systems (peering information inferred from Oregon route-views). Some networks come from the Gephi datasets, and include biological networks (neural network of C. Elegans, proteinprotein interaction network in yeast). The others are generated with Gephi and include trees, random networks and small-world networks. Our dataset and the description of each network are included in the online repository of the benchmark (https:// github. com/medialab/benchmarkForceAtlas2). We compared four different algorithms: ForceAtlas2 (FA2), its LinLog variant (FA2_LL), Fruchterman-Reingold (FR) and Yifan Hu (YH). We used the default settings, with the exception of a few settings.
On the other hand, the small networks converge in a few steps, and we wanted to be able to spot the moment it happens. We had to track the early steps. As a compromise, we decided to compute layout quality each ''power of 2'' step: 1, 2, 4, 8… up to 2048. The quality evolves a lot at the early stages of the spatialization, and then reaches a more static state. Our protocol provides the early behavior of each algorithm as well as its long-term results. We also observed that some layouts cause oscillations (as pictured in Figure  8 ), so we computed each ''power of 2 plus one'' step: 2, 3, 5, 9… up to 2049. We averaged the quality at each ''power of 2'' step with the next step to remove oscillations. Each network was randomized three times. The three random assignments are saved in the dataset.
You can download the dataset here: (https://github. com/medialab/benchmarkForce Atlas2/blob/master/dataset. zip). The benchmark resulted in 816 records of the layout quality at different steps. You can visualize these records there http://medialab. github. io/benchmarkForce Atlas2/and download them https://github. com/medialab/ benchmarkForceAtlas2/tree/master/benchmarkResults. Each file was analyzed to find the maximum quality, and two key moments. The ''Quick and dirty'' point is reached at 50% of the maximum quality, while the ''Quasi-optimal'' point is reached at 90% of the maximum quality. The first corresponds to an estimation of a rough spatialization while the second approximates a satisfying layout. A sample of these records is pictured in Figure  10 , and the full visualization is available online.
Conclusion As more and more people deal with relational data, network visualization assumes a key importance. ForceAtlas2 is our practical contribution to network sciences. It is not based on a new conception of force-directed layouts but it implements many features from other well-known layouts  [7]  [11]  [5]. However, by its design and features, it aims to provide a generic and intuitive way to spatialize networks. Its implementation of adaptive local and global speeds gives good performances for network of fewer than 100000 nodes, while keeping it a continuous layout (no phases, no auto-stop), fitting to Gephi user experience. Its code is published in Java as a part of Gephi source code (https:// github. com/gephi/gephi/tree/master/LayoutPlugin/src/org/ gephi/layout/plugin/forceAtlas2).
Current and future embedded manycore systems bring complex and heterogeneous architectures with a large number of processing cores, making both parallel programming at this scale and understanding the architecture itself a daunting task. Process Networks and other dataflow based Models of Computation (MoC) are a good base to present a universal model of the underlying manycore architectures to the programmer. If a language exposes a simple to grasp MoC in a consistent way across architectures, the programmer can concentrate the efforts on optimizing the expression of parallelism in the application instead of porting code to a given system. In this paper, we present a process network extension to C called τ C and its mapping to both a POSIX target and the P2012/STHORM platform, and show how the language offers an architecture independent solution of this problem.
e. especially operating systems) and hardware support for advanced system support (threading, memory management, etc. ). To target with reasonable efficiency such systems, a possible path is to provide a safe, high level parallel Model of Computation (MoC) thanks to a programming language and a compiler able to target (several) manycore systems. We have chosen process networks as a suitable MoC for the following reasons: its amenability to strict timing and safety requirements when suitably restricted, its simplicity, its ability to provide a high-level abstraction on the hardware, and the feasibility of an efficient compilation process for it. We show in this paper how such a model is added to C with sound software engineering principles, maintaining compatibility with existing code, and how its compiler and abstraction layer are implemented to target different platforms (homogeneous/heterogeneous) such as a POSIX Threads machine on one hand and the MCAPI communication API for the P2012/STHORM manycore, on the other hand.
Related Works The underlying MoC of τ C can be put in perspective with the revival of dataflow models and process network models  [15]. It belongs to the class of Process Networks (PN), or Kahn process networks  [12]. As a language, τ C is an extension to C; alike Cilk  [6] , OpenCL  [13]  and XC  [19] , it adds a parallel programming model to the C language. It does so by adding new constructs to C (similarly to XC  [19] , and Brook  [7] ), avoids pragmas (as done the OpenStream effort  [3] ) and does not defines a new programming language (as done by StreamIt  [2] ). τ C was first described in a technical report for the Ther@ops project  [10]. Core components of the τ C programming model are similar but a bit less flexible than the core parallel patterns of FastFlow  [1] ; FastFlow SPSC are certainly faster than the τ C POSIX Threads target, however τ C is targeting embedded manycores.
Interfaces and ports The first extension is a type, called interface. It describes the ports of a component, and is written as a sequence of type : port where ports may be arrays (with or without size), and types may be any type except a pointer 1. The following example defines an interface named ISplit with one input port of type char named input, and an array of output ports of type char named output. The colon is here to make the difference between a port of type array of char and an array of port of type char. The chosen syntax is simple and quite common for example in actor languages or stream-oriented languages (StreamIt  [2] ). typedef ISplit : (char : input) -> (char : output[]); A feature of this syntax is that the size of a ports array may be undefined; the effective number of ports in the array should be defined at the point where the task is instantiated in the source code.