dataesr/scientific-paragraphs-categorization huggingface dataset:
This is particularly important when working with global initiatives and programs. Dashboards will also allow users from academia to the private sector and government bodies to understand what notable information from different sources is available, democratizing data discovery and exploration. Furthermore, these systems derive information from the data, leading to knowledge and then achieve wisdom from knowledge, leading to intelligent decision making  (Hai et al. , 2016). Lastly, while GARDIAN was designed to handle historic and processed data, with the new stream of "real time", data dashboards seem better equipped to address such needs. Real time FLWs data such as sensor data, satellite data, remote sensing data and weather/climate data can be easily integrated into dashboards by connecting the data stream to a cloud based storage platform for users to more easily access real time data produced by CGIAR and integrate data in agroecology and agrobiodiversity to target issues such as food security and other global challenges.
Discussion The current volume of data and information collected, stored, shared and used is almost unlimited. This data possesses a high value, and calls for smart logistic and cognitive management of the complex data that is available in order to exploit the data while serving a multiplicity of interests from stakeholders and policymakers to diverse research groups. CGIAR is a major producer of agricultural data and information and has paved the way for open access and FAIR data through its principles, policies, frameworks and platforms. While CGIAR has learnt many lessons from these processes, it must apply these lessons in its future workings. As data becomes more and more pervasive, users can become intimidated or overwhelmed by its sheer volume, even before any analysis is performed. If we apply the principle of "less is more", the CGIAR is arguably its own worst enemy with regard to effective data sharing and consumption.
Given the abundant data flow, the next challenge is not how to acquire more data, but how to re-use and translate it into something meaningful. User-friendly dashboards or tools that allow data discovery to flow into data exploration, analytics and data interchange offer the means for this. CGIAR has already implemented several dashboards to help facilitate research and collection (https://www. cgiar. org/dashboards/) and these need to continually be refined. While dashboards are an attractive way to bridge this gap we must also not overlook the human aspect of big data. Upstream processing for data curation and data governance is required and so sharing data learnings and pipelines such as those used and developed by CGIAR and the Platform is essential. Using this knowledge we can cultivate an open access ecosystem, and improve our knowledge on how to store, use, and re-use data more effectively.
The designer needs to take into account the computational (or experimental) budget available to collect the data and what type of loading scenarios are expected to be experienced by the model. The former is known a priori, but the latter is not known exactly until the finite element simulation itself is run. As a consequence, large training and testing datasets are usually employed in an attempt to cover all different loading scenarios for a given strain/stress range. When path-dependency is present, conceiving an efficient DoE becomes even more complex since stresses now depend on the history of the material, leading to potentially infinite parameter space. One way to bypass the computationally intensive approach is to run and incorporate new load paths on-the-fly, updating the surrogate model as necessary as in the works of Goury et al.
This is done by incorporating the previous state of the network when making predictions for the current state. However, this approach often suffers from short-term memory when dealing with long sequences. To address that issue, more complex architectures with more model parameters and fine control of the flow of information retained through a sequence of information were proposed (e. g. , GRU and LSTM). These networks gained popularity and have been used to model a wide variety of materials that show history-dependency  [6] [7] [8] [9] [10] [11]. However, RNNs are still severely limited by the curse of dimensionality associated with sampling arbitrarily long strain paths. The overview on the potential of RNNs for modeling path-dependent plasticity presented by Gorji et al. [12]  illustrates the multiple ways in which one can define a DoE and argue that GRUs, in particular, can be used to model the plastic response of materials provided a rich enough training dataset is used.
In this work, random walks are created by associating the prescribed strains to independent Gaussian Processes (GPs) with X ∼ N (µ, σ 2 ) and covariance function given by: k(x p , x q ) = σ 2 f exp ( - 1 2ℓ 2 ∥x p -x q ∥ 2 ) ( 30 ) where x p and x q are the time step indices of the strain sequence being sampled, σ 2 f is the variance and ℓ is a lengthscale. In this setting, the lengthscale controls the smoothness of the strain path and the variance controls how large the step size can be for each prescribed degree of freedom of the controlling nodes. Similar approaches were employed by Mozaffar et al. [8]  and Logarzo et al. [11]. Algorithm 1: Generation of random loading path using GPs Input : lengthscale ℓ, variance σ 2 f , number of strain components N components , number of time steps N steps Output: macroscopic strains D ε and macroscopic stresses D σ 1 initialize datasets: D ε ← ∅, D σ ← ∅ 2 for i ∈ [1, 2,.
, N components ] do 3 initialize input and output datasets for GP i :  X GP i ← 0, Y GP i ← 0 4 initialize GP i : GP i ← initGP( X GP i , Y GP i , ℓ, σ 2 f ) 5 for t ∈ [1, 2,. , N steps ] do D ε ← D ε ∪ ε current , D σ ← D σ ∪ σ current 14 for i ∈ [1, 2,. , N components ] do 15 add time step and current strain to dataset of GP i : X GP i ← X GP i ∪ t, Y GP i ← Y GP i ∪ ε i 16 update GP i with new data: GP i ::update ( X GP i , Y GP i ) 17 return (D ε , D σ ) The details of the present implementation are given in Algorithm 1. Note that instead of drawing the entire strain sequence for a given component, we sample it step by step and update the GP dataset before sampling again. This strategy results in the same strain sequence given a fixed random seed throughout the steps, but in this way the GPs can also be used in applications where the number of loading steps is changed on-the-fly.
Assessing network performance In this section, the performance of the proposed network is compared to a state-of-the-art RNN trained on different training dataset sizes and methods to sample the design space. The comparison is done for a single micromodel. Specifically, four scenarios are investigated: (i) predicting unloading/reloading behavior from monotonic data, (ii) predicting unloading/reloading behavior from non-monotonic data, (iii) predicting unseen patterns from non-monotonic data, and (iv) training with non-monotonic and non-proportional loading paths. In the first three scenarios, our network is trained exclusively on the fundamental loading cases of Type I (18 curves), while the training of the RNN is an open question to be addressed in the following sections. From now on, the network presented in this work will be referred to as Physically Recurrent Neural Network, or simply PRNN.
Next, a new test set with 100 Type III curves is evaluated by the same networks trained on the 288 monotonic curves. This time, the RNN fails to capture unloading and the addition of more monotonic data is ineffective, as shown in Fig. 12(a ). This outcome is not new to the literature and it is not surprising that RNNs need to see unloading behavior during training in order to be able to describe it. However, in contrast to the RNNs, the PRNNs provide the same level of accuracy for the test sets with and without unloading, even when not exposed to unloading data during training. In Fig. 12(b ) a single representative case from test set T III is plotted using the best RNN and PRNN. Both networks show good agreement with the reference solution until unloading starts (a feature not covered during training), but only the PRNN is capable of capturing the elastic unloading/reloading.
Predicting unloading/reloading behavior from non-monotonic data Following the conclusions of Section 6. 2, the training set of the RNN is expanded to include curves with the same unloading behavior as the one observed in the test set T III. The 288 monotonic curves of Types I and II from the previous section are combined with an increasing number of non-monotonic curves of Type III. This time, with the right features included in the training set, Fig. 13  shows a monotonic decrease of the average error for the RNN on T III curves. However, the performance of the RNN only meets the one obtained by the PRNN with around 32 times more data.
Predicting unseen patterns from non-monotonic data In this section, three additional test sets are considered for the RNN trained on Types I, II and III and the PRNN trained on Type I only. The goal is to test the ability of the networks to predict the macroscopic stress with patterns different from those seen during training. First, we consider a test set with 100 unseen curves of Type IVa, which consists of proportional curves in random directions with a different predefined unloading/reloading behavior than that of Type III. The average error for that set is shown in Fig. 14(a). Here, the 576 curves from the previous section are no longer enough to provide good accuracy when predicting a different unloading/reloading. By adding more Type III curves to the training set of the RNN, the average error decreases from 6.
Training both networks on non-monotonic and non-proportional loading In this section, both networks are trained on the most generic set of curves, i. e. random non-monotonic and nonproportional curves of Type V. In addition to that, we trained the PRNNs on the known and proportional loading  cases for comparison purposes. In that case, the size of the material layer is kept at 6 units and three training dataset sizes are considered. First, only the pure uniaxial cases are included, which yields 6 loading cases. Then, the 4 biaxial cases are added to the previous training dataset, resulting in 10 loading cases. And finally, we add the 8 cases with biaxial and shear loading, which amounts to the 18 fundamental paths shown in Fig. 6(b). When training both networks on non-proportional paths a new model selection procedure was carried out to determine the optimum size of the material layer and the GRU cell, respectively.
FE 2 applications In this section, the PRNN trained with 36 non-proportional and non-monotonic Type V curves and lowest test error for test set T V in Section 6. 5 is employed as the constitutive model in two numerical examples. Results obtained with the PRNN as constitutive model are compared against results obtained with full FE 2 with the same micromodel that the network was trained to be a surrogate for. Both types of analysis are performed with an in-house Finite Element code using the open-source Jem/Jive C++ numerical analysis library  [37]. At the macroscale, an arc-length method with an adaptive-stepping scheme  [38]  is adopted to tackle potential convergence issues. This way, if a loading step does not converge with the given (full) step size, a reduction factor is applied to it until the loading step converges or until a maximum number of reductions in the initial step has been reached, terminating the analysis.
Based on that, an extensive numerical comparison involving a state-of-the-art black-box model, namely a Bayesian Recurrent Neural Network (referred to in this work as RNN), was carried out in order to elucidate the abilities of the proposed network (referred to as PRNN). First, we trained both networks only on 18 monotonic curves with known directions and proportional loading in a similar fashion as done to calibrate classical mesomodels. Such strategy led to poor performance when trying to predict other random directions from the RNN, but good accuracy from our method (Fig. 11 ). Following that conclusion, the size of the RNN's training dataset was sequentially increased until the addition of more data did not result in significant gains in accuracy. At that stage, the PRNN performed with the same level of accuracy but with a factor of 16 times less data.
Next, both networks were used to predict non-monotonic loading. For that scenario, the PRNN showed the same level of accuracy as before with the same minimal training dataset (Fig. 12(a) ). Such outstanding result is not observed in the RNNs, which again required a larger training set. This time, non-monotonic loading curves were added until the RNN's accuracy could no longer be significantly improved. As a result, a 32 times larger training dataset in comparison to the one used to train our network was necessary. Furthermore, while our network continues to perform well in all the scenarios tested so far, two other situations exposed the pitfalls of RNNs: (i) when trying to predict unloading in a different location than the one seen in training (Fig. 14(a) ) and (ii) when the step size was modified (Fig.
15(a) ). This is typically tackled by sampling different unloading behaviors with different step sizes, leading to the choice of arbitrarily long sequences. However, we showed that this is a trivial scenario for the PRNN. The network is only as sensitive to step size as the material models it includes. In the last test, both networks were used to predict non-proportional and non-monotonic paths and neither succeeded, although they failed at very different levels. While the lowest error of the RNN was around 32 MPa, the best PRNN led to an error around 9 MPa error (Fig. 16(a) ). Based on that, a second approach to generate the dataset was considered. Random strain paths were generated from Gaussian Processes priors, which produces non-proportional and non-monotonic loading as opposed to the proportional loading previously considered for training.
This time, the size of the training dataset and the type of loading was also a variable for the PRNN. It was found that training the PRNN on random non-proportional and non-monotonic curves yields higher accuracy than training with known, proportional, and monotonic curves for all loading scenarios (Fig. 18 ). Although training with known directions is appealing, having a network that provides lower errors and consistent performance with random directions is also interesting. Ultimately, the PRNN consistently outperformed the RNN with 64 times less data. After ensuring the PRNN capacity in several challenging scenarios for black-box models, one of the networks trained on non-proportional and non-monotonic curves was chosen to surrogate the microscopic model in a set of two FE 2 examples. The first example concerned a tapered bar in transverse tension and was used to illustrate how the different material models in the PRNN behave for a single macroscopic integration point (Fig.
6 initialize current macroscopic strain: ε current ← ∅ 7 for i ∈ [1, 2,. , N components ] do 8 sample from posterior distribution: ε i ← GP i ::samplePosterior ( t ) 9 add value to strain vector: ε current ← ε current ∪ ε i 10 solve micromechanical BVP: σ current ← fullModel::materialUpdate ( ε current ) 11 if convergence then 12 store equilibrium solution of micromodel: fullModel::storeSolution( ) 13 add macroscopic strains and stresses to dataset:.
Methods: The platform, curated by the international research community, allows secure local integration of sensitive data while facilitating the development of data-driven applications and reports for decision-makers. Its main components include centrally managed databases with fine-grained access control to data, fully automated and documented data collection and transformation, and a powerful web-based data exploration and visualization tool. Results: EpiGraphHub is already being used for hosting a growing collection of open data sets and for automating epidemiological analyses based on them. The project has also released an open-source software library with the analytical methods used in the platform. Conclusions: The platform is fully open source and open to external users. It is in active development with the goal of maximizing its value for large-scale public health studies.
Although we cannot directly influence countries' decisions to make data available, we can speed up global accessibility. In this paper, we present an initiative cofunded by the World Health Organization (WHO) to build an open-source platform for continuous epidemiological data analysis. It aims at filling multiple gaps in the current public health data analysis ecosystem while functioning as a simple-to-use and responsive tool for decision-makers. We call this platform EpiGraphHub (EGH). It provides automated data integration, cleaning, and harmonization combined with a web interface for easy data exploration and building of live, interactive dashboards. We will present a high-level overview of the platform and some key examples of its use to illustrate its applicability. The proposed platform shares some similarities with other open data platforms, as shown in Table  1 ; however, it differentiates itself by providing additional features and focusing on public health data and epidemiological data analysis.
The other tools and frameworks we compare EGH against (Table  1 ) have slightly different purposes. For instance, Our World in Data (OWID)  [12]  is quite similar to the EGH data aggregation platform, except it is structured as a collection of data-enriched articles. EGH used OWID as one of its data sources. Next, the Comprehensive Knowledge Archive Network (CKAN)  [13]  is a federated data platform mostly used for cataloging heterogeneous data resources with semantic annotation capabilities. EGH data sets could be part of a CKAN catalog. Socrata  [14]  is very similar in features to CKAN. Finally, Google Data Studio, also known as Looker Studio  [15] , is similar to EGH's data-exploration component. It is an extremely powerful business intelligence tool that leverages the Google ecosystem for those who need to create analytical reports about any topic.
System Architecture EGH, which is built upon the open-source business-intelligence platform Apache Superset  [16] , contains added features that make it more suitable for epidemiological data analyses, such as the ability to scale well horizontally, allowing it to serve heavy loads on a distributed computing infrastructure. The components of the platform, better detailed in the following subsections, include the development of a distributed data collection engine for epidemiologically relevant data sets, provision of data harmonization as a service for users, hosting of analytical dashboards with privileged access to EGH's databases, and provision of analytical software libraries in Python and R optimized to make use of the data available on the platform. The platform's architecture facilitates the automated collection, transformation, storage, and analysis and visualization of data on an entirely open-source software stack (Figure  1 ).
The collection and transformation stages are customized for each data set and documented in the platform's online documentation  [17, 18]. Portability and replication of the entire stack are important aspects of the platform's design, which places each software service within Docker containers (Docker, Inc; Figure  2 ). A container is a standard unit of software that packages code and all its dependencies so the application can be deployed quickly and run reliably across different computing environments. To maximize code reusability and value for the open-source community, all the tools for data collection, transformation, and analysis were developed as EGH software libraries available both in Python and R. These libraries are fully documented and ready for independent use from the EGH platform.
Data Collection Since many health data repositories are openly accessible  [19] [20] [21] , the long-term availability and immutability of data sets is a key challenge when building a data analysis platform upon a broad set of data sources that operate under distinct governance systems and are funded by a variety of different sources. Lin et al  [22]  define the TRUST (transparency, responsibility, user focus, sustainability, and technology) principles for open data sets. Another set of principles for open data repositories are known as the FAIR (findable, accessible, interoperable, and reusable) data principles  [23]. EGH follows all these principles, but also guarantees that all the data used for a particular analysis remain fixed and accessible as they were at the time the analysis was done.
In order to allow for that and if licensing terms permit, we keep a copy of the original data on our servers. In the implementation of this replication, we make a distinction between static and dynamic data sets. Static data sets are the ones not subject to updating and revision-these data sets are imported only once. Dynamic data sets, on the other hand, must be periodically updated or extended. Disease surveillance databases such as COVID-19 case counts are a good example. For these data sets, we define a periodicity for their updating, which is automatically triggered by the platform. The entire workflow related to data collection and integration is implemented using Apache Airflow  [24]. Apache Airflow is a distributed task scheduler that allows for computational tasks to be defined as parts of a workflow directed acyclic graph and to be efficiently scheduled and monitored.
The criteria for selecting which data sets should be collected is first based on the relevance of our partners' research projects, for which a collaborative partnership exists, and second on requests from our community of users. A direct example of this prioritization is the current predominance of COVID-19 data sets due to our partnership with the WHO to tackle this global challenge. All data sets brought into the platform are fully documented with regard to their content, their provenance, and when they were collected. This allows users to ensure data quality and compare our version of the data with the versions available at their source. All data sets, raw or transformed, are stored in a PostgreSQL relational database server (PostgreSQL Global Development Group) with scalable storage capacity to handle sudden growth in demand.
In this database server, data are organized according to access level, wherein public and restricted-access data sets are kept in entirely separate databases (Figure  4 ). This guarantees the exposure of the full contents of public data sets on our web-based visual analytics tool without compromising the security of nonpublic data sets. One key aspect of the platform is its ability to connect and pull data from widely used health information management systems (HIMS) such as the District Health Information System 2 (University of Oslo), GoData (WHO), and others. Governmental and also private HIMS are typically closed platforms where only authorized personnel have access to the data. Therefore, EGH aims to make available open-source software to facilitate pulling data from these platforms, according to the data access authorization rules from data owners.
Our cloud service  [25]  also includes an integrated deployment of the open-source Kobo toolbox server  [26]  provided free of charge to partners that need to collect primary data. The importance of the data collection feature of EGH is exemplified through its alleviation of the restrictions of data silos. This feature enables decision-makers and their data analysis teams to easily get all the relevant data for a comprehensive analysis from a single source while benefiting from our work to locate, collect, transform or clean, and store the multiple data sets.