dataesr/scientific-paragraphs-categorization huggingface dataset:
B. CAF Implementation Method in OpenUH Front-end: Historically, the Fortran front-end of the OpenUH compiler derives from an older version of the Cray Fortran compiler. We modified this front-end to support our coarray implementation. Cray had provided some support for the extended CAF syntax. It could parse the [] syntax for recognizing coarray declarations and coindexed variables, it handled certain CAF intrinsics, and it translated the CAF language features to SHMEM-based runtime calls for targeting distributed systems with global address spaces. In order to take advantage of the analysis and optimizing capabilities in the OpenUH back-end, however, we needed to preserve the coarray representation into the back-end. To accomplish this, we adopted a similar approach to that used in Open64/SLbased CAF compiler  [5] : the front-end emits an intermediate representation which retains the cosubscripts as extra array subscripts.
Furthermore, we extended our front-end to support the set of new intrinsics subroutines/functions defined in Fortran 2008 for the CAF model, added support for dynamically allocating coarrays (where the lower and upper bounds for all dimensions and codimensions are specified at runtime), and we extended our compiler's internal representation for allocatable pointers/arrays to support coarrays. Back-end: In the back-end, we first added a prelowering phase which normalizes the intermediate code (represented as an abstract syntax tree (AST) and emitted from the front-end) to facilitate dependence analysis. Next, we added a coarray lowering phase in which the compiler will generate communication based on remote coarray references. This step currently occurs prior to the Fortran 90 (F90) lowering phase, during which elemental array operations and array section references are translated into loops.
We make use of the higher-level F90 array operations, supported by our compiler's very high-level internal representation, for generating bulk communication. AST nodes for representing single-element array references and array section references are processed to determine if they include cosubscripts, in which case it is a coindexed reference. A coindexed coarray variable signifies a remote access. For certain remote accesses that occur in the code, a compiler-generated temporary local communication buffer (LCB) is allocated for writing to or reading from the remotely accessed elements, functioning as a local source or destination buffer, respectively. In cases where a program variable can be used directly as the source or destination buffer, the compiler may not use an LCB to avoid the additional buffer space and memory copy that it would entail.
Runtime Support: The implementation of our supporting runtime system relies on an underlying communication subsystem provided by GASNet  [7]  or ARMCI  [8]. This work entails memory management for coarray data, communication facilities provided by the runtime, and support for synchronizations specified in the CAF language. We have also added support for reduction operations in the runtime, as well as point-topoint synchronization using event variables. It is expected that both these features will be included in the next revision of the Fortran standard. The communication layer reserves a segment of remotelyaccessible memory -registered and pinned-down for direct memory access by the network -for storing coarrays and other data that should be accessible across images. The structure of this memory segment is shown in Figure  3.
C. Additional Supported Features For Scalability In addition to the work we have done to comply with the current Fortran 2008 CAF model, we have added support for some currently non-standard language features. These comprise support for a set of collective operations, events, and compiler directives for controlling overlap between communication and computation. These features enable the programmer to more easily write scalable CAF codes, while providing facilities to avoid synchronization and communication latency costs. The Fortran standard committee is expected to formally accept language support for an expanded set of collectives and events in a soon to be released Technical Specification (TS) detailing new parallel processing extensions. a) Collectives: Support for collective operations that can operate on distributed data in a scalable fashion is essential.
In the second, backward stage, the recorded data is propagated backward in time. The RTM algorithm assumes that the forward propagated source wavefield and backward propagated data wavefield overlap in space and time at the location of reflectors. This imaging condition is evaluated during the backward pass. As it involves the wavefield from the forward pass, a technique must be employed to allow this wavefield to be recovered at each step during the backward stage. This could be achieved by saving the entire forward wavefield at each time step, and then reloading the appropriate data when it is needed. More sophisticated methods, such as only saving the boundaries of the forward wavefield  [10] , reduce the memory requirement at the expense of additional computations by recomputing the forward wavefield during the backward pass.
Typical seismic experiments involve several thousand shots. Each shot consists of a source wave pulse, usually at a distinct location, and the associated receiver data. A single shot in a production survey typically contains several gigabytes of data. The total acquisition data size is usually in the terabyte range. For example, one dataset acquired from 30 blocks (3 × 3 square miles per block) consists of 82K shots, 460M traces with 3600 samples per trace with total data size of about 6. 6 TB. Shots are processed individually, but potentially in parallel, each requiring tens of thousands of time steps of a 3D eighth-order finite difference propagator on a 3D domain containing billions of cells. Depending on the storage strategy used, significant volumes of data may need to be saved during each time step of the forward pass and recovered during the backward pass to enable the application of the imaging condition.
A. Implementation A full RTM code was developed using Coarray Fortran, capable of processing production data. Both isotropic and TTI propagators were included. A section of the image produced by the code of the 2004 BP model  [12] , is displayed in Fig. 4. This is a synthetic model designed to be representative of challenging sub-salt environments currently being encountered in exploration of the Gulf of Mexico and off-shore West Africa. It consists of more than 1000 source locations spread over 67 km, on a grid discretized into 12. 5m × 6. 25m cells. It was possible to design the code in such a way that only the communication modules were specific to a coarray implementation of the algorithm. This permitted an equivalent MPI version to also be created for performance comparison by merely writing MPI communication modules.
B. Performance The plots in Fig. 6  show the runtime per time step of the CAF and MPI versions during the forward stage of RTM. For the MPI version we used the Intel Fortran compiler, and for the CAF version we used the OpenUH compiler with comparable optimization options. A fixed domain size consisting of 1024 × 768 × 512 cells was used, on a cluster with Intel Nehalem CPUs and QDR Infiniband interconnect. These measurements appear to show good performance of the CAF code: it was up to 32% faster for the isotropic case, while approximately equal to the MPI code for TTI. Recall that for each time step, each image performs halo exchanges of its wavefield data with its neighbors. For the forward stage, the TTI model requires eighteen halo exchanges for two wavefields, while the isotropic model requires only six halo exchanges for one wavefield.
As these performance results was obtained prior to the availability of directives for hiding communication latency (described in Section III-C), the benefits observed for CAF in the isotropic case are offset by the significantly higher communication latency costs of the halo exchanges in the TTI case. Nevertheless, we believe this demonstrates that a production-level industrial code can be developed using CAF, with performance similar to that of an MPI implementation being achievable while retaining the benefits of a compact, clean syntax that is more accessible to the non-expert programmer.
V. PARALLEL I/O IN CAF Although CAF currently lacks support for parallel I/O, for the RTM implementation described in the preceding section we were able to utilize traditional sequential I/O. Each processor wrote its output to a unique file and post-processing was performed to obtain the final resulting image by combining these outputs. To load the relevant portion of the input data on each processor, strided reading was employed. For the number of processors tested, combined with the use of a Lustre parallel file system, this was not found to create a bottleneck. Thus, it was possible to develop a parallel RTM code using CAF, despite the latter's lack of support for parallel I/O. It was suggested, however, that the file system may be overloaded by this approach on larger systems used in production environments.
B. Incorporating Parallel I/O in Coarray Fortran Before a detailed description of our proposed extensions, let us consider the file access pattern illustrated in Fig. 7 , in which multiple images simultaneously access the non-contiguous, shaded portions of the file. The following is a code snippet to read the same file without changing the logical data layout in Fig. 7 , using our CAF extension for parallel I/O. Table  I  enlists the different types of control specifiers within the OPEN statement which are relevant to Parallel I/O support. Some of the key specifiers which have been extended or added have been discussed below: • UNIT: While OPENing a file collectively, all images must use the same unit number in the statement. • FILE: This includes the full path of the file in the file system.
It may be used to reserve space in the file for header information. • ACCESS: Out of the two access modes in Fortrandirect and sequential, performing a shared file access in parallel should be limited to direct-access mode. The WG5 standards committee suggests that sequential access mode should not be supported for parallel I/O. • ACTION: All images must pass the same value (read, write, or readwrite) for the specifier. Data-intensive scientific applications which require representations with multiple dimentional-views of the same dataset can represent the layout while using the OPEN statement. For example, Fig. 8  represents how a series of flat 24 records may be viewed as 8x3, or a 4x2x3 array of records. This allows opportunities for combining the large number of requests to a few. This helps to avoid bottlenecks at the I/O servers, reducing average latency among the I/O servers and the nodes.
D. Parallel I/O Implementation We are currently in the process of implementing the proposed parallel I/O language extensions. For our implementation, we incorporate the use of "global arrays", provided for example in the Global Arrays (GA) Toolkit  [22]  [23], into our CAF runtime. Global arrays are physically distributed in memory, but are accessible as a single entity in a logical global address space through the APIs provided in the GA toolkit. We make use of global arrays as I/O buffers in memory, taking advantage of the large physical memory available on the nodes and the fast interconnect in our HPC system. READ and WRITE statements are implemented using get or put to a segment of this global array buffer in memory. At the same time, an independent group of processes, managed by the runtime, will handle the data movement between the global array buffer and the actual storage devices asynchronously.
VI. RELATED WORK Having an open-source compiler is important for an emerging language as it promotes sharing of ideas and encourages people to freely experiment with it. There have been few public Coarray Fortran implementations to date. Dotsenko et al. developed CAFC  [5] , a source-to-source implementation based on Open64 with runtime support based on ARMCI  [8]  and GASNet  [7]. They used Open64 as a front-end and implemented enhancements in the IR-to-source translator to generate Fortran 90 source code that could then be compiled using a vendor compiler. G95  [25]  provides a coarray implementation which adheres to the Fortran 2008 standard. G95 allows coarray programs to run on a single machine with multiple cores, or on multiple images across (potentially heterogeneous) networks (a license is required in this case for more than 4 images).
There has been an on-going effort to implement coarrays in gfortran  [26] , and an updated design  document for this implementation is maintained online. The gfortran implementation provides comprehensive support for single-image execution, but as of this writing the runtime support (which may be MPI-or ARMCI-based) for multiimage execution is mostly incomplete. Rice University, more recently, has developed an open source compiler for CAF 2. 0  [27]  which uses the ROSE compiler infrastructure. While CAF 2. 0 provides support for "coarrays" that are functionally similar to coarrays as defined in Fortran 2008, their language features diverge significantly from the Fortran 2008 specification. To utilize parallel I/O in CAF applications, one may combine the use of MPI library calls within CAF programs.
However, this negates the goal of enhancing the programmability of data-intensive scientific applications. As illustrated in past examples, one of the strong features of parallel I/O in MPI is the availability of library interfaces to set file-views and read sections of the file. However, as illustrated in the prior code example, the use of MPI requires the programmer to explicitly calculate offsets for performing file I/O and then use different library functions to initialize the view. Since the proposed parallel I/O extension for Fortran allows for direct mapping of the data from the algorithm-domain to the actual application, a compiler's knowledge of the data types of the buffer involved in I/O and the actual control flow of the program itself can help determine the low-level details. Parallel I/O for Unified Parallel C (UPC), an extension to C which provides a PGAS programming mode similar to CAF, has been described  [18].
VII. CONCLUSION In this paper, we described the CAF programming model which has been standardized in Fortran 2008, and its implementation in an open-source compiler. Our implementation of the Fortran coarray extension is available at the OpenUH [09/04 13  :33]  website  [33]. We have demonstrated that a widely used, dataintensive seismic processing application, reverse time migration (RTM), could be implemented using coarrays, and share much of the same code base as an MPI version. Performance was found to be comparable to the MPI implementation, outperforming the MPI version by up to 32% in one setting. The lack of a scalable parallel I/O feature in the programming model still needs to be addressed. We have defined an extension to Fortran for enabling parallel I/O. We are exploring a new approach for implementing these extensions which utilizes global arrays in memory as I/O buffers and asynchronously manages the data transfer between the buffer and secondary storage.
Three-Dimensional Numerical Procedure for Mechanized Tunnelling The model has been developed using the FLAC 3D software  (ICG, 2009)  which is based on the Generalised Finite Difference Method. The analyses have been performed using small strain calculations. The tunnel construction process is modelled using a step-by-step approach, as this has been done by other authors  (Jenck and Dias, 2003; Melis et al. , 2002; Swoboda et al. , 2004; Kasper and Meschke, 2004; Mroueh and Shahrour, 2008; Boubou, 2010; Mollon et al. , 2013; Oreste, 2003; Oreste, 2013). Accordingly, each excavation step corresponds to an advancement of the tunnel face of 1. 5 m, which is equal to the width of a lining ring.
1 • C, in line with the heating demand temperatures as assumed by BREDEM based models, the analysis revealed large variability in the heating demand temperature  [10]. Also, for weekends, the estimated heating duration was only 8. 4 h, almost half of the BREDEM assumption of 16 h. For weekdays, the estimate was about in line with the length of time that BREDEM assumes for weekdays, i. e. 9 h. However, the authors did not analyze when the heating was on over the course of a day. The aim of this paper is to test if the BREDEM default values for heating demand temperatures and heating duration accurately reflect living room temperatures in English homes. The data consists of living room temperatures recorded in 2007-2008 in dwellings across the UK. The measured temperatures are compared to the BREDEM demand heating temperature of 21 • C and according to the default BREDEM heating pattern for weekdays and weekends.
Survey and temperature measurements This study draws on living room temperature data from the Carbon Reduction in Buildings Home Energy Survey (CaRB HES), the first national survey to exclusively focus on energy use in English homes, that commenced in early 2007 (for details, see  [10] ). Households were selected by stratified random sample drawn from the Postcode Address file. Sampling and face-to-face interviews in homes were carried out by the National Centre for Social Research (NatCen). During the interview, householders answered questions on the building characteristics of their home, heating practices, and socio-demographics. For a subset of homes, temperatures were monitored in the bedroom and living room from mid July 2007 to early February 2008. HOBO UA 001-08 sensors were used; these are self-contained data loggers that were programmed to record spot temperature every 45 min, resulting in 32 measurements per day.
Temperature data and data cleaning Living room data was recorded for the winter months, defined as a 92-day period between November 2007 and January 2008, after which point the temperature loggers were withdrawn. A variable expressing average daily external temperature was created based on minimum and maximum temperature at local weather stations within the respondent's Government Office Region  [14]. For no day or region in the data analyses did the average maximum external temperature exceed 15. 5 • C; this is the temperature above which it is assumed that no heating is necessary  [15]. The recorded internal temperature data was screened for outliers, i. e. for recorded temperatures below 10 • C or above 35 • C, and for changes of more than 10 • C in 45 min (indicating, e. g. , possible placement close to a heating source or in direct exposure to sunlight).
Analysing the data The measured temperatures over the 92 days of winter formed the basic unit of analysis. As the BREDEM models assume differences in heating demand depending on weekday versus weekend, the data were divided into weekdays (66 days) and weekends (26 days). During the cold months of winter, when external temperatures were not exceeding 15. 5 • C, BREDEM assumes heating systems must bring the living room to the comfort temperature of 21 • C. In Section 3. 1, the average temperatures for weekdays and weekends are indicated. Then, the measured temperatures during the assumed heating periods are compared to the assumed heating demand temperature. Section 3. 2 examines the probability that homes were heated to below 21 • C, to 21 • C, and above 21 • C. For each home and measurement point, the number of occurrences of temperatures equal to or below 20.
Mean temperature, therefore, would be expected to be higher on the weekends. In the CaRB HES dataset, the mean temperatures over the course of a day were M weekday = 18. 96 • C (SD weekday = 2. 46) and M weekend = 19. 11 • C (SD weekend = 2. 44). As data did not violate the assumption of normal distributions, as checked with the Kolmogorov-Smirnov test, parametric tests were used to compare temperatures; a paired t-test showed that weekend temperatures were significantly higher than weekday temperatures, t(247) = 6. 72, p <. 001. However, the difference was only M difference = 0. 16 • C, indicating that despite seven more hours of assumed heating for weekends by BREDEM, the average temperature was barely higher than for weekdays. To test the BREDEM assumption of a heating demand temperature of 21 • C for certain heating periods, the averages of each heating period were compared against a value of 21 • C.
Fig. 3  shows the probability of temperatures falling into each of the three categories at each measurement point, for weekdays (a) and weekends (b). The average probability -either over the course of a day or at any given measurement point or time period -can be interpreted in two ways: (1) it indicates the percentage of homes with temperatures in the respective categories at the time period or point under consideration and (2) it represents the likelihood of a home drawn at random from the dataset falling into the category over the period indicated. The graphs indicate that throughout the day, including BREDEM assumed heating periods, more than half the homes did not reach the assumed demand temperature. On the other hand, both within and outside assumed heating periods, some homes showed temperatures above 21 • C.
Acknowledgements This work has been done under the " People Energy and Buildings: Distribution, Diversity and Dynamics " project ( EP/H051112/1 ) in partnership with  EDF European Energy Efficiency Research Centre (ECLEER)  and funded by the  Engineering and Physical Sciences Research Council (EPSRC)  and  EDF Energy. The data analyzed in this paper is drawn from the  CaRB Home Energy Survey conducted as part of the Carbon Reduction in Buildings project  ( GR/S94377/01 ). The authors would like to thank  Kevin Lomas ,  Steven Firth ,  Andrew Wright , and  Mike Gentry  for their contribution in creating and managing the data set, and to thank the sponsors for their support.
ACKNOWLEDGEMENTS This research is partially funded by  Science Foundation Ireland (SFI)  via grant  08/SRC/I1403   FAME SRC (Federated, Autonomic Management of End-to-End Communications Services-Strategic Research Cluster ). This research is partially funded by the  European Union  through the  Marie Curie IAPP program  under the grant agreement no. 230684 :  CarMesh: Ubiquitous Wireless Mesh Networks for Next-Generation Personal Digital Automotive Services.
We present the Planck Sky Model (PSM), a parametric model for the generation of all-sky, few arcminute resolution maps of sky emission at submillimetre to centimetre wavelengths, in both intensity and polarisation. Several options are implemented to model the cosmic microwave background, Galactic diffuse emission (synchrotron, free-free, thermal and spinning dust, CO lines), Galactic H ii regions, extragalactic radio sources, dusty galaxies, and thermal and kinetic Sunyaev-Zeldovich signals from clusters of galaxies. Each component is simulated by means of educated interpolations/extrapolations of data sets available at the time of the launch of the Planck mission, complemented by state-of-the-art models of the emission. Distinctive features of the simulations are: spatially varying spectral properties of synchrotron and dust; different spectral parameters for each point source; modeling of the clustering properties of extragalactic sources and of the power spectrum of fluctuations in the cosmic infrared background.
The PSM enables the production of random realizations of the sky emission, constrained to match observational data within their uncertainties, and is implemented in a software package that is regularly updated with incoming information from observations. The model is expected to serve as a useful tool for optimizing planned microwave and sub-millimetre surveys and to test data processing and analysis pipelines. It is, in particular, used for the development and validation of data analysis pipelines within the Planck collaboration. A version of the software that can be used for simulating the observations for a variety of experiments is made available on a dedicated website.