dataesr/scientific-paragraphs-categorization huggingface dataset:
13 ), or enters the location numerically. The web site then notifies the server system that a WRF-SFIRE forecast has been requested. Given the ignition point, a Python script on the server generates a series of name lists with the correct parameters describing the fire simulation domain, which has 36 × 36 cells on the atmospheric 444 m mesh, and 360 × 360 cells on the fire 44 m mesh. The ignition point is as close to the center as possible. Static surface data on the fire simulation grid are generated and downscaled data from the 1. 333 km simulation, and the fuel-moisture forecast at 444 m are interpolated to the fire mesh grid. In about 10-12 min, the first hour of the forecast is produced, and within 30 min, a 6 h fire forecast is staged for download on the website. In addition to animations, the web site also creates Google Earth-based maps of fire spread, intensity, and area coverage.
Acknowledgements. This research was partially supported by the  National Science Foundation (NSF)  grants  AGS-0835579  and  DMS-1216481 , and the  National Aeronautics and Space Administration (NASA)  grants  NNX12AQ85G  and  NNX13AH9G. This work partially utilized the Janus supercomputer, supported by the  NSF  grant  CNS-0821794 , the  University of Colorado Boulder, University of Colorado Denver , and  National Center for Atmospheric Research. The wildfire system for Israel was funded by the  Israel Public Security Ministry. Edited by:  J. -B. Filippi  Reviewed by: two anonymous referees.
This region is chosen because it encompasses the atmospheric patterns that influence surface temperature and precipitation over Europe  (Hurrell et al. , 2003; Cassou et al. , 2005). Of course other reanalysis datasets or climate model simulations could be substituted to the NCEP reanalysis, for instance CMIP5 simulations  (Taylor et al. , 2012). Each day j between 1 January 1948 and 31 December 2012 can be written: j = y10 4 + m10 2 + d, (1) where y is the year  (between 1948 and 2012) , m is the month (between 1 and 12) and d is the day (between 1 and 31). In the sequel, days of the year are encoded in this manner. By convention, the calendar day of j is: κ(j ) = m10 2 + d. (2) For each "target" day j , the set S j of days j = y 10 4 + m 10 2 + d is determined, where y = y, and the calendar distance δ(j, j ) between j and j is less than 30 days.
This operation can be repeated for an arbitrary number of time steps. The outcome of this simulation is a sequence j of dates of analogues: j = {j 0 ,. , j N }. ( 16 ) If one is interested in simulating weather conditions for a given season, one can initialise j 0 with a random year and a calendar day starting the season (e. g. 21 March, June, September or December) and let the weather generator run for 90 days and an arbitrary number of seasons. This type of Monte Carlo simulation (simulating a large number of seasons) can be done in parallel, in order to increase the efficiency of the computation. The weather generator code has been tested on a computing server with 2 to 8 CPUs. The goal of this method for exploiting analogues of circulation is to generate potentially new sequences of (already observed) weather patterns.
Data In principle, the weather generator can simulate temperatures for any location, provided that it yields observations. We opted to focus on European temperatures. The European Climate Assessment and Data (ECA&D) dataset provides a regularly updated set of observations done by meteorological services over Europe  (Klein-Tank et al. , 2002). Time series are provided on a daily timescale. The data have been homogenized and quality checks were performed by the data providers. Data and metadata available at http://www. ecad. eu. A subset of 291 series from the 1872 average temperature time series of ECA&D (TG) was selected. Time series starting before 1948 and ending after 2012 (hence covering the NCEP reanalysis period) were chosen. Stations for which more than 10 % of data are missing or doubtful were removed.
Summer temperatures In those sets of experiments, the summers were initiated on the 21st of June. The five quantiles  (5, 25, median, 75 and 95)  of temperature anomalies from the ECA&D database are shown in Fig. 3  (left column), for reference. 90 % of temperature anomaly values range between -6 and 10 simulations are shown in Fig. 3  (central and right column) for the static and dynamic weather generators. The static weather generator has a generally slight warm bias (< 0. 6 • C). The bias is less than 0. 2 • C in France or Great Britain. The bias for the dynamic weather generator is slightly positive for the lower quantiles (< 0. 4 • C). It yields small negative values (< 0. 2 • C), especially in Germany, for the upper quantiles. The extreme summer conditions were simulated with initialisations on 21 June 2003.
Winter temperatures In those sets of experiments, the summers were initiated on the 21st of December. The five quantiles (5, 25, median, 75 and 95) of temperature anomalies from the ECA&D database are shown in Fig. 7  (left column), for reference. 90 % of temperature anomaly values range between -14 and 10 • C. For each quantile, the differences between observations and simulations are shown in Fig. 7  (central and right column) for the static and dynamic weather generators. The static weather generator has a generally warm bias (< 1 • C) (Fig. 7 , central column). The bias is less than 0. 6 • C in France or Great Britain. This warm bias is larger for the extremely low quantiles (5th quantile), especially in central Europe. The bias over Western Europe for quantiles above the 25th are generally smaller than 0.
g. heatwaves or coldspells). In terms of regional climate simulation, this corresponds to a nudging procedure with observed large scale conditions. -the generation of ensembles of trajectories from given initial conditions. This is useful for assessing probability distributions of events, for instance by choosing initial conditions preceding the events. This feature is similar to a numerical weather forecast, although it uses an already computed reanalysis dataset as a basis (or could use any model simulation). Such an option is a very cheap alternative (albeit with no physical constraint) to real atmospheric model simulations, although large ensembles can be achieved without the use of a supercomputer. AnaWEGE was tested on European surface temperatures, from the ECA&D data  (Klein-Tank et al.
Methods: We measured CT in 31 subjects without ocular diseases using Spectralis EDI SD-OCT. The choroid-scleral interface of the acquired images was first enhanced using a post-processing compensation algorithm. The enhanced images were then analysed using Photoshop. Two graders independently graded the images to assess inter-grader reliability. One grader re-graded the images after 2 weeks to determine intra-grader reliability. Statistical analysis was performed using intra-class correlation coefficient (ICC) and Bland-Altman plot analyses. Results: Using adaptive compensation both the intra-grader reliability (ICC: 0. 95 to 0. 97) and inter-grader reliability (ICC: 0. 93 to 0. 97) were perfect for all five locations of CT. However, with the conventional technique of manual CT measurements using built-in callipers provided with the Heidelberg explorer software, the intra-(ICC: 0.
Study Subjects and Design Data for this analysis were derived from the Singapore Malay Eye Study (SiMES), a population-based cross-sectional study of eye diseases in Malay adults, age ranged from 40-80 years living in Singapore. Details of the study design, sampling plan, and methodology have been reported elsewhere  [20]. In brief, participants recruited in the current study underwent standardized and detailed ophthalmic examination, including Spectralis EDI SD-OCT imaging (see next section). The study was approved by the Institutional Review Board of Singapore Eye Research Institute. It followed the tenants of the Declaration of Helsinki and written informed consent was obtained from the subjects after explanation of the nature and possible consequences of the study. Spectralis images of 31 subjects were randomly selected using a random number generated in Stata (College par, Texas, USA).
EDI SD-OCT Imaging CT was obtained using Spectralis SD-OCT with EDI modality (Wavelength: 870 nm; Heidelberg Engineering, Heidelberg, Germany) after pupil dilation using tropicamide 1% and phenylephrine hydrochloride 2. 5%. Subjects' keratometry readings and the refraction data were entered into the software program to estimate optical magnification and, therefore, to allow for more accurate comparisons across individuals. A single experienced examiner masked to the clinical diagnosis of the subject performed the EDI-OCT examination. Seven sections, each comprising 100 averaged scans (using the automatic averaging and eye tracking features of the proprietary device), were obtained in an angle of 5u-30u rectangle centered at the fovea. The horizontal section passing through the center of the fovea was selected for analysis.
Measurement of Choroidal Thickness The two major steps in our CT semi-automatic measurement protocol are: (A) post processing of images by adaptive compensation technique and (B) quantitative measurement of CT using Photoshop software. On average, measurement of CT at multiple locations (1. 5 and 3 mm nasal and temporal to the fovea) requires approximately 1 minute per image. (A) Adaptive compensation technique. An accurate evaluation of the CT with EDI-OCT mainly relies on how well one can delineate the choroid-scleral interface (CSI), which anatomically represents the junction between the choroid and the sclera, and is a principal landmark for quantitative measurements of choroid. However, at present identification of CSI is highly variable as there is no algorithm available in Spectralis for its automatic detection.
Therefore, in order to accurately determine CT, once the EDI-OCT image was obtained, the CSI was enhanced using a novel post-processing compensation algorithm  [21]  which greatly improved the detection of CSI by correcting the deleterious effects of light attenuation. In brief, this novel adaptive compensation algorithm improved the ability to detect and visualize the CSI. First, it removes noise over-amplification at high depth and shadow artifacts casted by blood vessels (thus decreasing the intra-layer contrast of the choroid). Second, it improves the visibility of posterior choroid boundary, by significantly increasing the inter-layer contrast across the CSI (Figure  1 ). (B) Measurement of CT using photoshop software. The enhanced images were measured in Photoshop CS6 extended (Adobe Systems Incorporated, San Jose, California).
Statistical Analysis Statistical analysis was performed using MedCalc Version 12. 6 (MedCalc Software, Ostend, Belgium) and SPSS Version 20. 0 (SPSS, Inc. , Chicago, IL, USA). Shapiro-Wilk tests were used to check the normality of CT data at various locations. The reliability of the CT measurement was assessed using intra-and inter-grader agreements between two independent graders, measured by the absolute agreement model of the intra-class correlation coefficient (ICC)  [22]. ICC value of 0. 81-1. 00 indicates almost perfect agreement. Values of less than 0. 40 indicate poor to fair agreement. Bland Altman plot analyses  [23, 24]  were performed to see if there is any proportional bias between measurements. A two-tailed paired sample t-test was used to analyze differences between means in CT by location.
The software, DPDAK (directly programmable data analysis kit), is based on a plug-in structure and allows individual extension in accordance with the requirements of the user. The article demonstrates the use of DPDAK for on-and offline analysis of scanning small-angle X-ray scattering (SAXS) data on biological samples and microfluidic systems, as well as for a comprehensive analysis of grazing-incidence SAXS data. In addition to a comparison with existing software packages, the structure of DPDAK and the possibilities and limitations are discussed.
Data reduction and simple analyses, such as the extraction of invariants  (Porod, 1951)  of the SAXS or SANS curve, are needed to pre-screen the data and have to be carried out before in-depth analyses, often with large amounts of data and in an online fashion directly during the data collection to allow for potential modifications of the experimental strategy. This leads to the following four essential key features for a fast onor offline data reduction and analysis software: (i) an easy adaptation to specific needs; (ii) an online mode enabling a pre-analysis of data in parallel to measurements, with automatic handling of new data as well as the ability to deal with high data rates; (iii) an open-source philosophy, which is essential to verify and extend the functionality and to allow the software to be maintained by a larger group; and (iv) support of Windows and Linux operating systems.
The latter is necessary because most beamlines use Linux for their experiment control, but many users work on Windows PCs. Nowadays there are several tools available; some are listed in Table  1  (for more see e. g. http://smallangle. org/content/software). Most of the reviewed tools are open source and run on both Windows and Linux computers, but either do not have an online mode or have no plug-in or macro interface. In this article, we present a new directly programmable data analysis kit (DPDAK), which includes all required features. DPDAK is now in use at the micro-and nanofocus X-ray scattering beamline at PETRA III (MiNaXS P03) and the Spot SAXS/WAXS beamline at BESSY II (HZB, Berlin, Germany). We provide detailed information about the main features of DPDAK. DPDAK's framework structure is described and the plug-in interface is elucidated so that the software can be extended with new features.
Specifications and features DPDAK is based on a plug-in framework and is currently used as a tool for analysis of WAXS, SAXS and GISAXS data. The software package is written in Python and the motivation for this is based on four major facts: (i) Python is open source and is (ii) well established in the experimental physics scientific community, which results in (iii) a huge variety of packages of algorithms and mathematical tools. Compared to other programming languages, Python has (iv) a simpler syntax, which makes it easier to use for non-computer scientists. The user interface allows for plotting of one-dimensional curves, two-dimensional color maps and scattering images. All plots can be navigated by zooming and panning and allow the range and scaling on the axis to be changed (see screenshot in Fig.
1b ). Current export plug-ins allow for saving data in text files in spreadsheet format. Image sequences can be converted to other file formats or saved as video files. Most of the plug-ins read and operate on images, curves and numerical data. They are processed sequentially to enable online analysis during current measurements. For reading diffraction images DPDAK uses the FabIO Python library  (Knudsen et al. , 2013). It supports a wide range of file formats like tif, mar, edf and cbf and can be extended with new formats in a simple way. DPDAK uses the Python packages NumPy and SciPy (http://www. scipy. org/) for numerical operations and fitting. The graphical user interface (GUI) is implemented using the package wxPython (http://www. wxpython. org/). Matplotlib is used to display any kind of graphs from onedimensional to two-dimensional plots.
The DPDAK Windows version includes a Python installation with all these packages, while the Linux version requires a manual installation. Scattering images can be corrected for background and intensity and binned before integration. Integration is implemented as simple box integration for peak   )  and can be used in any data analysis software. New analysis methods can be added to the API. It also implements a user interface which is currently not designed for online processing. ‡ Scatter is primarily designed for the analysis, modeling and fitting of one-and twodimensional small-angle scattering data of non-ordered, partially ordered or fully ordered nano-and mesoscale structures  (Fo ¨rster et al. , 2010). and median intensity profiles, various GISAXS line cuts, and SAXS integration for azimuthal and radial profiles.
A peak fitting tool for one-dimensional data can be used for data with an arbitrary combination of Gaussian, Lorentzian and pseudo-Voigt profiles and background functions. DPDAK features include integration and calibration of SAXS and WAXS scattering patterns, which is implemented by using either Fit2D  (Hammersley et al. , 1996)  or the pyFAI library  (Kieffer & Karkoulis, 2013). The user can choose between those two methods by selecting the corresponding plug-in -although we recommend the pyFAI method since it is more comprehensible and faster than Fit2D. By combining the pyFAI library from ESRF (European Synchrotron Radiation Facility in Grenoble, France) with the DPDAK GUI, we suggest that this may replace Fit2D, which is no longer being developed. For GISAXS setups, DPDAK allows users to create horizontal line cuts (called out-of-plane cuts) along q y ¼ ð2=Þðcos f sin 2 f Þ and vertical line cuts (called detector cuts) along q z ¼ ð2=Þ Â ðsin f þ sin i Þ, as well as along arbitrary directions in q y , q z.
Workflow and framework structure DPDAK is designed as a flexible online data processing toolkit. An illustration of DPDAKs work-and dataflow is given in Fig. 1(a). During an experiment at a synchrotron the user controls the beamline via the on-site infrastructure, and raw data in the form of scattering patterns are produced and stored. A DPDAK installation runs in parallel to read the raw data directly from a file system and to perform user-defined data reduction processes. The results are stored in the DPDAK database and can be displayed in various forms (images, plots etc. ) to the user. Fig. 1(b ) shows a screenshot of DPDAK during online analysis of SAXS on bone (the data after evaluation are presented in Fig. 2 ). The left side shows the user interface with the file path and several evaluation parameters.
The right side shows four plots representing details of the evaluation of the SAXS data (for details see the applications example in Fig. 2 ). Similar or more complex and accurate analysis of raw data can be performed after the experiment with the user's own 'offline' DPDAK installation. DPDAK is implemented in a framework structure based on plugins (small program units). The basic concept is a model-viewcontroller (MVC) architecture pattern  (Krasner & Pope, 1988). This approach aims to separate the code for the user interface from the application data and the code for user interaction and processing. As a result of this separation the code becomes more structured into specialized individual components, and the application becomes independent of its GUI. The controller implements the data processing, where plug-ins can be connected in a tree-like structure.
The data are sent from plug-in to plug-in and each plug-in adds new data to the output. For each incoming data segment (e. g. detector image) the plug-in structure is processed. The DPDAK framework implements an easy to use storage for all processed data, called the database. For fast access, all processed data are held in memory, except for image files which are linked to their location on a hard drive. The database is implemented as a table-like structure. Each column corresponds to a plug-in output and has therefore a defined type (e. g. a scalar value or a curve). Each row corresponds to a data set, the complete output of one or more plugins at a specific time.
Programming user-defined plug-ins Since Python is an interpreted programming language, developing a plug-in system is possible without the implementation of a scripting language or the need to compile plug-ins. By using the built-in function _import_(name), a text file can be imported as a Python module just by its file name. Therefore, all plug-ins are stored in a plug-in subfolder inside the main program folder and are imported at program start. A new plug-in can be added by creating a text file with the. py extension inside the plug-in folder. The DPDAK framework distinguishes three types of plug-ins: base, display and export plug-ins. A base plug-in is used to read data (detector images, text files etc. ) and process data. The processing of data can vary from simple arithmetic operations up to fitting a model function.
Display plug-ins add new elements to the GUI. They have access to the database to display data, e. g. a plot. An export plug-in can be used to export data from the database to any kind of format. In order that the framework can work with a plug-in, it must make use of a defined interface. There exists one Python class for each plugin type. Those classes contain some methods that must be implemented to make the plug-in work. As most of the users will mainly add base plug-ins, in Fig. 3   in calculating the minimum, maximum, average and sum intensity of an ROI in a detector file. In the description class variable (lines 5-18), the required parameters and the in-and output of the plug-in are defined. Parameters are inputs for the users to control the plug-in. Each defined parameter is automatically generated and shown in the GUI.
In the example (Fig. 3 ), parameters for the position, width and height of the ROI are defined. The input and output information tells the framework which data are needed by the plug-in and which new data will be generated and have to be stored in the database. In this case a detector image is requested as input data and four scalar values are returned as output. Lines 20-32 show the implementation of the getData method, which is called for each data set in the database. The parameters and input are used to calculate the output values. The method needs to return the data as defined.
Results and discussion of application examples In order to give an overview of DPDAK's capabilities, we present five examples of applications. First we show two examples where the nanostructure of biological bone samples is determined by scanning SAXS and WAXS experiments at the Spot beamline at BESSY II (HZB, Berlin, Germany) and at the microfocus beamline ID 13 at ESRF (Grenoble, France). This is followed by two experiments performed at the MiNaXS/P03 beamline at PETRA III (DESY, Hamburg, Germany) which highlight the online analysis of GISAXS experiments to track sputtering of gold on silicon and polymer substrates. The fifth experiment (done at the MiNaXS/P03 beamline at PETRA III) shows a mapping of SAXS data visualizing the flow of polymeric wormlike micelles in microchannels. These examples reflect the following advantages of DPDAK: (i) precise evaluation of data sets with several tens of thousands of data points is only achievable by using tailored plug-ins extracting the expedient parameters (see application examples in Figs.
) and a tailored choice of the most interesting measurement regions. Fig. 1 (b) shows a screenshot of DPDAK during the online evaluation. These data were used to display Figs. 2(b) and 2(c), which show the azimuthal intensity profile and the Kratky plot that are calculated by DPDAK. These can be displayed for each measurement point separately to control and fine tune the evaluation procedure. The colored circles in Fig. 2 (a) show the measurement points, where the color corresponds to the average particle thickness T and the gray triangles represent their preferred orientation, while the gray scale of the triangles refers to the parameter (degree of alignment). Another bone sample was measured at beamline ID13 at ESRF with a 1 mm beam in scanning mode. Example code for a plug-in calculating the sum, the average, the minimum and the maximum intensity of a rectangular region inside a detector image.