dataesr/scientific-paragraphs-categorization huggingface dataset:
VISUAL-TimePAcTS VISUAL-TimePAcTS is a system for analyzing activity diaries  [VFC10]. It uses non-geographical space-time cubes. The cube's two data axes can be mapped to data dimensions such as individuals, locations, or activities. We focus on the case where one axis maps to individuals while the other axis maps to activities. Activities are also encoded using color. VISUAL-TimePAcTS supports linear space flattening on both data axes. Figure  31 (a) shows 6 individuals (horizontal axis) and their activities (colors) across time (vertical axis). Figure  31 (c) shows the evolution of activities aggregated across all people over time. VISUAL-TimePAcTS supports a seamless transition between the two operations through interactive 3D rendering (Figure  31(c) ). Since 3D rendering employs orthographic projection and no shading, it is essentially an oblique flattening operation.
Wakame Wakame [FW10] is a system for visualizing multivariate data by extruding starplots along a time dimension. The base plane of the space-time cube lays out starplots by their geographical location, although any layout could be imagined (Figure  34(a) ). Colors correspond to dimension in the data. For time-cutting, the user selects a single time point on the complementary timeline and the system moves the camera orthogonal to the base plane. Besides the space-time cube systems reviewed in this section, there is a wealth of general 3D visualization systems. Commercial and research tools exist in domains such as geovisualization (e. g. , Voxler [Vox], ArcGIS  [arc] ), scientific visualization (e. g. , VTK  [SAH00] , Matlab [mat] and R  [r] ), and medical visualization  [MTB03]. Although these tools do not treat time as a specific dimension, they can be used to inspire the design of interactive space-time cube systems.
The infovis pipeline is more general but too high-level to capture the similarities and differences between the visualizations we presented. On the other hand, our model is incomplete in that it does not define how the space-time cube is built. To fully support a variety of space-time cube operations on the same dataset, the generalized space-time cube must be implemented as a first-class object, as done in many spacetime cube systems (Section 6). Thus space-time cube operations are best seen as presentation mapping or rendering transformations, i. e. , transformations that turn the abstract visual form into a fully-specified 2D image or 3D model  [JD13]. In other terms, our space-time cube operations can be used to decompose and refine the presentation mapping transformation of the infovis pipeline.
OLAP Cubes Related to both implementation and higher dimensionalities of the generalized space-time cube are data cubes [GCB * 97] in Online Analytical Processing (OLAP cubes). OLAP cubes consist of three data dimensions, selected freely from a potentially high dimensional dataset and do not have to involve a single temporal dimension. In this sense, OLAP cubes could be seen as superset to all space-time cubes. However, OLAP cubes are unable to capture "moving" objects such as animals or nodes in a network (Figure  26 , 1 to 4 ), hence representing only a subset of all space-time cubes. OLAP cubes are meant for querying and aggregating multidimensional data, rather than for visualization and exploration. They are pure logical models, and we are not aware of any visualization system that explicitly uses OLAP cubes.
Acknowledgements We would like to thank the anonymous reviewers, as well as the presentation audience at EuroVis 2014 for their valuable feedback. Collaboration on this work was initiated by  Dagstuhl Seminar  "Putting Data on the Map 12261",  June 2012 , and supported in part by  NSERC ,  SMART Technologies, AITF, Surfnet and GRAND NCE , as well as by  Clique Strategic Research Cluster  funded by  Science Foundation Ireland (SFI)  Grant No. 08/SRC/I1407.
ES-PaDOnS/GRACES spectra were collected in spectroscopic "star only" mode, with a resolution similar to that of all other spectra, and consist of single 300 s observations. All raw frames are processed with the reference pipeline Libre ESpRIT implementing optimal extraction and radial velocity (RV) correction from telluric lines, yielding a typical rms RV precision of 20-30 m s -1  (Moutou et al. 2007; Donati et al. 2008). Least-Squares Deconvolution (LSD,  Donati et al. 1997)  was applied to all spectra, using the same line list as in our previous studies (D15, D16). The full journal of observations is presented in Table  1. Rotational and orbital cycles of V830 Tau (denoted r and o in the following equations) are computed from Barycentric Julian Dates (BJDs) according to the ephemerides: BJD (d) = 2, 457, 011.
Both parameters are derived by looking for the pair that minimizes the χ 2 r of the fit to the data (at constant information content in the reconstructed image), whereas the corresponding error bars are computed from the curvature of the ∆χ 2 paraboloid at its minimum  (Donati et al. 2003). (∆χ 2 is defined as the χ 2 increase with respect to the minimum χ 2 in the map. ) Results are shown in Fig. 7. The differential rotation we derive from our complete data set is slightly smaller (though still compatible at a ≃3σ level) than that inferred from the late-2015 Stokes I LSD profiles only (D16). Despite the fact that this weakening is observed in both Stokes I and V data, we think that this small change likely results from intrinsic variability at the surface of V830 Tau 7. Further evidence that high latitudes of V830 Tau are rotating more slowly than average (in agreement with the differential rotation pattern we recover) comes from the drift to later phases of the polar regions at which the large-scale dipole field component is anchored and where Hα emission is strongest.
FILTERING THE ACTIVITY JITTER AND MODELLING THE PLANET SIGNAL We describe below the results of 3 independent techniques aimed at characterizing the RV signature of V830 Tau b from our data. The first 2 methods are those already outlined in D16 and used to detect V830 Tau b from the late-2015 data alone, that we now apply to both late-2015 and early-2016 data sets, with some modifications to account for the intrinsic variability between the 2 epochs (see Sec. 3. 2). The third one follows the approach of  Haywood et al. (2014)  and  Rajpaul et al. (2015) , and uses Gaussian-process regression (GPR) to model activity directly from the raw RVs. The results obtained with each technique are described and compared in the following sections.
This technique was found to yield results in agreement with those our first direct method gave when previously applied to our V830 Tau data (D15, D16). The method was slightly modified to handle 2 different subsets of data at the same time, following  Yu et al. (2016). The main difference is that, for each set of planet parameters, we now reconstruct 2 different brightness images (one for each subset) with ZDI, both at constant information content; we then compute a global χ 2  r for this dual image reconstruction as a weighted mean of the χ 2 r 's associated with the 2 ZDI images (with weights equal to the number of data points in the subsets). This allows us in particular to handle different brightness distributions for different epochs, without which data cannot be optimally fitted as a result of the intrinsic variability that the spot configuration is subject to (see  Sec.
SUMMARY & DISCUSSION This paper reports the results of an extended spectropolarimetric run on the wTTS V830 Tau, carried out in the framework of the international MaTYSSE Large Programme, using ESPaDOnS on the CFHT, Narval on the TBL and GRACES/ESPaDOnS on Gemini-North, spanning from 2015 Nov 11 to Dec 22, then from 2016 Jan 14 to Feb 10, and complemented by contemporaneous photometric observations from the 1. 25-m telescope at CrAO. This new study is an in-depth follow-up of a previous one, based only on the first part of this data set and focussed on the detection of the young close-in hJ orbiting V830 Tau in 4. 93 d (D16), and of an older one that suspected the presence of V830 Tau b, but from too sparse a data set to firmly demonstrate the existence of the planet (D15). Applying ZDI to our two new data subsets, we derived the surface brightness and magnetic maps of V830 Tau.
Cool spots and warm plages are again present on V830 Tau, totalling 13% of the overall stellar surface for those to which ZDI is sensitive. The brightness maps from late 2015 and early 2016 are similar, except for differential rotation slightly shearing the photosphere of V830 Tau and for small local changes in the spot distribution, reflecting their temporal evolution on a timescale of only a few weeks. The magnetic maps of V830 Tau are also quite similar at both epochs and to that reconstructed from our previous data set (D15), featuring a mainly poloidal field whose dominant component is a 340 G dipole tilted at 22 • from the rotation axis. As for the brightness distribution, the magnetic field is also sheared by a weak surface differential rotation, and is evolving with time over the duration of our observing run.
We detected several flares of V830 Tau during the second part of our run, where one major event and a weaker precursor were strong enough to impact RVs at a level of about 0. 3 km s -1. In addition to generate intense emission in the usual spectral activity proxies including the Hα, Ca ii IRT and He i D 3 lines, these flares Table  5. Summary of our results using the three filtering techniques described in Sec. 4; columns 2 to 4 are for the 2 ZDI-based and GPR methods described in Secs. 4. 1 to 4. 3 and applied to our new data from late 2015 to early 2016, whereas column 5 is for GPR applied to the entire data set (including that of D15). Column 6 recalls the results derived in D16 from the late 2015 data only as a comparison. The first table section lists the derived planet parameters (with M p denoting the planet mass), the second one mentions the inferred GP hyper parameters in the GPR case, and the last one recalls the achieved χ 2 r (to the filtered RVs for ZDI #1, to the Stokes I profiles for ZDI #2 and to the raw RVs for GPR) and the rms dispersion of the RV residuals (whenever relevant).
Parameter We applied 3 different methods to our full data set to further confirm the existence of its hJ, and better characterize its orbital parameters. The first two methods, using ZDI to model and predict the RV activity jitter, are those with which V830 Tau b was originally detected, in a slightly modified version allowing them to handle two different ZDI images (corresponding to the late-2015 and early-2016 subsets) at the same time and account for the potential evolution of brightness distributions between the 2 epochs. Our third technique is fully independent from the 2 others and directly works from raw RVs, using GPR to model the RV activity jitter and MCMC to infer the optimal planet and GP parameters and error bars in a Bayesian formalism, following  Haywood et al. (2014). All 3 methods unambiguously confirm the existence of V830 Tau b and yield consistent results for the planet parameters when applied to our new data; in particular, all are able to reliably recover the RV planet signal (of semi-amplitude 68 ± 11 m s -1 ) hiding behind the activity jitter (of semi-amplitude 1.
Figure10. Variations of ∆χ 2 of the ZDI fits to the late-2015 and early-2016 LSD profiles of V830 Tau (for a fixed spottedness level at both epochs), after removing the reflex motion of a close-in a planet and for a range of orbital periods P orb (actually the ratio of the orbital to rotation period P orb /P rot ) and semi-amplitudes K of the planet RV signature. (This is a 2D cut from a 3D map, with the phase of the RV signal also included as a search parameter). A clear minimum is obtained in the ∆χ 2 landscape, whose projection in a K vs P orb /P rot plane passing through the minimum is shown here. The outer color contour traces the projected 99. 99% confidence interval, corresponding to a ∆χ 2 of 21. 1 for a 3-parameter fit to the 3312 data points of the LSD profiles.
ACKNOWLEDGEMENTS This paper is based on observations obtained at the  CFHT  (operated by the  National Research Council of Canada / CNRC , the  Institut National des Sciences de l'Univers / INSU  of the  Centre National de la Recherche Scientifique / CNRS of France and the University of Hawaii ), at the TBL (operated by  Observatoire Midi-Pyrénées  and by  INSU / CNRS) , and at the  Gemini Observatory  (operated by the  Association of Universities for Research in Astronomy, Inc. , under a cooperative agreement with the  National Science Foundation / NSF  of the United States of America on behalf of the Gemini partnership: the  NSF , the  CNRC ,  CONICYT of Chile, Ministerio de Ciencia, Tecnología e Innovación Productiva of Argentina , and  Ministério da Ciência, Tecnologia e Inovação of Brazil ).
We acknowledge funding from the  LabEx OSUG@2020  that allowed purchasing the ProLine PL230 CCD imaging system installed on the 1. 25m telescope at CrAO. SGG acknowledges support from the  Science & Technology Facilities Council (STFC)  via an  Ernest Rutherford Fellowship  [ ST/J003255/1 ]. SHPA acknowledges financial support from  CNPq ,  CAPES and Fapemig. We finally thank the referee,  Teruyuki Hirano , for his valuable comments that helped us improve the paper.
Therefore, it is not obvious which unique type should be given to a channel like s or, equivalently, to the functions/methods for using it. The solution adopted in conventional (i. e. , non-behavioral) type systems, and that is found in virtually all mainstream programming languages used today, is to declare that communication channels like s can be used for exchanging "raw" messages in the form of byte arrays or strings. It is up to the programmer to appropriately marshal data into such raw messages before transmission and correspondingly unmarshal raw messages into data when they reach their destination. In Java, for instance, the InputStream and OutputStream interfaces and related ones provide read and write methods that respectively read data from a stream to a byte array and write data from a byte array to a stream.
• High-performance computing often relies on parallel processes that synchronize by means of message passing. Chapter 4 describes the use of behavioral types in conjunction with Message Passing Interface (MPI) which is the de facto standard API for high-performance computing. Also in this case, behavioral types provide an effective means for making sure that communications occur without errors. We survey three alternative approaches making use of behavioral types in this context: one based on higher-level structuring abstractions, one based on source code verification, and one based on source code generation. • Chapter 5 describes an application of behavioral types to multiagent systems. The latter have been proved to be an industrialstrength technology for integrating and coordinating autonomous and heterogeneous entities in open systems.
In this setting, the possibility of formally describing interaction protocols in the form of behavioral types enables forms of runtime monitoring for multiagent systems. • Chapter 6 provides an overview of the use of behavioral types in Singularity OS, a prototype Operating System developed by Microsoft that adopts communication as the fundamental and only synchronization mechanism between processes. Sing # , the programming language used for the implementation of Singularity OS, is an extension of C # that comprises both object-oriented and functional constructs and provides a native notion of channel contract, a form of behavioral type. The formal investigation of behavioral types in this setting has led to the discovery of un-forseen system configurations that yield memory leaks and to the development of refined behavioral type theories preventing them.
This translation is done by a separate tool, StMungo. The combination of Mungo and StMungo can be seen as a unification of channel session types with the more general concept of typestate ( §2. 3), in which method availability depends on the state of an object. The distinctive feature of Mungo's approach to typestate is the use of session-type-like syntax for constraints on sequences of method calls, instead of explicit pre-and post-conditions on methods. In the following, we first show a straightforward adaptation of the running example, keeping the same structure as for SJ/Moose. We then show how a class can divide the implementation of the protocol between several methods. The translation of channel session types into object session types is only defined, in the paper, for a language of session types which does not include the while construct (![]* and ?{}*) of SJ and Moose.
We show how the code would be written nevertheless, using the structural type system defined by  Gay et al. [2015]. For brevity we work with channel session types instead of Scribble protocol definitions, and simplify the method names further to send and receive. Let us suppose a global access point serviceAccessPoint has been declared with channel session type ?[?  [Address]. !  [Date] ]. This channel session type gives the translation:  The system works by taking the session type of the whole class and inferring from the method bodies the types the fields will have after each method call. Here the only field initially has a null type because it is not initialized. Then the first method called must be connect with an argument type of AgencyAccessPoint. The body of connect is typable in this context and changes the type of the field to the initial state of PlaceOrderSession.
The next stage of development of typestate systems was Plural  [Bierhoff and Aldrich, 2007, Beckman et al. , 2008]. It is an extension of Java, implemented as an Eclipse plug-in. For alias control it uses a system of fractional permissions  [Boyland, 2003 [Boyland, , 2013] ]  which allows a single reference to an object, with a certain access permission, to be split into fractions which are later recombined to restore the full permission. Plural also supports concurrency by means of synchronization and atomic blocks, and allows typestate specifications to be defined over collections of interacting objects. Moving on from Plural,  Aldrich et al. [2009]  proposed typestateoriented programming, with the goal of integrating typestates directly into a new language design instead of adding typestates to the features of existing languages.
They argue that this approach leads to a cleaner language design and ultimately to better code. Plaid is an object-oriented language following this approach, developed by  Sunshine et al. [2011a,b]. In contrast to Fugue and Plural, the typestates in Plaid are not predicates over concrete states. Typestates are declared in a way which is very similar to classes. Different typestates in Plaid may have the same values for the fields of the concrete state, but the fields of different typestates need not be the same. An object can change its typestate by means of an assignment, written this <-NewTypestate(. ). This can be seen as a dynamic constructor which replaces the current object by an instance of NewTypestate (the arguments to the constructor are used to initialize the declared fields of NewTypestate).
Since then, several implementations of the standard have been developed for different platforms that support hundred of thousands of processing units. MPI programs adhere to the Single Program, Multiple Data paradigm (SPMD), in which a single program specifies the behavior of the various processes, each working on different data and running on a different processor/core. MPI offers different forms of communication, including point-to-point, collective, and one-sided communication. The communication can be characterized along two orthogonal directions: (1) synchronous and asynchronous and (2) blocking and non-blocking (also referred as immediate). The standard includes primitives for all four possible combinations that arise from the fact that MPI communications account for the duration of the transmission.
In this context, behavioral types can be of great help to developers of MPI applications since they allow dedicated tools to check that programs comply to given communication protocols. Example Below is an implementation of the travel agency example in C using MPI primitives (C+MPI). The programmer must craft the communication between Customer and Agency (in this simple case, by sending and receiving messages) in order to realize the desired behavior. The program defines the behavior of both participants at the same time, according to the SPMD paradigm. It starts by initializing the MPI library and by retrieving the process rank, an integer that uniquely identifies each process involved in a parallel computation. In the present case, the process ranked 0 is the customer, whereas the process ranked 1 is the travel agency.
MPI is shutdown with a call to the MPI_Finalize function. Several approaches based on behavioural types have been studied and implemented to verify and/or guarantee the correctness of MPI ap-plications; in the rest of this chapter, we illustrate three of them: one that makes use of high-level, session-based communication primitives ( §4. 1), one based on verification of C+MPI code with the help of userprovided annotations ( §4. 2), and another one based on code generation ( §4. 3). All these approaches rely on so-called global types, a particular kind of behavioral types, that allow for the specification of communication protocols from a neutral viewpoint. A detailed presentation of global types is deferred to Chapters 5 and 8. For the time being, we anticipate that a global type can be projected to an endpoint protocol describing the behavior of a single participant in an interaction.
The theory of session types guarantees, to this point, that the protocol is deadlock free and communication safe by construction. The final step is to guarantee that each process behaves according to each endpoint protocol. The global type corresponding to the Customer-Agency example is shown below, using the syntax of Scribble (see §8. 2): Notice that the endpoint projections of this global type correspond to those presented in §2. 2. 1 and to the behavior of the C+MPI code shown earlier.
Session C Session C  [Ng et al. , 2012 ] is a multiparty session-based programming environment for C that enforces deadlock-freedom, communication safety, and global progress through static type checking. This approach starts with the specification of a global protocol, using a protocol description language such as Scribble, that captures the communication pattern of the parallel algorithm to be implemented. From this protocol, the projection algorithm generates endpoint protocols that guide the design and implementation of each endpoint C program. The endpoint protocol can be further optimized through subtyping for asynchronous communication, preserving the original safety properties. The underlying theory can ensure that the complexity of the toolchain stays in polynomial time on the size of programs.
Session C represents an enhancement from SJ ( §2. 2. 1) in the sense that it can handle multiparty communications directly, whereas SJ treats only binary sessions, and it offers primitives for chaining the binary constructs on different multiple sessions together. As for session delegation, Session C does not handle it since there is less motivation to use session delegation in the multiparty setting; on the other hand, SJ supports delegation. At runtime, Session C offers a significant speed-up (60%) when compared to SJ and to MPI for Java. The programming environment is made up of two main components: a session type checker and a runtime library. The session type checker takes an endpoint protocol and a source code program as input and validates the source code against its endpoint protocol.