dataesr/scientific-paragraphs-categorization huggingface dataset:
Annotation of TEs in the B. tabaci Genome The screening of TEs in the genome of B. tabaci using the REPET package led to the identification of 1,327,236 putative repeats. After removal of sequences corresponding to satellites and poorly supported sequences without a TE hallmark, 1,292,393 copies were recovered, representing 51% of the whole genome sequence. These elements were clustered into 4872 lineages, of which 699 belong to Class I of TEs, 1348 belong to Class II, and 2825 were uncategorized even though they have TE characteristics (Tables  1  and S1 ). The majority of these lineages were represented by at least one FLC, i. e. , 27,599 sequences that cover more than 95% of the consensus of each lineage (File S1). The Class I lineages are represented by 73,223 TE copies covering 5. 7% of the whole B.
Discussion The current study examined the TEs' content, in addition to their insertions, within and near the defensome genes associated with insecticide resistance in the sequenced genome of the whitefly B. tabaci. TE characterization is an important challenge because TEs represent a significant proportion of the genome of many species and may play a role in several regulatory, transcriptional, and protein innovations. TEs are also associated with many cases of insecticide resistance acquisition, allowing the adaptation of several insect species to environmental stressors. Fortunately, a growing number of methodologies and software tools, such as TEdenovo, LTRdigest, and HelitronScanner, have been developed to address this need  [37]. In this study, we used the REPET package, which combines two main pipelines: TEdenovo, which provides a full TE library for all repeats detected, and TEannot, which is used to annotate repeats.
One of the most recent and complete studies was conducted by  Wang et al. (2016) , who evaluated ten different docking programs, including five commercial programs and five academic programs using a collection of 2002 protein-ligand complexes from the PDB. Concurrently, a strong emphasis has been put on generating highly refined test sets, which only include high-quality structures of relevant protein targets containing drug-like ligands. Some of the most-used validation datasets are CCDC/Astex  [14]  and Iridium  [15]. Such datasets and comparative studies provide a comprehensive understanding of the advantages and limitations of each docking program and help users make more appropriate choices among available methods. However, they suffer from an important limitation: in an attempt to keep the comparison across docking programs fair, the authors of the comparative studies use standard parameters, whereas in real-life applications, advanced users introduce substantial bias to improve performance.
In consequence, such comparative studies reveal the intrinsic capabilities of the programs, which is quite different from how they are actually used in typical drug-discovery settings. In addition, as relatively small sets of well-curated protein-ligand complexes become widely adopted as test-sets, there is a risk of biasing docking programs towards those specific datasets. The challenges organised by the Drug Design Resource (D3R) represent a welcome departure from this tendency. D3R aims to provide benchmark datasets and blinded challenges to assist in the evaluation and improvement of computational algorithms, giving participants the freedom to use the methods as they see fit, but encouraging the use of reproducible protocols. Besides the annual Grand Challenge, D3R also organises the CELPP Challenge (Continuous Evaluation of Ligand Pose Prediction)  [16].
Overview of the Pipeline One of the key aspects of this work is the automation of the process; therefore, all the steps are gathered in a combination of python, SVL and shell scripts and divided into individually functional modules corresponding to the different phases of the protocol (Figure  1 ). There are four phases summarized here (see Method section for further details): Phase 1: Protein analysis. Download the sequence of the query protein, identify structures of homologous proteins in the PDB and ligands that bind to them (this is performed through a query in 3decision  [17] ). Phase 2: Ligand analysis. Compute a similarity score and maximum common substructure between the query ligand and all ligands retrieved in Phase 1. Phase 3: Pharmacophore generation. Derive, whenever possible, a pharmacophore for the ligands retrieved in Phase 1.
Workflow Input Data, Data Structure and Output Each weekly CELPP data package is downloaded as a gzipped tar file that contains one directory per target. The target is a protein defined by its primary sequence. Within each directory, there is a set of structures that have the same or highly similar sequences to the target. They are provided as potential receptor structures for docking and contain the highest resolution unbound candidate protein (hiResApo), the highest resolution ligand-bound (hiResHolo), the candidate protein that contains the ligand with the largest MCSS to the target ligand (LMCSS), the candidate protein that contains the ligand with the smallest MCSS (SMCSS) and the candidate protein that contains the ligand with the highest structural similarity (based on Tanimoto score and Daylight fingerprints, as implemented by RDkit  [18] ) to the target ligand (hiTanimoto).
Workflow Input Data, Data Structure and Output Each weekly CELPP data package is downloaded as a gzipped tar file that contains one directory per target. The target is a protein defined by its primary sequence. Within each directory, there is a set of structures that have the same or highly similar sequences to the target. They are provided as potential receptor structures for docking and contain the highest resolution unbound candidate protein (hiResApo), the highest resolution ligandbound (hiResHolo), the candidate protein that contains the ligand with the largest MCSS to the target ligand (LMCSS), the candidate protein that contains the ligand with the smallest MCSS (SMCSS) and the candidate protein that contains the ligand with the highest structural similarity (based on Tanimoto score and Daylight fingerprints, as implemented by RDkit  [18] ) to the target ligand (hiTanimoto).
Pipeline Effectiveness and Processing Time The above-described pipeline performance was tested with a collection of pre-released CELPP weeks as well as with the weekly released CELPP set. The execution time of the whole protocol took an average 6. 5 min per target. The total execution time varied each week depending on the number of released targets (26 to 68 in the period considered here) and the connection speed to 3decision (from 22 s to 3 min per target). The 3decision protocol could not obtain reference structures for 20% of the targets due to some internal errors of a beta version of the program or because there were no ligands found in druggable pockets from similar proteins. This last event was relatively rare, as it accounted for 25% of times that we were not able to obtain results from 3decision, or 5% of the total.
The main difference between the sets as that the automatic pipeline for retrieving the cavities using 3decision was not yet automatized during the development stage. In consequence, all the cavities were visually inspected and selected using the 3decision webserver. By contrast, the automatic scripts used at the validation stage to identify the docking cavity and retrieve aligned ligands from 3decision were error-prone. We also had to consider the possibility that the test set was not representative enough of the whole range of systems that can be found in the CELPP Challenge. Nonetheless, the sources of errors and the difference in performance between the test set and validation will be reviewed in the next section. After analysing the prospective results, we wanted to review if the algorithm for docking protocol selection derived from the test set was the most adequate one.
Challenges to Address In this section we will describe the most important factors affecting the predictive performance of our pipeline. Figure  5  depicts the main issues and challenges to overcome in the CELPP challenge, which will be treated in more detail in the following sections. The values obtained with the validation set were much worse than the ones obtained using the test set. The main difference between the sets as that the automatic pipeline for retrieving the cavities using 3decision was not yet automatized during the development stage. In consequence, all the cavities were visually inspected and selected using the 3decision webserver. By contrast, the automatic scripts used at the validation stage to identify the docking cavity and retrieve aligned ligands from 3decision were error-prone.
Automated Protocols When testing a docking program or workflow, a crucial component that will have a big impact in the predictions is the choice of dataset  [13]. Usually, the datasets to test docking programs, such as DUD-E  [23]  or Astex  [14] , are highly curated datasets, whilst the CELPP receptors are selected automatically and are not manually prepared by experts. Additionally, we have to take into account that CELPP is designed as a cross-docking challenge, which means that we have the added problem of protein flexibility, as the used receptor may not be in the most-fitting position for the ligand. Finally, participants are given, each week, an average of 40 systems to predict and a limited amount of time (3 days), which implies that all the processes need to be automatized, leaving virtually no time for the visual inspection or study of the targets.
In consequence, the pose prediction performance is lower than for other challenges. The median prediction RMSD for the best categories (LMCSS and hiTanimoto receptors) is around 5 Å, being only 20% of the pose predictions accurate within 2 Å  [17] , whereas reported performance for curated datasets regularly reaches the 80%  [13]. Clearly, the latter reflects a best-case scenario, which means that a significant effort to improve automated target structure selection and preparation will be necessary in order to attain better results in CELPP.
Candidate Preparation For each candidate structure, co-crystallized solvent and ligands were removed using Schrödinger's split structure tool  [34] , and only the coordinates of the receptor were kept. Subsequently, the protein preparation tool from MOE  [35]  was used to fix problems within the crystal structure, and the Protonate 3D tool  [36]  was used to assign protonation states to the protein (assuming pH 7. 0). All the files were saved in Tripos MOL2 format, as required by the docking program, rDock  [5]. All the above steps were integrated in an SVL script for automation purposes.
Selection of Similar Proteins, Druggable Pockets and Ligand Retrieval One of the pillars of the whole process was being able to select good reference systems from which we could extract some restraints to guide our docking predictions. For this purpose, we integrated into the pipeline a protocol based on the 3decision tool from Discngine; 3decision  [17]  is a web-based platform that centralizes all structural knowledge (including all the RCSB PDB dataset) to perform multiple kinds of analyses. We queried   [33]. Ligand belongs to a series of analogues with pyridine as a heme-ligating head that works as an inhibitor of CYP3A4 by decreasing the heme reduction rates  [33]. (B) Interaction of ligand EV8 (green) and NADP (pink) in PDB 6gd0. In yellow dashed lines are H-bond interactions and in green dashed lines π interactions.
Selection of Similar Proteins, Druggable Pockets and Ligand Retrieval One of the pillars of the whole process was being able to select good reference systems from which we could extract some restraints to guide our docking predictions. For this purpose, we integrated into the pipeline a protocol based on the 3decision tool from Discngine; 3decision  [17]  is a web-based platform that centralizes all structural knowledge (including all the RCSB PDB dataset) to perform multiple kinds of analyses. We queried 3decision using a dedicated REST API endpoint. Using as input the target sequence in FASTA format, a blast against the database was performed to select those proteins that share a high identity (I% > 80%). The 3decision database also contains all pre-computed druggable pockets as predicted by the fpocket cavity detection tool  [27].
Pose Selection The output from the pipeline was a set of poses generated by the docking program for each candidate structure in an SDF file. Then, the poses were sorted by rDock's intermolecular score (SCORE. INTER), which accounts for the protein-ligand interaction's free energy. Formally, solutions should be sorted based on the total score, which accounts for the intramolecular energy as well (SCORE. INTRA + SCORE. INTER), but it has been shown that the intramolecular term bears a large error and can introduce more noise than signal to the predictions  [42]. Using sdsort, the best pose was selected and saved in an SDF file. If more than one cavity was detected, this selection protocol was then applied to each cavity. Thereafter, the cavities were ranked based on the MCSS score obtained during the Ligand similarity and MCSS calculation, and then the best poses from each cavity were ranked by rDock's SCORE.
Conclusions Quantifying the performance of docking software in real scenarios is essential to understanding their limitations, managing expectations and guiding future developments. With the CELPP Challenge, D3R aimed to provide a fast-growing validation set that better captures all the complexity in a real drug-discovery setting. Here we presented an initial version of our pipeline for participation on the CELPP Challenge, which applies different knowledge-based docking approaches depending on the already available information on PDB. To provide a baseline performance, the CELPP team developed four workflows based on different docking programs, one being rDock. The rDock workflow represents a default implementation of the method without any optimisation and using the cavity defined by the challenge.
A greater understanding of the drivers of transport demand is paramount to better understanding the speed and depth of the actions required to mitigate greenhouse gas (GHG) emissions. To facilitate sustained and equitable transitions to low-carbon transport systems, researchers and policymakers need to have a much more sophisticated understanding of how travel demand will grow over time and respond to ongoing innovation and policies. In this paper, we argue that the lack of access to high-quality data on the current and historical travel demand and interdisciplinary research hinders transport planning and sustainable transitions toward low-carbon transport futures. We first review the historical trends using data from the International Transport Energy Modeling (iTEM) Open Data project (section 2) and compare demand projections from several known models (section 3).
Transport demand trends over the last 60 years In aggregate, onroad travel distance (in passenger distance travelled, PDT, per person) and vehicle ownership strongly correlate with GDP development. This relationship holds pretty well over space and time  (Schäfer et al 2009, Mattioli and Adeel 2021). The size of the country, population density, and spatial distribution of urban centres certainly play an essential role as well. Nevertheless, the (log-)linear relation of PDT to GDP remains clear, despite country differences concerning the above factors. Data from the iTEM Open Data & Harmonized Transport Database  (Linero et al 2020)   12  shows that onroad PDT vs GDP per capita for all countries 1980-2018 (figure  1 ) exhibits a strong linear correlation of log-transformed panel data: log(onroad PDT, 1000 km per person per year) = 1.
Providing open access to high-quality data There are several publicly available transportation data sets, but the datasets are often incomplete and inconsistent across sources due to differences in data collection and data processing methods used. The incompleteness and inconsistencies create difficulties for researchers to interpret and analyse the data. Modellers typically spend a lot of time and resources to collect, clean and harmonise these data individually and repeat this process every year. Although a few institutions provide detailed datasets, their cost is prohibitively high for research institutions and non-governmental organisations. These data barriers pose challenges for researchers to fully understand today's transportation systems and create useful knowledge for the transition to sustainable and low-carbon mobility.
A direct consequence of this problem is the lack of The recently established iTEM Open Data project (iTEM 2022a, 2022b) is a community process to produce open transport data: high-quality, transparent, frequently updated and improved, free to access. As articulated in related disciplines  (Hörsch et al 2018 , Arnold and Bowler et al 2019 , DeCarolis et al 2021) , the project implements the principles of FAIR Data (findable, accessible, interoperable, reusable) to produce valid data using reproducible, interoperable, reusable code and builds on existing standards for handling statistical (meta)data. The harmonised transport database aims to create transparency through two key features: • Open access: a comprehensive collection of publicly-available transportation data that are harmonised, cleaned, cross-checked and cross-validated.
• Open source: all source codes used for cleaning and modifying the original datasets are publicly accessible from GitHub and documented. All codes are available for modification and extension. Initial iterations of the iTEM project incorporate upstream data from more than 15 sources, including the International Transport Forum (ITF-OECD), Eurostat, United Nations bodies, the World Bank, and the International Organisation of Motor Vehicle Manufacturers. Current poject efforts focus on harmonising, cleaning, cross-checking and cross-validating the input data and creating graphs to visualise the data. The code that handles these data is free, open-source, continuously tested, and developed in the open using established reproducible and collaborative workflows and feedback from a global user community.
S Yeh et al The iTEM Open Data process offers a venue for this work-and the resulting data-to be shared: instead of regularly repeating data-searching and data-cleaning by individual teams, researchers invest their efforts in connecting new data sets, identifying and patching erroneous data points, or improving methods for harmonisation. The project's data processing pipeline extends from retrieval and cleaning of input data sources, harmonisation, and (flexible) (dis-)aggregation, to derivation of new measures, infilling, and output/dissemination of the harmonised data set. The results include the historical data series of key transportation measures in figures 1 and 2. In other disciplines, including climate science and high energy physics, open data and community processes have lowered barriers for collaboration and improved the validity of scientific results and usefulness of insights.
Acknowledgments The authors thank the reviewers for their suggestions that have significantly improved the quality of the paper. S Y acknowledges funding from  Swedish Foundation for Strategic Environmental Research (Mistra). S Y, P F, Y L acknowledge funding from  H2020 European research programme  (Grant Agreement ID:  821124 ). P F acknowledges funding from  H2020 European research program  (Grant Agreement ID:  101003866 ). Y L acknowledges funding from  Swedish Research Council for Sustainable Development Formas  (Project No. 2016-1326 ).
Data availability statement The data that support the findings of this study are openly available at the following URL/DOI: https:// zenodo. org/record/4287423. Department of Energy & University of Maryland. 2. Model website: www. globalchange. umd. edu/gcam/ 3. Scenarios: HiBio Ctax, HiElec Ctax 4. Data collected: 1 July 2019 (b) Global Transportation Roadmap 1. Organisation: International Council on Clean Transportation 2. Model website: https://theicct. github. io/roadmap-doc/ 3. Scenarios: ICE Policy Potential, With Currently Adopted Policies 4. Data collected: 15 January 2021 (c) International Transport Forum, ITF 1. Organisation: ITF, Organization for Economic Co-operation and Development 2. Model website: www. itf-oecd. org/itf-transport-outlook-project 3. Scenarios: R1, R3 4. Data collected: 8 February 2021 (d) International Transportation Energy Demand Determinants 1.
Organization: Energy Information Administration, U. S. Department of Energy. Part of the World Energy Projection System (WEPS+) framework 2. Model documentation: www. eia. gov/reports/index. cfm/T1601 3. Scenarios: Reference 4. Data collected: 1 July 2019 (e) Mobility Model (MoMo) 1. Organisation: International Energy Agency 2. Model website: www. iea. org/topics/energy-technology-perspectives 3. Scenarios: EV30@30, NPS 4. Data collected: 1 July 2019 (f) PROMETHEUS energy system model 1. Organisation: E3Modelling S. A. 2. Model website: https://e3modelling. com/modelling-tools/prometheus/ 3. Scenarios: Baseline, Baseline COVID 4. Data collected: 12 March 2021.
Definitions of regions As described in the iTEM documentation  (Linero et al 2020) , all the ITEM regions are listed in the file at https://github. com/transportenergy/metadata/blob/master/model/regions. yaml. The ISO code of each country is in the library PyCountry. However, in some datasets, certain countries do not have the exact names as those appearing in the library; therefore, a section called Country and ISO Code in each dataset indicates what name is used for the countries not found in PyCountry.
The iTEM historical dataset is composed of 15 individual datasets collected from public data sources, including the International Transport Forum (ITF-OECD), Eurostat, United Nations, International Organization of Motor Vehicle Manufacturers, etc as well as our derived new variables for checking (in)consistency between different datasets. The data are harmonised to a consistent iTEM region definition (individual countries and 17 world regions) and variables (e. g. activity, energy, emission, stock), service (freight and passenger), mode (e. g. air, rail, road, shipping), vehicle type (e. g. cars, sport utility vehicle (SUV), bus, medium-size trucks), technology (e. g. battery electric vehicles, fuel cell vehicles, internal combustion engine vehicles), and fuels (e. g. compressed natural gas, biofuels, gasoline, diesel).
A. Simulation of the proposed antenna In order to validate the developed materials dedicated for the final battery-free geolocation tag, a modified loop antenna is designed (Fig. 1 (a) ). The 3D EM simulation and optimisation of the antenna were performed with Ansys HFSS software. The loop antenna structure was optimised after several simulations steps to improve the return loss and the realized gain. It is simulated with the obtained parameters (dielectric and electrical) of the Ag NP ink and the NCF substrate. The PCB and the connector to be used for the characterisation were clearly modelled in the software to faithfully reproduce the fabricated samples. The simulated return loss of the antenna in Fig. 3  shows a resonant frequency at 855 MHz with a bandwidth of 67 MHz of under -10 dB. From the radiation pattern and the 3D polar plot in Fig.