dataesr/scientific-paragraphs-categorization huggingface dataset:
CONCLUSIONS AND FUTURE WORK The methodology and models used to compute EOS and opacities in the Instituto de Fusión Nuclear have been presented in this work. This data are stored in tables suited to be used in radiation hydrodynamic codes like ARWEN. These methods can obtain accurate atomic properties for several materials using well-known models and with a very fast algorithm. Future work will include testing of RADIOM model in simulations and developing a full NLTE module in bigbart and also developing an EOS consistent with the atomic calculations for NLTE. Also a time-dependent ionization routine has been developed  [15]  to get the charge state evolution including NLTE effects and then corrections to the opacities and EOS must be applied to account for this NLTE effects.
[13]  proposes Isolated WDDL to solve this weakness. However, the area increase resulting from this method is comparable to Schaumont technique. To decrease the area increase of Schaumont method, Baddam and Zwolinski  [14]  presented a design technique that separates the true part from the false part of the design by implementing an inverter using XOR gate. This technique may be sensitive to attacks based on glitches. In  [15] , authors propose a constrained placement technique in Xilinx and Altera FPGAs to improve dual signals timing balance, without increasing the design area. But current commercial routing software does not support balanced routing of differential nets. In  [16]  authors propose to achieve a reduction of fanout and number of gates in timing path as a solution to counter routing imbalance.
TW Hya is a well studied disk with a rich set of observed atomic/molecular lines from the near-IR to the submm. Kastner et al. (1997)  were the first to observe molecules such as 12 CO, 13 CO, HCO + , HCN, and CN in the disk around TW Hya. Subsequently,  Thi et al. (2004)  observed a series of CO, HCN, and HCO + lines, whose profiles indicate an origin in the outer disk (R out ∼ 200 AU). The molecular emission arises from gas in Keplerian rotation  (Qi et al. 2006)  and the line ratios require gas temperature gradients different from that of the dust. Salyk et al. (2007)  detected also a series of CO v=1-0 ro-vibrational lines from inside 1 AU. Najita et al. (2010)  report the nondetection of water in the Spitzer/IRS data of TW Hya at wavelengths of 5-14 µm. [Ne ii] and optical forbidden lines originating at 1 -10 AU seem to trace a photoevaporative wind  (Pascucci et al.
Herschel PACS observations Our TW Hya observations are part of the Herschel Open Time Key Project GASPS (P. I. Dent), see  Dent et al. (2013). We initially obtained PACS  (Poglitsch et al. 2010 ) spectroscopy (obsid 1342187238 PacsRangeSpec, 5150 s and obsid 1342187127, PacsLineSpec, 1669 s) centered on 8 selected lines. In a later stage, we obtained a deeper range scan to confirm tentative detections (obsid 1342211845, 41107 s). The observations were carried out in ChopNod mode, in order to be able to remove the emission of the telescope. Fig. 1 : The full set of TWHya PACS spectra obtained from the GASPS program including the deeper range scan. The spectroscopic data were reduced with the stable developers build version 8. 0. 1559 of the Herschel Interactive Processing Environment (HIPE; Ott 2010), using standard tasks provided in HIPE.
(2010a). Details about the 3D Monte Carlo radiative transfer code MCFOST can be found in  Pinte et al. (2006 Pinte et al. ( , 2009)). Details on the thermochemical disk modeling code Protoplanetary Disk Models (ProDiMo) are discussed in a series of papers  (Woitke et al. 2009a; Kamp et al. 2010; Thi et al. 2011b; Woitke et al. 2011; Aresu et al. 2011; Meijerink et al. 2012). Our chemistry is based on the UMIST2007 database  (Woodall et al. 2007). Details on the atomic and molecular data used to calculate the statistical equilibrium and line radiative transfer are provided in Appendix A. The elemental abundances are changed with respect to the original paper to reflect the low metallicity of the original ISM material that formed the disk in the first place (Table  2 ). The data are taken from  Jenkins (2009) , column 7 of his Table  4  and are referred to as 'low metal' case.
1994). The rate leading to OH though varies in the chemistry databases ranging between 1. 16×10 -11 cm 3 s -1 (UMIST, OSU) and zero (KIDA). The HCO + chemistry and its dependence on electron density (and thus metallicity of the gas) is discussed in some more detail in Appendix B. CO in the outer disk forms at the disk surface via ions and ion-molecules such as C + , CO + and HCO + , HOC +. At intermediate layers neutral-neutral chemistry dominates (CH + O, C + NO and O + C 2 ). In all layers, the main destruction mechanisms are photodissociation and/or freeze-out of CO. Deeper into the disk, an equilibrium is reached between thermal-/photo-desorption and freeze-out, except in very shielded regions where H + 3 (generated by cosmic rays) adds to the destruction channel. The water chemistry will be discussed in detail in Sect.
The statistical equilibrium and line transfer of water We tested the formal water line radiative transfer of ProDiMo against the 3D Monte Carlo radiative transfer code MCFOST  (Pinte et al. 2006 (Pinte et al. , 2009) )  for a series of our water lines. The line radiative transfer is implemented such that it uses the level populations from ProDiMo as starting point. To remove gridding uncertainties and possible interpolation uncertainties, we used the same grid (100x70) and Table  6 : Selected CO, water and H 2 lines with their observed fluxes -n. a. denotes not available -  (Salyk et al. 2007; Najita et al. 2010; Zhang et al. 2013)  in the near-and mid-IR wavelength range from the 'standard model' (model 1) and the model with 100 times higher gas mass inside 4 AU (model 14). (1) At the low resolution of Spitzer, the observed fluxes are for a blend of multiple water lines, while the model flux is for the individual line.
Acknowledgements. GM is supported by  Ramon y Cajal  grant  RYC-2011-07920. IK acknowledges funding by an  NWO   MEERVOUD grant. WFT, PW and IK acknowledge funding from the  EU   FP7-2011  under Grant Agreement nr. 284405. CP acknowledges funding from the  European Commission 's 7 th Framework Program (contract  PERG06-GA-2009-256513 ) and from  Agence Nationale pour la Recherche (ANR) of France  under contract  ANR-2010-JCJC-0504-01. Part of the computations presented in this paper were performed at the  Service Commun de Calcul Intensif de l'Observatoire de Grenoble (SCCI)  on the super-computer funded by  Agence Nationale pour la Recherche  under contracts  ANR-07-BLAN-0221 ,  ANR-2010-JCJC-0504-01  and  ANR-2010-JCJC-0501-01.
Today, efficiently implementing an application on shared memory manycore accelerators is a hard task. Linux eases the development, but is not adapted to exploit the maximum of the platform yet. Bare metal programming environments provided with accelerators give a low-overhead access to the platform. However, they increase the complexity of development, mainly due to 4 gaps: each accelerator has its own specific environment; bare metal environments are only supported on the hardware platform or on the proprietary simulator; they have seldom, if ever, execution debugging support; they do not have parallel programming models, and whenever they exist, they are platform-specific. In order to fill the gaps and thus, to lower the barrier to develop on bare metal on shared memory manycore accelerators, we present PACHA.
It features two aspects: a low overhead, Platform Agnostic, Close-to-HArdware (PACHA) programming interface, which allows to handle only one version of the application code for all supported accelerators, and an easy-to-use multi-platform development environment, which abstracts the complexity of each accelerator's development environment. With a x86 support and a Linux compatibility, PACHA offers a functional simulator and all the Linux set of debugging tools. Further, based on the programming interface, three parallel execution models have been ported in order to facilitate the development and comparison of applications. PACHA is currently fully supported for x86 platforms, TILEPro64 and STHORM. A case study on a TILEPro64 is presented: the performance gain using PACHA rather than Linux with OpenMP or Pthread is about 1,8x to 4x, without increasing the development cost.
Introduction Nowadays, embedded systems are exploited to execute high performance applications with strong power constraints. To meet this challenge, shared memory symmetric manycore accelerators are proposed, such as the STHORM platform created by STMicroelectronics and CEA, formerly known as Platform 2012  [1]  , Tilera processors  [2] , Kalray processors  [3] , or Octeon III  [4]. In order to efficiently exploit these platforms, it is required to program and use them correctly, which implies choosing the right triplet {application, parallel execution model, accelerator}. To find it, an accurate solution is to test the application with different parallel execution models on several accelerators. This task requires a long development time, often without fitted tools. Indeed, each accelerator has its particular programming and development environments.
Although Linux is often supported by the accelerators in order to simplify programming, it is not yet adapted to efficiently implement an application on manycore due to its considerable overhead. Constructors often propose a close-to-hardware programming environment to exploid the accelerator efficiently. On Tilera, there is the "Bare Metal Environment" (BME) and On STHORM, there is a low-level runtime. They provide basic primitives to access hardware without an operating system (OS) but they increase the difficulty to program and compare the architectures. Bare metal environments have four issues: (1) They provide similar concepts, but with different interfaces. For the programming interface, the names of data types and functions are different. This forces the developer to write a new version of the application and learn how to use a new programming environment.
Thus, bare metal environments require more efforts and are time consuming to develop an application. In order to reduce the development cost and ease the benchmarking of an application on shared memory manycore accelerators, we propose PACHA, which contains a near zero overhead Platform Agnostic Closeto-HArdware (PACHA) programming interface, an easy-to-use multi-platform development environment and lightweight parallel execution models. PACHA is developed in the C language. A back-end for each platform makes connection between PACHA's Interfaces and the platform. PACHA makes the following contributions: • Opaque unified access to bare metal environment: The PACHA programming interface abstracts the different usages and the complexities of each platform bare metal interface without extra overhead.
Only one version of the application code is handled for all supported accelerators. • Functional simulator: The user is not dependent on the hardware platform or the proprietary simulator. The user can run the application on the host machine (typically Linux workstation). • Complete set of debugging tools: The user also can run the application using the Linux support of the target platform or on the host machine to take advantage of the debug tools provided by Linux. • Unified parallel programming models: Based on the platform-agnostic programming interface, such models ease the comparison and the development of an application on several platforms. Developping on Bare metal and benchmarking application on multiple platforms become available at a low-cost with PACHA. The interface is minimalist, integrating a new platform is thus fast, approximately 600 lines of code.
Currently, four back-ends are implemented in PACHA: TILEPro64 Linux, TILEPro64 Close-to-hardware, STHORM simulator and x86 platforms. The rest of this paper is organized as follows : Section 2 reviews the state of art in programming and comparing memory shared manycore accelerators. Section 3 details the PACHA programing interface and Section 4 presents the multi-platform development environment. Section 5 then illustrates PACHA with a case study on a TILEPro64. It presents an evaluation of the Linux and close-to-hardware back-ends and then compares the closeto-hardware back-end with programming parallel models to the currently most used way, using only Linux with Pthread or OpenMP. Section concludes and introduces our future work.
MultiBench is limited to a thread-based programming model and gives only the opportunity to customize the included computation workload, it does not permit to develop a personal application. To test a given application on several accelerators without handling many versions of the application's code, a minimum of abstraction is required. Linux (with Pthread or OpenMP) and virtual machines  [10, 11]  still have significant overhead and require specific support. There are multi-platform API initiatives aiming efficiency on manycore accelerators, such as OpenACC  [12]  which is based on code directives, MCAPI  [13]  which implies programming with message-passing and OpenCL  [14]  which aims to support heterogeneous platforms using an intermediate representation and runtime compilation. Another way to be close to hardware and test an application on multiple accelerators is to port existing lowlevel runtime such as ExoKernel  [15] , Corey  [16]  or McRT  [17].
However, it may take a lot of time because the software architecture may not be fitted, particularly the separation between functional and hardware-dependant parts. The most adaquate is McRT, which is already willing to run on multiple architecture. Bare metal environments provided by chip vendors are a support for running applications without paying too much system overhead, so debugging and profiling supports are not native. Few tools exist such as  [18]  for NetLogic XLP and  [19]  for asymmetric multiprocessing architectures, using a core with Linux and shared information with baremetal cores. Another solution is to use functional simulators such as QEMU  [20] , but still complex manycores are hard to model. PACHA brings a low-cost way to develop an application on baremetal, with only one version of the code running on several platforms.
A generic set of functions has to be defined. Using the generic data types allows to have a generic definition of functions. Note that using generic types forces the user to manipulate these generic data only with the functions provided by the programming interface. Moreover, several types of return values have to be explicitly defined with a known type (i. e LibC type), which allows the user to print or use these return values in another parts of the code easily. Some return values are constant, such as error codes or status codes. These values are often platform dependent. For example the non-blocking function trying to acquire a lock, can return 0 when the lock is acquired (for STHORM) or 1 (for TILEPro64). So these values of constants have to become generic. • Generic execution context: Independently of the application, an init (and destroy) function have to be implemented to hide all the action to do before the beginning of the real application.
Plus, a generic entry point has to be defined to abstract the entry point of each accelerator. A generic entry point also allows a generic configuration of the platform. For example, if the platform is an emulated platform, the generic entry point hides the need of creating the simulated environment. An overview of PACHA programming interface is presented Table  1. It is developed in the C language and defined by an explicit layer, which creates a clear separation between generic and hardware dependent-code. The explicit layer permits also to add easily generic code between the application and the back-end. This feature can be useful for debugging and profiling, for example, to profile the number of cycles spent to wait for a lock. The programming interface is based on the three principles presented above and allows to get only one version of the code for multiple accelerators without adding an overhead.
The generic types are defined with typedefs. The pre-process replaces the generic type by the platform type, thus there is no overhead at the execution which allows linking with any data type: a proprietary type, a structure, a pointer or a scalar type. In Table  1 , the generic types are italicized. The generic set of functions contains the minimum set of functions in order to exploit the accelerator resources and to give the opportunity to create parallel execution models and complete application. The programming interface is minimalist, Hence, integrating a new platform is fast. The average for our 4 implemented platforms is 600 lines of the C language and 15 of ASM. In order to implement a platform in PACHA, the minimum to have is a memory manager and a locks manager. If the platform doesn't have these libraries, approximately 500 lines of code must be added.
The accelerator resources are reachable by libraries such as memory management, platform management, traces and performances. For synchronization and parallelism, libraries such as locks and tasks are available. Through this programming interface, no parallel execution model is fixed. It makes the assumption that the beginning of the code is executed by all the cores and then each core executes only the code written for it. Thus, multiple parallel execution models can be defined by software, such as pipeline chain (each core has a functionality and data flows through each processing stages), master-slave (a master creates and schedules tasks on different slave cores), fork-join, etc. The functions are defined by static inline function pointing toward the function implemented by the back-end.
Exploiting platforms features This lightweight generic programming environment provides a minimalist interface. To allow a user to evaluate the application using a special feature of a given architecture, a special feature could be used through the programming interface or by adding an extension. Special features can be hide by the platform-agnostic programming interface, that is to say, they are employed to implement the interface. For example, in STHORM there is a hardware synchroniser (HWS)  [21]. It is a hardware module dedicated to speed up generic synchronization constructs. It could be used for implementing the lock library. But, this hardware synchroniser brings more than the lock concept, it brings also events concept and hardware semaphores. Thus, another way to exploiting the specificities is to explicit specific features by adding an extension to the basic PACHA programming interface.
It permits to test with or without the extension and put the concept to the test on other platforms. Indeed, for STHORM, an HWS extension has been added, which provides concepts such as hardware semaphores and events. For the platforms which do not have the feature, it can be emulated. For instance, on the TILEPro64 the event concept has been easily emulated with messages on the network. The emulation allows to handle only one version of code with the explicit feature. The differences between accelerators do not only concern the programming environment, but also the development environment. To allow a non-expert developer to test the application on multiple accelerators, we propose an easy-to-use multi-platform development environment.
The development environment Constructors provide with their platform a development environment containing their own software tools and methods. A development environment is mainly composed of tools to compile, configure the platform and start an application. They require a learning time before it could be used by a new user. Further, bare metal programming environments have a lack of debugging tools and parallel execution models. To reduce the development time, an easy-to-use multi-platform development environment is proposed. It consists in three concepts: (1) abstracting the proprietary development environment, (2) Linux compatibility and (3) platform independent parallel execution models.
Abstracting proprietary development environment Development tools provided by chip suppliers can be different and require specific options. For example, for the configuration of the accelerators, TILEPro64 uses a specific descriptive file and STHORM uses compilation options. For the execution, each environment has its own method to transfer the code and start the accelerator: for a x86 platform, it's only an execution on the host. For TILEPro64, a launcher is involved. All these differences, require that developers go back to the documentation and adapt their development tools such as profiling scripts or makefile. To abstract these differences, our multi-platform development environment has fixed a minimal set of actions. Thus, all the correspondences are done in the back-end implementation, and a user always employs the same actions regardless the targeted platform.
Basic configurations are available to users by shared compilation options, such as the number of cores. For an expert exploitation of the platform, most of the options of each processor are available and custom configurations can be set up. For example, on TILEPro64, which contains a grid of 8x8 cores, it is possible to select any sub grid of the architecture. From the easy-to-use options, the TILEPro64 back-end generates automatically the proprietary description file to configure the platform. This concept allows to switch from a platform to another with only one command. Plus, thanks to the platform agnostic programming interface, an application can be represented by one version of code. So, these two features offer a new way to reduce the development duration of an application: using Linux back-ends.
Linux compatibility to debug applications and speed-up development Close-to-Hardware programming environments do not provide complete debugging tools, and are only supported by the hardware platform and its simulator. These two points can seriously slow down the development of an application. It is why a compatibility with Linux is proposed in our development environment. Indeed, PACHA permits to get only one version of code and quickly switch between platforms, thus if a problem does not depend on the back-end of the platform, it will be fixed thanks to the Linux back-end. Linux provides a complete suite of debugging tools and is widely available. To ease the porting of Linux back-end, a tool is added under the platform agnostic programming interface. Thanks to this tool, two back-ends have been ported in less than one week each, one back-end for x86 platform and one for TILEPro64 (over Linux).
Case study on the Tilera TILEPro64 This section presents a case study of PACHA on the Tilera TILEPro64. An overview of the architecture is presented in Fig 1. We choose this platform for this case study because it is one of the first advanced shared memory manycore accelerator that supports Linux with the OpenMP and Pthread libraries. Two back-ends for the TILEPro64 have been implemented. The first supports the Tilera "Bare Metal Environment" (BME). It was implemented in two weeks, which includes learning time of BME. The second is a Linux back-end, using the Linux environment already ported by the Tilera team to the TILEPro64 architecture. It was implemented in few days, thanks to the Linux tools already present in the development environment (section 4. 2). We did not implement the application natively on BME because, as one of the problems that we have described before, BME has no debug tools and no parallel programming models.