dataesr/scientific-paragraphs-categorization huggingface dataset:
Since vcf files can change in terms of the number of fields (due to the addition of novel in silico scores, databases, etc. ), the duplicated lines for each variant will not present the same information; i. e. , there will be missing information in some columns due to pipeline updates (Figure  1B ). This issue is compounded when searches are carried out for multiple individuals who have benefited from different versions of the pipeline. Implementation of an in-house script can overcome this issue (Figure  1B ), facilitating interpretation by decreasing variant redundancy in the results of the basic GREP query (with an 11-fold mean decrease between the basic and custom GREP query). However, even without a custom script, a basic GREP query can already provide files that are interpretable for biologists, and a GREP query remains easy to set up for routine use.
Therefore, a clinician adopting this strategy would have to search every new entry to find out whether this is linked to a human disorder falling into their area of expertise. Sometimes, several relevant manuscripts (up to four) are added to PubMed on the same day or on different days of the same week (up to seven manuscripts over 4 days of the same week), whereas sometimes no manuscripts are relevant for weeks (up to eight) at a time. Therefore, there is a fine line between setting a loose threshold that will miss some manuscripts and daily GREP querying that will lead to work overload. A compromise could be a one-off search capturing the most recent 20 articles or searches at two time points capturing 10 articles. In conclusion, a reanalysis strategy combining intensive bibliographic monitoring and rapid GREP queries of a large ES database offers promising added value in increasing diagnostic yield and reducing diagnostic delay in rare diseases.
Acknowledgments The authors thank the families for taking part in the study. The authors thank the  University of Burgundy Centre de Calcul (CCuB)  for technical support and management of the informatics platform, and the GeneMatcher platform for data-sharing. Several of the authors of this publication are members of the European Reference Network for Developmental Anomalies and Intellectual Disability (ERN-ITHACA; FTMT, ASDP, AV, LF). The authors thank the  Free Software Foundation  for the GREP software (Copyright © 1999-2002, 2005, 2008-2021  Free Software Foundation, Inc. ). The authors also wish to thank  Suzanne Rankin  ( Dijon Bourgogne University Hospital ) for reviewing the English manuscript.
Background: Body composition could help to better define the prognosis of cancers treated with anti-angiogenics. The aim of this study is to evaluate the prognostic value of 3D and 2D anthropometric parameters in patients given anti-angiogenic treatments. Methods: 526 patients with different types of cancers were retrospectively included. The software Anthropometer3DNet was used to measure automatically fat body mass (FBM3D), muscle body mass (MBM3D), visceral fat mass (VFM3D) and subcutaneous fat mass (SFM3D) in 3D computed tomography. For comparison, equivalent two-dimensional measurements at the L3 level were also measured. The area under the curve (AUC) of the receiver operator characteristics (ROC) was used to determine the parameters' predictive power and optimal cut-offs. A univariate analysis was performed using Kaplan-Meier on the overall survival (OS).
However, the 2D measurements seemed less accurate than their 3D multi-slice counterparts  [12]. For example, it has been shown that during weight loss, changes in visceral and subcutaneous adipose tissue are poorly evaluated on 2D imaging  [13] , while 3D imaging gives good results for intra-abdominal fat  [14]. Therefore, multi-slice segmentation is preferable  [15] , but needs automatic processing to avoid a time-consuming manual segmentation  [13]. To analyze body composition, we developed a software, called Anthropometer3DNet, which allows the automatic and multi-slice measurement of anthropometric parameters on computed tomography (CT), routinely used for cancer patients. Initially developed to work on CT of PET/CT with a multi-atlas segmentation method  [16] , it has been improved by using neural networks and is now able to analyze diagnostic CT with variable acquisition fields (abdominal-pelvic or thoracic-abdominal-pelvic).
Endpoints and Assessments The following baseline clinical data were collected: age, sex, type of cancer, line of treatment, type of treatment. A diagnostic abdomen-pelvis or thorax-abdomen-pelvis CT scan was taken for all patients before starting targeted therapy. The CT scans were non-injected or acquired during the portal phase of the injection. The primary endpoint was overall survival (OS), defined as the time from the beginning of targeted therapy to death or last follow-up.
Anthropometric Parameters The parameters were extracted by Anthropometer3DNet, an updated version of Anthropometer3D  [16, 18, 19]. This software, usable for research purposes on the site www. oncometer3d. com, automatically measures in less than 5 min parameters FBM 3D , MBM 3D , VFM 3D and SFM 3D (in kg) on the CT of injected or non-injected (thoraco-)abdomino-pelvic CT. This software performs a deep learning-based segmentation of fat (visceral and subcutaneous) and muscle voxels based on a multi-slice 2D U-net Algorithm  [20, 21]. In parallel, it determines the slice levels using a Densenet Algorithm  [21]. For parts outside the acquisition area, it uses adaptive extrapolation factors  [22]  for the tissues of interest (k muscle for muscles, k subcutaneous fat for subcutaneous fat and k visceral fat for visceral fat).
This difference may explain why the 3D parameters were significant while the 2D parameters were not. Moreover, a paradoxical result was obtained: For GIST cancers, the 2D parameter of the muscle area (MBA 2D ) suggests that a large muscle area is related to a worse prognosis, while the 3D parameter (MBM 3D ) suggests the opposite. Compared to the 2D measurements and other 3D software  [25] , one of the strengths of the 3D analysis performed by Anthropometer3DNet is that it uses factors for extrapolation of the data outside the field of acquisition. It can obtain a total mass rather than an area or an index in the results, and this global mass measurement could potentially be useful for therapeutic adaptation. Moreover, thanks to the automatic segmentation performed and the wide windowing of the Hounsfield units, it is exploitable on injected and non-injected scanners.
For research, the Anthropometer3DNet software is available on the Oncometer3D. com platform via an online service. In this study, there were some differences in the results between the different populations in the sub-analyses. For example, VFM 2D and VFM 3D were statistically significant for renal cancers, SFM 3D , SFA 2D and FBM 3D for GIST and MBA 2D and MBM 3D for HCC, while the other cancer types had no significant parameter. This difference could be explained by the lack of statistical power due to the reduced number of patients in the subpopulations but also by the preponderant prognostic role of neoplasia for some types of cancer. Morever, the difference in body composition  [27]  might also be the reason some parameters were significant for men and not for women. In the subgroup analysis by cancer type, some results are similar to what has been shown in the literature.
Such an exercise would require systematically executing a MEM for potentially hundreds of retrospective forecasts, and analysing large volumes of spatial-temporal model output. This would require computing power far beyond a single workstation, and although the concept of using the combined power of a network of computers to solve demanding computational tasks dates at least back to the 1970's (e. g. ,  Farber, 1970; Jones & Schwans, 1979; Vouk, 2008) , the MEM community is mostly unable to utilise distributed computing power due to compounding challenges. Inherent limitations related to their computational complexity and structure, with long run times to represent non-linear processes at different temporal and spatial scales that cascade through food webs make MEMs incompatible with common high-performance computing technologies and computing scientific software execution infrastructures  (Steenbeek et al.
, 2021). Scientific workflow management systems  (Curcin et al. , 2010; Wang et al. , 2008) , code execution frameworks (e. g. ,  Ludescher et al. , 2013) , and commercial cloud computing solutions tend to require that hosted applications execute cleanly, safely, orderly and optimised by abiding to strict guidelines regarding programming languages and code architecture, execution efficiency, resource use, and scalability (e. g. ,  Rimal et al. , 2011). As MEMs are mostly developed on limited academic budgets with little involvement of IT staff, re-coding a MEM to match such requirements is too costly and perhaps even undesirable in order not to get locked into proprietary technological execution frameworks  (Steenbeek et al. , 2021). On the other hand, distributed computing via networked computers, virtual machines and virtualization technologies such as Kubernetes  (Jeffery et al.
Runtime environment The framework was deployed across a network of computers with varying specifications as shown in Table  1. All computers hosted 64-bit Operating Systems and were powerful enough to execute EcoOcean. Machines were located in two physical locations, interlinked via a Dropbox (www. dropbox. com) professional plan with 2TB of storage space for mass data transfer, and a free Sync (www. sync. com) account for framework communication. For every 4 threads or fewer, a separate framework client was created, which meant that the runtime environment was able to simultaneously perform 24 executions of EcoOcean (Table  1 , Nº clients). Total 24.
Application The EcoOcean executions were encapsulated in a custom developed command-line utility, henceforth referred to as the "EcoOcean wrapper", that configured the EcoOcean model for executing a specific simulation, executed the simulation, intercepted and condensed EcoOcean maps over time into time series, and saved these time series into one ZIP file per run. By specifying a ZIP output file name adhering to a simple and strict naming protocol, the command line utility understood exactly how to configure and run EcoOcean, how to name the output ZIP file, and how to finally place these output ZIP files directly into a Dropbox folder dedicated to multi-run framework server-side data collation. All EcoOcean simulations started in the year 1950 after a ten-year spin-up (or burn-in) period, and were executed through 2015.
EcoOcean output was collated for the period 1980-2015. For both ESMs, EcoOcean was executed with and without fishing following  Coll et al. (2020). ESM data were delivered to EcoOcean in the form of monthly varying maps. The maps representing mean temperatures for the top 150m, water column and bottom were fed into the EcoOcean habitat foraging capacity model  (Christensen et al. , 2014) , and the maps for large and small phytoplankton were used to force the magnitudes and distributions of the corresponding phytoplankton groups within EcoOcean  (Coll et al. , 2020). For the two ESMs and the two fishing scenarios, EcoOcean was driven by ESM historical data to gather simulation baseline output. Then, for the two ESMs, two fishing scenarios and every retrospective prediction start year for the three members, EcoOcean was executed with historical data up to the start year of a retrospective prediction, after which EcoOcean was executed until the end of the retrospective predictions while being driven by the ESM data for that retrospective prediction.
For the retrospectice prediction experiments, output was only collected for the period covered by the 7-(EC-Earth3-CC) or 10 (NorCPM1) year retrospective predictions. As EC-Earth3-CC data started at 1980, historical data for the year 1980 were repeated during the EcoOcean spin-up period and for the period from 1950 through 1980. NorCPM1 did not distinguish explicitly between small and large phytoplankton; therefore, the total phytoplankton biomass data was used to proportionally drive large and small phytoplankton dynamics in EcoOcean.
Framework performance The prediction experiments resulted in a workload of 384 jobs, each job containing only one task: the invocation of the EcoOcean wrapper command-line utility. The driver data delivered by both ESMs comprised approximately 1 million time-tagged maps at a volume just over 415 GB. EcoOcean produced an estimated volume of 5 TB in output maps that were condensed into time series CSV files by the EcoOcean execution wrapper on the framework clients. The EcoOcean wrapper then compressed the time series CSV files and placed them in the Dropbox output folder for automatic transport to the framework server computer. By using time series, the framework produced a more manageable output volume of 50 GB, which was compressed to 3GB for file transfer to the server for analysis. The full set of EcoOcean simulations required approximately 2600 hours of CPU time, but via the framework used here -with a total of 164 computational cores (Table  1 ) -the complete set of simulations was performed in just under 30 hours.
Simulations The simulations provided four sets of output -for the two different ESMs under fished and nonfished oceans, each featuring time series trends for the 11 ocean sub-basins and 19 ocean statistical areas for fisheries purposes, for 52 functional groups. Figure  7  shows what these data look like when plotted. ESM baseline, and the three coloured lines represent EcoOcean estimates when deviating away from the baseline for 7-year retrospective predictions. Ecosystem output is plotted relative to the annual average 1980 value. Overall, results show that across the food web and the observed regions, the EcoOcean biomass trajectories displayed varying degrees of responsiveness to ESM uncertainty, depending on position of the selected functional group in the EcoOcean food web, the presence of fishing, the region analysed, and choice of earth system model linked to EcoOcean.
Experience using the framework The framework performed well, despite its conceptual simplicity and reliance on the most basic technologies. The use of cloud storage providers for framework communication was not without caveats. We started out by using one storage provider, Dropbox, to handle all server-client data transfer, but we observed a high number of cancelled and restarted EcoOcean runs. Status logs showed that the server often perceived remote clients as having become unresponsive and repeatedly rescheduled their jobs, which we traced back to crucial framework status messages getting intermixed with, and delayed by, the slow transfer of large input and output data files. Swapping over to two separate cloud storage providers (Sync for framework communication, and Dropbox for bulk data transfer), with each cloud storage provider operating on different folders, solved the issue.
To avoid any kind of unnecessary complexity, the use of cloud providers was therefore ideal to showcase the framework. To demonstrate that the run framework can be OS agnostic, our setup included one Linux computer among five Windows computers. We were able to make this setup work as 1) both the framework and the EcoOcean execution wrapper were written in. NET Standard which natively run on both OS-es; and 2) we were able to fully handle typical OS incompatibilities in our code by enforcing strict data handing conventions. However, as the framework is intended dispatching workloads that rely on any scientific software, framework operators may find that mixed OS family deployments may be very complicated to setup and operate. We recommend that these should be avoided at all costs, and if mixed OS family setups cannot be avoided, we surmise that it may be technically easiest to containerize  (Bentaleb et al.
During the execution of a workload, launched programs may allocate more than their fair share of available resources (such as available processors, runtime memory and disk space). In the worst case, badly behaving programs can crash an operating system. For those with the means and know-how, it would make sense to execute framework clients on virtual machines or containers. These technologies primarily shield the underlying operating system from badly behaving software. Containers increasingly replace virtual machines due to their ability to control resource allocation  (Herbein et al. , 2016)  and to load-balance the use of system resources (e. g. ,  Hota et al. , 2019). Such features ensure smoothly flowing executions of hosted software. The framework -or the very concept of the frameworkcan be easily adapted to execute workloads across more stable environments.
Here may lie an opportunity for Machine Learning approaches that are increasingly applied to marine ecology  (Rubbens et al. , 2023). While properly designed statistical approaches can distinguish acceptable from unacceptable ecosystem trends for specific marine ecosystem models, ML approaches can perhaps expand this understanding to infer full food web dynamics from changing environmental conditions, species distributions and fisheries. Following promising work by  Trifonova et al. (2017)  and  Uusitalo et al. (2018) , we hope that ML approaches can, one day, assist in the search for more representative parameterizations of complex and mechanistic ecosystem models. A framework such as ours will be essential to mass-execute and perturb MEMs to generate the training datasets needed, and may be able to act as a foundation for ML-assisted MEM calibration.
Acknowledgments JS acknowledges institutional support from the  Polytechnic University of Catalunya (UPC) , Barcelona, Spain. RB, VC, MC, EE, NK, PO, DR and JS acknowledge the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement  N• 817578  ( TRIATLAS ). VC and JS acknowledge the  European Commission 's  Horizon 2020 Research and Innovation programme  under grant agreement  N• 101000302  (EcoScope). JS and MC acknowledge the  European Commission 's  Horizon 2020 Research and Innovation programme  under grant agreement  N• 101060072  (ACTNOW) and the  Spanish Ministry of Science and Innovation  grant agreement  N •  PID2020-118097RB-I00  (ProOceans). MC acknowledges.
Galaxy parameters from SED fitting Next we measure the host galaxy properties such as B -band absolute magnitude and luminosity ( M B and L B ), stellar mass ( M ), star formation rate (SFR), and specific star formation rate (sSFR) using available spectroscopic and photometric data and template fitting methods. Since the USMg II host galaxies are at low impact parameters to the quasar sightline, we model the quasar image using the appropriate SDSS point spread function  (Xin et al. 2018 ) , and then subtract it from the original image before extracting the parameters of the host galaxies. The procedure for modelling and subtracting the PSF for the USMg II system J0004 -0826 is shown in Fig. 6. We measure the flux of the host galaxy in different photometric passbands and correct for finite telescope gain using standard approaches presented in the SExtractor software  (Bertin & Arnouts 1996 )  and the PYTHON fork of the software, Source Extraction and Photometry  (Barbary 2016 ).
We make use of the publicly available PYTHON package, Bayesian Analysis of Galaxies for Physical Inference and Parameter EStimation ( BAGPIPES ;  Carnall et al. 2018 ) , to extract the galaxy parameters. We consider the stellar population models by  Bruzual & Charlot ( 2003 )   the default implementations of nebular emission, dust, and IGM attenuation in BAGPIPES. More details of modeling and fitting the galaxy SED to the spectroscopic/photometric data using BAGPIPES can be found in section 3. 1 of  Carnall et al. ( 2018 ). To start with, we fix the redshift of the galaxies to their spectroscopic redshifts. We assume that all stars within the galaxy have the same metallicity, and vary it with a uniform prior in the range 0. 01-2. 5 of the solar metallicity. We parametrize the star formation histories (SFHs) using the delayed exponential model.
e. the inferred metallicity will be different for different assumed values of q. Therefore, we measure the gas phase metallicity ( Z) and the ionization parameter (q) simultaneously based on the emission lines ([O II ], [O III ] and H β) present in the galaxy spectra and the photoionization model provided by Le vesque, K e wley & Larson ( 2010 ) using the PYTHON fork  (Mingozzi et al. 2020 )  of the IDL code IZI (Inferring metallicity and ionization parameters,  Blanc et al. 2015 ). Apart from two cases, we do not detect the [O III ] λ 4960 emission at ≥ 3 σ significance. We therefore take the associated flux of this line to be one-third of the flux associated with [O III ] λ 5008 line as suggested by theoretical studies  (Storey & Zeippen 2000 ). Another difficulty in the use of R 23 is that the ratio is doubly degenerate in terms of the oxygen abundance.
An aluminum filter of 1. 2 mm thickness was used to reduce beam hardening effects. The reconstruction was done with the XAct 10251 v1. 1 (Rx-Solutions) software package with a filtered back projection algorithm (Feldkamp method-cone beam geometry with Tukey filter and a sinus apodization filter). The result is a set of 16-bit cross sections with a voxel resolution of 32 μm.
The parameters of such plugin were set to: a variance of the noise sigma = 15 and a smoothing factor of 1. Additionally, an edge enhancement unsharp mask filter of radius = 1 was used to reduce partial volume effects due to image blurring where the strength of the filter mask was set to 0. 6. Finally, we corrected radial drifts using the software toolbox QuantIm  (Vogel et al. , 2010)  with a method inspired by  Iassonov and Tuller (2010). We expect that, at the voxel resolution of 32 μm in our undisturbed soil samples, we will be able to assign the gray level of each image voxel to one of the different soil constituents: air, water, POM and minerals. Given that water and POM have a similar density, the X-ray attenuation through these materials results in a similar gray level. Schlüter et al.
, 2016)  in Fiji, which is based on the algorithm of  Beucher and Meyer (1990). This plugin requires as input images, the gradient and a global segmentation in both cases of the gray scale image. To create the global segmented image we used the Otsu method the darker is the color the lighter is the material in (c) air in red, POM+water in green, soil matrix in black, and minerals in blue. (Otsu, 1979)  with three thresholds computed with the software toolbox QuantIm  (Vogel et al. , 2010). While the gradient was obtained with the Fiji function of the same name. To reduce the noise produced during the segmentation step, a majority filter for a cubic kernel of 3 × 3 × 3 voxels was applied, using the software toolbox QuantIm  (Schlüter et al. , 2014). This filter action consists in replacing the current label by the most representative label among all neighbors in a cubic kernel.
Acknowledgments The research described in this article was made possible by the financial support of the  ANR ,  France Project Soil-3D  (Number  ANR-15-CE01-0006-01 ). Patricia Ortega-Ramírez  was funded by the  ANR ,  France  project  NanoSoilC  (Number  ANR-16-CE01-0012-03 ). We acknowledge the  PLATeforme INstrumentale d'Analyse (PLATINA)  of the  IC2MP (University of Poitiers ) for access to the micro-CT device. AM acknowledges financial support from the  European Union (ERDF)  and ' Région Nouvelle Aquitaine', France.