dataesr/scientific-paragraphs-categorization huggingface dataset:
The group of curves at the bottom corresponds to even-order moments, whereas the top group corresponds to odd-order moments, with (for fixed n) an error that increases with the order. Example results for the moments with n = 10 are given in Appendix D. With n = 20 the curves nearly overlap and cannot be distinguished with the scaling used for the plots. Based on these results and Figure  4 , the HyQMOM closure appears to converge with increasing n. As a measure of the computation cost, the case with n = 20 required 22 mins using Matlab on a laptop computer. 7. Discussion and conclusions. Despite its apparently simple form, the path from the original HyQMOM closure for n = 2 to the general HyQMOM closure in Theorem 4. 6 was not straightforward. In  [13] , the 1-D HyQMOM closure for n = 2 was discovered by forcing an abscissa of a representing VDF to be located at the mean velocity (this induces a 2 = 0).
In any case, a VDF as a weighted sum of n + 1 Dirac delta functions found from J n+1 defined in (4. 19 ) can be uniquely associated with the HyQMOM closure. The pragmatic response is that HyQMOM will be at least as good as QMOM with n + 1 weights and abscissas for evaluating unclosed integrals with respect to the unknown velocity VDF. For population balance equations defined on semi-infinite or finite domains, it is not obvious that HyQMOM will provide any advantage relative to QMOM. Given that HyQMOM uses the even-order moment M 2n while QMOM uses the odd-order moment M 2n+1 , it will be necessary to prove that the HyQMOM closure for M 2n+1 is realizable for semi-infinite and finite domains. If this is the case, then the HyQMOM closure presented in this work can be used to investigate convergence with increasing n.
Besides the kinetic equation and population balances, other potential applications of the HyQMOM closure include radiation transport  [35, 9, 10]  and multiphase-flow models derived from a kinetic equation  [27]. Our current research is focused on the extension of 1-D HyQMOM to multiple dimensions (e. g. , 2-D and 3-D) and infinite domains. In prior work with n = 2  [13, 29] , this was accomplished using the conditional QMOM  [38]  and a reconstructed VDF based on the weights and abscissas corresponding to Q 3. For our extension of 1-D HyQMOM, we eschew that approach, and instead seek to close the multi-dimensional moments appearing in the free-transport flux vector using ideas developed in the present work. Our initial results in this direction are promising from both an analytical and computational perspective.
(10) and (13). Experimental assessment of the sensor. Measurements of the realized sensor filled in with samples were then performed. The data were measured in the frequency range of 10 MHz-15 GHz, with a resolution of 9. 37 MHz (1601 points) on a properly-calibrated Rhode & Schwarz® ZVA 67 VNA. A precision micropipette (Gilson PIPETMAN ® Classic P200, resolution of 0. 1 μL) was used to fill the container with 43. 6 μL, exactly, of each sample prepared as explained in "Ternary mixtures involving water, sodium  chloride and sucrose" section (Table  5 ). After each sample measurement, a careful double rinsing procedure based on ethanol and DI-water was applied. It was followed by a compressed-air drying step before moving on to the next sample measurement. All measurements were made at a room temperature of 23° C.
Modeling Formation with an N-body Gravitational Code We simulate the formation of terrestrial super-Earths using a modified version of the gravitational N-body code SyMBA  (Duncan et al. 1998; Scora et al. 2020). The code uses a multitime step symplectic integrator to efficiently resolve close encounters between bodies. It tracks the movement of particles within the disk based on gravitational interactions alone. Only embryos can gravitationally interact with each other; debris particles below a certain mass threshold (0. 04 M ⊕ in our simulations) have no gravitational effect on each other but do interact with the embryos. (Hauck et al. 2013 )) values, respectively, and the bottom line is a planet made of only core (CMF = 1). The blue shaded area is the region that planets should occupy if they follow stellar compositional ratios, taken from  Scora et al.
This article describes recent improvements made in the design process of offshore flexible pipes. These improvements consider the more precise complex geometry and architecture of the flexible pipes, while considering their corrosive environment (high pressure, high temperature, acid gases (CO 2 , H 2 S), sea water, etc. ) and the relevant physics. MOLDI TM , the design software that was developed 20 years ago to predict flexible pipes annulus environment, has been constantly upgraded to increase its representativeness: use of chemical potential or fugacity to better describe the mass transport, improvement of the thermodynamic module to better describe the interaction between chemical species and allow to model the purging through gas release valves. Recently, a major advance has been made allowing to cope with flooded annulus flexible pipes.
When the annulus is flooded, the tortuosity produced by the presence of steel wires inside the annulus can take a major importance. Therefore, a new model, named 3DIFF, has been developed to describe the 3-dimensional characteristics of the annulus and its impact on fugacity profile across the structure. Depending on permeation properties of each layer, the result is that the presence of water can produce a fugacity gradient within the annulus. This heterogeneity must be considered during the design process to be fully representative of service conditions and allow to select flexible pipes materials with confidence. Experimental devices used to generate permeation database are under constant evolution to study even more complex mechanisms such as the diffusion process in a flooded tortuosity or the compression effects of polymeric material on their permeation properties.
The performance of structural steel wires is strongly linked to the properties of the annulus medium which can be predicted by modeling. MOLDI TM is the design software that has been developed 20 years ago to predict flexible pipes annulus environment  [3]. Among its options, this software enables to predict the condensation of water, the purging by gas release valves and to calculate the fugacity of the different gases along time up to the equilibrium. The fugacity of acid gases (CO 2 and H 2 S) has a major impact on the materials selection which is one of the most important step in the design of flexible pipes. The modeling process has been revisited and major improvements have been made. The objective of this paper is to present the theoretical basis of the diffusion process modeling and the thermodynamic module.
MOLDI TM is the software developed by IFPen and TechnipFMC to predict the annulus environment. A first technical paper about this model was published 20 years ago  [3]. The objective of this new paper is to present the improvements over the last years: The diffusion process is better described using updated physical equations, taking into account the complex geometry of the diffusion path and the impact of water in the annuli when flooded. The thermodynamic model has been improved. The permeability database is continuously maintained and improved in line with the new data available. The methodology used to get the equivalent H 2 S partial pressure taking into account its consumption has been published before  [4] [5] [6] [7] [8]  and will not be presented in this paper. 3 Physical principles and governing equations.
The results obtained with both the helical 3D and the plane 3D models are presented in Table  3  considering either a dry or a flooded annulus. In both cases the models are in good agreement validating the concept of the plane 3D model. The major advantage of the plane 3D model is its simplicity enabling to adapt its geometry to each flexible pipe characteristics and to run calculations in a reasonable time. The mass transport law that is described in Section 3. 1 is also applicable to 3DIFF model. The permeability database with the physical parameters in polymers is the same as in MOLDI TM (Sect. 3. 2).
Validation/comparison with data in service Three cases have been simulated with MOLDI™. The operating conditions and the results are presented in Table  5. For the two first cases, the annulus composition was analyzed in service and compared to the calculated composition. For the third case, the volume of condensed water in the annulus was measured during the dissection of the flexible pipe and this volume is compared to the calculated one. In terms of composition, results are not far from the measurements if we consider the operational variability that can be encountered in service compared to the calculations performed with only one set of parameters. Looking at the third case, it can be noticed that the water condensation predictions are strongly conservative compared to the measurements.
MOLDI TM is the software used for flexible pipes designs to predict the annulus equilibrium. Among its characteristics, the water condensation can be predicted and the purging through Gas Release Valve (GRV) is taken into account. This design software is efficient in terms of calculation time and it integrates a correction to take into account the effects of tortuosity and flooding when it is applicable. 3DIFF is the R&D tool that is under continuous evolution to refine the annulus medium predictions and identify the best developments for the future flexible pipes. The validation of the results obtained in flooded conditions has already started and promising results have been obtained. The test campaign is still on-going to validate the predictions in various conditions of temperature and pressure and with different materials.
The impact of the geometry will be further highlighted and tests will also be performed above the saturation, with a gas phase. The continuous improvement of the permeability database is also a major axis to refine the models predictions. As stated before, standard tests are typically performed in two compartments cell: one gas charging cell and one gas collection cell separated by a polymer membrane. New parameters are being investigated; in particular, in the recent years, the compression of the polymer has been highlighted as an important parameter. For this purpose, a specific cell has been adapted enabling to test polymer tubes at high pressure.
Conclusion Flexible pipes material selection is equally driven by the mechanical loadings and the properties of the annulus. Having reliable annulus environment predictions is thus essential to optimize flexible pipe design and avoid product performance issues in operation. In this paper the physical principles and the governing equations of the diffusion models developed by IFPen and TechnipFMC were detailed. A modification of Fick's law is used to describe the mass transport: the gradient of fugacity is now the driving force for the diffusion process. The thermodynamic module was improved using the CPA equation of state that is well adapted to the mixture of interest. A specific model called 3DIFF was developed in order to investigate the impact of water flooding associated with the complex geometry of a flexible pipe annulus.
It was highlighted that the tortuosity and the flooding of the annulus result in a strong heterogeneity and in an increase of the annulus severity. Similarly, the flooding of the insulation annulus is a key factor that also results in an increase of severity of the medium in contact with steel wires. MOLDI TM has been upgraded and remains the certified design software that is used by TechnipFMC. As with the former versions, MOLDI TM makes it possible to predict the fugacities of CO 2 , CH 4 and H 2 S in the annulus, the water condensation and the vented gas flowrates. A methodology has been developed to take into account the effects of tortuosity and flooding when it is applicable. Medium scale and full scale tests together with field data were used to validate the software. Besides a specific experimental unit was developed to validate the impact of flooding.
The applicability of program repair in the real world is a little researched topic. Existing program repair systems tend to only be tested on small bug datasets, such as Defects4J, that are not fully representative of real world projects. In this paper, we report on a longitudinal analysis of software repositories to investigate if past commits are amenable to program repair. Our key insight is to compute whether or not a commit lies in the search space of program repair systems. For this purpose, we present RSCommitDetector, which gets a Git repository as input and after performing a series of static analyses, it outputs a list of commits whose corresponding source code changes could likely be generated by notable repair systems. We call these commits the "repair-space commits", meaning that they are considered in the search space of a repair system.
Using RSCommitDetector, we conduct a study on 41, 612 commits from the history of 72 Github repositories. The results of this study show that 1. 77% of these commits are repair-space commits, they lie in the search space of at least one of the eight repair systems we consider. We use an original methodology to validate our approach and show that the precision and recall of RSCommitDetector are 77% and 92%, respectively. To our knowledge, this is the first study of the applicability of program repair with search space analysis.
INTRODUCTION Fixing software bugs is a notoriously time-consuming task for developers  [37]. To address this issue, automatic program repair systems apply repair strategies to fix software bugs without human intervention. These systems have shown promising results on bug datasets, such as Defects4J  [14]  and Bugs. jar  [36]. However, it has been shown that the performance of program repair on one of such datasets does not necessarily generalize to other datasets  [6]. Consequently, the existing evaluations cannot be taken as fully revealing the applicability of program repair in real world. In general, there are two major obstacles to evaluate the applicability of program repair systems. First, running repair systems to fix a bug requires a huge computational power  [6]. Second, most systems do test-based program repair  [30] , hence require the program under repair to have a test-suite that fails before the repair.
However, it is hard to find a large number of versions of real world projects with test-suites that can be compiled and executed  [41]. For example, after analyzing 168, 772 Travis CI builds during more than two months, Madeiral et al. [24]  found that only 251 (0. 14%) of them are real world bugs that meet all criteria for being used in a sound evaluation for program repair. Considering the aforementioned challenges, we propose a novel way for assessing the applicability of repair systems in real world. Instead of actually running a repair system on bug datasets, our key idea is to investigate how often past patches use the same repair strategies as the ones employed by program repair systems. If a human patch uses the same repair strategy as a program repair system, it can be assumed that this system would be able, in theory, to repair the same bug (modulo implementation limitations and computational power).
In this paper, we propose to specify the repair strategies that repair systems use to change the source code of a buggy program. This specification is actionable: given a repair strategy and a patch, we can say that the patch uses the same repair strategy or not. Based on a set of repair strategy specifications, we can identify the changes made by human developers that correspond to known repair systems. We design and implement RSCommitDetector for this. RSCommitDetector takes a Git repository as input and outputs the list of commits whose corresponding source code changes could likely be generated by a repair system. RSCommitDetector enables us to study the applicability of program repair on past commits. RSCommitDetector specifies the repair strategies based on the change pattern specification language of Martinez et al.
[28]. To determine if the source code change of a commit c could be generated by a repair system r , RSCommitDetector statically analyzes the change in two steps. Firstly, it checks whether the edit script of abstract syntax tree (AST) follows one of the strategies employed by r. Secondly, it checks if all code fragments used in the source code change can be synthesized by r. If c passes both checks, we say that c lies in the search space of r. The current version of RSCommitDetector specifies the search space of 8 notable repair systems: Arja  [47] , Cardumen  [27] , Elixir  [37] , GenProg  [18] , jMutRepair  [26] , Kali  [35] , Nopol  [45] , and NPEfix  [4]. To study the applicability of program repair on past commits, we run RSCommitDetector on 72 projects of Bears  [24]. We also conduct two systematic experiments to measure how accurately RSCommitDetector determines whether a commit lies in the search space of a system.
Our results show that RSCommitDetector has a precision and recall of 77% and 92%, which is arguably high, but there is no other tools doing the same task for comparing. For perspective, defect prediction over commits is a similar task, and a state-of-the-art tool reports on a precision and recall of 72% and 65%  [33]. By analyzing 41, 612 commits, our experiments show that 1. 77% (737/41, 612) of all the commits lie in the search space of at least one repair system. This is a key result for automated repair research. First, it means that it is possible to create large datasets of commits for program repair research: since there are millions of commits in open-source repositories, 1. 77% represents a fair number. Such commit datasets are utilized for different purposes, like data-driven tuning of repair systems  [22]  and training neural networks to generate commit messages for program repair patches  [13, 31].
Second, this provides a real-world estimation of the percentage of bugs which can be automatically repaired, 9. 3% (see Section 5. 1 for the explanation), this estimation 1) is consistent with recent results (9. 9% for Bears  [6] ), and 2) is more realistic than previous estimations (e. g. 52%  [17] ). We note that among the considered repair systems, Elixir  [37]  is the system whose search space covers the largest number of commits (0. 86%), while jMutRepair search space covers the least (0. 01%) of all considered commits. To sum up our contributions are: • A conceptual framework for specifying the search space of program repair systems, appropriate to study the applicability of program repair on past commits of software repositories. • RSCommitDetector, a publicly available tool that implements the conceptual framework.
Given a Git repository, RSCommitDetector automatically detects the commits lying in the search space of 8 notable program repair systems. • A comprehensive series of longitudinal experiments. By analyzing 41, 612 commits from 72 Github repositories, we show that 1. 77% of commits in this dataset lie in the search space of at least one of the considered repair systems. This is a major result because it gives practitioners a clear and intuitive understanding of where a state-of-the-art of program repair lies. • A systematic measurement of the reliability of RSCommit-Detector. Our prototype system has a precision and recall of 77% and 92%, respectively which is arguably high w. r. t to the difficulty of code change analysis. The rest of this paper is organized as follows: Section 2 presents the terminology that we use in this paper.
g. , see Listing 1). Per this strategy, an if-statement is added before a suspicious statement. The corresponding if-condition checks whether a variable used by the suspicious statement is equal to null. If the if-condition holds, a return statement is executed. Repair Ingredient: An existing source code fragment that is reused by a repair system to fix the bug  [29, 44]. For example, in one of its repair strategies, GenProg  [18]  creates a candidate patch by replacing a suspicious statement by another existing statement written elsewhere in the program. The latter is the ingredient of the candidate patch. Note that ingredients can have different types. For example, in GenProg the ingredient is a statement, in NPEfix  [4]  it is a variable, and in Cardumen  [27]  it is a template mined from the program under repair.
Scope of Ingredients: The scope of ingredients is all the parts of program that are considered for extracting the ingredient  [29, 44]. For example, when jGenProg  [26]  (a Java implementation of GenProg) replaces an old statement s (written in file f from package Listing 1: Commit 275c6 in Jgrapht, which is in the search space of NPEFix, it applies repair strategy "skip method". p) with a new one, the new statement can be selected from three different scopes: 1) same file (i. e. , f ), 2) same package (i. e. , from any file belonging to p), and 3) same program. Search Space of Repair System: Let us assume a repair system r with certain repair strategies and scope of ingredients. When a program is given as the input, the search space of r is the set of all patches that r can generate for the program given the strategies and ingredients  [25].
LONGITUDINAL ANALYSIS ON PAST COMMITS 3. 1 Overview In this paper, our main goal is to mine open-source repositories for detecting repair-space commits, defined as follows: Repair-space Commit: Given a commit c that transforms the old_version of a program into the new_version and a repair system r , we say that c is a "repair-space commit" for r if and only if new_version is in the search space of r when old_version is given as the input. For example, Listing 1 is a real commit in project Jgrapht, this code change is in the search space of NPEfix, hence we say that this commit is a repair-space commit for NPEfix. In this example, line 1 and line 5 are from the old_version, while in the new_version lines 2-4 are added. When the old_version is given to NPEfix as input, new_version is in the search space because NPEfix can generate it using the "skip method" strategy.
We design and implement RSCommitDetector to detect repairspace commits. RSCommitDetector encodes the search space of repair systems. In particular, it encodes each repair strategy rs by specifying a) the repair operators from rs, expressed using finegrained code changes, and b) the rules that those changes must respect (e. g. , the code introduced by a change is a valid ingredient according to a given scope). If a commit is detected by RSCommit-Detector to lie in the search space of a repair system, we call it a "detected repair-space commit". Figure  1  shows an overview of how RSCommitDetector works. The whole process consists of four steps. 1) Input preparation: for a given Git repository, the tool identifies updated files for each commit. 2) Extracting AST actions: for each updated file, the actions that transform the AST of the old revision into the new one are extracted.
3) Extracting change pattern instances: the updated files whose corresponding AST actions match a "repair systems change pattern" are determined. We design the change patterns to model the repair strategies employed by repair systems. 4) Final checking: the commits whose updated files match change patterns are checked to see if the new code fragments that they use for the update can also be generated by the repair systems. The result of the fourth step are the commits that RSCommitDetector detects as repair-space commits. In Section 3. 2 to Section 3. 5, we present each of these steps with more details.