dataesr/scientific-paragraphs-categorization huggingface dataset:
Version control and branching model hotfix is a mirror of the release branch and is used to patch the code that is in production. If a critical bug occurs in production, this branch is used to fix the issue. master is only used to archive the code from the release and hotfix branches. This branch is not used for development. Among these four branches, the release, hotfix and master are protected branches such that only the developers with the Maintainer role in the GitLab repository can directly push code on these branches (the other users have to use the GitLab merge request functionality to push on protected branches). In addition to these four branches, the developer can create local branches to i) implement a new feature (the branch is named with a prefix feature plus any meaningful suffix) and ii) fix a bug in production or resolve a problem during the third step (these branches are either named with the prefix release or hotfix depending on the use case plus some relevant contextual information).
The system (or functional) testing validates that the full bioinformatics pipeline works and fits well the end-user's needs. The regression testing checks that the correction of bugs or the development of new functionalities did not introduce defects in unchanged areas of the bioinformatics pipeline. In addition, we highlight the importance of the operational testing to check that the bioinformatics pipeline provides the expected results on a reference dataset (golden dataset) in the production environment. This testing is systematically launched prior to any new analysis by the bioinformatics pipeline in the production environment. This ensures that the results are reproducible as long as the exact same version of the bioinformatics pipeline is used.
Whatever the use case, the bioinformatics pipeline is deployed in production and operated by the end-users once it has successfully passed all the testing. Whenever new patient data has to be analyzed to deliver results for diagnostic or theranostic purposes, the bioinformatics pipeline can be launched by the end-users only if the operational testing reproduces the results from the golden dataset, otherwise it is blocked by internal control mechanism. In this case, the developers investigate the reason of the failure and have to fix it using the hotfix mode. As a real example, we provided a of the repository that is available for any registered user at https://gitlab. com/biogitflow/biogitflow-template. This repository has been created according to the guidelines from the section Create a new project in Gitlab from the biogitflow documentation.
It was a major step to improve our daily practice of software engineering towards better quality management and was a source of motivation to change our work habits. More precisely, the use of the biogitflow protocols contributed to the harmonization of the development practices across developers. Every git pipeline repository is now structured the same way that makes easy the skill transfer from one person to another. This is very convenient, especially when you have to maintain different pipeline repositories with different developers involved. Moreover, multiple deployment environments along with the branching model make the developer feels a constructive and positive pressure as long as the deployment in the production (the danger zone) is getting close: this is a source of stimulation for better quality.
Data availability Underlying data All data underlying the results are available as part of the article and no additional source data are required. Extended data biogitflow documentation is available at: https://biogitflow. readthedocs. io/. Archived source of the biogitflow documentation at time of publication: https://doi. org/10. 5281/zenodo. 3885463 License: CeCILL Version 2. 1. This paper presents the protocol for the development and support of bioinformatics pipelines using git and GitLab. The intended users are bioinformaticians working in a clinical setting, while bioinformaticians working in research/academia can also benefit. This reviewer questions if the scope of the intended audience can be expanded. For example, in a clinical setting, software developed in the field of medical informatics is often used along with the software developed in biology.
But could the same approach at the workflow development be applied to proteomics, metabolomics and other relevant for personalized medicine and diagnostics fields? This is really true that the proposed protocols are not restricted to genomics. We have added in the conclusion that they can be applied straightforwardly to any omics bioinformatics pipelines and even any software development. > It shouldn't belie the value of the presented protocol, but the reader and potential user might benefit and become more enthusiastic about using the biogitflow if the presented resource provided and described an example of a specific pipeline with a small test dataset. The biogitflow protocols come with a biogitflow-template that is publicly available on GitLab. com. In this new version, we have added in the biogitflow documentation an 'Exercises' section that first explains how the user can fork the GitLab repository.
Then, the user can practice the different exercises. As biogitflow is mainly dedicated to the use git and GitLab and not the coding standard or the code itself, it is difficult to provide a specific pipeline with a test dataset. Therefore, we strongly encourage the user to start from the template and go through the different exercises just following the technical protocols available on the documentation. > The paper requires proofreading for typos; e. g. , "As a real example, we provided a of the repository that is available …" Typos have been fixed.
Bernard Pope Melbourne Bioinformatics, University of Melbourne, Parkville, Vic, Australia I thank the authors for their careful consideration of the issues raised in the previous review. I believe the changes made to the paper in response to those issues have improved the manuscript. I believe the following, relatively minor, issues should be considered in the next revision of the paper: The abstract should mention that biogitflow is based on gitflow, a well-established workflow in the software engineering community.
○ You will find below a detailed answer to the different issues that we have addressed in the revised manuscript. Best regards, Choumouss Kamoun, Julien Roméjon and Philippe Hupé === Detailed response to the reviewer1's comments === > The abstract should mention that biogitflow is based on gitflow, a well-established workflow in the software engineering community. We have modified the abstract accordingly > It is not clear what "for any registered user" means, please clarify. We have rephrased and explained that it is recommended that the user registers on GitLab. com > Typo: "remoterepository", should be "remote repository". The typo was indeed present in the online pdf but not in the word file we used to submit the revised version. I guess the editor can fix the typo. > Some of the key differences between gitflow and biogitflow are enumerated, but additional explanation as to why they are different would be useful.
Version 1 Reviewer The formalisation prescribes a branching, testing, merging and release process, with set roles and permissions for developers, and methods for managing the development of new features (nominal mode) and bug fixing (hotfix mode). In addition to describing the biogitflow workflow, the paper also contains a short section on testing bioinformatics software pipelines, however, this is largely a recapitulation of standard testing terminology, and does not appear to be particularly bioinformatics-specific. The paper has a brief discussion about the motivation for adopting the workflow and some unsubstantiated claims about improving their software engineering practices. It also has a brief discussion about the need to train developers in the workflow and formal accreditation. Two large figures are included in the paper that attempt to illustrate the proposed workflow in nominal and hotfix modes.
> In addition to describing the biogitflow workflow, the paper also contains a short section on testing bioinformatics software pipelines, however, this is largely a recapitulation of standard testing terminology, and does not appear to be particularly bioinformatics-specific. > The paper has a brief discussion about the motivation for adopting the workflow and some unsubstantiated claims about improving their software engineering practices. It also has a brief discussion about the need to train developers in the workflow and formal accreditation. > Two large figures are included in the paper that attempt to illustrate the proposed workflow in nominal and hotfix modes. > While the topic of this paper is interesting and highly relevant to bioinformatics software developers working in areas of clinical application, where process accreditation is a key concern, there are a number of areas where I think the paper could be improved: > 1.
We fully agree that the protocols are complex and it is not straightforward to master them. Of note, we pointed out in our reply to you comment number 5 that the protocols are mainly relevant in the context of production to deliver to process data on the fly which is obviously a challenge especially when the bioinformatics pipelines have to deal with a very high-throughput of data. The complexity of the workflow just reflects the reality of the development and deployment cycle in the context of production as we intend to promote industrialized processes for the software implementation in order to offer better service, better reactivity, better traceability to end-users. Formalism was thus required and this is the reason why we wrote the biogitflow documentation. You are also fully right when you say that it is "prone to error and misapplication" and that some "complexity could be avoided by automation".
> 3. What alternative competing development models exist? Other alternatives exist such as GitHub flow and GitLab flow. We added them in the section "Version control and branching model". > 4. How can the authors be sure that the workflow is in fact making a positive difference to their software development? This is a good question that is difficult to answer. This would require something like an experimental design comparing two or more workflows based on the assessment of objective performance metrics, and then compare the metrics to figure out if they are statistically different. We did not perform such an approach. However, we can say that the benefit of the biogitflow protocols was two-fold: 1/ "harmonization of the development practices" and 2/ the "constructive and positive pressure" for "better quality".
Report 22 October 2020 https://doi. org/10. 5256/f1000research. 27261. r72478 © 2020 Pope B. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Bernard Pope Melbourne Bioinformatics, University of Melbourne, Parkville, Vic, Australia Motivated by laboratory accreditation requirements for the development of bioinformatics workflows related to high throughput sequencing in a clinical setting, the authors have developed a software development process formalisation based on gitflow, a popular model in mainstream software engineering practice.
It is a calculation of the convolution based on the tidal levels density function and of a distribution function of SSs  (Duluc et al. , 2012)  have shown that the quality of the results from this convolution approach for small return periods is questionable. The second procedure uses the data of observed maximum water levels  (Chen et al. , 2014; Haigh et al. , 2014; Huang et al. , 2008). This approach was recommended by FEMA's guideline  (FEMA, 2004)  for coastal flood mapping. The GEV model was recommended to conduct the frequency analysis of extreme water levels, if long-term datasets are available. Based on the regional observations, the process of estimation of extreme water levels uses an adequate frequency analysis model to estimate the distribution parameters, the desired return levels (RLs) and associated confidence intervals.
Data characteristics are shown in the table 1. These data were first processed to keep only common periods containing a minimum of gaps. The choice of the variables to be probabilized is done at this stage. used by  Duluc et al. , (2012). The frequency analyses were performed with the Renext library also developed by  IRSN (IRSN and Alpstat, 2013). The Renext package was specifically developed for flood frequency analyses using the Peaks-Over-Threshold (POT) method.
Acknowledgements The authors would like to thank  François Ropert , a research engineer (CEREMA, centre d'études et d'expertise sur les risques, l'environnement, la mobilité et l'aménagement) for his thoughtful comments and advices about copula theory application. The authors are grateful to the  SHOM (Service Hydrographique et Océanographique de la Marine)  for providing data. Salvadori G. and  De Michele C. : Frequency analysis via copulas: Theoretical aspects and applications to hydrological events. Water Resour. Res. , 40,  W12511 , doi: 10. 1029/2004WR003133 ,2004. Gupta, I. : Probabilistic seismic hazard analysis method for mapping of spectral amplitudes and othe designspecific quantities to estimate the earthquake effects on manmade structures. Journal of Earthquake Technology, 2007.
Acknowledgements We warmly thank  N. Cribiori ,  S. Renaux-Petel ,  C. Roupec ,  C. Ruef ,  H. Skarke  and  D. Tsimpis  for useful exchanges during the completion of this work. D. A. and P. M. acknowledge support from the  Austrian Science Fund (FWF) : project number  M2247-N27. P. M. thanks the ITP at  TU Wien  for hospitality and for the opportunity to work on this project. T. W. acknowledges support from the  Austrian Science Fund (FWF) : project number  P 30265.
The text was rendered on the same touch screen in 8-dot Braille coding. This browser illustrates three main limitations we wish to remove. First, it only considers part of the layout information (layout of the elements, graphic/image/text differences), which are not sufficient to exploit the richness of the typographical phenomena (e. g. , colors, weights, font size) and the luminous contrasts they induce. Second, the browser uses Braille to render text on the screen, whereas only a minority of blind people can read it and the Braille language is limited to translate typographic and layout information. Third, the user's autonomy is reduced in the choice of accessible information since the browser unilaterally decides which information is likely to be of interest. Another interesting browser has been proposed called CSurf  [16]  but it also relies on data filtering and the valuable information is selected by the browser itself.
The TactiNET hardware  [20]  has been developed to offer both versatility and easy setup in the design of experiments. As shown in Figure  1 , it consists of: • A control tablet (item 1) where all the experimental parameters can be managed and programmed (e. g. , shape of the patterns, vibrations frequencies, etc. ) and sent via Bluetooth to the user's tablet (item 2). • A user tablet (item 2), where web pages are processed and displayed according to the graphical language. The user's five fingers coordinates are sent to the host system via a connection provided by a ZigBee dongle (item 3). • The host system (item 4) where actuators can be connected through satellites. Each actuator can be either a piezoelectric vibrator or a Peltier device to provide haptic or thermal user feedback (item 5).
Towards a Graphical Language for the Tactile Output A first experiment has been carried out in  [21]  that aims at pre-testing the ability of users to recognize shapes on a handheld device with the TactiNET in its minimal configuration within a non-visual environment. This configuration consists of: • A single satellite positioned on the non-active hand: one vibrotactile actuator, • A single dimension of variation: the brighter (respectively darker) the pixel overflown by the index finger, the lower (respectively higher) the vibration amplitude. The experiment has been conducted with 15 sighted users (eyes closed) and 5 blind people (see Table  1 ) to explore, count, recognize and manually redraw different simulated web pages configurations. The conclusions of this experiment were as follows.
Recognition of Web Page Structures To test the perceptual capacities of the TactiNET through its graphical language, we propose an exploratory experiment based on the semi-automatic conversion of the global visual structures of web pages into vibrotactile stimuli. This conversion is achieved by dividing a given web page into meaningful clusters of bounding-boxes represented by rectangular shapes, and by translating them into vibrotactile stimuli. The final objective is to evaluate how these macro-structures can be perceived in a non-visual environment by using the graphical language of the TactiNET.
Conclusions and Perspectives In this paper, we developed a vibrotactile framework called TactiNET for the active exploration of the layout and the typography of web pages in a non-visual environment, being the idea to access the morpho-dispositionnal semantics of the message conveyed on the web. For that purpose, we first built an experimental device allowing the analogical transposition of the light contrasts emitted by a touch-sensitive tablet into vibratory and thermal stimuli. The main ergonomic constraints were to be easily positionable on any part of the body, modular in terms of the quality and the quantity of actuators, inexpensive (less than 100 dollars), robust and light. We then tuned the device to lay the bricks of a tactile language based on the expressive capacity of the stimuli produced.
GipsyX/RTGx is the Jet Propulsion Laboratory's (JPL) next generation software package for positioning, navigation, timing, and Earth science using measurements from three geodetic techniques: Global Navigation Satellite Systems (GNSS), Satellite Laser Ranging (SLR), and Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS); with Very Long Baseline Interferometry (VLBI) under development. The software facilitates combined estimation of geodetic and geophysical parameters using a Kalman filter approach on real or simulated data in both post-processing and in real-time. The estimated parameters include station coordinates and velocities, satellite orbits and clocks, Earth orientation, ionospheric and tropospheric delays. The software is also capable of full realization of a dynamic terrestrial reference through analysis and combination of time series of ground station coordinates.
For an overview of POD and measurement processing see the books  [Tapley et al. , 2004b]  and  [Bierman, 1977]. Born from Very Long Baseline Interferometry (VLBI) data analysis expertise and software  [Sovers and Fanselow, 1987] , the first JPL GPS data models were coded during 1984-1985 in the GPSOMC FOR-TRAN software  [Sovers and Border, 1990]. Immediately thereafter we began development of a more comprehensive software set, the GPS Inferred Positioning System and Orbit Analysis Simulation Software package (GIPSY-OASIS, forever nicknamed GIPSY)  [Wu et al. , 1986] , also coded in FORTRAN, to support the early campaign-style GPS orbit determination (GiG'91 for example  [Melbourne et al. , 1993] ) and positioning experiments  [Blewitt, 1989a]. That very early version of GIPSY should be considered a prototype for the more formally designed, enhanced, and documented version  [Wu et al.
, 1990] , written to support the first precision GPS flight experiment on the TOPEX/Poseidon altimetry mission  [Bertiger et al. , 1994]  as well as the continuous GPS orbit determination operations at JPL that are the cornerstone for all precision GIPSY applications. With the maturation of the GPS constellation, which became fully operational in 1994, real-time operational applications, such as differential positioning, started to emerge. The state-space formulation of real-time differential systems, today a universally accepted practice also known as wide area differential GPS (WADGPS) or global differential GPS (GDGPS), was conceived and patented at JPL  [Yunck et al. , 1989] , and led to the creation of the Real Time GIPSY (RTG) software. RTG ported most of GIPSY's precise satellite and signal models from FORTRAN into C, but redesigned the software architecture, and in particular the estimation filter, for efficient real-time operations.
Successful early demonstration of RTG  [Whitehead et al. , 1998 ] has led the United States Federal Aviation Authority's (FAA) to adopt JPL's state-space algorithms for its Wide Area Augmentation System (WAAS), with RTG as the prototype software for this critical aviation infrastructure, which has since been adopted by several other countries as well  [Bertiger et al. , 1997]. In 2000, RTG became core software for JPL's GDGPS system, as well as for other commercial systems. As with any JPL-developed software, GIPSY and RTG are owned by the California Institute of Technology (Caltech). Licensing requests are available from [https:// gipsy-oasis. jpl. nasa. gov]. With hundreds of issued licenses to academia (which are free of license fees), industry, and government, GIPSY and RTG are among JPL and NASA's most licensed software, and the recipient of multiple industry and NASA awards, including the 2000 NASA Software of the Year Award for RTG, and 2004 Space Technology Hall of Fame induction for GIPSY and RTG (as "Precision GPS Software System" ) [https://spinoff.
, 2010a] , and we set out to create JPL's 4th generation GPS data processing software, entitled RTGx. Later, the NASA Space Geodesy Project (SGP) provided additional support to enhance post-processing for space geodesy  [Merkowitz et al. , 2018]. All programs synergistically benefited. This was an opportunity to modernize the entire geodetic data processing software set at JPL and unify the agile real-time processing of RTG with the post-processing flexibility of GIPSY, all within a new architecture that can support all of JPL's, NASA's and the Air Force's OCX current and anticipated needs. This unified multi-capability software set was named GipsyX/RTGx (or RTGx/GipsyX, depending on the main use case. The choice of capitalization is intentional). The development of GipsyX/RTGx was mostly completed by 2016.
Software Design, Overview GIPSY's core computational engines were written in FORTRAN with glue code and automation in C-shell, Bourne-Shell, and Perl. RTG was written in C. Both GIPSY and RTG implemented precise sets of models consistent with the 2010 Conventions of the International Earth Rotation Services (IERS)  [Petit and Luzum, 2010]. RTG was designed for lean real-time processing, and did not have post-processing capabilities required by many of NASA's science applications and by the geodetic user community. While FORTRAN has been modernized since our original GIPSY writing, it is not currently as widely used as C or C++, and is hardly taught at universities. The U. S. Air Force contract for OCX forbade outright the use of FORTRAN. C does not support object-oriented programing, which we deemed necessary for ease of development and maintenance.