dataesr/scientific-paragraphs-categorization huggingface dataset:
Context. Since 2019, the direct imaging B-star Exoplanet Abundance STudy (BEAST) at SPHERE@VLT has been scanning the surroundings of young B-type stars in order to ascertain the ultimate frontiers of giant planet formation. Recently, the 17 +3 -4 Myr HIP 81208 was found to host a close-in (∼50 au) brown dwarf and a wider (∼230 au) late M star around the central 2. 6 M primary. Aims. Alongside the continuation of the survey, we are undertaking a complete reanalysis of archival data aimed at improving detection performances so as to uncover additional low-mass companions. Methods. We present here a new reduction of the observations of HIP 81208 using the patch covariance algorithm (PACO), a recent and powerful algorithm dedicated to processing high-contrast imaging datasets, as well as more classical algorithms and a dedicated point spread function subtraction approach.
2023 ) -with their frequency being anticorrelated with binary separation  (Wang et al. 2014 ) -as well as triple and higher-order planethosting systems in strongly hierarchical configurations  (Roberts 2015; Cuntz et al. 2022). Indirect techniques have identified a few systems where both components host substellar companions (see, e. g. ,  Desidera et al. 2014; Lissauer et al. 2014; Udry et al. 2019) ; Based on data obtained with the ESO/VLT SPHERE instrument under programs 1101. C-0258(A/E). notably, HD 41004 stands out due to its close A-B separation (∼23 au): with a m sin i = 18 M Jup brown dwarf orbiting at 0. 017 au from component B (0. 4 M ) and a m sin i = 2. 5 M Jup companion around component A (0. 7 M ) on an orbit with semi-major axis a = 1. 6 au and a large eccentricity e = 0. 4  (Zucker et al.
Data reduction Data reduction was performed on the COBREX Data Center, which is a modified and improved server based on the High Contrast Data Center, (HC-DC, formerly SPHERE Data Center;  Delorme et al. 2017). The COBREX Data Center aimes to improve the detection capabilities with existing SPHERE images by means of the patch covariance (PACO) algorithm. More specifically, we used PACO ASDI  (Flasseur et al. 2018 (Flasseur et al. , 2020b,a) ,a)  as well as the No-ADI routine embedded in the SPHERE speckle calibration software (SPECAL;  Galicher et al. 2018 ) as postprocessing algorithms. The prereduction pipeline (i. e. , going from raw data to a calibrated 4D datacube) is identical to the one implemented in HC-DC, performing dark, flat, distortion, and bad pixel corrections. PACO models the noise using a multi-Gaussian model at a local scale on small patches, allowing for a better estimation of the temporal and spectral correlation of the noise.
Orbital properties We ran the emcee code (Foreman-Mackey et al. 2013) to derive information on the orbital parameters of the companion starting from the astrometry and their best-fit masses of Cb and C. We used their relative astrometry, as measured by PSF subtraction, because it is affected by much smaller uncertainties than absolute astrometry (Appendix A). The sampling tool is based on the emcee 3. 0 library, using a mix of custom move functions to alleviate potential multimodality problems and the cyclicity of angular variables. We note that 100 walkers, between 100 000 and 400 000 iterations, and ten temperatures were used. The priors include a uniform log prior for sma (a ∈ [0, 80] au). The upper value in sma corresponds roughly to 0. 3 times the projected separation between A and C, which, following  Musielak et al.
Acknowledgements. This project has received funding from the  European Research Council (ERC)  under the  European Union 's  Horizon 2020 research and innovation programme ( COBREX ; grant agreement n •  885593 ). SPHERE is an instrument designed and built by a consortium consisting of  IPAG (Grenoble, France) ,  MPIA (Heidelberg, Germany) ,  LAM (Marseille, France) ,  LESIA (Paris, France) ,  Laboratoire Lagrange (Nice, France) ,  INAF -Osservatorio di Padova (Italy) ,  Observatoire de Genève (Switzerland) ,  ETH Zürich (Switzerland) ,  NOVA (Netherlands) ,  ONERA (France)  and  ASTRON (Netherlands)  in collaboration with  ESO. SPHERE was funded by  ESO , with additional contributions from  CNRS (France) ,  MPIA (Germany) ,  INAF (Italy) ,  FINES (Switzerland)  and  NOVA (Netherlands). SPHERE  also received funding from the  European Commission Sixth and Seventh Framework Programmes  as part of the  Optical Infrared Coordination Network for Astronomy (OPTICON)  under grant number  RII3-Ct-2004-001566 for FP6 (2004 )(2005)( 2006 )(2007)(2008), grant number  226604 for FP7 (2009 )(2010)(2011)(2012) and grant number  312430 for FP7 (2013 )(2014)(2015)(2016).
This work has made use of the  SPHERE Data Centre , jointly operated by  OSUG/IPAG (Grenoble) ,  PYTHEAS/LAM/CeSAM (Marseille) ,  OCA/Lagrange (Nice) ,  Observatoire de Paris/LESIA (Paris) , and  Observatoire de Lyon (OSUL/CRAL). T. H. acknowledges support from the  European Research Council  under the  Horizon 2020 Framework Program  via the  ERC Advanced Grant   Origins 83 24 28. G. -D. M. acknowledges the support of the  DFG priority program SPP 1992 Exploring the Diversity of Extrasolar Planets  ( MA 9185/1 ) and from the  Swiss National Science Foundation  under grant  200021_204847  PlanetsInTime. Parts of this work have been carried out within the framework of the NCCR PlanetS supported by the  Swiss National Science Foundation. R. G. and S. D. acknowledge the support of  PRIN-INAF   2019 Planetary Systems At Early Ages (PLATEA ).
This research has made use of the SIMBAD database and VizieR catalogue access tool, operated at  CDS, Strasbourg, France. This work is supported by the  French National Research Agency  in the framework of the  Investissements d'Avenir program  ( ANR-15-IDEX-02 ), through the funding of the " Origin of Life " project of the  Univ. Grenoble-Alpes. This work was supported by the  Action Spécifique Haute Résolution Angulaire (ASHRA) of CNRS/INSU  co-funded by  CNES. This research has made use of data obtained from or tools provided by the portal http://exoplanet. eu/ of The Extrasolar Planets Encyclopaedia.
While, initially, work on language workbenches focused on supporting the syntax and static semantics of DSMLs (and providing editors and static analysers), leaving execution primarily to the development of template-based code generators, more recently there has been a growing interest in language workbenches for executable DSMLs (xDSMLs, e. g. , see chapter 26 of  [21]  or  [8] ). Here, in addition to a specification of the language syntax, language engineers provide a specification of the DSML's execution semantics (aka. behavioral semantics) and the language workbench uses this to provide additional services such as (omniscient) debuggers and analysis tools. This has enabled the efficient development of execution and analysis support for new DSMLs. To date, most language workbenches support the specification of an execution semantics in the form of a sequence of steps (i.
In this paper, we demonstrate how key abstractions can be used to handle the concurrency in a behavioral semantics independently of the way it is actually encoded. Based on these abstractions, we demonstrate how a generic execution engine supporting a given set of common services can be implemented. We show how this generic execution engine is able to embrace two very different ways to specify the concurrency in an operational semantics. We show how such an implementation can be used to provide a protocol for analysis techniques such as concurrent omniscient debugging. We also show how we can give additional control over concurrency to the language engineer and language user to enable the dynamic exploration of a language's concur-rency model. We have implemented our approach in the GEMOC Studio language workbench  [8] , but the overall approach is applicable to any language workbench, possibly using different technological spaces  [30].
To define the concurrent operational semantics of our xDSML, we first need to differentiate the runtime state of a model from the static parts of the model. In any executable model, some parts are static (aka. abstract syntax tree), and some others correspond to the runtime state, also called the dynamic state. For instance, if one considers the concept of Variable in a language, its type and its initial value are static parts of the model while the current value of the variable is part of the runtime state. While both the model and the runtime state will be accessed by the semantics, only the runtime state can be changed during execution. The GEMOC studio  [10]  supports a modular definition of both parts (i. e. , separate cross-referenced metamodels that are subsequently woven together).
parts -> size () = 0) implies Relation Precedes ( s e l f. Machine -> first (). doWork , s e l f. doMoveAlong ) them simultaneously as decided by the user, this way allowing exploration of different acceptable execution paths  [53]. We also implemented a second version of the same concurrent operational semantics for the motivating example using MoCCML  [17, 16] , a dedicated metalanguage to formally define partial orders, and Kermeta 3  [24]  to define the rewriting rules as object-oriented and imperative methods. For instance, the generate-Head in Kermeta 3 is shown in Listing 1. Nothing in Listing 1 specifies when the rewriting rule should be called. This is the goal of the MoCCML model  [10]. For this purpose, each rule is associated to an event and the events are constrained together based on the static information in the model.
Concurrency Model In order to introduce the concepts of concurrency model and concurrent execution trace, we rely on an introductory example. Let us consider the simple language S composed of Statements where a statement can be an Action, a Fork with its set of Blocks of statements that can be executed concurrently, or a Join. Figure  4  provides a program written in the S language. In this example, the sequence B; C can be executed concurrently with the sequence D; E; both after A and before F. Additionally, the C must always follow B and E must always follow D. This is a partial order that can be represented like in Figure  5  by a set of Precedes constraints between the application of rewriting rules. In this partial order, any total order is a correct execution with respect to the concurrent operational semantics.
A Generic Framework for Concurrent Model Execution The GEMOC Studio subsumes the Eclipse Modeling Framework  [42]  and its ecosystem which provides the Model Editing Server either for textual editing (thanks to Xtext 5  which supports the Language Server Protocol (LSP)) or graphical editing (thanks to Sirius 6  which supports the Graphical Language Server Protocol (GLSP)). Within the GEMOC Studio, two concurrent metalanguages are already included to specify DSL execution semantics with possible concurrency, namely MoC-CML combined with Kermeta  [10]  and Henshin  [43]. While each approach provides unique constructs leading to some differences in the expressivity as discussed in the previous section, the proposed framework offers a unified way to interact with the resulting execution engine and drive the possible executions of a conforming model.
Implementation We have implemented our complete approach in the GEMOC Studio language workbench for executable domain-specific modelling languages  [8]. The code is opensource (EPL-1. 0) and can be found on Github 11. The GEMOC Studio uses the concept of an execution engine to separate the operational semantics of an xDSML from generic IDE features such as omniscient debugging or behavioural analysis. Most execution engines available for the GEMOC Studio are sequential ; that is, they do not support the concurrent execution of steps. We have implemented a generic abstract concurrent execution engine for the GEMOC Studio, which allows support for specific concurrent metalanguages to be developed as sub-classes. Each one of these metalanguage integrations provides, for all xDSMLs implemented using the corresponding metalanguage, the complete interface for concurrent operational semantics runtimes presented in Sect.
4 and Sect. 5. Figure  10  shows a 11 Links to the Github repositories and to a working build of the implementation can be found in the companion web page: http://gemoc. org/concurrency2021/ screenshot of the GEMOC Studio running the motivating example model. To integrate a new concurrent metalanguage in the GEMOC studio, a sub-class of the generic abstract concurrent execution engine needs to implement two methods (cf. Figure  11 ): 1. computeInitialLogicalSteps() corresponds to com-puteSymbolicSteps in Figure  8. It returns a Choco  [25]  Model encoding a constraint over a set of Small-StepVariables-special boolean variables that are each linked to a specific SmallStep object. 12  2. executeSmallStep(smallStep) corresponds to ex-ecuteAtomicStep in Figure  8. The generic concurrent execution engine can be configured with a set of concurrency strategies, which are automatically applied to the symbolic steps.
To allow the definition of strategies that make decisions based on what part of the runtime state will be accessed or changed by a step (e. g. , the Overlap strategy), we have extended the internal GEMOC API so that each SmallStep is associated with a Footprint that records where in the model the step will affect (cf. Figure  12 ). It is the responsibility of the operational semantics runtime to fill this footprint. Currently, the Henshin-based implementations does so already. For MoCCML, we will extend, in future work, Kermeta 3 (the underlying implementation language for atomic steps) to provide annotation of operations indicating the footprint. We have integrated two concurrent metalanguages in GEMOC Studio, namely Henshin and MoCCML. These are implemented as sub-classes of Abstract-ConcurrentEngine.
Because concurrent models can capture a potentially exponentially large state space using a static constraint similar to conditional breakpoints is not feasible. Instead, it may be necessary to step through a sequence of steps to reach a particular runtime state. Manually stepping through model behaviours for this becomes difficult as the number of possible events rises. Our concurrency strategies allow the language user to limit the choice making it easier to reach a runtime state of interest. The video on the companion web page 14  shows an example of this user scenario. In this section, we present how we evaluated the genericity of our approach through our implementation in the GEMOC Studio language workbench.
Concurrency model independence Both integrations of Henshin and MoCCML worked successfully: all the generic code used to drive the execution flow and the use of strategies worked as expected in both cases. We can therefore answer that the proposed approach can work for both concurrency semantics based on implicit concurrency models, and concurrency semantics based on explicit concurrency models. As a complementary note, we can observe that the generic execution engine (i. e. , the reusable code that does not have to be re-written for each metalanguage) is made of 589 LoC (Lines of Code), while the Henshin metalanguage integration is only 182 LoC and the Moccml metalanguage integration is only 256 LoC. Thus, the majority of the implementation code is generic and not specific to any metalanguage, and integrations can be built atop the framework with reasonable amounts of efforts.
Tools definition The concurrent omniscient debugger worked as planned after testing, with both variants of each xDSML (i. e. , the Henshin variant and the MoC-CML variant). No code specific to these metalanguages was needed in the implementation of the tool, which means that this tool can be reused for the concurrent execution of any model executed in the GEMOC Studio, provided that the metalanguages used for the operational semantics were well integrated. We can therefore answer that the proposed framework can be used to define relevant tools for concurrent model execution, regardless how was defined the concurrency model of the the concurrent operational semantics of the considered xDSML.
More recent proposals include Generic Model Environment (GME)  [44] , Metacase's MetaEdit+  [45] , Microsoft's DSL Tools  [11] , Krahn et al's Monticore  [29] , Kats and Visser's Spoofax  [26] , Jetbrain's MPS  [49]. While more and more elaborated, such language workbenches rarely focus on the debugging of models. This preoccupation related to domain specific debugging is recent  [36] ; and few existing approaches propose debugging as a software package. For instance MetaEdit+ provides a specific API as a crude way to debug/animate models from an external software and Spoofax provides a simple hard coded debugger. We can also cite the Debugger Adapter Protocol (DAP 15 ) proposed by Microsoft, which defines the services which are required to enable the debugging of a program independently of the language it conforms to.
4. 1 1 Figure 7 presents an overview of the proposed framework for representing and analyzing model concurrency. It is illustrated on the basis of our implementation within the GEMOC Studio (with dashed lines in Figure7), but can be broadly adopted in any language workbench supporting the specification of the DSL execution semantics with possible concurrency. The GEMOC Studio subsumes the Eclipse Modeling Framework [42]  and its ecosystem which provides the Model Editing Server either for textual editing (thanks to Xtext 5 which supports the Language Server Protocol (LSP)) or graphical editing (thanks to Sirius 6 which supports the Graphical Language Server Protocol (GLSP)).
051 steps. The detector was placed at G = 121 from the sample. The ILL data is available at 10. 5291/ILL-DATA. 8-02-919 and 10. 5291/ILL-DATA. 8-02-951. The lamellar d-spacing of the lipid bilayer was determined from the observed scattering angles 2y of the Bragg peak positions according to d = 2p/q. For the data analysis, we used the software Origin (OriginPro, Version 2016. OriginLab Corporation, Northampton, MA, USA). Neutron scattering length density (NSLD) profiles were constructed using the following equation: r z ð Þ ¼ 2 d X hmax h¼1 F h j jv n cos 2ph d z; ( 4 ) where d is the lamellar spacing of the bilayer in the z direction, z 2 Àd=2; d=2 ½ , F h j j ¼ AE ffiffiffiffiffiffiffiffiffi ffi I h Q h p , Q h is the Lorentz correction factor equal to q for oriented bilayers, I h is the integrated intensity of the hth Bragg peak and v n is the phase of the structure factor, corresponding to [À1,À1, + 1, À1].
For the determination of the membrane lateral spacing, the location of peaks along the O-axis was determined. The data was reduced to intensity vs. O plots for several values of 2y. Gaussian fits were then used to determine the center of the satellite peaks. Numbering of the satellite peak order along the q x axis (h) began at O = 2. 451 corresponding to h = 1. The angle between the peaks (DO) was determined by plotting the peak locations as a function of peak order. The scattering vector q was then determined using eqn (3) where y in this case is the half angle between the two omega peaks. The repeating distance in the membrane plane (d x ) was calculated by d x = 2p/q. (iii). NMR experiments. Solid-state  31  P and 2 H NMR were performed on a Bruker NEO 800 MHz SB spectrometer (Bruker Biospin, France) equipped with a triple 1 H/ 2 H/ 31 P 4 mm MAS probe.
21 The simulation also implements partial orientation/deformation of vesicles, tubes, bicelles, etc. , using the theory developed by Pott and Dufourc. 22 The simulation program for wide line spectra has been developed in FORTRAN and implemented in a user-friendly graphical interface (Microsoft. NET) for Windows platforms. The program is available on demand. Calculation of spectral moments and chain length. For wideline solid-state 2 H-NMR and when the spectrum is composed of a single lamellar phase, spectral moments allow to quantitate thermally-induced spectral changes and were calculated according to Beck et al. 1  and Davis  23  using a FORTRAN code implemented in a user-friendly routine, NMRFriend, by Buchoux et al. 24  Calculation of deuterated chain length is performed according to Douliez et al.
Characterization by neutron diffraction Next, the ability of DoPhPI containing membranes to form oriented bilayer structures was confirmed using neutron diffraction on the instrument D16 at the Institut Laue Langevin (ILL) Grenoble, France. 34 In typical bilayer forming systems, the hydration of lipid films by water vapor leads to the formation of stacks of lipid bilayers separated by layers of water. The repeating structure of these lipid multistacks, composed of the bilayer and the associated water layer, leads to the appearance of Bragg peaks in the diffraction data which can be used to characterize the bilayer structure (Fig. 2 ). 35, 36 ure DoPhPI membrane as a function of temperature. DoPhPI was able to produce two sets of evenly spaced Bragg peaks which confirmed that these lipids form lamellar (bilayer) structures.
Comparison of simulations in 31 P-NMR and 2 H-NMR (Fig. 5 ) is very informative as 2 H-NMR reports only on DPPC partitioning. For instance, for the system DoPhPC/DoPhPI at 25 1C, the lamellar phase amounts 49%, the cubic, 51% whereas 2 H-DPPC is in lamellar phase for 90%. This clearly indicates that at this temperature the lamellar phase is enriched in PC species compared to the cubic that is rather a PI-rich phase. WAXS/SAXS experiments were performed on NMR preparations by transferring the hydrated sample onto a Kapton loop, data collection was performed at 25 1C. After circular integration we obtain the classical Bragg peak representation of diffracted intensity as a function of q = (4p sin y/l), Fig. S9  (ESI †). For lamellar phases, the diffracted peaks ratios scale as 1,2,3,4,5,6. as function of the Miller index h.
Acknowledgements We would like to thank the instructors, TAs, and fellow classmates at the  Marine Biosciences Laboratory course Deep Learning for Biological Microscopy , especially  Jan Funke  ( Janelia ),  Dagmar Kainmueller  ( MDC Berlin ),  Zachary Whiddon  ( University of Louisville ), and  William Patton  ( Janelia ) for assistance on early versions of yoU-Net. We would also like to thank  Bryan Millis  in the  Vanderbilt Biophotonics Center  and  Kari Seedle  in the  Vanderbilt Nikon Center for Excellence  and the  Vanderbilt Center for Imaging Shared Resources (CISR)  for experimental and imaging assistance. We thank  Vanderbilt's Program in Developmental Biology, Microtubules and Motors Club and Molecular Biophysics Training Program  for project feedback and discussion.
Pregnant or breast-feeding women will not be included. Participants will be screened among the population of patients seen at an early psychosis outpatient clinic (Centre d'évaluation des jeunes adultes et adolescents-CJAAD, GHU). Healthy controls will be reached through the healthy volunteers database of the CRC. Participant assessment will be as follows (Fig. 1 , Table  1 ). 1) During the pre-inclusion visit, participants will be informed of all the details of the protocol, orally and in writing, and eligibility criteria will be verified. Then a two-week reflection period will be observed, before the signature of a written consent at the baseline inclusion. 2) The baseline visit will consist of a first visit of three half-day sessions including medical, psychopathological and neuropsychological assessments, biological sampling (described below), and speech recording.
Clinical, psychopathological and neuropsychological assessment A clinical assessment will include anamnestic data collection (socio-demographic characteristics, treatment history, medical history, psychiatric history); a clinical examination with a physical examination, a psychiatric examination, the CAARMS, the positive and negative syndrome scale (PANSS), the Montgomery-Åsberg Depression Rating Scale (MADRS), Social and Occupational Functioning Assessment Scale (SOFAS), and neurological soft signs  [78]. The neuropsychological assessment will include intellectual functioning (WAIS-IV), executive functioning (fluences, attentional capacities, episodic and working memory), and social cognition.