dataesr/scientific-paragraphs-categorization huggingface dataset:
The transmittance calculations are computed for all the diverse set of atmospheric profiles resulting in a large database of level to space transmittances and associated profile variables used for the statistical regression and hence coefficient generation. In the fast model the optical depths for mixed gases and each variable gas are computed from equation 1, converted into transmittances and then combined into 'effective' transmittances as ratios according to the following formulation originally recommended by McMillin et al. (1995): Geosci. Model Dev. Discuss. , https://doi. org/10. 5194/gmd-2018-64 Manuscript under review for journal Geosci. Model Dev. Discussion started: 22 March 2018 c Author(s) 2018. CC BY 4. 0 License. transmittances can prove cumbersome when adding more variable gases and a more recent paper by McMillin et al.
Introduction It is now 16 years since the first data release from the Sloan Digital Sky Survey (SDSS;  York et al. 2000). This Early Data Release, or EDR, occurred in 2001 June  (Stoughton et al. 2002). Since this time, annual data releases from SDSS have become part of the landscape of astronomy, populating databases used by thousands of astronomers worldwide  (Raddick et al. 2014a (Raddick et al. , 2014b)) , and making the SDSS's 2. 5 m Sloan Foundation Telescope  (Gunn et al. 2006 ) one of the most productive observatories in the world  (Madrid & Macchetto 2009). This paper describes the 14th public data release from SDSS, or DR14, released on 2017 July 31. The SDSS has completed three phases and is currently in its fourth phase. SDSS-I and -II conducted a Legacy survey of galaxies and quasars  (York et al.
Data Distribution The DR14 data are distributed through the same mechanisms as DR13, with the addition of a Web application to interactively interface with optical and infrared spectra. We describe our three distribution mechanisms below. These methods are also documented on the SDSS Web site (http:// www. sdss. org/dr14/data_access), and tutorial examples for accessing and working with SDSS data can be found athttp:// www. sdss. org/dr14/tutorials. The raw and processed imaging and spectroscopic data, as well as the VACs, are available through the Science Archive Server (SAS,data. sdss. org/sas/dr14). Data can be downloaded from the SAS directly by browsing the directory structure, and also in bulk using rsync, wget, and Globus Online (seehttp://www. sdss. org/dr14/data_access/bulk for more details).
The data files available on the SAS all have their own data model, which describes the content of each file in detail. These data models are available athttps://data. sdss. org/datamodel. The processed imaging and optical and infrared spectra on the SAS are also available through an interactive Web application (https://dr14. sdss. org). This Web application allows the user to search for spectra based on specific parameters, e. g. , plate, redshift, coordinates, or observing program. Searches can be saved through permalinks, and options are provided to download the spectra directly from the SAS, either individually or in bulk. Previous data releases back to DR8 are available through the same interface. A link is also provided to the SkyServer explore page for each object. Finally, the DR14 data can be found on the Catalog Archive Server (CAS;  Thakar 2008; Thakar et al.
2008). The CAS stores catalogs of the photometric, spectroscopic, and derived quantities; these are available through the SkyServer Web application (http://skyserver. sdss. org) for browser-based queries in synchronous mode and through CasJobs (http:// skyserver. sdss. org/casjobs), which offers more advanced and extensive query options in asynchronous or batch mode, with more time-consuming queries able to run in the background  (Li & Thakar 2008 ). The CAS is part of the SciServer (http:// www. sciserver. org) collaborative science framework, which provides users access to a collection of data-driven collaborative science services, including SkyServer and CasJobs. Other services include SciDrive, a "drag-and-drop" file hosting system that allows users to share files; SkyQuery, a database system for cross-matching astronomical multiwavelength catalogs; and SciServer Compute, a system that allows users to upload analysis scripts as Jupyter notebooks (supporting Python, MatLab, and R) and run these databases in Docker containers.
2001). SPIDERS will also obtain on average ∼10 spectra per square degree over the course of SDSS-IV, but the number of fibers per square degree on a plate is weighted toward the later years to take advantage of the new data from eROSITA. A small fraction of eBOSS time is dedicated to an ancillary program to perform multi-object reverberation mapping for a single 7 deg 2 field. This program (SDSS-RM) aims to detect the lags between the broad-line flux and continuum flux in quasars over a broad range of redshift and luminosity with spectroscopic monitoring, which allows the measurement of the masses of these quasar black holes. Started as an ancillary program in SDSS-III, SDSS-RM continues in SDSS-IV with ∼12 epochs (each at nominal eBOSS depth) per year to extend the time baseline of the monitoring and to detect lags on multiyear timescales.
Data Description DR14 includes the data from 496 plates observed under the eBOSS program; it also includes the 126 SEQUELS plates (already released in DR13) from an ancillary program to take advantage of some of the dark time released when BOSS was completed early. The SEQUELS targets are similar to the eBOSS targets as it was a program to test the selection algorithms of eBOSS, in particular the LRG  (Prakash et al. 2016 ) and quasar algorithms  (Myers et al. 2015). The final ELG target recipe does not follow the one tested during SEQUELS. The new ELG recipe is documented in the DR14 release following the description given by  Raichoor et al. (2017). For the TDSS program, combined SDSS DR9 and Pan-STARRS1 data (PS1;  Kaiser et al. 2002)  are used to select variable object targets  (Morganson et al.
Retrieving eBOSS Data All SDSS data releases are cumulative and therefore the eBOSS data also include the SEQUELS data taken in SDSS-III or SDSS-IV, reduced with the latest pipelines. eBOSS targets can be identified using the EBOSS_TARGET1 bitmask. The summary spAll-v5_10_0. fits data file, which includes classification information from the pipeline, is located on the SAS 139  ; the data can also be queried via the specObjAll table on the CAS.
Redshift Measurement and Spectral Classification Catalog with Redmonster The Redmonster software 140  is a sophisticated and flexible set of Python utilities for redshift measurement, physical parameter measurement, and classification of one-dimensional astronomical spectra. A full description of the software is given in  Hutchinson et al. (2016). The software approaches redshift measurement and classification as a c 2 minimization problem by cross-correlating the observed spectrum with a theoretically motivated template within a spectral template class over a discretely sampled redshift interval. In this VAC, the software has been run on all DR14 LRG spectra. Redmonster was able to successfully measure redshifts for ∼90% of LRG spectra in DR14. This is an increase of ∼15%, in absolute terms, over spectro1d, and nearly matches the most optimistic estimate for the fraction of measurable redshifts as determined by visual inspections.
Since the ancillary programs of APOGEE-1 were largely successful and broadened its scientific scope, APOGEE-2 continues in this vein and DR14 presents some of the first ancillary program data. As in APOGEE-1, the primary stellar targets of APOGEE-2 are red giant branch stars. APOGEE-2 extends the target stellar classes with designated observations of red-clump (RC) stars in the bulge as well as faint stars (e. g. , dwarf spheroidal and halo stream members with  H 14). On top of the APOGEE-led programs, additional data are collected with the MaNGA co-targeting program. For the MaNGA pointings, APOGEE data are collected concurrently, with the targeted fields in the direction of the Galactic caps. To document the APOGEE-2 targeting scheme, a new set of bit flags is employed in DR14: APOGEE2_TARGET1, APO-GEE2_TARGET2, and APOGEE2_TARGET3.
APOGEE DR14 Distance Estimations from Four Groups This VAC provides spectrophotometric distance estimates for APOGEE stars that have been calculated by four groups, using slightly different isochrone techniques. All groups used the DR14-calibrated ASPCAP stellar parameters, if they fall inside the calibration ranges (see J. Holtzman et al. 2018, in preparation). The distances come from (1) the StarHorse code  (Santiago et al. 2016; Queiroz et al. 2018) , (2) the code described in  Wang et al. (2016) , (3) the isochrone-matching technique described in  Schultheis et al. (2014) , and (4) the distance code described in J. Holtzman et al. (2018, in preparation).
The MaNGA samples can be weighted so that they are equivalent to a volume-limited sample. The required volume weights are described in  Wake et al. (2017)  and are provided in the DR14 version of the targeting file. DR14 includes 1278 Primary galaxies, 947 Secondary galaxies, and 447 Color-enhanced supplement galaxies. Which sample a given target galaxy belongs to is given by the MANGA_TARGET1 bitmask (or mngtarg1 in the "drpall" file). Bits 10, 11, and 12 signal that galaxies were selected as Primary, Secondary, or Color-Enhanced targets, respectively. In addition to ∼121 ancillary program targets, ∼50 galaxies were observed as fillers and do not fall into these target categories. They should be ignored in statistical studies of the MaNGA data. MaNGA has also begun observing Milky Way stars in a bright-time survey program called the MaNGA Stellar Library (MaStar) that makes use of MaNGA IFUs during APOGEE-2 observations.
All data products are stored on the SAS athttp://data. sdss. org/sas/dr14/manga/spectro/redux/. Here you will find the drpall summary table as well as the subdirectories that store the reduction output for each plate, both for observations obtained on a specific night and for the results of combining all observations of a given plate into a "stack. " The drpall table may be queried either after downloading this file to disk or through the SDSS CASJobs system. Such queries define selections of galaxies of interest and can return the plate-IFU combination for those galaxies that identifies how they were observed. These in turn can be used to find the SAS directory locations of the corresponding data products. Large downloads can be accomplished via rsync calls as described on the SDSS Web site.
MaNGA FIREFLY Stellar Populations The MaNGA FIREFLY VAC  (Goddard et al. 2017)  provides measurements of spatially resolved stellar population properties in MaNGA galaxies. It is built on and complements the products of the MaNGA data analysis pipeline (DAP; K. Westfall et al. 2018 , in preparation) by providing higher order and model-based data products. These are measurements of optical absorption line strengths as well as the physical properties age, metallicity, and dust attenuation. The latter are derived from full spectral fitting with the code FIREFLY  (Wilkinson et al. 2015 (Wilkinson et al. , 2017) )  using the supercomputer SCIAMA2 at Portsmouth University. The VAC is a single FITS file (4 GB) containing measurements of all DR14 MaNGA galaxies. The catalog contains basic galaxy information from the literature (i.
4. 1 and 6. 4. 2). Finally, we intend for DR15 to mark the first release of the "Marvin" ecosystem, which includes powerful Python tools for seamlessly downloading and querying the MaNGA data as well as a Web interface that provides advanced search functionality, a user interface for the MaNGA data cubes, and the ability to quickly choose and display maps of key quantities measured by the DAP. For eBOSS, future data releases will include the ELG survey results as well as the continuation of the LRG-QSO surveys. They will also include further VACs: in particular, the continuation of the quasar catalog, a detailed ELG catalog, as well as large-scale structure clustering catalogs required for independent clustering analysis. Further improvement on the redshift measurement and spectral classification catalog is also likely.
Such a package should be well validated and have excellent performance characteristics, in particular in terms of speed since complicated amplitude fits can otherwise have unacceptable CPU requirements. This motivated the creation, and ongoing development, of the Laura ++ package, which is described in the remainder of the paper. Laura ++ is written in the C ++ programming language and is intended to be as close as possible to being a standalone package, with a sole external dependency on the Root package  [53]. In particular, Root is used to handle data file input/output, histogrammed quantities, and the minimisation of negative log-likelihood functions with Minuit  [54]. Further documentation and code releases (distributed under the Apache License, Version 2. 0  [55] ) are available from http://laura.
Dalitz-plot analysis formalism Given two variables that describe the Dalitz plot of the P → d 1 d 2 d 3 decay, all other kinematic quantities can be uniquely determined for fixed initial-and final-state (subsequently referred to as parent and daughter) particle masses. The convention adopted in Laura ++ is that the DP is described in terms of m  2 13 ≡ m 2 (d 1 d 3 ) and m 2 23 ≡ m 2 (d 2 d 3 ). Hence, these two variables are required to be present in any input data provided to Laura ++. The description of the complex amplitude is based on the isobar model  [56] [57] [58] , which describes the total amplitude as a coherent sum of N amplitudes from resonant or nonresonant intermediate processes. 2 This means that the total amplitude is given by A m 2 13 , m 2 23 = N j=1 c j F j m 2 13 , m 2 23 , (3) where c j are complex coefficients, discussed further in Sec.
( ) B → π + π -K 0 S , there is a further complication that must be considered. In the example given, if one chooses for the B decay that d 1 would be π + , d 2 would be π - and d 3 would be K 0 S , one should then define the B decay using the conjugate particles, i. e. d 1 would be π -, d 2 would be π + and d 3 would be K 0 S. In practice, however, one often has an untagged data sample that contains both B and B decays that are not distinguished and so a single definition of the DP must be used. (Flavour-tagged analyses are discussed in Sec. 9. ) Consequently, the amplitude model must account for the incorrect particle assignments for one of the flavours. Due to the choice of convention in Laura ++ this can be handled in a straightforward manner as long as the self-conjugate particle (the K 0 S in the example given) is assigned to be d 3.
Particle definitions and kinematics The most fundamental parts of the code define the properties of the parent particle P and its three daughters d 1 , d 2 and d 3 and their associated kinematics. Allowed types for  3  The information on the decay that is to be modelled is encapsulated within the LauDaughters class, which is constructed by providing the names or PDG codes  [62]  of the parent and daughters. The particle properties are retrieved using the LauDatabasePDG singleton class, which extracts and supplements information from the Root TDatabasePDG particle property class. P are B + , B -, B 0 , B 0 , B 0 s , B 0 s , D + , D -, D 0 , D 0 , D + s and D - s , while the possible daughters types are π + , π -, π 0 , K + , K -, K 0 S , η, η , D + , D -, D 0 , D 0 , D + s and D - s. The LauDaughters object then instantiates a LauKinematics instance, supplying to it the masses of the parent and its daughters.
In order to minimise the amount of information that needs to be recalculated at each fit iteration, a caching and bookkeeping system is employed that stores the amplitudes of each component of the signal model as well as the Gauss-Legendre weights and the efficiency for every point on the integration grid. At each fit iteration it then checks which, if any, resonance parameter values have changed and with which amplitudes those parameters are associated. Only those affected amplitudes are recalculated (for each integration grid point and for each event in the data sample). While greatly improving the speed of fits, this comes at some cost in terms of memory usage, in particular if the integration grid is very fine. If the number of grid points is extremely large a warning message is printed, which recommends that the integration scheme be tuned using the setNarrowResonanceThreshold and setIntegralBinningFactor functions of LauIsobarDynamics to reduce the number of points.
Dalitz-plot distributions Backgrounds in the data sample can be taken into account by including them in the total likelihood defined in Eq. (  26 ). This means that the DP distributions of all background categories need to be provided. In an analogous way to the implementation of the signal efficiency described in the previous section, the DP distribution of each background category is represented with a uniformly binned two-dimensional Root histogram. Background contributions are handled in Laura ++ as follows. Firstly, the names of all background categories need to be provided to the fit model via the setBkgndClassNames function of the appropriate LauAbsFitModel class. Then, each named category needs to have its DP distribution defined and added to the fit model. This is achieved by supplying one (or more if the model subdivides the data to account for effects such as CP violation) LauBkgndDPModel object.
Work flows The Laura ++ package is designed to perform three main work flows: • Monte Carlo generation of toy datasets from a defined PDF, • fitting a defined PDF to an input data set, • calculating per-event weights for an input data sample (usually full detector simulation) from a defined DP model. In this section we describe the setup stages that are common to all tasks, then each of the three work flows in turn, and finally some variations that are available. Code taken from the various examples included with the package is used to illustrate many of these points. These code snippets are in C ++ but it is also possible to use the python bindings that are generated by rootcling when the Laura ++ library is compiled and to write the application code in python. An example that demonstrates how to do this, GenFit3pi.
54 , -0. 84 , false , false ) ) ; for ( std :: vector < L auAbsCo effSet * >:: iterator iter = coeffset. begin () ; iter != coeffset. end () ; ++ iter ) { fitModel -> se tAmpCoef fSet (* iter ) ; } The boolean arguments to the constructor indicate whether the value should be fixed in the fit. Since Laura ++ version v3r1, the ordering of the components is defined by the isobar model (first all coherent resonances in order of addition to the isobar model, then all incoherent resonances in order of addition), and the coefficients are automatically rearranged to match that order. Thus, the user does not need to worry about the order of the components given here. To either generate toy datasets or to fit data, it is necessary to specify the number of events in each of the signal and (if appropriate) background categories.
The Laura ++ work flow requires that these values are specified also in the case of weighting data, although they are not used. In the case of fitting data the given values may be floated, as is often appropriate when additional discriminating variables are included in the fit (see Sec. 6. 2), or fixed, as is usually necessary when only the DP is being fitted. In the former case, if the doEMLFit option is specified the fitted values of the yields can be expected to have the correct Poisson uncertainties. The user should ensure that the specified number of events in the signal and background categories correspond to the number of events in the data file that will be read in to that fit. The number of signal events is set as follows: LauParameter * nSigEvents = new LauParameter ( " nSigEvents " ,500.
Depending on the starting values of the fit parameters it is possible that the fit will converge to one of the local minima. As such it is highly advisable to perform multiple fits to each data sample using randomised starting values for the parameters of the isobar coefficients. As mentioned in Table  2 , the control function useRandomInitFitPars can be used to toggle this behaviour. It is then required only to re-run the executable to obtain a fit based on a new randomised starting point. The applications in the examples directory of the package all include a compulsory command-line option to provide an integer to label the particular fit (or set of fits, if fitting multiple experiments), which is then incorporated into the name of the file containing the ntuple of results for that fit or set of fits.
In order to modify an existing fit code to act as a worker process it is sufficient to modify only the final line: where the additional arguments to the runSlave function are a string and an unsigned integer that specify the hostname (e. g. "localhost" when all processes are running on the same host) and port number on which the master process is listening for connections. The code to start a master process is extremely simple: L au Si mF i tM as te r master ( nSlaves , port ) ; master. runSimFit ( ntupleName , nExpt , firstExpt , useAsymmErrors , twoStageFit ) ; The arguments to the constructor specify the number of worker processes that are expected to connect and the port on which it should listen for connections (a value of 0 indicates that it should use the first available port). The arguments to the runSimFit function specify the name of the file to which the fit results ntuple should be written, the number of experiments to be run and the ID of the first experiment, whether or not asymmetric uncertainties should be determined, and whether or not the fit consists of two stages.
Performance A DP fitting package such as Laura ++ must be highly performing in several different ways. First, it must allow the user to obtain a good fit to data, and to evaluate the goodness of the fit. Several different methods to quantise the goodness of a multidimensional fit have been proposed in the literature and those which are available in Laura ++ are described below. A selection of examples of results obtained using Laura ++ is then given. Another important performance metric is the speed of execution; this is discussed for a number of example uses of the package.
Examples The Laura ++ package has been used for numerous publications by several experimental collaborations and groups of phenomenologists. Below, several examples that demonstrate the features of the package are discussed. In addition, Laura ++ has also been used for various other studies of three-body charmless B meson decays by the BaBar collaboration  [73] [74] [75] [76] [77] , studies of charm decays by the LHCb collaboration  [78] , unpublished studies by several collaborations (for example Refs. [31, 79] ), and investigations into the phenomenology of different three-body decays  [50, 80, 81]. Studies of charmless three-body B meson decays provide interesting opportunities to investigate the dynamics of hadronic B decays including potential CP violation effects. The B + → π + π + π -  [33, 82]  and B + → K + π + π -  [34, 36]  decays have been investigated by the BaBar collaboration using the Laura ++ package.