dataesr/scientific-paragraphs-categorization huggingface dataset:
Package creation and termination Beyond package adoption and maintenance, the package lifecycle may include steps such as package creation and package termination. CPMOs may provide a policy for these steps as well. Package creation. Creating new packages is never the primary objective of a CPMO, but there are cases where package creation happens directly in the CPMO. To best achieve their objective of anticipating turnover and unresponsive maintainers, CPMO may consider encouraging CPMO members to create new packages directly in the CPMO, as a sort of default location. This was proposed during the Meteor Community kickoff discussion by a participant: "So one thing could also be to encourage people to start projects in this organization. I know that for many projects I created in the past I do not really care where I would start them, so if there is simple default people could have, it could make it easier for keeping maintenance later on.
But we could argue that it looks bad or something but no one has ever made this argument yet. And also no one actually went through the list and said "hey this repo hasn't been accessed in the last years, so let's probably archive it?"" On the other hand, CPMOs (like Elm Community) which assign maintainers to each package may know when a maintainer has left and no replacement has been found and may document the package as unmaintained until a new maintainer is found. CPMOs that maintain lists of hosted packages and their maintainers may use these lists to mark packages as unmaintained or deprecated. This is the case of Elm Community. Among the reasons to deprecate a package, we have observed the case of packages departing to a new sponsor: "0. 19 fork hosted by CurrySoftware ([link])" The case of packages moving to the core project: "mark elm-test as unmaintained [.
The template can even include a checklist of criteria to accept the package, and a checklist of technical steps to apply after the proposal is accepted. Many CPMOs use issues in their meta repositories for package adoption proposals, and at least Meteor Community, Flutter Community, and Coq-community use an issue template. When an issue template is used and the CPMO has a notion of principal maintainer, it can make sense to also provide a template for maintainer departure / replacement. This is the case in both Flutter Community and Coq-community. Limiting the need for a trust-building process. If the CPMO workforce is limited, there is only so much that the CPMO can do to alleviate maintenance issues in the ecosystem. Therefore, it is essential to ensure wide participation to the CPMO by ecosystem members.
g. , package releasing). Making it mandatory to go through the automation unless you have some special privileges (e. g. , unless you are a CPMO admin) can guarantee that some tasks are done according to the rules. Other checks can be the use of protected branches and mandatory reviews (for CPMOs where lazy consensus is used for package maintenance). The level of security to put in place also strongly depends on the ecosystem. It depends in particular on the ecosystem language and package manager. In ecosystems based on a strongly typed language (like Elm) that strongly restricts the behavior a function can have based on its type, and where the package manager builds from sources from a tag in a version-controlled repository, and has checks to ensure that the contents of the sources cannot be changed, many security risks of an ecosystem like npm are already avoided.
But ever since then, I more or less just ignored it. I have not been active, particularly in that organization, for, I don't know, a couple of years, and it's only because it seems to be working so well. " But also that a CPMO may lose some of its momentum after the initiator has left. According to Sebastian Wilzbach: "the Dlang-community has died a bit on the maintainer front, with like for example me leaving or me getting very passive" It should be possible now to explore this question since several CPMOs are becoming older: Vox Pupuli was founded in 2014, Sous Chefs and Elm Community were founded in 2015. Trac Hacks is much older  (2005) , but it has served several roles beyond the one of a CPMO: SVN hosting provider and package registry. So, its evolution may also be largely related to these other important objectives and may not be as relevant to initiators or participants of CPMOs whose main infrastructure is just a GitHub organization.
Related work As we have already mentioned, to the best of our knowledge, we are the first researchers to study the CPMO model. However, there is previous research on several related topics that could be of interest to CPMO initiators and participants, and that we can compare to our own results. Open source communities. Open source software is frequently developed by communities. Since the seminal report of Raymond  [22] , many researchers have studied specific open source communities (e. g. , Linux and Apache  [15] , GNOME  [11] , etc. ), and part of the accumulated knowledge on standard open source communities is also applicable to CPMOs. For instance, open source governance models  [19]  are relevant for CPMOs who may want to adapt them (as was done by Vox Pupuli). Results on community inclusion (contribution barriers faced by newcomers  [28] , codes of conduct  [25, 27, 30] , etc.
For instance, the Debian project is one of the oldest Linux distribution, and it is entirely community-based. Researchers have studied Debian to explore themes such as the evolution of volunteer participation  [24] , or the apparition of governance structures  [26] , both of which should be relevant for CPMOs. Automation developed to help maintain Linux distributions  [5]  could also inspire automation for CPMOs. Open source foundations. Open source foundations are non-profit legal entities created to ensure the long-term sustainability of open source projects, and related objectives, by raising funds and managing legal assets  [17]. Most foundations were created around a specific project (e. g. , the Linux foundation around the Linux kernel, the Apache foundation around the Apache web server), but have been extended to host a variety of open source projects  [16].
Data availability Supporting data for this article is made available on Figshare at https:// doi. org/10. 6084/m9. figshare. 20502228. v1. This dataset contains all the (initial and focused) codes for the public documents that have been used to generate the theory in this paper, as well as a mind map making the link between categories and quotes presented in this paper and the coded documents. The coded interview transcripts are excluded from this dataset and will only be made available privately at individual researchers' request after getting permission from each of the interviewees.
Architecture StorAlloc is a tool able to simulate the scheduling of I/O-intensive jobs on heterogeneous storage resources available on a HPC system. In this section, we present its design and discuss implementation choices. The objective of StorAlloc is to provide a simple way to develop and evaluate storage-aware job scheduling algorithms targeting heterogeneous storage resources (any kind of disk-based storage can be described). Therefore, StorAlloc has been designed following the basic principles of a job scheduler, i. e. a middleware allowing clients to request resources available on a supercomputer. Extending from the original architecture, we added the ability to run it as a simulator, using a single code base. StorAlloc's design is based on the composability of several components, which can be run together and extended in order to provide the desired behavior.
Simulation A longer-term goal of StorAlloc is to provide a single code base for a storageaware job scheduler and its simulator. Therefore, we have designed our simulation server with a "component in the middle" approach. The core components run as if they were actually deployed on a real system except that, if the simulation mode is enabled, the requests are rerouted to the simulation server which stacks them until a specific message triggers the actual execution of the simulation. Then, the simulation is unrolled and go through the scheduler, using a discrete event simulation (DES) model  [8]. During that phase, data measuring the impact of scheduling is collected and feeds a visualization server in real-time. In particular, we measure the following indicators: -Total allocated (and deallocated) volume.
Simulation setup To simulate storage requests from clients representative of real applications, we used a dataset composed of one year of a Darshan 2 logs on Theta, a 11. 7 PFlops Cray XC40 supercomputer at Argonne National Laboratory 3. We extracted from these traces jobs spending at least 10% of their run time doing IO, and reading or writing at least 10 GB of data. It resulted in about 24 000 jobs out of approximately 624 000 jobs, each one translating into a storage request in StorAlloc: the requested capacity is based on the maximum of either read or write volume while the allocation time uses the initial job duration. In order to have a good overview of what can be observed with our simulator, we have run 192 different simulation setups based on the settings presented in Table  3. The average simulation time is around 25m48s per run, in a range of [5m40s; 1h29m57s] on a single core of a Intel Core i7-1185G7 processor.
Analysis We present here results plotted from StorAlloc simulation data. From these figures, we can conclude on an approximation of a right sizing of the platform and we can compare the efficiency of the tested scheduling algorithms. For this analysis, platforms and algorithms have been chosen to reflect a variety of behavior. Platform sizing In our dataset, the sum of all the storage capacities requested by clients, called sum_cap, reaches 1. 6 PB. In Figure  2 , we plot the percentage  of this value achieved by each of the 192 runs of our simulation according to storage layouts and algorithms, grouped by platform capacity and split strategy. On the top row (no request split), only the 1N1D layout at 64TB capacity reaches 100% of sum_cap. However this layout is merely a baseline which shouldn't be used, as it leads to a high concurrency and consequently a very low node bandwidth.
From this result, we can also conclude that never more than 64TB are needed at the same time in our dataset. This information must be balanced by the fact that we exclude from Theta's traces several hundreds of thousands of jobs that we do not consider I/O intensive. The best results with other layouts peak slightly above 60%, which hints towards an underprovisioning of storage resources. The bottom row depicts the same analysis with requests split in chunks of 200GB. We see that all layouts reach a 100% of sum_cap at least once for 64TB. More generally, the splitting of requests allows a better use of resources and requires less storage space (the 16TB platform reaches 90% of sum_cap for half of the runs). These results give little information, however, about the use of the disks composing the modeled platform.
Acknowledgments This work used resources of the  Deutsches Klimarechenzentrum  (DKRZ) granted by its  Scientific Steering Committee (WLA)  under project  IDs uo1075  and  mh0469. We thank the three anonymous reviewers for constructive and helpful comments, and  Nicola Maher  for conducting a pre-submission review. This research was funded by the  Max Planck Society (MPG)  and the  German Research Foundation (DFG)  under Germany's  Excellence Strategy-EXC.
Data Availability Statement The MPI-ESM1. 2-LR coupled climate model is distributed via http://www. mpimet. mpg. de/. The scripts and code for reproducing the plots are openly available through the publication repository of the Max Planck Society at https://hdl. handle. net/21. 11116/0000-000D-B686-E. The simulations of MPI-GE CMIP6 can be accessed via DKRZ's ESGF server at https://esgf-data. dkrz. de/search/cmip6-dkrz/ by specifying the requested variable and frequency and the following IDs: Source: MPI-ESM1-2-LR; Institution: MPI-M (DKRZ for ssp119); Experiment: historical, ssp126, ssp245, ssp370, ssp585; Variant Label: r*i1p1f1. Please note that the ensemble size is currently extended to 50.
This network is designed to effectively handle MBPs of various shapes and backgrounds, including those with complex features. Methods. First, we normalized our sample of MBP images. We then followed this with elastic deformation and rotation translation to enhance the images and expand the dataset. Next, a dual-branch encoder was used to extract the features of the MBPs, and a Transformer-based global attention mechanism was used to extract global contextual information, while a convolutional neural network (CNN) was used to extract detailed local information. Afterwards, an edge aware module was proposed to extract detailed edge features of MBPs, which were used to optimize the segmentation results. Focal loss was used during the training process to address the problem of the small number of MBP samples.
(2019)  and ⋆ All the code and datasets used in this study have been made publicly available and can be accessed at the following link: https://github. com/yangpeng6/MBP-TransCNN ⋆⋆ Haicheng Bai is the co-first author of the article. Magyar et al. (2021)  have elucidated the intricate linkage between MBPs and the footpoints of prominent atmospheric structures, such as coronal holes. Furthermore, these investigations have proposed the intriguing possibility that MBPs may serve as viable source regions for the newly detected phenomenon of magnetic switchbacks in the solar wind. Therefore, MBPs play a critical role in the study of various active behaviors of magnetic elements in the photosphere and in explaining coronal heating. With the development of ground-based solar telescopes and adaptive optics systems, the resolution of solar images has been increasing, revealing finer structures of MBPs.
2017)  to train networks on manually annotated datasets of hundreds of MBPs. They achieved good segmentation accuracy using Mask RCNN to segment MBPs in G-band and TiO-band images. However, as the abundance of astronomical image data is substantial and MBPs are often small and have complex shapes, making manual annotation is time consuming and costly. In addition, the prediction speed of deep learning methods is relatively slow, at around 15 s per frame. To address these issues, this paper proposes a deep learning MBP recognition and segmentation method based on a mixed encoder of  CNN and Transformer (see Appendix A). The approach we propose has four main contributions: (1) To achieve effective learning on a small number of annotated images, we designed a Transformer branch in the hybrid encoder architecture with CNN that extracts global attention and then performs feature fusion with the initial network branch in order to enhance global semantic information.
(2) The boundary between MBPs and the background is often fuzzy and challenging to discern, making it difficult to accurately localize the boundaries of MBPs without introducing additional prior information. Existing methods often struggle to achieve complete segmentation of MBP boundaries. To address this issue, we integrated an edge aware module (EAM) into the encoder structure to extract edge details from the image and enhance the precise segmentation of MBP boundaries. (3) To address the challenge of having only a small proportion of pixels being occupied by MBPs in the image, we used a weighted loss that assigns a larger training weight to the positive samples of MBPs and a smaller weight to the negative samples of the background. (4) To address the challenge of limited solar MBP image data, which requires a large amount of annotated data for deep learning training, we annotated only ten frames of the original dataset and generated a substantial number of synthetic images using data augmentation techniques.
Elastic deformation was applied to the annotated dataset, which is particularly crucial for solar image segmentation, as this type of deformation is well-suited for solar images, and the deformed images still bear resemblance to the original real solar images. The purpose of this article is to apply deep learning techniques in image processing to MBP segmentation. Deep learning networks have achieved state-of-the-art results in various fields due to their powerful learning abilities. This article presents the first attempt to mix CNNs and Transformers for precise pixel-level segmentation of MBPs. The organization of this article is as follows. Section 2 provides a detailed description of the data, including the dataset and how to augment it. Section 3 introduces in detail the method of using the combination of CNN and Transformer to train the MBP segmentation network.
Datasets and preprocessing Deep learning methods require large annotated datasets for network training. In the process of deep learning, or machine learning, data are the main driving force for the model. By training with existing data, we obtain corresponding network parameters, allowing our designed model to have a generalized ability to predict unknown or unseen samples. Applying these parameters to practical applications is the main process of model training. The cleanliness, completeness, and other aspects of the data are critical factors affecting the quality of network learning. Therefore, the establishment of our MBP dataset is crucial and directly impacts the final segmentation performance.
Dataset In this article, observational data from the 1. 6-m aperture Goode Solar Telescope (GST) at the Big Bear Solar Observatory (BBSO;  Cao et al. 2010)  were used to segment solar MBPs. This telescope is equipped with an adaptive optics system that can accurately correct atmospheric distortions to obtain clear images. Imaging observations of the photosphere were performed using a broadband filter imager (BFI) and a TiO bandpass filter with a wavelength of 705. 7 nm and a field of view occupying the central 70 ′′ × 70 ′′ of the solar disk  (An dić et al. 2011). The exposure time for each frame was 2 ms, with a frame cadence of 15 s. The TiO bandpass is widely used in the study of MBPs and A121, page 2 of 14  Yang, P. , et al. : A&A, 677, A121 (2023).
Building the dataset We utilized observational data from six distinct time periods captured in the quiet region of the Sun. We processed these observational data using Bai (2022) normalization method and subsequently stored them as three-channel images. Table  1  lists the relevant details of these datasets. We selected D1 as our training dataset, which corresponds to a day of quiet solar observations. This day was chosen to include variations in lighting conditions and a diverse range of clear MBP configurations. This selection is particularly effective in training a robust network that can handle various possible morphologies of MBPs. To ensure coverage of the observed data quality for most of the MBPs on that day, we included a temporal dimension in the selection of the training dataset.
We curated a testing dataset comprising D2, D3, D4, D5, and D6, encompassing MBP observations from five distinct dates. The purpose of this selection is to showcase the robust performance of our algorithm across the majority of quiet solar regions while ensuring the preservation of MBP quality. These datasets span various time intervals, with some capturing shorter periods and others spanning more extended durations. The chosen images exhibit a diverse range of characteristics, encompassing instances with abundant MBP group formations as well as those featuring only a few instances. Furthermore, the image quality varies from blurry to clear. This comprehensive dataset encompasses a wide spectrum of observed MBP qualities. The successful identification and segmentation results achieved with this diverse collection of images serve as a testament to the efficacy of our algorithm.
To ensure high accuracy of the Ground Truths, the dataset utilized in this study was constructed by combining the detection results obtained from the algorithm of  Bai (2022)  with the expertise of several domain specialists. Specifically, building upon the identification performed by the Bai (2022) algorithm, our team of three domain specialists conducted further refinement to achieve highly accurate annotations. Regarding the identification outcomes, if two or more experts agreed on classifying a pixel as an MBP, we made the pixel white using Photoshop. Conversely, if two or more experts deemed a pixel 1 http://www. bbso. njit. edu/~vayur/NST_catalog/ to not be an MBP, we made it black. After annotating ten frames from the datasets, we expanded the dataset using elastic deformation. The steps for elastic deformation are as follows.
(f) Returning the interpolated image: The image that has undergone deformation and affine transformation has greater variability and can be used as augmented data. For a more comprehensive understanding of elastic deformation, readers can refer to the paper by  Simard et al. (2003). The outcomes of elastic deformation are illustrated in Fig. 1. Eventually, we augmented the D1 dataset by transforming ten annotated images into 1000 via elastic deformation and used them as the training set for the network training.
01, a momentum of 0. 9, and a weight decay of 1 e-4. The default batch size was one, and the dataset contained 1000 images. The total number of training iterations for 100 epochs was 100 000. We refer to our trained network as MBP-TransCNN. The loss value stabilized after 10k iterations, which took approximately 9 h of training time. To evaluate the segmentation performance of our network, we used five evaluation metrics for image segmentation in order to quantify the segmentation performance  (Long et al. 2015). These metrics are precision, recall, F1 score, pixel accuracy (PA), and intersection over union (IoU). To calculate the above indicators, TP, TN, FP, and FN were required. The definitions of these terms are as follows: true positive (TP) is the number of pixels that are predicted to be positive and are actually positive.
True negative (TN) is the number of pixels that are predicted to be negative and are actually negative. False positive (FP) is the number of pixels that are predicted to be positive but are actually negative. False negative (FN) is the number of pixels that are predicted to be negative but are actually positive. In our dataset, there are two classes (0, 1), where zero represents the background and one represents MBPs. We used P ii to represent the number of samples that are originally in class i and are predicted as class i, which corresponds to TP and TN. Next, P i j represents the number of samples that are originally in class i but predicted as class j, which corresponds to FP and FN. If class i is the positive class, then P ii represents TP, P j j represents TN, P i j represents FP, and P ji represents FN when i = j.
The F1 score is a combination of the recall and precision, and it can reflect the model's ability to search accurately and comprehensively. The calculation formula is as follows: F1 = 2 1 Precision + 1 Recall = 2 × Precision × Recall Precision + Recall. ( 8 ) The intersection over union ratio representation refers to the ratio of intersection and union of predicted results and real values of a certain category. For image segmentation, it is found by calculating the intersection ratio between the predicted mask and the real mask. The calculation formula is IoU = TP TP+FP+FN. Table  2  presents the average PA, recall, F1 score, and IoU for MBP segmentation in five datasets. The mean values of precision, F1 score, and PA are all greater than 0. 9, with the average values of precision, F1 score, and PA being 0.
Detection and segmentation of MBPs Our trained MBP-TransCNN network performed well on datasets D2-D6, exhibiting excellent segmentation results for MBP images. As shown in Fig. 5 , each bright point is marked with A121, page 6 of 14  Yang, P. , et al. : A&A, 677, A121 (2023)   a white label on a binary image, and the corresponding TiOband image with bright points is labeled in green. The pixel-wise segmentation has segmented MBPs with clear boundaries.