dataesr/scientific-paragraphs-categorization huggingface dataset:
4 were used as a training set. Repeated Monte carlo cross validation was used to optimize both the number of pairs and to identify the pairs which best separated ASB-CLL. For additional validation of ASB-CLL the published proteomics dataset by Eagle et al. 24  was used (Validation2_Eagle cohort). The k-TSP classifier trained above was used on the Eagle et al. dataset. One TSP-pair had to be excluded due to lack of overlap and the classification threshold was lowered by 1 as a consequence. Mean protein abundances for the genes in the KEGG gene sets "Spliceosome", "B-cell receptor signalling", "proteasome", and "Valine, leucine and isoleucine degradation" were calculated and compared between the ASB-CLL cluster and all other patients.
i, Mean PSI value per patient calculated from the 1000 most variable 3' alternative splice site (A3SS), 5' alternative splice site (A5SS), skipped exon (SE), retained introns (RI), and mutually exclusive exon (MXE) events across all patients of the discovery cohort. ASB-CLL patients are compared to non-ASB-CLL patients. Supplementary figure  7: a  analysis results using the KEGG database for protein level differences between U-CLL and M-CLL in the context of trisomy 12. Data was adjusted for differences between U-CLL and M-CLL in cases with disomy 12 (WT). Leading edge genesets with significantly different protein-mRNA correlations are highlighted (red circle = significantly higher correlation, blue circle = Significantly lower correlation) e, Volcano plot of DeqMS analysis results of protein level differences between U-CLL and M-CLL in the context of trisomy 12.
Data was adjusted for differences between U-CLL and M-CLL in cases with disomy 12 (WT). Genes from the B cell receptor signaling pathway are highlighted in yellow. g, We used a custom bioinformatics pipeline including BWA and Samtools (alignment;  58  ), and Varscan (variant calling and annotation;  59  ). Current databases (COSMIC 60 , 1000G  61  , dbSNP145  62  , ClinVar  63  ) were taken into consideration to evaluate and report variants above a threshold of 5 % mean variant allele fraction (VAF) as pathogenic/non pathogenic. Only mutations which occurred in at least three patients and an allele frequency of more than 20 % were considered for further analyses. In-depth data dependant acquisition mass spectrometry proteomics using HiRIEF Cell pellets were dissolved in Lysis buffer (4 % SDS, 50 mM HEPES pH 7.
Supernatant was discarded and the beads air-dried. Tryptic peptides were detached from the beads by addition of 100 μl of 3 % ACN, 0. 1 % FA and transferred to a new tube. 5 μg of peptides from each sample were injected and separated using an Ultimate 3000 RSLCnano system coupled to a Q Exactive HF (Thermo Fischer Scientific, San Jose, CA, USA). Samples were trapped on an Acclaim PepMap nanotrap column (C18, 3 mm, 100 Å, 75 µm x 20 mm, Thermo Scientific), and separated on an Acclaim PepMap RSLC column (C18, 2 µm, 100 Å, 75 µm x 50 cm, Thermo Scientific). Peptides were separated using a gradient of mobile phase A (5 % DMSO, 0. 1 % FA) and B (90 % ACN, 5 % DMSO, 0. 1 % FA), ranging from 6 % to 30 % B in 180 min with a flow of 0. 25 ml/min. For data independent acquisition (DIA), data was acquired using a variable window strategy.
The survey scan was performed at 120,000 resolution from 400-1200 m/z, with a max injection time of 200 ms and target of 1e6 ions. For generation of HCD fragmentation spectra, max ion injection time was set as auto and AGC of 2e5 were used before fragmentation at 28 % normalized collision energy, 30,000 resolution. The sizes of the precursor ion selection windows were optimized to have similar density of precursor m/z. The median size of windows was 18. 3 m/z with a range of 15-88 m/z covering the scan range of 400-1200 m/z. Neighbor windows had a 2 m/z overlap. For protein identification and quantification, all raw files analyzed by Spectronaut using the Direct-DIA option without the use of a spectral library, files were searched against ENSEMBL protein database (GRCh38. 98. pep. all. fasta).
All parameters were kept as default for protein identification. Briefly, runs were recalibrated using iRT standard peptides in a local and non-linear regression. Precursors, peptides and proteins were filtered with FDR 1 %. The decoy database was created by mutation method. For quantification, only peptides unique to a protein group were used. Protein groups were defined based on gene symbols to obtain a gene symbol centric quantification. Stripped peptide quantification was defined as the top precursor quantity. Protein group quantification was calculated by the median value of the top 3 most abundant peptides. Quantification was performed at the MS2 level based on the peak area. The quantitative values were filtered using the qvalue for each sample. Imputation was not performed at any stage of the quantification data generation.
Protein complex analysis Protein core complex information was retrieved from the CORUM website (http://mips. helmholtzmuenchen. de/corum/#download). All complex members were assumed to interact with each other. Protein complex information was converted into a pairwise interaction matrix as previously described  15. The distribution of correlations between proteins/genes in known complexes in both the transcriptomics and proteomics data was compared to the distribution of correlations between randomly selected protein/gene pairs. For the investigation of trisomy 12 related complexes, CORUM complexes which contained genes located on chromosome 12 were kept. The log2-value of the relative median abundance of individual proteins in the trisomy 12 cases compared to non-trisomy 12 cases was calculated and complexes with an overall upregulation and no down regulated proteins were kept.
Modularity clustering of the nodes was carried out with a resolution of 0. 8. Annotation of the modularity clusters was done by first extracting all proteins belonging to a cluster. Next, any protein in the full overlap dataset (n =7313) that had a Pearson correlation above 0. 7 to any of the cluster members was included in the target gene set for that cluster. Enrichment using a target-background approach was carried out against the MSigDB categories Hallmark, C1, C2, C5 and C6. The full overlap data set (n =7313) was used as background and the R packages msigdbr and ClusterProfiler were used to calculate enrichments (github code: "enrichment_of_network-msigdb").
001) and transcript levels (not significant p =0. 17) in ATM mutated (mut) and wild-type (wt) CLL samples; Wilcoxon signed-rank test. d, XPO1 protein (** p =0. 004) and transcript levels (not significant p =0. 18) in XPO1 mutated (mut) and wild-type (wt) CLL samples; Wilcoxon signed-rank test. Hazard ratios from Cox regression for overall survival (OS) with genes and proteins in Validation1_DIA dataset with strong weights for LF1 and LF2 in the discovery cohort. P-values are shown on the right. Significant associations (p <0. 05) are colored in blue. Mean and 95 % confidence intervals are shown. Out of the proteins with strongest weights on LF9, none were detected in the DIA dataset. coded by PG. e, Responses of Proteomics Groups (PG) to the individual drugs tested in the ex-vivo drug sensitivity screen.
Violin plot of abundances of proteins involved in branched chain amino acid (BCAA) degradation comparing the subgroup identified as ASB-CLL in the Validation1_DIA dataset to all other patients. b, Violin plot of proteasomal protein abundances comparing the subgroup identified as ASB-CLL in the Validation1_DIA dataset to all other patients. c, Overall survival (OS) of untreated patients in the discovery and Validation1_DIA cohorts, divided into ASB-CLL and all other patients. d, Boxplot of B cell receptor (BcR) signaling protein abundances in the subgroup identified as ASB-CLL in the Validation2_Eagle cohort, in comparison to all other patients. e, Boxplot of spliceosomal protein abundances in the subgroup identified as ASB-CLL in the Validation2_Eagle cohort, in comparison to all other patients.
f, Boxplot of abundances of proteins involved in branched chain amino acid (BCAA) degradation comparing the subgroup identified as ASB-CLL in the Validation2_Eagle dataset to all other patients. g, Boxplot of proteasomal protein abundances comparing the subgroup identified as ASB-CLL in the Validation2_Eagle dataset to all other patients. trisomy 12 status. Proteins not found in the DIA-dataset are colored grey. (M-CLL, tris12+ n= 14; M-CLL, WT, n= 89; U-CLL, tris12+, n= 6; U-CLL, WT, n= 46), c, Percentages, normalized to solvent control, of alive cells CLL samples of the discovery cohort in co-culture with the human bone marrow stroma cell line HS-5, treated ex-vivo with idelalisib (9 µM), ibrutinib (40 nM) or duvelisib (4. 5 µM). The comparisons of Tris12M-PG & Tris12U-PG samples with the other PGs samples are shown; Wilcoxon signed-rank test.
Acknowledgements The authors would like to acknowledge support from  Clinical Proteomics Mass Spectrometry at Karolinska University Hospital and Science for Life Laboratory  for providing assistance in mass spectrometry sample preparation and data analysis. We would also like to thank  Christiane Zgorzelski  for technical assistance. We thank  Nils Kurzawa ,  Simon Raffel ,  Steffanie Göllner ,  Konrad Herbst  and  Peter Lichter  for helpful discussions. We thank the  EMBL genomics core facility  for technical support. The authors gratefully acknowledge the data storage service SDS@hd supported by the  Ministry of Science, Research and the Arts Baden-Württemberg (MWK) ,  BioMS  and  SciLifeLab proteogenomics core facility  and the  German Research Foundation (DFG)  through grant  INST 35/1314-1 FUGG ; as well as grant support from the  Swedish Research Council  (R.
Data availability The mass spectrometry proteomics data have been deposited to the ProteomeXchange Consortium via the PRIDE partner repository with the dataset identifiers PXD017453 (Discovery set) and PXD024544 (DIA Validation set). The RNAseq data for the Validation3_RNA cohort is available through the European Genome-Phenome Archive through accession number EGAS00001001746. The data can be easily explored through our web application: https://www. imbi. uni-heidelberg. de/dietrichlab/CLL_Proteomics/.
c, ATM protein (** p =0. 001) and transcript levels (not significant p =0. 17) in ATM mutated (mut) and wild-type (wt) CLL samples; Wilcoxon signed-rank test. d, XPO1 protein (** p =0. 004) and transcript levels (not significant p =0. 18) in XPO1 mutated (mut) and wild-type (wt) CLL samples; Wilcoxon signed-rank test. Hazard ratios from Cox regression for overall survival (OS) with genes and proteins in Validation1_DIA dataset with strong weights for LF1 and LF2 in the discovery cohort. P-values are shown on the right. Significant associations (p <0. 05) are colored in blue. Mean and 95 % confidence intervals are shown. Out of the proteins with strongest weights on LF9, none were detected in the DIA dataset. coded by PG. e, Responses of Proteomics Groups (PG) to the individual drugs tested in the ex-vivo drug sensitivity screen.
, Violin plot of abundances of proteins involved in branched chain amino acid (BCAA) degradation comparing the subgroup identified as ASB-CLL in the Validation1_DIA dataset to all other patients. b, Violin plot of proteasomal protein abundances comparing the subgroup identified as ASB-CLL in the Validation1_DIA dataset to all other patients. c, Overall survival (OS) of untreated patients in the discovery and Validation1_DIA cohorts, divided into ASB-CLL and all other patients. d, Boxplot of B cell receptor (BcR) signaling protein abundances in the subgroup identified as ASB-CLL in the Validation2_Eagle cohort, in comparison to all other patients. e, Boxplot of spliceosomal protein abundances in the subgroup identified as ASB-CLL in the Validation2_Eagle cohort, in comparison to all other patients.
In this framework, three Component objects are coupled together by a Model object and executed concurrently, so that the order in which the components are called does not impact on the outcome of the simulation. The Model is responsible for the exchange of information between components, including their potential temporal accumulation and aggregation and/or their potential spatial remapping (using an Exchanger object), and is responsible for the time iteration of all components (using a Clock object). The Component object provides infrastructure to support the science component; e. g. reading input (using DataSet objects), writing output (using Record and RecordStream objects), and state memory allocation (using State objects). The Component class itself is subclassed into the actual framework components represented by the SurfaceLayerComponent, SubSurfaceComponent, and OpenWaterComponent classes, which are used to enforce inward and outward transfers corresponding to the framework interfaces.
Open science library Alongside the framework infrastructure itself, an initial library of open source science components complying with the standard framework interface is available. This allows users to explore alternative combination of components as alternative solutions to simulate the terrestrial water cycle. Additional components can be exploited by the framework so long as they comply, or can be made to comply, with the framework interface via a particular Python class template (see Script 7). Land system and hydrological modellers are encouraged to become contributors to the framework by sharing their science components with the rest of the community. These contributions can be implemented purely in Python, but can also rely on Fortran, C, or C++ programs called by interface middleware.
Meaningful data The interface specification is effectively a data specification. To guarantee the unambiguous specification of that interface, as well as to bring to the framework and to users alike a full awareness of the physical meaning and spatio-temporal context of input and output data, the NetCDF Climate and Forecast (CF) Metadata Conventions  (Eaton et al. , 2020)  are exploited in the framework. These conventions provide a robust guide for describing, processing, and sharing geophysical data files. They are used in a variety of applications, including for global model inter-comparison efforts such as CMIPs (e. g. Eyring et al. , 2016). The DataSet class responsible for providing each Component with input data relies on reading CF-NetCDF files. This enables the framework to check the compatibility between the data and the configured component, both physically and spatiotemporally.
Application Programming Interface The first step in this workflow is to define the temporal and spatial discretisations. The user has to instantiate TimeDomain and SpaceDomain objects. The framework comes with a variety of constructor methods for these two objects, including using existing data structures, e. g. from_field, or using the limits and spacing of the discretisation, e. g. from_start_end_step for TimeDomain and from_extent_and_resolution for SpaceDomain. Examples using the latter are presented in Script 1. The second step consists in selecting the NetCDF files containing the input data. To do so, the user has to instantiate a DataSet object (Script 2). These files must comply with the CF-conventions (subsection 2. 5). The third step, which completes the configuration of a Component, is to provide these three objects to the selected component alongside values with units for the component parameters and constants.
Additionally, the user can select the variables to tomisable temporal resolution (multiple of its TimeDomain resolution) and summary statistics (mean, minimum, maximum, instantaneous). In Script 3, the open water science component RFM, based on the RFM model  (Bell et al. , 2007; Dadson et al. , 2011) , is used and configured. Instantiating a Component will be successful only if all the inputs, parameters, and constants required by the science component are provided and compatible in names, units, time and space dimensions with the component and its time and space domains. The fourth and last step in the configuration workflow is to gather three components, one of each of the three types SurfaceLayerComponent, SubSurfaceComponent, and OpenWaterComponent to form a model. In Script 4, the variables 'sl', 'ss', and 'ow' are instances of each, respectively, configured similarly to the example in Script 3.
Configuration file An alternative to the API is the use of a configuration file written using the human-readable serialisation language YAML. This provides both a more accessible configuration approach for users less comfortable with programming and a way to easily share configurations with other users. The complete configuration workflow presented above using the API can be formulated in a Configuration files can then be loaded using the API to instantiate the Model directly (Script 5). Note, after the successful instantiation of a Model using the API (i. e. Script 4), such a YAML file is automatically created in the configuration directory.
Simulation A configured Model can then be used to start model spin-up cycle(s) and/or to start a simulation run over the entire simulation 185 period specified in the time domains of the components (Script 6). The spin-up period can either be within or outside of the simulation period, so long as the datasets given to the components contain data for it. Both spin-up and simulation runs can produce dump files, that is files containing intermediate snapshots in the simulation period with all the information required to resume the simulation in case of an unexpected interruption. The user can specify a dumping frequency to choose how often such snapshots should be saved. Once the Model is re-instantiated using its config-190 uration file created through Script 4, the simulation can be resumed using any snapshot in these dump files.
Moreover, these files can be used to provide initial conditions for the component states in replacement or in addition to the spin-up cycles. The fourth step is to define the component characteristics, including its inputs, parameters, constants, states, and outputs in their corresponding class attributes (e. g. lines 9-23 in Script 7). The fifth and last step is to implement the three class methods initialise, run, and finalise (e. g. lines 26-34 in Script 7, where the pass statements should be replaced by the 205 actual implementation of these methods). This initialise-run-finalise (IRF) paradigm is based on the interfacing standards BMI  (Peckham et al. , 2013; Hutton et al. , 2020)  and OpenMI  (Harpham et al. , 2019). Instances of newly created Component classes can then be created and, thanks to their base class, they inherit the functionality that make them readily usable in the framework, as described in section 3.
For existing models, the contributor may need to perform some refactoring of their source code, namely to comply with the 210 framework interfaces and to comply with the initialise-run-finalise paradigm. The creation of a Python class is a requirement for use in the framework, however, the initialise, run, and finalise methods can call software which can be interfaced with Python, such as existing Fortran, C, or C++ programs. A blank template is available on GitHub at unifhy-org/unifhycontrib-template to provide a starting point for contributors to package their new or existing models into framework compatible Python libraries.
Selected configurations The capabilities of the framework are demonstrated through three different configurations summarised in Table  2. The first configuration puts the Artemis and the RFM models together to form a simple land system model. It demonstrates the flexibility in the temporal and the spatial resolutions of the various components. Indeed, the surface layer and the subsurface components are taken from the Artemis model and configured to run at an hourly timestep on a 0. 5 degree resolution latitudelongitude grid, while the open water component from RFM is used and configured to run at 15-minute intervals on a 0. 5/60 (~0. 008) degree resolution on a latitude-longitude grid. The second configuration demonstrates the possibility to replace science components with datasets. To do so, the surface and subsurface runoff outputs from the JULES model  (Best et al.
This is a composite metric made of three equally-weighted components r S , α N P , and β, assessing the agreement in the dynamics (i. e. correlation), the variability, and the volume (i. e. bias) of the discharge time series, respectively  (Pool et al. , 2018). Table  3  features these metric components computed for the three configurations and the three study catchments using the Python package hydroeval  (Hallouin, 2021). The comparative performance of the three configurations for each catchment in turn informs the most suitable combination of components for a given temporal and geographical context. For instance, the third configuration appears to be the most suitable in the Tay catchment, if one is solely interested in simulating the river discharge accurately (R N P of 0. 766), while the second configuration would be preferred for the Ouse and Severn catchments (R N P of 0.
Conclusions This framework represents the first implementation of a new modular blueprint to model the terrestrial water cycle. It is open source and comes with extended online documentation. By design, this Python package is intended to be easy to use, with a low entry bar for people with little programming experience. Indeed, installing a Python package is straightforward and only a few steps in a Python script are needed to set up and run a complete model in a Jupyter notebook, which is likely to prove useful for teaching and training activities alike. It is also intended to be easily customisable, through choosing from a library of compatible components those most suitable for a given region and for a given objective. Finally, it is intended to be easily extensible by creating new components, which should streamline the development and sharing of new science for the terrestrial water cycle.
available in the CHESS-land dataset (Martínez-de la Torre et al. , 2018) are put together as a DataComponent and used in place of the subsurface component, which is then coupled with the open water component of the RFM model, both on a 1 kilometre resolution on the British National grid. The surface layer component is removed by setting it as a NullComponent. The third and last configuration puts together the Artemis and SMART models. It demonstrates the possibility to substitute parts of an existing model (i. e. SMART) with parts from another model (i. e. Artemis) and explore the impacts on the model performance. The SMART model is a rainfall-runoff model for application to hydrologically meaningful spatial elements (e. g.
Acknowledgements. This work was funded by the  Natural Environment Research Council (NERC)  as part of the  Hydro-JULES programme  ( NE/S017380/1 ). The authors would like to thank the developers of cf-python,  David Hassell  and  Sadie Bartholomew , for implementing the requested features required by the framework, and  Andy Heaps  for the cf-plot support. They would also like to thank  Katie Facer-Childs  for providing the rainfall and potential evapotranspiration data used to calibrate the SMART model,  Helen Davies  for providing.
Main beam search process The solution pool, with the function of beam size controlling, is defined as a frontier which consists of one or more rivets, where each rivet is a subset of the frontier (See Fig. 4  ). Since backwardmove is not allowed in the heuristic, the frontier is moving down left towards the I/O point in each iteration. The detailed procedure of this process is given in the pseudo code of Algorithm 1 , BeamSearchP BS, which is also an expanded description of Fig. 3. We define and initialize a global state variable, label C s to hold and keep the states and solutions data updated during the execution of BeamSearchP BS and its subroutines Algorithms 2 -4 (line 1). In Algorithm 1, Line 2 to line 4 check if the goal I/O location is reached, then return the initial motion plan, which means an empty set with zero move cost.