dataesr/scientific-paragraphs-categorization huggingface dataset:
Cell tracking in cytonote 6w data Initial videos were preprocessed using Fiji commands Gaussian blur (2. 0) and Variance filter (10. 0), then a Fiji plug-in Trackmate  (Tinevez et al. , 2017)  was used to track cells and extract their trajectories. Parameters used were -DoG detector (diameter -35 pixels, threshold -5, subpixel localization), Simple LAP tracker (linking max distance -15, gap-closing max distance -15, gap-closing max frame gap -5). Tracks were filtered with several parameters ('Track displacement' -above 5, 'Duration of track' -above 50, 'Track start' -below 61). Extracted cell trajectories were further analyzed using a custom-made Matlab routine (which you can find in Figure  4 -source data 1).
Reorientation plot analysis Evaluation of the Nucleus-Golgi axis reorientation requires two axes: one going through the centroid of the Nucleus and the centroid of the Golgi and another one going through the center of the Nucleus and the center of the optogenetic activation area. The previously described image segmentation techniques were used to segment the optogenetic activation area. Next, the angle between the two axes was calculated using centroid coordinates and an inverse tangent function 'atan' in Matlab. Then, the angle in radians was wrapped to [0 2pi], using the 'wrapTo2Pi' function and unwrapped with 'unwrap' function. The angle, then, was converted from radians to degrees and plotted in a graph.
Cumulative plot analysis The speed of the axis reorientation process in different experimental conditions was compared by plotting the data from the previously described reorientation analysis. The first timepoint, when the angle reached 30° was chosen to delineate that the Nucleus-Golgi axis has reoriented, which gave the timing of the reorientation for each cell. Next, the 'cumsum' function in Matlab was used to get the cumulative sum of how many cells have reoriented at a certain timepoint, which was then normalized to 1 (depicting 'all cells') by dividing by the total number of cells in the dataset.
Morphodynamic map analysis Morphodynamic map analysis was based on the similar analysis in  Yang et al. , 2016. The cell displacement was followed from frame to frame, providing information, where cell plasma membrane was protruding and where it was retracting. In practice, the contour of the cell in each frame of the video was equidistantly divided into 100 points, called markers. From one frame to another, the pairing of markers was chosen by minimizing the total square distances between markers at time t and t + dt by testing all possible circular shifts of the contour at t + dt. The position of the Nucleus-Golgi axis, calculated from the Golgi and nucleus centroid positions, was plotted on top of the morphodynamic map, showing which way it was pointing. For further analysis and visualization, each column of the obtained morphodynamic maps could be (circularly) shifted, so that the middle marker always represents the Nucleus-Golgi axis, cell trajectory or the x-axis of the image by using Matlab's 'circshift' function.
Cross-correlation analysis of traffic flow Image stacks in tiff format were adjusted using Fiji's 'Bleach correction -Histogram matching' function. Then, a previously described morphodynamic map of cell protrusions was recorded for every cell, and a Golgi mask was created using the segmentation algorithm described in the section of 'Image segmentation'. A line was drawn from every one of 100 points of the cell boundary in the morphomap toward the centroid of the Golgi mask. Using Matlab's function 'improfile', the mean of fluorescence intensity was calculated along every line. Using these calculations another morphomap, depicting the secretion pattern, was drawn and cross-correlation between the two morphomaps was calculated using 'xcov' function in Matlab.
Statistical analysis Unless otherwise noted, all experimental results are from at least three independent experiments. For data which didn't follow normal distribution, we used a nonparametric Wilcoxon rank sum test (comparing two groups) or Kruskal-Wallis test (for experiments with more than two groups) followed by a post hoc Dunn's multiple comparison test. All tests were performed using Matlab. Statistical details of each experiment can be found in the figure legend. Unless otherwise indicated, error bars represent standard deviation (s. d. ).
Acknowledgements We thank the  Institut Curie Cytometry platform  for cell sorting;  Remy Fert  and  Eric Nicolau  from the  Mechanical Workshop  for their technical assistance;  Pascal Silberzan  and  Caroline Giuglaris  for the access and help with Cytonote 6 W microscope;  Gaëlle Boncompain  for sharing the RUSH system contructs;;  Mathieu Deygas  for RPE1::EGFP-α-tubulin cell line;  Krek lab  for RPE1::EB3-EGFP cell line;  Aastha Mathur  for advice on the Immunofluorescence (IF) staining protocol;  Pallavi Mathur  for help with Western blot (WB) technique;  Bruno Goud  for critical reading of the manuscript and helpful discussions;  John Manzi  and  Fahima Di Federico  from  UMR168 BMBC platform ,  Maud Bongaerts  and  Laurence Vaslin  for experimental advice and help with plasmid constructs;  Jean de Seze  for fruitful discussions and help with adaptation of the cell tracking routine.
The Hubble Frontier Fields represent the opportunity to probe the high-redshift evolution of the main sequence of star-forming galaxies to lower masses than possible in blank fields thanks to foreground lensing of massive galaxy clusters. We use the BEAGLE SED-fitting code to derive stellar masses, M = log ( M / M ), SFRs, = log ( ψ / M yr -1 ), and redshifts from galaxies within the ASTRODEEP catalogue. We fit a fully Bayesian hierarchical model of the main sequence o v er 1. 25 < z < 6 of the form = α 9. 7 ( z) + β( M -9. 7) + N (0 , σ 2 ) while explicitly modelling the outlier distribution. The redshift-dependent intercept at M = 9. 7 is parametrized as α 9. 7 ( z) = log [ N (1 + z ) γ ] + 0. 7. Our results agree with an increase in normalization of the main sequence to high redshifts that follows the redshift-dependent rate of accretion of gas on to dark matter haloes with γ = 2.
DATA A N D S E D F I T T I N G The ASTRODEEP catalogue  (Merlin et al. 2016a ; Castellano et al. 2016 ; Di Criscienzo et al. 2017 )   2017 ) describe how the catalogues are produced but we summarize the main points here. The F160W image is used for primary object detection and provides the base of the catalogue. New objects detected in a stacked IR image (F105W, F125W, F140W, and F160W-band) are added to the catalogue. The total ASTRODEEP catalogue contains 29 373 objects. For the purpose of this work we only use the cluster fields, containing 15 379 objects. The HAWK-I K s-band imaging and Spitzer IRAC imaging has significantly poorer resolution than the HST data. Therefore the ASTRODEEP team use a deconfusion method, using the software TPHOT  (Merlin et al. 2015 (Merlin et al. , 2016b ) ) , to perform photometry in these longer wavelength images, taking the high-resolution HST detection image as a prior of the source shapes and positions.
SED fitting We wish to exploit the full form of the posterior distribution in stellar mass, M [ = log ( M / M )], SFR, [ = log ( ψ / M yr -1 )], and redshift, z to derive constraints on the main sequence and its evolution. Although the ASTRODEEP team supplied photometric redshifts and derived physical parameters, to achieve our goal, we refit to the photometry using BEAGLE (BayEsian Analysis of GaLaxy sEds), a Bayesian SED fitting code (Che v allard & Charlot 2016 ). A.
Where two of the three Gaussians o v erlap within 1. 5 σ in redshift, their probabilities are summed together and joint probability compared to the final peak. Where all three Gaussians o v erlap, no peak is rejected. Although only ∼6 per cent of galaxies had peaks remo v ed, this was necessary because a small fraction of low-redshift objects with a peak at high redshift can significantly affect the results since there are far fewer high-redshift galaxies. The implementation of the full model is based initially on the J. Meyers PYTHON implementation 6  of the K07 Gibbs sampler updated by CL21 to accept GMM fits to posterior M --z distributions derived from BEAGLE fitting. We release the code and input values used for this work. 7.
This might take the form of retaining only objects with abo v e a lower limit which is defined by how well is constrained. This type of modelling is explicitly accounted for in the package LEO-PY ,  (Feldmann 2019 ) , but the underlying model does not explicitly account for outliers. This is mitigated by  Feldmann ( 2019 )  when fitting to the main sequence at 0. 01 < z < 0. 05 by modelling the distribution as asymmetrically distributed about the main sequence, allowing a tail to low to account for quiescent galaxies and those in transition. Ho we ver, we have demonstrated that objects above the relation also need to be accounted for in an outlier model. It is beyond the scope of this paper to include modelling of censored data, which we defer to future work. It is possible that the lower-limit in the prior for a rising SFH is reducing the slope we measure from the main sequence, since the region of low at low mass required to produce a steeper slope is relatively inaccessible thanks to the effective prior.
Search and data extraction strategies We searched the databases Medline through PubMed and Embase from inception until 31 August 2021. We used a series of key words and their corresponding Mesh terms for the Pubmed search and the same key words as Emtree terms for the Embase search. Full search strategies are available in supplementary material. One investigator (S. G. ) screened titles and abstracts for eligibility. Two investigators (S. G. , L. B. L. N. ) independently read the selected articles to assess eligibility and met to determine final eligibility. A third investigator (O. L. ) split the case in case of persistent discrepancy. We screened grey literature (frequent consultation of core clinical journal websites, abstracts of the congresses of international infectious diseases societies, advisory committee on immunization practice presentations regarding COVID-19 vaccines in immunocompromised populations) and references lists of included reports for further studies.
One investigator (S. G. ) collected the following data from all selected reports: study type, study population, control group (if any), vaccine used, estimated vaccine efficacy or effectiveness, time from completion of vaccination to measurement of immunogenicity, methods for measurement of immunogenicity, cellular response indicators (if any), neutralization indicators (if any), amount and rate of non-responders (to an additional dose of vaccine if any), factors associated with non-response or lower antibody titres (in multivariable analysis, if any, otherwise in univariable analysis). If studies did not report response status after completion of vaccination schedule for their entire study population, we only considered the subpopulations for whom those data were available. We collected and synthesized data from studies and created graphs using an Excel spreadsheet.
Results We launched searches on 7 June 2021, again on 21 June 2021, and set up daily e-mail alerts on both databases for subsequent days until 31 August 2021. Searches retrieved 3544 results on Medline and 2373 results on Embase, with 525 duplicates. After title and abstract screening, we retained 271 reports. After full-text reading, grey literature and reference list inspection, 162 studies were included from 170 reports (some reports detailed different timepoints of the same study [15e28] (Fig. 1 ). Most studies were prone to some bias; 21 of them were estimated of good quality (Tables  S1  and S2 ). Most frequent sources of bias were lack of definition of population from which participants were included, of sample size calculation and of adjustment on potential confounding factors. The studies on vaccine efficacy or effectiveness were all considered of good or fair quality in the risk of bias assessment.
Immunogenicity data Most studies (n ¼ 157) reported immunogenicity data amounting to 25 209 participants, mainly cancer or haematological malignancy patients (7835, 31. 1%), patients on dialysis (6302, 25. 0%), solid organ transplant recipients (5974, 23. 7%) and immune-mediated disease patients (4680, 18. 6%). Eighty-three of those studies included a control population who also received the vaccine or recovering COVID-19 patients.
which took place during periods of high local prevalence of the alpha variant  [183]. However, data on the delta variant are still missing, and studies in the general population suggest a reduced effectiveness against SARS-CoV-2 infection (but not against severe forms) with this variant  [218, 219]. No study has yet reported effectiveness nor efficacy of an additional dose of vaccine in immunocompromised populations. Further studies with longer follow-up will help determine longterm immunogenicity. Literature data are still scarce if existent in many immunocompromised populations, including patients with inborn errors of immunity, allogenic stem cell transplantation and people living with HIV. A search of the ClinicalTrials. gov database on 31 August 2021 revealed two ongoing randomized controlled trials in immunocompromised populations: one comparing the Moderna and Pfizer vaccines in solid organ transplant recipients and people living with HIV, and one in patients with chronic kidney disease and dialysis comparing the Moderna and Pfizer vaccines as third dose after two doses of mRNA vaccines.
Other phase 2 or phase 3 studies evaluating currently not approved COVID-19 vaccines include people living with HIV. This review has certain limitations. The included studies assessed post-vaccine antibody response through various anti-Spike protein assays, performed at different timepoints. Heterogeneity in populations and methods used to assess immunogenicity and frequent lack of details on included populations make it difficult to perform meta-analysis with currently available data, which is why we chose not to do so. Most included studies were observational with a small sample size, thus permitting little adjustment on confounding. We could not perform additional analyses of factors associated with non-response as individual data were mostly unavailable, thus we reported those as mentioned by the authors.
With commits and releases, hundreds of tests are run on varying conditions (e. g. , over different hardware and workloads) that can help to understand evolution and ensure non-regression of software performance. We hypothesize that performance is not only sensitive to evolution of software, but also to different variability layers of its execution environment, spanning the hardware, the operating system, the build, or the workload processed by the software. Leveraging the MongoDB dataset, our results show that changes in hardware and workload can drastically impact performance evolution and thus should be taken into account when reasoning about evolution. An open problem resulting from this study is how to manage the variability layers in order to efficiently test the performance evolution of a software.
We rely on the concept of deep variability: existing interactions between different variability layers can modify or disturb our understanding of software variability and thus changing its underlying performance  [16, 25]. Since the performance decreases in a heterogeneous way across all tests, tasks and projects 3 , it sometimes complexifies the developer life when reviewing code or pull requests. 1 See https://github. com/mongodb/mongo/pull/1068#discussion_r56706401 or https: //github. com/mongodb/mongo/pull/1118#discussion_r88797998 2 See https://github. com/mongodb/mongo/pull/472#issuecomment-22801074 3 See also https://github. com/mongodb/mongo/pull/23 Previous work has shown that thanks to testing infrastructures like Evergreen  [7] , it is yet possible to identify change points  [8]  i.
e. , changes made by developers that significantly alter software performance and measure their impact on the daily usage of the software. We are also interested in studying the impact of these change points, but in relation to the executing environments of MongoDB and the possible impact of variability layers. In short: is MongoDB performance evolution sensitive to deep variability? Figure  1  typifies the problem we are addressing  5. On the top graph, we display the change points detected by the test infrastructure over time, as well as their effect and impact on the performance (y-axis, percentage change). Bubble sizes represent the Z-scores  [1]  related to the change points. On the bottom, we show the evolution of performances i. e. , Time Series (TS) for six different executing environments but considering the same project, task, variant of hardware and test for each.
Like that, we are able to observe the effect of a change point on the different Time Series, each TS having its own evolution. The interesting part starts in the middle of May and ends in June 2021 ; around the 15 ℎ of may, the performance property suddenly drops for TS #1, TS #4 and TS #5 while it increases for TS #2, TS #3 and TS #6. This suggests that two groups of TS react differently to the same commit. This result can be explained by looking at the thread level set when executing MongoDB. With the thread level fixed at 1, the performance property  6  increases. With a thread level of 512, the performance drops. Is it a performance bug though? Based on their thread level value when configuring the software, users will either agree or disagree. In this case, this is an example showing how an external factor (like the thread level here) threatens the work of MongoDB developers.
This issue was fixed in the end of May. After this addition -or deletion, performance matches its former value for all time series. In this paper, we aim at identifying different variability layers impacting the evolution of performance of MongoDB. We first study the difference of performance evolution according to hardware in Section 2 and then the impact of workloads in Section 3. Technical details. This paper is part of the ICPE 2022 Data Challenge  7. We rely on the dataset they provided for all our experiments  8. For Sections 2 and 3, we use the Legacy Performance Dataset  [8]. Code and results are publicly available 9.
Protocol Metric. We define the Daily Relative Percentage Change (DRPC), a metric designed to measure the relative difference of performance (in percentage) per day : 𝐷𝑅𝑃𝐶 (𝑡) = 100 𝑑 (𝑡,𝑡 +1) * 𝑝 (𝑡 +1)-𝑝 (𝑡 ) 𝑝 (𝑡 ) where  () is the performance value at the time  and  (,  +1) is the number of days between  and  + 1. We divide by the number of days between  and  + 1 to avoid artificially increasing the results when there are few measurements separated by long time periods. We then average the results in absolute value for each date of measurement , which provides the average DRPC related to a time series. Time series pre-processing. We remove all the time series having less than two measurements, because the metric is impossible to compute in this case. Implementation. We consider the 22 workloads of the dataset; for each, we gather the time series including performance measurement on this workload and compute the average DRPC.
DISCUSSION In this paper, we have considered two variability layers, namely hardware and workload, and studied their impacts on software evolution. Other variability layers can well be considered in the future, for example i) operating system: the Linux kernel is highly configurable and may have an impact on performance evolution of MongoDB; ii) compile-time options and flags: the way Mon-goDB has been built 13 can change the performance distributions. For instance, Lesoil et al. [18]  report on preliminary evidence of complex interactions between run-time options (e. g. , command line parameters) and compile-time options (e. g. , using. /configure) with different effects of non-functional properties of software. In the case of MongoDB we can wonder whether and to what extent these layers impact software evolution, e.
THREATS TO VALIDITY Our results may vary with other choices of metrics. For instance, the DRPC used in Section 3 may amplify the noise of measurements by construction, thus slightly overestimating the real percentage of performance change. 13 See https://github. com/mongodb/mongo/blob/master/docs/building. md When standardising the performance in Section 2, there exists a risk to artificially create outliers if the standard deviation of the performance is too low. It could partly explain Section 2. 2 results. Yet it appears to be the only solution to efficiently compare DTW related to distributions having different scales.
RELATED WORK Software evolution and performance. There exist research works studying the impact of software evolution on performance  [2, 5, 8, 19, 20, 22, 24]. Martin et al. [19]  presents a solution, based on transfer learning, to deal with the evolution of the Linux kernel when predicting kernel sizes of configurations. Mühlbauer et al. [22]  investigated the history of software performances to isolate when a performance shift happens over time and variants (software configurations). Our study pursues a similar objective, but pays attention to the impact of hardware and workload on software evolution. Our results show that hardware and workload variability cannot be ignored when reasoning about performance history. Hardware variability. Resarch work has been investigating the effect of hardware on software performance  [4, 9, 11, 14, 27, 28].
In particular, Valov et al. [27, 28]  suggest that changing the hardware has reasonable impacts on software configurations since linear functions are highly accurate when reusing prediction models. Unlike our work, the evolution of software is not taken into account in their studies and dataset, nor are changes in workloads. Workload performance analysis. There are numerous works addressing the performance analysis of software systems  [3, 6, 12, 13, 15, 17, 17, 23, 26]  depending on different input data (also called workloads or benchmarks). In this paper, we specifically study the impact of workloads on software evolution. Jamshidi et al. [14]  conducted an empirical study on four configurable systems, varying software configurations and environmental conditions, namely hardware, workload, and software versions.
Results show transferring performance can be difficult depending on environment changes. An important feature of the study, and therefore of their dataset, is that all three variability factors are modified together, for example, both version, hardware and workload are modified and compared to a baseline. Without isolating the individual effect of each variability layer, it is challenging to understand whether a performance shift is due to the evolution of software or other factors (hardware and workload). In contrast, our study leverages the dataset to investigate i) the impact between hardware and evolution ii) the impact between workload and evolution.
(2015 Chondrogiannis et al. ( , 2017) )  as implemented in the Alternative Routing Library for Boost Graph (ARLib) developed by Leonardo Arcari (https://github. com/leonardoarcari/arlib, last access: 25 February 2022). The main interest of this algorithm is that it allows the user to specify a maximum overlap ratio between alternative paths. During the search process, a candidate alternative path is successively compared to the previously retained paths by computing the ratio between the sum of the weights of the shared edges and the total cost of each of the previously retained paths, omitting the starting and ending edges. The candidate path is added to the KSP solution set only if its overlap ratio is below a predefined θ threshold value between 0 and 1. Such a threshold is particularly relevant for dense graphs retrieved from a continuous geophysical model.