dataesr/scientific-paragraphs-categorization huggingface dataset:
This paper deals with the empirical validation of a building thermal model using a phase change material (PCM) in a complex roof. A mathematical model dedicated to phase change materials based on the heat apparent capacity method was implemented in a multi-zone building simulation code, the aim being to increase understanding of the thermal behavior of the whole building with PCM technologies. To empirically validate the model, the methodology is based both on numerical and experimental studies. A parametric sensitivity analysis was performed and a set of parameters of the thermal model have been identified for optimization. The use of a generic optimization program called GenOpt ® coupled to the building simulation code enabled to determine the set of adequate parameters. We first present the empirical validation methodology and main results of previous work.
Furthermore, before integrating PCM into new or retrofit buildings, it will be interested to predict the thermal effects of these materials on the whole building. To contribute to the energy efficiency policy recommendations on buildings energy consumption, a one-dimensional simplified numerical model for phase change material has been developed and implemented in a prototype of building simulation code named ISOLAB. This one is able to take into account the building envelopes, including PCM or not, and the actual impact on energy consumption. Nevertheless, before using PCM model integrated in ISOLAB code and to ensure the reliability of the results, this article focuses on the empirically validation of the latter. We first present the tools used, building simulation code and the generic optimization program GenOpt®.
A building simulation code: ISOLAB Developed by MIRANVILLE, ISOLAB is a prototype of building simulation software developed with the Matlab environment  [15]. Nodal description of buildings and finite difference scheme of the time variable in one-dimensional are used to simulate the dynamic thermal behavior of a monozone or multi-zone building according to its environment (weather data and location). In order to determine temperatures of the whole building, the following matricial formalism (1) is solved by using an implicit finite-difference method  [16]. C w T ̇w=A w T w +B w , (1) Where the index w is used for walls and windows. A w is the state matrix including the terms linked to heat conduction and the interior linearized convective exchanges. B w is the vector containing outside or internal solicitations of the system.
The choice of GenOpt ® has also been made according to its simulation program interface that allows the coupling with any simulation program, without requiring code modifications. Indeed, the coupling is done by creating some files required by GenOpt ® to run an optimization and also an auto-executable version of the model  [18]. In addition, GenOpt ® is dedicated for the thermal building simulation. For more details about the generic optimization program, the interested reader may refer to  [17]. Before performing the optimization sequences with GenOpt ® , the studied system with the main results of previous work are presented in the following paragraph.
PCM model optimization using GenOpt ® The optimization sequence consists in reaching the best set of parameters by maximizing or minimizing a chosen cost function, subject to a set of constraints (or a defined domain), until optimization criteria are reached. Indeed, many simulations are run and when a stopping criterion is reached, like the required error on the studied output for instance, the optimization is stopped. To optimize the thermal model of PCM implemented in ISOLAB by using GenOpt ® , a methodology for the coupling of the building simulation code with the optimization program is required. The study has already been presented and the interested reader may see  [18]  for details. Among methods of fixing sets of parameters implemented in GenOpt ® , the GPS (Generalized Pattern Search) Hooke-Jeeves MultiStart Algorithm was used.
Indeed, it allows to look over some parameters and to avoid that the result values are obtained from a local minimum value. In addition, this algorithm is compatible with all building thermal insulation code and gives reliable results. The used cost function is calculated by using a mathematical model tool based on the modified standard deviation: s= √ 1 n ∑(x i -x ̅) 2 n i=1 (4) If several model outputs are used to optimize the model, the global cost function is the sum of the absolute values of costs functions for each output. The optimization sequence is stopped, if and only if, same minimum values of the cost functions were reached for 10 different optimization sequences. In our approach, several optimization sequences (1500 optimization sequences were reached approximately) and statistics studies were performed.
The proposal of these authors is a combination of two correlations for taking into account both natural convection in laminar regime and turbulent regime: h= [(1. 51 |∆T| 1 4 H ) 6 + (1. 33|∆T| 1 3 ) 6 ] 1 6 (5) Where ∆T is the averaged difference temperature between the surface of the wall and the indoor air of the room. H corresponds to the height of the wall. With the predicted air temperature in zone 2, the errors between the curves can also be explained by the prediction of the corrugated iron surface temperature. Indeed, the latter has a direct effect on the temperature of each component of the complex roof. To reduce these errors, the radiative model should be improved and the radiosity method should be used  [15]. To conclude this step, the thermal model was fully-coupled with ISOLAB code and the results of PCM model are very encouraging.
The corroboration step The corroboration step consists in using another experimental period in order to verify if all parameters determined can be generalized and are not specific for a given period. Moreover, it also allows evaluating the efficiency of the proposed model. For this step of corroboration, the meteorological data used are from October 2 to 5, 2012. This period was characterized by  [19] :  an average maximal global radiation of 900 W. m -2  an average wind speed of 3. 50 m. s -1  an average outdoor temperature of 26°C  an average rate humidity of 65% The results from the corroboration step are summarized in Table  6. In this part, the validation criteria are also respected. For instance, comparison between numerical simulations and measurements for the predicted indoor air temperature is depicted in Figure  9.
Background: Many bioinformatics tools use reference data, such as genome assemblies or sequence databanks. Galaxy offers multiple ways to give access to this data through its web interface. However, the process of adding new reference data was customarily manual and time consuming, even more so when this data needed to be indexed in a variety of formats (e. g. Blast, Bowtie, BWA, or 2bit). BioMAJ is a widely used and stable software that is designed to automate the download and transformation of data from various sources. This data can be used directly from the command line, in more complex systems, such as Mobyle, or by using a REST API. Findings: To ease the process of giving access to reference data in Galaxy, we have developed the BioMAJ2Galaxy module, which enables the gap between BioMAJ and Galaxy to be bridged.
Reference data in Galaxy Galaxy  [1] [2] [3]  is a web portal that gives access to a large variety of bioinformatics tools in an easy to use graphical user interface. It also provides visualization modules, such as Trackster  [4] , which are able to display the analysis results directly in a web browser. Many of the tools and visualization modules that are present in Galaxy use reference data, such as genomes or specialized databanks (e. g. UniProt  [5]  or GenBank  [6] ). This data can be made available in simple flat file formats (e. g. FASTA) or various indexed formats (Bowtie  [7] , BWA  [8] , Blast  [9] ), depending on the requirements of each tool. There are several methods to configure access to this reference data in Galaxy.
*. loc files The first (and oldest) method available uses so-called '*. loc files'. Tabular files with a. loc extension are present in the tool-data directory of the Galaxy server files. Each. loc file contains a list of paths of a given format (e. g. Blast databanks) with a unique identifier and a description. Although this method is simple and has been working well for a long time, it has a few drawbacks. First, because it is a manual file editing method, administrators have to be very careful to respect the tabular syntax and to give the exact path to the reference files. Furthermore, a restart of the Galaxy server is required for the changes to take effect, which is not very compatible with the high availability of a production server.
Data libraries Reference data can be uploaded to a Galaxy instance in 'data libraries'. In this case, the data is usually added by administrators of the instance using the Galaxy administration panel. Depending on the configuration, nonadministrator users can also be allowed to populate data libraries. Users can then access this data from the 'data libraries' menu on the portal and import it to their histories for further analysis. One important benefit of this method is the ability to restrict access to specific users or user groups, which is very important when adding unpublished data (e. g. newly sequenced genomes). However, the process of adding data is still manual and as such can be subject to errors. Furthermore, all of the data needs to be imported into a history before it can be used.
Tool data tables and data managers Instead of reading the list of compatible reference data directly from a unique *. loc file, each tool can load it from a 'tool data table'. A tool data table is the result of the Galaxy server merging all of the corresponding compatible *. loc files found in its file tree. 'Data managers'  [10]  are a new category of tool that leverage tool data tables, which are available from the main Galaxy Tool Shed  [11]. Their goal is to let Galaxy administrators populate tool data tables directly from the administration panel using web forms. Several data managers are already available that allow us to automatically: 1) fetch FASTA files from local or external sites (e. g. NCBI, UCSC); 2) build indexes (e. g. Bowtie, Blast); and, 3) reference this data in the corresponding data tables.
They are directly available in the tools that use these data tables. Tool data tables and data managers are a first move towards the automation of the management of reference data in Galaxy. However, the whole process still requires human intervention to launch the data download and to process it at regular intervals. This method is also Galaxy-centric: the files and indexes that are made available inside Galaxy are stored in the Galaxy server files, following a logical directory structure. Exploring this reference data from outside Galaxy (e. g. with the command line) can be problematic without prior knowledge of this directory structure and of its root. Thus, on architectures where Galaxy is not the only access point to computing resources, this method can lead to data duplication.
BioMAJ BioMAJ  [12]  is a workflow engine that is dedicated to data synchronization and processing. It automatically finds new releases of reference data on external sources using different protocols (e. g. http, ftp, or sftp). The data is then downloaded and optionally converted to various formats using fully configurable 'post-processes'. BioMAJ makes it possible to schedule databank updates automatically at regular intervals, reducing human intervention to a short initial configuration step. Update reports are sent by email if there are unexpected errors. It is possible to configure BioMAJ and to consult the databank's status (e. g. latest release, next planned update) using a web user interface. A RESTful API is also available to ease the development of external software requiring access to the databanks.
BioMAJ2Galaxy presentation The aim of our project was to use BioMAJ to manage the retrieval and processing of the reference data. We also aimed to extend BioMAJ with a module to manage the reference data that is available in Galaxy. BioMAJ2Galaxy offers the ability to add or to remove reference data to/from a Galaxy instance. It should be noted that the removal feature can impair the ability of the users of Galaxy to reproduce analyses. However, this feature was developed because it is often impossible to store multiple releases of each databank due to disk space considerations. BioMAJ can be configured to keep a variable number of releases for each databank. At the end of each successful databank update, if this maximum number is reached, then the oldest release is deleted from the disk. Thus, any reference to it in Galaxy also needs to be removed.
It is up to the BioMAJ administrators to decide on the number of releases to keep. BioMAJ2Galaxy takes the form of several Galaxy data managers, BioMAJ post-processes written in Python, and code contributions that were integrated in the Galaxy and BioBlend  [13]  projects. The code and documentation is freely available on the dedicated GitHub repository  [14]. Figure  1  presents a detailed view of the architecture of BioMAJ2Galaxy.
Data managers Seven data managers were written for this project, one for each of the most used types of reference data (FASTA, Bowtie, Bowtie2, BWA, 2bit, BlastDB as well as dbkeys). They are all available on the Galaxy User Group Grand Ouest (GUGGO) Tool Shed  [15, 16] , in the 'data manager' category. As such, they can be installed on any recent Galaxy instance directly from the administration panel. These data managers are only in charge of filling the data tables with paths to pre-existing files; they perform no data processing at all. New data managers that are adapted to other formats will be made available on the same Tool Shed in the future, depending on the adoption of the data tables system by new Galaxy tools.
BioMAJ processes The data managers presented in the previous paragraph are invoked by Python scripts that are available on the GenOuest GitHub account  [14]. This code extensively uses the BioBlend Python library  [13]  to interact with the Galaxy API. BioMAJ2Galaxy is composed of four scripts that are used as BioMAJ post-processes (to add new reference data) or remove-processes (to remove obsolete reference data). Because they are standard Python executables, these scripts can also be run manually from the command line. First, we add the reference data to the corresponding data tables using add_galaxy_data_manager. py. It is possible to add multiple data types at once. A second script, remove_galaxy_data_manager. py, performs the deletion of the reference data from the data tables. For users who prefer to use data libraries (particularly to restrict access to specific users), add_galaxy_library.
py can be used as a post-process to add reference data to a new or already existing data library. An option is available to specify which Galaxy role(s) is allowed to access this data. The script remove_galaxy_data_library. py can be used as a removeprocess to delete the reference data from a data library. These scripts should be launched as the last steps of the processing workflows that are defined for each BioMAJ databank. The previous steps correspond to the data processing tasks that are performed with other post-processes (either BioMAJ built-in scripts or custom scripts).
Usage BioMAJ2Galaxy requires an up-to-date version of Galaxy and the data managers from the GUGGO Tool Shed  [11]  should be installed. An up-to-date version of the BioBlend Python library is also required. Using BioMAJ2Galaxy for a given BioMAJ databank implies some configuration changes. This can either be done directly from the web interface or by modifying the databank configuration file manually (Figure  2 ). Once the configuration step is finished, the databank simply needs to be updated (directly from the web interface, via the command-line, or as a scheduled task). The reference data is available in the whole Galaxy portal as soon as the BioMAJ update process completes with no error.
Figure1BioMAJ2Galaxy architecture: BioMAJ fetches data from external online repositories. Post-processes are in charge of formatting the data in various formats. They then invoke Galaxy data managers using the Galaxy API via the BioBlend Python library. Alternatively, it is possible to invoke a post-process that adds reference data to the Galaxy data libraries. The injected reference data can then be used directly in tools or visualizations, and/ or can be accessed in data libraries. When an obsolete databank version is removed, BioMAJ remove-processes are launched to remove any reference to the corresponding reference data in the Galaxy data tables or data libraries.
Methodology The determination of the position and the flux density of the sources have been performed in different steps. From the starting map, presented in Sec. 2. 1, an estimate of the background has been subtracted (Sec. 2. 2). The source positions have been determined from this background-subtracted map using the sourceExtractorSussextractor software. Finally, the flux density in each position was estimated using the sourceExtractorTimeline software, and each source has been subtracted from the timeline data once determined its flux density (Sec. 2. 3). 2. 1. Data The four HeViCS fields have been observed in two orthogonal scans at a sampling rate of 60 s - 1  with four repetitions for a total of eight scans. The final map is obtained by averaging the bolometer timeline measurements that sampled the region in each map pixel (naiveScanmapper task in HIPE 9.
Source identification and flux density measurement Source detection is performed in an iterative loop. A list of initial positions of point sources is produced using the implementation of sourceExtractorSussextractor  (Savage & Oliver 2007 ) in HIPE 9. 0. 0  (Ott 2010)  that is applied to a map where the foreground cirrus structure has been subtracted (see Section 2. 2). The sourceExtractorSussextractor software convolves the reduced map with a bidimensional Gaussian kernel having a FWHM of 17. 5, 23. 9, and 35. 1 at 250, 350, and 500 µm, respectively. The value of each pixel in the convolved map corresponds to the maximum likelihood estimate of the flux density that a source should have if centered on that pixel. The extractor routine finally searches for local maxima in pixel regions with a size comparable to the beam, which are the neighboring eight pixels.
5. 2. Although sourceExtractorSussextractor produces flux density measurements for the sources it detects and although other software packages have been developed for source extraction within confused extragalactic fields (including software developed specifically for Herschel), we prefer to use the timeline-based source extraction for several reasons. First of all, the SPIRE data are flux calibrated at the timeline level using timeline-based PSF-fitting techniques  (Bendo et al. 2013) , so the methods that we have used are consistent with the flux calibration measurements themselves and are therefore expected to be more accurate. Second, when the maps are produced from the timeline data, multiple measurements from the timelines are averaged together to produce the surface brightness measured in each pixel.
Clearly, the redshift distribution considered for the sources with an optical counterpart in SDSS is biased towards low redshift galaxies. Because the SDSS catalog is 95% complete for r = 22. 2 AB mag, the cross correlation with our FIR catalogs give us the possibility to estimate the contribution of the low redshift component to the total number counts. In Fig. 11 , we show the number of counts of the HeViCS sources, the subsample with optical counterparts and redshift estimation, and the component without redshift. Above 100 mJy, the number counts are dominated by the component with the optical counterpart that forms the bulk of the bright end of the distribution, while the compo-   (Oliver et al. 2010) , BLAST  (Patanchon et al. 2009 ), HerMES DR1  (Béthermin et al. 2012a) , and the results of a P(D) (probability of deflection) analysis applied to the HerMES SDP data from  Glenn et al.
Acknowledgements. We warmly thank the referee for his/her constructive comments and suggestions. We would like to thank  D. Munro  for freely distributing his Yorick programming language (available at http://www. maumae. net/yorick/doc/index. html). S. B. , L. H. , S. Z. , S. di S. A. are supported through the  ASI-INAF agreement I/016/07/0  and  I/009/10/0. C. P. was also supported by  PRIN-INAF 2009/11  grant (extended to 2012). C. P. acknowledges support from the  Science and Technology Foundation (FCT, Portugal)  through the  Postdoctoral Fellowship   SFRH/BPD/90559/2012 ,  PEst-OE/FIS/UI2751/2014 , and  PTDC/FIS-AST/2194/2012. Funding for SDSS-III has been provided by the  Alfred P. Sloan Foundation , the Participating Institutions, the  National Science Foundation , and the  U. S. Department of Energy Office of Science.
Background: The peer review process is a cornerstone of biomedical research publications. However, it may fail to allow the publication of high-quality articles. We aimed to identify and sort, according to their importance, all tasks that are expected from peer reviewers when evaluating a manuscript reporting the results of a randomized controlled trial (RCT) and to determine which of these tasks are clearly requested by editors in their recommendations to peer reviewers. Methods: We identified the tasks expected of peer reviewers from 1) a systematic review of the published literature and 2) recommendations to peer reviewers for 171 journals (i. e. , 10 journals with the highest impact factor for 14 different medical areas and all journals indexed in PubMed that published more than 15 RCTs over 3 months regardless of the medical area).
Peer reviewers' assessments can also be affected by the study results: peer reviewers tend to rate the methodological quality of a study with positive results higher than the same study reported with negative results  [10, 11]. Moreover, the reproducibility between reviewers is disputable  [12] [13] [14]. Finally, peer reviewers are not able to detect fraud  [15]  and mistakes  [16]. Our hypothesis is that several tasks can be expected from peer reviewers and that peer reviewers and editors may have different views on which task is important. We aimed to 1) identify all tasks that are expected of peer reviewers when evaluating a manuscript reporting a randomized controlled trial (RCT), 2) sort these tasks according to their importance, and 3) determine which tasks are clearly requested by editors in their recommendations to reviewers.
Journal recommendations to reviewers We selected a sample of journals publishing full-text articles in English. We aimed to select a large variety of journals publishing RCT results. For this purpose, we proceeded in two steps. 1) We searched PubMed with the keywords randomized controlled trial with the following filters: study type RCT, English language, human studies, published between January 1 and March 31, 2013, and with an abstract available (search date February 2, 2014). All citations retrieved were exported to an EndNote file. We selected all journals whatever the category (Additional file 1) that had published at least 15 reports of RCTs indexed in PubMed during the 3-month period. 2) We arbitrarily selected, in the Web of Science (Journal Citation Reports), 14 categories in the field of medicine among the 111 existing categories in the field of (bio)medicine.