dataesr/scientific-paragraphs-categorization huggingface dataset:
In the present work, the angular correlation analysis was carried out with the computer code CORLEONE  [35]. The best fit confirms the spin hypothesis 11 → 10 → 9. In the present experiment, we used the four Clover detectors from the ring at 90 degrees with respect to the beam axis as one composite Compton polarimeter. The coincidence signals from the respective arms of the polarimeter, perpendicular and parallel to the reaction plane, were summed-up to improve the statistics. The difference spectrum in Fig. 2  reflects the linear polarization of the transitions observed. The negative lines correspond to transitions of predominantly magnetic character while the positive lines correspond to transitions of predominantly electric character. The electromagnetic character of all previously known transitions was confirmed.
[36, 41]. For the analysis of the DSAM data, we performed a Monte Carlo simulation of the slowing-down histories of the recoils using a modified  [34, 42]  version of the program DESASTOP  [43]. The analysis of the line shapes was carried out according to the DDCM for treating DSAM data  [36, 37]. The results are shown in the Table  2. The clover rings of Euroball form a highly efficient Compton polarimeter. On the basis of directional correlation of γ radiation from oriented states  [44]  and linear polarization analysis, an M1 character with negligible E2 component was assigned to the ΔI = 1 intraband transitions. The ΔI = 2 intraband transitions show an E2 character. The interband transitions with ΔI = 2 have an E2 character and the interband transitions with ΔI = 1 show a mixed M1 + E2 character.
In the TQPTR calculation, both yrast and yrare negative -parity bands are based on the 11th proton orbital with positive parity and on the 14th neutron orbital with negative parity. They originate from the πg 9/2 and νh 11/2 subshells and are associated at γ = 0 • with the Nilsson configurations 7/2 + [413] and 1/2 -[550], respectively. The calculated transition strengths are compared to the experiment in Fig. 3. The theoretical B(E2)'s reproduce quite well the absolute values and the increasing trend of the experimental data after spin I = 14. At lower spins, the description is worse since the rigid rotor approach cannot explain the small drop of the experimental values between spins 9 and 13. The comparison between the experimental and calculated B(M1) transition strengths leads to the conclusion that the TQPTR calculations reproduce roughly the data in Band 1, but overestimate the transition strengths in Band 2 (at spins 10,11 ).
For the TQPTR, the ratio between the moments of inertia have been calulated by cracking about the three principle axes using the parameters reported in Ref. [2]. In the IBFFM calculation, the proton and neutron are coupled to the triaxial core as described in Ref. [55]. Both descriptions include the coupling between the odd particles and the even-even core in a similar way, taking into account the partial filling of the h 11/2 shells. The orientation in space is the only core degree of freedom in the TQPTR model. In IBFFM the deformation of the core is taking into account as an additional degree of freedom. The results of both calculations are shown in Fig. 5. The comparison with the experimental data show a clear disagreement with TQPTR results and much better matching with the IBFFM calculation.
In the case of 102 Rh the comparison between the experimental and calculated B(M1) transition strengths leads to the conclusion that the TQPTR calculations reproduce roughly the data in Band 1 and are consistent with the transition strengths in Band 2 at spin 11. The absence of an appreciable staggering of the data in Band 1 indicates that the expectation for the observation of a static chirality are not realized. Also, the TQPTR calculations reveal that the optimum value of the triaxiality parameter γ = 20 • differs from the value of 30 • characterizing the static chiral case. In the case of 134 Pr we performed IBFFM calculations, where the IBFFM core has the deformation parameters as additional degrees of freedom, which are described by the IBM. The γ -decay properties of the levels, calculated in this framework, are in excellent agreement with experimental data.
Acknowledgements This research has been supported by  Bulgarian Science Fund  under Contract No. DFNI-E 01/2  and by a  NUPNET-NEDENSAA  project funded by the  Bulgariana Ministry of Education and Science. INGA  was funded by the  Department of Science and Technology, Government of India (Grant No. IR/S2/PF-03/2003-I ) and the  University Grants Commission.
Climate simulations The downscaled climate simulations used in this study are derived from the SCRATCH2010 database (http://www. cerfacs. fr/~page/scratch/), which has been used in various climate change impact studies in France (e. g. Gouache et al. , 2012; Habets et al. , 2013). SCRATCH2010 climate simulations are generated using a statistical downscaling method applied to global largescale climate simulations. The methodology is described in  Boé et al. (2006) , and in  Boé and Terray (2008). It is based on weather-typing and builds on the physical links between the large-scale circulation and the local scale climate, from which statistical relationships can be derived. The spatial scale of representation is changed but the temporal distribution of weather variables is close to the parent global simulation.
The ISBA land surface model In this study, we use these latest improvements of the model within the SURFEX version 7. 3 software. This version of the model is similar to the one validated using satellite LAI products by  Lafont et al. (2012)  and  Szczypta et al. (2014) , except for the addition of a subroot-zone soil layer  (Boone et al. , 1999)  and an enhanced multilayer canopy radiative transfer model  (Carrer et al. , 2013). The values of the ten key parameters of the model are listed in Table  1  for the vegetation types considered in our simulations. Key parameters of the photosynthesis model respond to the soil water stress permitting the representation of drought-avoiding and drought-tolerant responses to drought. For low vegetation and for trees, the response to drought is based on the meta-analysis of  Calvet (2000)  and  Calvet et al.
Acknowledgements This work was supported by  ANR  in the framework of the  ORACLE  project ( ANR-10-CEPL-011 ). We thank  Nathalie de Noblet  (LSCE) and  Iñaki Garcia de Cortazar Atauri (INRA)  for their helpful comments and advices, and  Catherine Meurey (CNRM)  for technical support. We want to pay tribute to the memory of  Nadine Brisson (INRA) , who played a key role in the initiation of this project.
INTRODUCTION Microbenchmarks allow for the finest grain performance ACM ISBN 978-1-4503-2138-9. DOI: 10. 1145/1235 testing (e. g. , test the performance of a single loop). This kind of test has been consistently used by developers in highly dependable areas such as operating systems  [30, 19] , virtual machines  [9] , data structures  [32] , databases  [23] , and more recently in computer graphics  [25]  and high performance computing  [29]. However, the development of microbenchmarks is still very much a craft that only a few experts master  [9]. In particular, the lack of tool support prevents the adoption of microbenchmarking by a wider audience of developers. The craft of microbenchmarking consists in identifying a code segment that is critical for performance, a. k. a segment under analysis (SUA in this paper), wrapping this segment in an independent program (the payload ) and then have it executed a large number of times by the scaffold in order to estimate its execution time.
The amount of technical knowledge needed to design both the scaffold and the payload hinder engineers from effectively exploiting microbenchmarks  [2, 3, 9]. While recent frameworks such as JMH  [2, 20, 18]  address the generation of the scaffold, the construction of the payload is still an extremely challenging craft. Engineers who design microbenchmark payloads very commonly make two mistakes: they forget to design the payload in a way that prevents the JIT from performing dead code elimination  [9, 20, 7, 3]  and Constant Folds/Propagations (CF/CP)  [1, 20]. Consequently, the payload runs under different optimizations than the original segment and the time measured does not reflect the time the SUA will take in the larger application. For example, Click  [9]  found dead code in the CaffeineMark and ScifiMark benchmarks, resulting in infinite speed up of the test.
Dead Code Elimination is avoided applying a novel transformation called sink maximization, while (CF/CP) is mitigated by turning some SUA's local variables into fields in the payload. Finally, the payload is maintained in stable state by smart reseting variables to their initial value. The main objective of this technique is to assist Java developers who want to test the performance of critical code segments. We have implemented the whole approach in a tool called AutoJMH. Starting from code segment identified with a specific annotation, it automatically generates a payload for the Java Microbenchmark Harness (JMH). We use JMH as the scaffold for our microbenchmarks since it is the de-facto standard for microbenchmarking today. The framework address many of the common pitfalls when building scaffolds such as Loop Hoisting and Strength Reduction, optimizations that can make the JIT reduce the number of times the payload is executed.
We evaluate AutoJMH according to three different dimensions. First, we evaluate to what extent our program analyses can generate payloads out of large real-world programs. We run AutoJMH on the 6 028 loops present in 5 mature Java projects: our technique can extract 4705 SUA into microbenchmarks (74% of all loops) and find initialization values and generate complete payloads for 3462 (60%) of the loops. Second, we evaluate the quality of the automatically generated microbenchmarks: we use AutoJMH to regenerate 23 microbenchmarks handwritten by performance experts to effectively detect 8 performance issues. Automatically generated microbenchmarks measure the same times as the microbenchmarks written by the JMH experts. Third, we qualitatively compare the microbenchmarks generated by 6 professional Java engineers, noticing that engineers usually make naive decisions when designing their benchmarks, distorting the measurement, while AutoJMH prevents all these mistakes by construction.
To sum up, the contributions of the paper are: • A static analysis to automatically extract a code segment and all its dependencies • Code generation strategies that prevent artificial runtime optimizations when running the microbenchmark • An empirical evaluation of the quality of the generated microbenchmarks • A publicly available tool and dataset to replicate all our experiments 2 In section 2 we discuss and illustrate the challenges for microbenchmark design, which motivate our contribution. In section 3 we introduce our technical contribution for the automatic generation of microbenchmarks in Java. In section 4 we present a qualitative and quantitative evaluation of our tool and discuss the results. Section 5 outlines the related work and section 6 concludes.
Dead Code Elimination Dead Code Elimination (DCE) is one of the most common optimizations engineers fail to detect in their microbenchmarks  [9, 21, 7, 20]. During the design of microbenchmarks, engineers extract the segment they want to test, but usually leave out the code consuming the segment's computations (the sink ), allowing the JIT to apply DCE. It is not always easy to detect dead code and it has been found in popular benchmarks  [9, 21]. For example, listing 1 displays a microbenchmark where the call to Math. log is dead code, while the call to m. put is not. The reason is that m. put modifies a public field, but the results of the Math. log are not consumed afterwards. Consequently the JIT will apply DCE when running the microbenchmark, which will distort the time measured. Map < String , Double > m = MapUtils.
AUTOJMH AutoJMH automatically extracts a code segment and generates a complete payload with inputs that reflect the behavior of the segment in the original application. The generation process not only wraps the segment in an independent program, it also mitigates the risks of unexpected DCE and CF/CP optimizations and ensures that it will reach stable state in the same state executed by the SUA during the unit tests. Figure  1  illustrates the different steps of this process. If the SUA satisfies a set of preconditions (detailed in section 3. 1), AutoJMH extracts the segment into a wrapper method. Then, the payload is refined to prevent dead code elimination, constant folding and constant propagation (steps 2, 3), as well as unintended stable state (step 4) when the payload is executed many times.
The last steps consist in running the test suite on the original program to produce two additional elements: a set of data inputs to initialize variables in the payload; a set of regression tests that ensure that the segment has the same functional behavior in the payload and in the original application. In the rest of this section we go into the details of each step. We illustrate the process through the creation of a microbenchmark for the return statement inside the Enu-meratedDistribution::value() method of Apache Common Math, shown in listing 3. The listing also illustrates that a user identifies a SUA by placing the Javadoc-like comment @bench-this on top of it. This comment is specific to AutoJMH and can be put on top of every statement. The resulting payload is shown listing 4. double value (double x , double.
param ) throws DimensionMismatchException , N u l l A r g u m e n t E x c e p t i o n { v a l i d a t e P a r a m e t e r s ( param ) ; /* * @bench -this */ return Sigmoid. value (x , param [0] , param  [1] ) ; } Listing 3: An illustrating example: a SUA in commons. math In listing 4 we can see that AutoJMH has wrapped the return statement into a method annotated with @Benchmark. This annotation is used to indicate the wrapper method that is going to be executed many times by the JMH scaffold. The private static method Sigmoid. value has been extracted also into the payload, since it is needed by the SUA. AutoJMH has turned variables x and params into fields and provides initialization code from them, loading values from a file, which is part of our strategy to avoid CF/CP. Finally, AutoJMH ensures that some value is returned in the wrapper method to avoid DCE.
SUA extraction AutoJMH starts by extracting the segment under analysis (SUA) to create a compilable payload. This extraction step processes the Abstract Syntax Tree (AST) of the large application, which includes the source code of the SUA. The segment's location is marked with the @bench-this Javadoc-like comment, introduced by AutoJMH to select the segments to be benchmarked. If the SUA satisfies the preconditions, AutoJMH statically slices the source code of the SUA and its dependencies (methods, variables and constants) from the original application into the payload. Non-public field declarations and method bodies used by the SUA are copied to the payload, their modifiers (static, final, volatile) are preserved. Some transformations may be needed in order to achieve a compilable payload.
Non-public methods copied into the payload are modified to receive their original target in the SUA as the first parameter (e. g. , data. doSomething() becomes doSomething(data)). Variable and method may be renamed to avoid name collision and to avoid serializing complex objects. For example, suppose a segment using both a variable data and a field myObject. data, AutoJMH declares two public fields: data and myObject_data. When method renaming is required, AutoJMH uses the fully qualified name. At the end of the extraction phase, AutoJMH has sliced the SUA code into the payload's wrapper method. This relieves the developer from a very mechanical task and its automation reduces the risks of errors when copying and renaming pieces of code. Yet, the produced payload still needs to be refined in order to prevent the JIT from "overoptimizing" this small program.
Therefore, we first use the return statement at the end of the method, taking into consideration that values stored in fields are already sinked and therefore do not need to be consumed. Then, we look for the minimal set of variables covering the whole sink of the payload to minimize the number of BH methods needed. Sink maximization performs the following steps to generate the sink code: To determine the minimal set Vmin, the AutoJMH converts the SUA code into static single assignment (SSA) form  [34]  and builds a value dependency graph (VDG)  [35]. In the VDG, nodes represent variables and edges represent direct value dependencies between variables. For example, if the value of variable A directly depends on B, there is an edge from B to A. An edge going from one variable node to a phi node merging two values of the same variable is a back-edge.
Keep stable state with Smart Reset In Section 2 we discussed the risk for the payload to reach an unintended stable state. This happens when the payload modifies the data over which it operates. For example, listing 6 shows that variable sum is auto-incremented. Eventually, sum will be always bigger than randomValue and the payload will stop to execute the return statement. AutoJMH assumes that the computation performed in the first execution of the payload is the intended one. Hence, it automatically generates code that resets the data to this initial state for each run of the SUA. Yet, we implement this feature of AutoJMH carefully to bring the reset code overhead to a minimum. In particular, we reset only the variables influencing the control flow of the payload. In listing 7 AutoJMH determined that sum must be reset, and it generates the code to do so.
Retrieving inputs for the payload The last part of the microbenchmark generation process consists in retrieving input values observed in the original application's execution (steps 5 and 6 of figure  1 ). To retrieve these values, we instrument the original program to log the variables just before and after the SUA. Then, we run once the test cases that cover the SUA in order to get actual values. In order to make the collected values available to the wrapper method in the payload, AutoJMH generates a specific JMH method marked with the @Setup annotation (which executes only once before the measurements), containing all the initialization code for the extracted variables. Listing 4 shows an example where variables x and params are initialized with values retrieved from a log file.
EVALUATION We perform a set of experiments on large Java programs to evaluate the effectiveness of our approach. The purpose of the evaluation is twofold. First, a quantitative assessment of AutoJMH aims at evaluating the scope of our program analysis, looking at how many situations AutoJMH is able to handle for automatic microbenchmark generation. Second, two qualitative assessments compare the quality of Au-toJMH's generated microbenchmarks with those written by experts and with those built by expert Java developers who have little experience in microbenchmarking. We investigate these two aspects of AutoJMH through the following research questions: RQ1: How many loops can AutoJMH automatically extract from a Java program into microbenchmarks? In addition to the generation of accurate microbenchmarks, it is important to have a clear understanding of the reach of AutoJMH's analysis capacities.
RQ1: Automatic extraction of segments We run AutoJMH on 5 real Java projects to find out to what extent the tool is able to automatically extract loops and generate corresponding payloads. We focus on the generation of benchmarks for loops since they are often a performance bottleneck and they stress AutoJMH's capacities to deal with transient states, although the only limitations to the slicing procedure are the ones described in section 3. 1. We selected the following projects for our experiments, because their authors have a special interest in performance (the exact versions can be found in AutoJMH's repository 5  ): Apache Math is the Apache library for mathematics and statistics; Vectorz is a vector and matrix library, based around the concept of N-dimentional arrays. Apache Common Lang provides a set of utility methods to handle Java core objects; Jsyn is a well known library for the generation of music software synthesizers.
ImageLib2 is the core library for the popular Java scientific image processing tool ImageJ. To answer RQ1, we annotate all the 6 028 loops in these 5 projects and run AutoJMH to generate payloads. Table  2  sumarizes our findings, one column for each project and the last column shows totals. The row "Payloads generated" shows the number of loops that AutoJMH succesfully analyzed and extracted in a payload code. The row "Payloads Generated & Initialized" refines the previous number, indicating those payloads for which AutoJMH was able to generate code and initialization values (i. e. they were covered with at least one unit test). The row "Microbenchmarks generated" further refines the previous numbers, indicating the amount of loops for which AutoJMH was able to generate and initialize a payload that behaves functionally the same as the SUA (i.
e. equal inputs produce equal results). The rows below detail the specific reason why some loops could not be extracted. We distinguish between "Variables unsupported" or "Invocations Unsupported". As we can see, the main reason for rejection are unsupported variables. Finally, row "Test Failed" shows the number of microbench- The key result here is that out of the 6 028 loops found in all 5 projects, AutoJMH correctly analyzed, extracted and wrapped 3 462 loops into valid microbenchmarks. These microbenchmarks resulted from 3 485 payloads for which Au-toJMH was able to generate and find initialization values and who's regression test did not fail. In total, AutoJMH generated the code for 4 705 payloads. The tool rejected 1377 loops because they did not meet the preconditions. Looking into the details, we observe that Vectorz and Apache Lang contain relatively more loops that satisfy the preconditions.
Microbenchmarks dataset We re-generate 23 JMH microbenchmarks that were used to find 8 documented performance regression bugs in projects by Oracle 6  and Sowatec AG  [12]. We selected microbenchmarks from Oracle, since this company is in charge of the development of Hotspot and JMH. The flagship product of Sowatec AG, Arregulo 7  , has reported great performance results using microbenchmarks. The microbenchmarks in our dataset contained several elements of Java such as conditionals, loops, method calls, fields and they where aimed at variety of purposes. Follows a small description of each one of the 23 microbenchmarks (MB) in our dataset: MB 1 and 2: Measure the differences between ArrayList. add and ArrayList. addAll when adding multiple elements. MB 3 to 5: Compare different strategies of creating objects using reflection, using as baseline the operator new.
Eleven microbenchmarks generated with wrong variable declarations still measure similar times, because some SUA cannot be constant folded (e. g. , the Map. get method in in MB 7 cannot be constant folded). Finally, line 5 shows that passing wrong initial values produces different results, since adding 5 elements to a list takes less time than adding 20 (MB 1, 2) or converting into a string the PI constant  (3, 141592653589)  is certainly slower than a integer such 4 for example (MB 18 to 23). The three cases that measured correct times occur when the fields that are initialized in the payload are not used (as is the case in MB 5). The code for all the microbenchmarks used in this experiment, as well as the program and the unit test used to rebuild them, can be found in the website of AutoJMH 8.