dataesr/scientific-paragraphs-categorization huggingface dataset:
Additionally, it is important to mention that all the input parameters  Thus, to have optimal electrode mesostructures to reach complete wetting at the shortest possible time, pore size distribution and interconnectivity of the pores must be well designed during the manufacturing. This can be a challenging task with traditional manufacturing process, still it is achievable with alternative techniques such as SPS sintering and 3D printing  [34, 35]. In conclusion, we present an innovative ML model based on a multilayers perceptron (MLP) architecture, to predict electrolyte infiltration in porous NMC electrodes. The host structure of the NMC porous electrode was obtained experimentally by (micro-CT) X-ray tomographic measurements. The MLP was trained with data coming from physicsbased 3D LBM model and extracted pore networks from (micro-CT) Xray tomography.
Additionally, our ML model generates only around 10 Mb of data to be compared with the 50-200 Gb generated during the LBM simulations, saving data storage space and making post-processing fast and affordable. All the advantages mentioned above allow the model to quickly screen different electrode architectures and electrolyte properties paving the way towards a fast and efficient tool for the optimization of the electrolyte infiltration process. On top of that, the simulation tool reported in this work is devoted to be integrated in the overall computational workflow of the ARTISTIC project, which aims at simulating a digital-twin of the LIB electrode manufacturing process, including the electrode slurry, the coating, the drying, the calendering, the electrolyte infiltration and the resulting electrochemical performance.
The complete dataset is randomly split into the training and testing dataset containing 80 % and 20 % of the total data, respectively. Fig. 1A represents the evolution of the loss values (MSE) for the training data (80 % of the total amount of data) and the validation data (the remaining 20 %) during the training step of the MLP over 1000 training cycles. Fig. 1Bshows the average R 2 scores for the model compared with the mean square error (MSE) between the initial saturation curve and its discretization to define the saturation values outputs. In order to obtain a compromise between the global accuracy of the MLP and the error between the saturation curves and their associated discretized values, we successively retrained the MLP model after removing those saturation value outputs that were not properly fitted, thus reducing the number of outputs in the model.
Acknowledgements A. A. F. , A. S. , M. D. and M. C. acknowledge the  European Union 's  Horizon 2020 research and innovation programme  for the funding support through the  European Research Council  (grant agreement  772873 , " ARTISTIC " project). A. A. F. and M. D. acknowledge  ALISTORE European Research Institute  for partial funding support. A. A. F. and O. A. acknowledge partial funding from the  Région Hauts de France  and from the  European Union 's  Horizon 2020 research and innovation program  under grant agreement No  957189  ( BIG-MAP ). The authors also thank  Markus Osenebrg ,  André Hilger  and  Ingo Manke  for the support at the P05 synchrotron beamline at  DESY  at  Institute of Applied Materials, Helmholtz-Zentrum Berlin für Materialien und Energie GmbH. The authors acknowledge  Dr.
C) Analysis of the main health needs for preparing the Instagram profile Following the above steps, a descriptive analysis of the population's socio-demographic and health profile was carried out. Using the results of the google forms analysis, the key points for the development of health promotion actions published through Instagram were included. The study was developed to have a format to call young followers as a tool to increase the number of followers and the interaction of readers with the @comodormimos profile. The content was permanently posted on the profile, as well as a "question box " publication. With the presentation and baseline explanations completed, the posting of content related to the theme Sleep and Hygiene of Sleep began, seeking to create a logical sequence of posts and to use accessible language.
Therefore, we claim that we can compare the tools through the solutions for this benchmark. The tools cover a wide area of model query technology and database management systems; thus, the analysis of the solutions using those tools allows us to reason on the previously mentioned questions. The benchmark was originally proposed at the Transformation Tool Contest (TTC) 2018 as live contest  [51]. At the TTC, several solutions have been submitted  [12, 17, 34, 49, 78]. After the TTC, we invited further researchers working in incremental query technology to provide solutions in their favourite tools. In this paper, we present all of these solutions and compare them with respect to their features, complexity of change propagation and overall performance. The remainder of this paper is structured as follows: Sect.
Solutions In this section, we present the solutions developed for the Social Media benchmark from Sect. 2. We present the following solutions: -Modelling tools and graph databases running in a managed runtime (JVM 5 or CLR 6 ): -A solution using the plain. NET query API and NMF to represent the models in memory (Sect. 3. 2) and a solution using the incrementalization system of NMF (Sect. 3. 3). -Multiple solutions using the model management system Hawk (Sect. 3. 4). -A solution using the incremental reference attribute grammar tool JastAdd (Sect. 3. 5). -A solution using the model transformation language YAMTL (Sect. 3. 6), with a batch variant and two incremental variants (implicit/explicit incrementality). -A batch solution using the ATL model transformation language with the EMFTVM batch execution engine (Sect.
Tool description Eclipse Hawk is a tool to manage models that have been fragmented (e. g. for versioning purposes) by incrementally indexing the various connected fragments into a common graph database  [8]. Hawk can watch over a local folder or a version control system and update the graph whenever the model files change. For this case study, Hawk was configured with the ability to index EMF models, maintain a graph database using one of three backends (Neo4j, SQLite, or Greycat  [42] ) and run queries in a dialect of the Epsilon Object Language (EOL)  [61]. Greycat implements a graphoriented data model on top of existing key-value stores, such as LevelDB or RocksDB. For the present work, LevelDB was chosen as the underlying key-value store. Further, Hawk provides the concept of "derived attributes", which extend a type with pre-computed expressions which are updated incrementally as the graph changes.
Query 1 Several versions of the first query were implemented. For the sake of clarity, we will call these "batch", "incremental update" (IU) and "incremental update and query" (IUQ). As mentioned in Table  1 , all Hawk variants have partial incrementality. Batch and IU use full result sorting, and IUQ uses an "online top-x" approach. The batch mode is the most direct use of Hawk. In this version, the tool is told to watch a folder that contains the initial version of the model. An EOL script replays the change sequences on the model, and Hawk updates the graph based on the new versions of the model. The Post type is extended with the score derived attribute, which is updated incrementally by Hawk. The definition of score is as follows, using self as the Post being extended: With this derived attribute, it is simple to implement the main query itself.
Tool description Attribute Grammars  [60]  can be used to describe the structure of context-free data along with their static semantics. Reference Attribute Grammars (RAGs)  [43]  extend this paradigm such that attributes are allowed to return other nodes of the abstract syntax tree (AST) as a result of their computation. The tool JastAdd  [44]  is based on Reference Attribute Grammars and offers non-terminal attributes  [86]  and circular attributes  [62] , used to represent a part of the model and to compute parts of the second query, respectively. In JastAdd, a grammar specified in BNF with inheritance and attributes specified written in Java are woven together to generate plain Java code. It contains a Java class for every non-terminal specified within the grammar, uses the code of the attributes inside its methods and has additional boilerplate code, e.
Tool description YAMTL  [16]  is a model transformation language for EMF models, with support for incremental execution  [18] , designed as an internal DSL of Xtend. The solution to the Social Media benchmark uses query rules that only consist of input patterns, whose filters define the queries, and uses the YAMTL pattern matcher for evaluating them. Queries are defined using Xtend and the Java Collections Framework. The YAMTL solutions implement the online top-x approach, keeping the best three candidates at all times, with the operation bestThreeCandidates. Three variants of the solutions have been implemented: batch (YAMTL-B), implicitly incremental (YAMTL-II) and explicitly incremental (YAMTL-EI). YAMTL-B disables dependency tracking enabling a faster initial transformation but subsequent updates compute queries from scratch.
Tool description Neo4j is a graph database management system using the property graph data model. Such graphs consist of labelled entities, i. e. nodes and edges, which can be described with properties encoded as key-value pairs. Neo4j uses the Cypher query language  [33]  which offers both read and update constructs  [37]. While the main focus of Neo4j is to run graph queries in an online transaction processing (OLTP) setup, it also supports graph analytical algorithms with the Graph Data Science library 11   [71].
Tool description To study the usability and performance of relational database management systems (RDBMSs), we implemented a batch solution in PostgreSQL. Figure  6  shows the database schema capturing the social network model. Instances of each node type (e. g. Comment) and the edge type with many-to-many cardinality (friends) are stored in relations (tables) with the following schemas: comments(id, ts, content, submitterid, parentid) posts(id, ts, content, submitterid) likes(userid, commentid) users(id, name) friends(user1id, user2id) Each relation representing a node has a primary key. Many-to-many edges are represented in association tables with two foreign keys. Many-to-one edges are stored as a foreign key in the table representing the node at the endpoint of the edge with a cardinality of "one".
Additionally, indexes were defined on the foreign keys. This supports the SQL optimizer in choosing arbitrary join orders. Evaluating both Q1 and Q2 require checking transitive reachability between nodes, a common recursive query which cannot be expressed in first-order logic or relational algebra  [4]. However, it is possible to express such queries using a relational database by 1. either defining additional data structures and running a sequence of SQL queries in a loop until reaching a fixed point  [26]  or 2. or using SQL:1999's WITH RECURSIVE construct, which allows the formulation of recursive queries. In this solution, we use WITH RECURSIVE as it is widely available in modern SQL implementations  [89].
Tool description For the incremental solution, we have extended the database schema as shown in Fig. 7. Compared to the batch schema, this has three auxiliary relations and an extra attribute: (1) q1_scoring for maintaining the scores and timestamps of the Posts as defined in Q1, along with (2) cf and (3) cfc with the same semantics as in the Batch solution of Q2. The attribute (4) comments. postid is where Q1 maintains the root Post reference for each Comment, which is then used in Q1. Additionally, we have employed a horizontal parti-Fig. 7  ER diagram of the database schema, extended for incremental processing with 3 tables, 1 attribute to hold the root Post reference of the Comments and 5 status attributes added to the existing tables (highlighted in yellow boxes with dashed borders) tioning strategy  [1]  on each table.
The partitioning uses an attribute status consisting of a single character "B" or "D". During a particular update phase, rows that were already in the database are stored in the "B" (before) partition, while rows that have just been inserted are temporarily stored in the "D" (diff ) partition. At the end of each update phase, rows from the diff partition migrate to the before partition. For both queries, we implemented algebraic incremental view maintenance with delta queries derived using the rules given in  [38]  and [81, Appendix E].
Query 1 The implementation of Q1 (shown in Listing 28) uses the comms, posts, and likes collections. In Line 8, we extract the Comments and their direct parent objects, which can either be a Post or another Comment. In Lines 19-13, we determine the direct replies for each Post. Next, in Lines 14-25, we collect all transitive replies for each Post using the iterate operator, which executes the specified function until a stable result set is reached. In Lines 26-31, we collect the number of likes for each Comment, each having a cardinality of 1 (corresponding to their contribution to the 14 https://github. com/TimelyDataflow/Naiad 15 https://www. microsoft. com/en-us/research/project/naiad/ 16 https://www. rust-lang. org/ 17 https://github. com/TimelyDataflow/timely-dataflow. 18 https://github.
This criterion does not apply to batch solutions, i. e. ones that recalculate the query from scratch after each model change. Persistence To enable a failsafe operation, it is a desirable property for an analysis tool to continue the analysis even if the process is unexpectedly shut down. For this, data structures to save intermediate results have to be persisted, which is why we call this category query persistence. Further, in order to process models beyond the size of the main memory, it is desirable to persist the models in a database such that solutions do not have to have all model elements in memory. We refer to this as model persistence. Parallelism As modern CPUs have multiple cores, it is desirable for a query technology to be able to make use of these resources by running parts of the query or its incremental change propagation in parallel.
Declarative query language NMF makes use of the SQO (Standard Query Operators), which is a common standard on the. NET platform. Similarly, the Xtend solution uses the standard collection operators of Java. ATL uses (a slightly adapted version of) OCL. The SQL and Neo4j solutions use the standard query languages of these databases: SQL:1999 and Cypher. EOL used by Hawk is standard in Epsilon, but the community of Epsilon is much smaller than the community of relational databases,. NET or Neo4j. AOF and YAMTL have their tool-specific query languages which are declarative (both solutions can be executed incrementally from the query specification) but not yet standards. JastAdd uses its own language to specify synthesized and inherited attributes with tool-specific extensions like circular rules.
Data Model: the data model exposed to the user. Engine: programming language used to implement the engine (model transformation engine, database query engine, etc. ), Solution: programming language and query language (if applicable) used to implement the solution, Decl. : the solution specified the queries using a declarative query language, Batch: only batch mode is supported, Implicit: implicit incrementalization is supported, Explicit: a solution with explicit incrementalization was implemented, DB: database-backed, i. e. the tool persists the model on disk after each transaction, MV: materialized views, Parallel: parallelization is supported. Notation-⊗ yes; ⊘ to some extent; ◯ no; ⍟ yes, using Java 8 streams   1 ) ATL (batch) Θ( p log p + c) Θ (p log p + c) Θ (p log p + c) Θ (p log p + c) Θ (p log p + c) Xtend Θ( p log p + c) Θ (p log p + c) Θ (p log p + c) Θ (p log p + c) Θ (p log p + c) PostgreSQL (batch) Ω(( p + c) log cl + l) Ω(( p + c) log cl + l) Ω(( p + c) log cl + l) Ω(( p + c) log cl + l) Ω(( p + c) log cl + l) YAMTL-B (batch) Θ( p + c) Θ ( p + c) Θ ( p + c) Θ ( p + c) Θ ( p + c) NMF O(1) O(log p) O(h + log p) O(h + log p) O( Hawk (IU) O(n) O(n) O(n + p log p) O(n + p log p) O(n) JastAdd Θ( p) Θ ( p) O( p + n) O( p + n) Θ ( p).
Data model Given that the benchmark was originally presented at the TTC, it is not surprising that most solutions can operate directly on EMF models. NMF uses its own metamodel NMeta but includes a transformation from Ecore and uses the same serialization format  [45]. For JastAdd, it is necessary to reformulate the metamodel as grammar. The solutions for Differential Dataflow, Neo4j, Graph-BLAS and PostgreSQL do not operate on models directly but require dedicated adapters to feed the data from models into their input formats (CSV files). 1 ) O(  1 ) O(  1 ) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) ATL (batch) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) Xtend O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) O(l • f + c log c) PostgreSQL (batch) Ω(l • log l f + l) Ω( l • log l f + l) Ω( l • log l f + l) Ω( l • log l f + l) Ω( l • log l f + l) YAMTL-B (batch) O(l • f • α(l) + c) O(l • f • α(l) + c) O(l • f • α(l) + c) O(l • f • α(l) + c) O(l • f • α(l) + c) NMF incremental O(1) O(1) O(log c) O( f 2 + log c) O(l • f + c log c) Hawk (IU) O(c log c) O(c log c) O(c log c) O( f 2 + c log c) O(l • f + c log c) JastAdd Θ(c) Θ ( c) Θ ( c) O(c + f 2 ) O(l • f ) AOF O(1) O(1) O(log c) O( f 2 + log c) O(l • f + c log c) ATL (incremental) O(1) O(1) O(log c) O( f 2 + log c) O(l • f + c log c) Differential Dataflow O(1) O(1) O(log c) O( f 2 + log c) O(l • f + c log c) YAMTL-II (incremental) O( O(l • f • α(l)) O(l • f • α(l)) Hawk (IUQ) O(  1 ) O(  1 ) O(  1 ) O( f 2 ) O(l • f ) PostgreSQL (incremental) Ω(l • f ) Ω ( l • f ) Ω ( l • f ) Ω ( l • f + c 2 f 2 ) Ω( l • f + c 2 f 2 ) Neo4j (incremental) O(log u) O(log p) O(log c) O(u • f + log c) O(c 2 ).
Explicitness of incrementalization The NMF reference solution, the ATL solution, the Xtend solution and the batch versions of SQL, Neo4j and Graph-BLAS solutions are not incremental. The incrementalization in the incremental NMF solution and in the AOF solution is implicit: the framework deducts a dependency graph from a model of the code that is available at runtime. This dependency graph is at the level of individual operations, so that only those operations really affected by a change need to be re-computed. However, these frameworks require data structures that explicitly support incrementalization. Both NMF and AOF already contain support for a wide range of common operations and allow Users to add new algorithms and data structures when needed, such as for calculating the connected components in Q2.
In the Hawk solutions, there are two aspects to incrementalization: the way that the persistent graph is updated and the way that the query is run. The batch solution uses derived attributes to cache the scores of Comments and Posts, which are implicitly updated incrementally if the nodes used to compute them change: however, the queries run in batch mode, and every change in the social network requires a full re-serialization to disk before the indexing process can update the graph. The incremental update solution uses the same approach for querying, but it does not re-serialize the social network model: instead, it applies the change sequences directly to the internal graph used for querying. The incremental update and query solution uses an explicitly incrementalized version of the query, using graph listeners to trigger the rescoring of Comments and Posts, and uses the same approach to directly update the underlying graph database from the NMF change sequences.
Persistence Most of the presented solutions keep the data only in memory without any features for fault-tolerance. This means that the solutions require a separate tooling to ensure a failsafe operation. The exceptions to this are Hawk, Neo4j and PostgreSQL, which make use of database systems internally and are therefore durable, in the sense that models and intermediate query results for their incremental variants are available even if the application gets terminated unexpectedly. For many of the other tools, model persistence could be achieved through persistence systems such as Eclipse CDO. 20 However, although the model sizes used in the scope of the benchmark went up to a few million model elements and connections, solutions were always able to handle the models in main memory. Therefore, the need for solutions with model persistence to hit the disk for an update led to performance penalties in comparison with other solutions.
Benchmark environment We ran the solutions on a cloud virtual machine with 8 cores of an Intel ® Xeon ® Platinum 8167M CPU, a base clock speed of 2. 0 GHz and a turbo clock speed of 2. 4 GHz. Hyper-Threading was turned off. The machine was running the Ubuntu 20. 04. 2 LTS operating system. To help reproducibility, the experiments were executed in containers managed by Docker 20. 10. 6. The runtime environments for Javaand. NET-based solutions were OpenJDK 1. 8. 0 update 282, OpenJDK 11. 0. 10 and. NET Core 3. 1. 14. Each tool was measured 5 times, and the geometric mean of the results is used. The timeout value for each run was set to 10 minutes. The modelling tools used XML-based representations (e. g. XMI files) to load the data and the change set sequences. For the rest of the tools (Neo4j, GraphBLAS, PostgreSQL and Differential Dataflow), both the initial model and the change sequences were loaded from CSV files.
e. the solutions have different execution speeds but very similar scalability characteristics. The GraphBLAS batch solution outperforms all other batch solutions by more than one order of magnitude. JastAdd and YAMTL that come next are still faster than NMF by a factor of 3 and faster than the remaining by at least an order of magnitude for Q1. For Q2, many solutions had severe performance problems which is why they did not complete for larger model sizes. One can also see that in particular for the SQL solution and the JastAdd solution, the slope is steeper for the larger model sizes, indicating the chosen algorithm implementation does not scale equally well. For Hawk, one can see how the choice of the underlying database implementation affects performance: the perfor-Fig. 9  Execution times of solutions with batch evaluation Fig.
Selected incremental tools To allow a better comparison between the implicitly and explicitly incremental solutions, we plotted a selected subset of the incremental tools in Fig. 12. The results show again large differences in the runtime for the initial query computation of about three orders of magnitude. The load times show the differences between solutions that operate on plain CSVs and those that use a modelling framework or have to set up a database. The results for the change propagation just confirm what we found in the previous sections: while the explicitly incrementalized solutions have a slope, indicating that the time for updating the results grows with the size of the models, the implicitly incrementalized solutions essentially ignore the size of the models when propagating updates.