dataesr/scientific-paragraphs-categorization huggingface dataset:
The deterministic ensemble Kalman filter (DEnKF) We use the DEnKF  (Sakov and Oke, 2008)  to assimilate the SIT and SIC observations. Unlike the stochastic EnKF, the DEnKF does not require the observations to be perturbed to avoid filter divergence. DEnKF is also conceptually more straightforward compared to other transform-based deterministic EnKFs (see  Carrassi et al. , 2018 , for the differences between various EnKF flavors). The open-source DA software, EnKF-C version 2. 8. 0  (Sakov, 2014) , is adopted to perform the DA. The EnKF-C provides the functionality for automated quality control as well as ensemble inflation and localization, which are briefly outlined below.
Naturally, the downside of high-frequency assimilation is the increased computational cost  (Lange and Craig, 2014; He et al. , 2020). More frequent assimilation of SIT was not considered in view of the limited daily coverage of CryoSat-2 data in the ice pack. As a reference, we produce a free ensemble experiment without DA constraints, referred to as the free run hereafter. Because the CS2SMOS product is only available in the ice-freezing season, all the experiments are conducted from 18 October 2019 to 16 April 2020 (182 d). The initial conditions of the experiments are generated from an ensemble spin-up run from 3 September to 17 October 2019 (45 d). The spin-up run is initialized from the neXtSIM-F forecasts  (Williams et al. , 2021)  and integrated with different perturbations for each ensemble member as described in Sect.
Because the SIC and SIE evolution primarily depends on the underlying ocean boundary condition, we argue that during the model forecast, the daily TOPAZ4 data counteract the effect of weekly assimilation on the ocean states. This is not the case in SIC1-SIT7, which updates the analysis SST and SSS daily in the slab ocean via DA. This argument is in agreement with the study by  Williams et al. (2021) , which blamed the model for the underestimation due to the lack of input of detached landfast ice and fast melting in the seas. This phenomenon is further discussed in Sect. 7.
Discussion and conclusions We propose an ensemble-based data assimilation system for the Lagrangian sea ice model, neXtSIM, to enhance its Arctic sea ice forecast skill. The DEnKF is applied to work with a time-dependent, non-conservative model mesh, following the projected EnKF strategy introduced by  Aydogdu et al. (2019). The Lagrangian nature of the model implies that each ensemble member evolves on an independent adaptive moving mesh. At analysis times, we interpolate the ensemble members onto a fixed and regular reference mesh, on which the analysis is carried out. The analysis state variables are then projected back to the individual member meshes. The ensemble is generated by perturbing an internal model parameter and external forcings, namely the ice cohesion, the atmospheric forcing (10 m wind velocities, longwave downwelling radiation, and snowfall rate) from the ECMWF product, and the oceanographic forcing (SST, SSS) from the TOPAZ4 forecast.
g. , in the SIC RMSD (Fig. 2 ) and spread (Fig. 3 ). The underestimation of SIE is reduced in the Beaufort-Chukchi Sea and the Kara-Barents Sea in SIC1-SIT7 (Fig. 5 ). The IIEE is roughly comparable to those obtained by the operational TOPAZ4 system, with a large part of the errors caused by underestimation (see the validation time series for sea ice at https://cmems. met. no/ARC-MFC/V2Validation/ timeSeriesResults/year-day-01/SItimeSeries_year-day-01. html#OSI_xIIEE, last access: 12 August 2022). The similarities of IIEE results are thus likely caused by areas of ocean surface temperatures that are too warm. Nevertheless, we also note that the IIEE may contradict the SIC statistics since it only uses an isoline of the SIC. Moreover, we observe a large reduction of the (both positive and negative) model SIT biases by assimilating the CS2SMOS SIT data (Sect.
Acknowledgements. We thank  Pavel Sakov  for helpful discussions and improvement regarding the EnKF-C code and  Jiping Xie  for contributing the TOPAZ interface to sea ice observations. We are grateful for the support from  Timothy Williams  and  Anton Korosov  regarding the environments of neXtSIM and its analysis tools. We thank the  EUMETSAT OSI-SAF center  for providing the sea ice concentration and SID data: https://osi-saf. eumetsat. int/ (last access: April 2023). The production of the merged CryoSat2-SMOS sea ice thickness data was funded by the  ESA  project  SMOS & CryoSat-2 Sea Ice Data Product Processing and Dissemination Service , and data from 9/2019 to 4/2020 were obtained from  AWI. The work is funded by the  DASIM-II  grant from  ONR. Alberto Carrassi ,  Christopher K. R. T.
Jones ,  Ali Aydogdu , and  Pierre Rampal  acknowledge the support of the project  SASIP  funded by  Schmidt Futures - a philanthropic initiative that seeks to improve societal outcomes through the  development of emerging science and technologies. Sukun Cheng  and  Laurent Bertino  were co-funded by the  FOCUS  project from the  Research Council of Norway , and  Alberto Carrassi  and  Yumeng Chen  are also supported by the  UK National Centre for Earth Observation. Computations were carried out on the  Norwegian Supercomputing Infrastructure Sigma2  (grants  nn2993k  for computing and  NS2993K  for data storage). Financial support. This research has been supported by the  Office of Naval Research  (grant nos. N00014-18-1-2493  and  N00014-18-1-2204 ), the  Norges Forskningsråd  (grant no.
Data availability. The atmosphere product from ECMWF IFS is available at https://apps. ecmwf. int/archive-catalogue/ ?type=fc&class=od&stream=oper&expver=1 (Owens  and  Hewson, 2018). The TOPAZ4 ocean forcing is available from the EU Copernicus Marine Environment Monitoring Service -Arctic Ocean physics analysis and forecast at https://resources. marine. copernicus. eu/product-detail/ARCTIC_ ANALYSIS_FORECAST_PHYS_002_001_a/INFORMATION (Sakov et al. , 2012). The OSI-SAF SIC (SSMIS) data are available at https://osi-saf. eumetsat. int/products/osi-401-b (OSI-SAF, 2023a). The OSI-SAF SID data are available at https://osi-saf. eumetsat. int/products/osi-405-c (OSI-SAF, 2023b).
The development of practical query languages for graph databases runs well ahead of the underlying theory. The ISO committee in charge of database query languages is currently developing a new standard called Graph Query Language (GQL) as well as an extension of the SQL Standard for querying property graphs represented by a relational schema, called SQL/PGQ. The main component of both is the pattern matching facility, which is shared by the two standards. In many aspects, it goes well beyond RPQs, CRPQs, and similar queries on which the research community has focused for years. Our main contribution is to distill the lengthy standard specification into a simple Graph Pattern Calculus (GPC) that reflects all the key pattern matching features of GQL and SQL/PGQ, and at the same time lends itself to rigorous theoretical investigation.
INTRODUCTION The foundations of graph databases were laid more than 30 years ago in papers that define the now ubiquitous notion of regular path queries (RPQs)  [10, 12]. They preceded the development of graph database systems by decades: it was in this millennium that the graph database industry properly emerged, driven by two similar models, namely RDF data and property graphs. The latter one is now promoted by multiple vendors such as Oracle, Neo4j, Amazon, SAP, Redis, TigerGraph etc. A very notable development in the evolution of property graph databases is the decision, taken 3 years ago, to produce a new standard query language called GQL  [24]. It would subsume the hitherto used languages such as Cypher  [16]  of Neo4j, PGQL  [23]  of Oracle, GSQL  [14]  of TigerGraph, and the G-CORE proposal from an industry/academia group  [1].
The new GQL (Graph Query Language) Standard is developed by the same ISO committee that is in charge of developing and maintaining the SQL Standard. The core of any graph query language is its pattern matching engine, that finds patterns in graphs. GQL's pattern matching facilities are in fact shared across two standards: • SQL/PGQ, a new Part 16 of the SQL standard, that defines querying graphs specified as views over a relational schema; • GQL, a standalone language for querying property graphs. The development of GQL as a query language standard is rather different from SQL. The latter came out of a well-researched relational theory; relational calculus led to its declarative approach, while relational algebra formed the foundation of RDBMS implementations. But while GQL is "inspired" by the key developments of database research, they are not represented directly in the language, which itself is designed by an industry consortium.
The GQL committee lists 1  three main academic influences: regular path queries  [12] , Graph XPath  [18] , and regular queries on graphs  [22]  which are the regular closure of conjunctive RPQs. While these provided important initial orientation, the GQL development is much more in line with industry-level languages such as Cypher, GSQL, and PGQL. The theory of graph query languages on the other hand produced a multitude of languages based on RPQs: CRPQs, UCRPQs, 2(UC)RPQs, ECRPQs, just to name a few (see  [2, 3]  for many more). However, none of them can play the role of relational calculus with respect to the development of GQL, as they do not capture its key features with respect to both navigation and handling data. Our goal then is to produce that missing piece, a theoretical language that underlies GQL and SQL/PGQ pattern matching and can be studied in the same way as the RPQ family has been studied over decades.
Doing so has two significant difficulties: (1) GQL pattern matching is described by close to 100 pages of the Standard text which is not human-friendly; it is intended for developers implementing the language; (2) Even that text is not available to the research community: the relevant ISO standards will only be published in 2023 and even then will be behind a paywall. The only publicly available source is  [13]. It outlines the main features of GQL and SQL/PGQ pattern matching by means of several examples and thus hardly serves the purpose of introducing a pattern matching calculus to form the basis of further study of graph querying. Such a calculus should judiciously choose the key features leaving others for extensions. Think again about the SQL/relational calculus analogy. The latter does not have bag semantics, nulls, aggregates, full typing, and many other SQL features.
We adopt a similar approach here. Our goal is to introduce a calculus that captures the essence of GQL pattern matching, without every single feature present. Similarly to relational calculus, we settle for the core set-semantics fragment without nulls or aggregates, each of which can be added as extensions. What is new? We now outline the main differences between the currently existing theoretical languages and real-life pattern matching in property graphs that we need to capture. • Much of the theoretical literature relies on an overly simplified model of graph databases as edge-labeled graphs; this is common in the study of RPQs and extensions  [3]. Typical patterns in languages like Cypher combine graph navigation with querying data held in nodes and edges. With data values, the theoretical model of choice is data graphs  [18] : in those, each node carries a single data value, similarly to data trees studied extensively in connection with tree-structured data  [7].
This means edges can be traversed in different directions, or traversals can be indicated as having no direction at all. • To ensure the number of paths returned is finite, real-life languages put additional restrictions on paths, such as insisting that they be trails (no repeated edges, as in Cypher), simple (no repeated nodes), or shortest (as in G-Core  [1] ). Typically in research literature one considers each one of those semantics separately, but GQL permits mixing them. • Similarly to Cypher, in GQL one can match paths and output them. In theoretical languages this feature is rather an exception  [1, 5]. • Finally, one can apply conditions to filter matched paths. For example, after matching (𝑥 : 𝑎) 𝑒:𝑏 ---→ 1. ∞ (𝑦 : 𝑎), one can apply a condition 𝑥. 𝑘 = 𝑦. 𝑘 stating that property 𝑘 of both 𝑥 and 𝑦 is the same.
Notice that we cannot talk similarly about properties of 𝑒, as they are bound to a list. Other features of patterns are those in regular languages: concatenation, disjunction, repetition; they can be applied on top of already existing patterns, similarly to  [22]. Our main contribution is the Graph Pattern-matching Calculus GPC that captures all the key features of GQL and SQL/PGQ pattern matching. Its syntax is described in Section 3 (after the definition of property graph concepts in Section 2). To ensure the well-definedness of its expressions, the calculus comes with a type system, given in Section 4. We give a formal semantics of GPC in Section 5, and provide a number of basic results on the complexity of the language, and its relationship with classical theoretical formalisms in Section 6.
Both 𝑥 and : ℓ can be omitted. In the case when they are present, the variable 𝑥 gets bound to the matching edge, and : ℓ constrains the allowed edge labels. The concrete syntax of GQL and SQL/PGQ involves aspects like parentheses and precedence of operators, which we do not take into account here. Instead, we assume that GPC expressions are already parsed, so as to work directly on their abstract syntax trees. The full grammar of GPC is given in Fig. 1. Here: 2 As is usual in the graph database literature  [3, 20, 21, 25] , we use the term path to denote what is called walk in the graph theory literature  [8].
The pattern (𝑥 : 𝐴) -→ (𝑧 : 𝐵) ← -(𝑢 : 𝐶) + ( ) is an optional pattern 5 : a feature present in many languages such as SPARQL and Cypher. It matches an edge from an 𝐴-node to a 𝐵-node, binding 𝑥 and 𝑧 to its endpoints, and if the 𝐵-node has an incoming edge from a 𝐶-node, binds 𝑢 to its source. This pattern can be seen as the disjunction 𝜋 1 + 𝜋 2 where 𝜋 1 = (𝑥 : 𝐴) - → (𝑧 : 𝐵) ← -(𝑢 : 𝐶) and 𝜋 2 = (𝑥 : 𝐴) - → (𝑧 : 𝐵) ( ). In 𝜋 2 , the concatenated ( ) must match the same node as 𝑧 and thus it has no effect on the pattern; this accounts for the case where the node bound to 𝑧 has no incoming edge from a 𝐶-node. The pattern (𝑥 : 𝐴) 𝑦 --→ 1. ∞ (𝑧 : 𝐵) looks for paths of arbitrary positive length from an 𝐴-node to a 𝐵-node. It uses variable 𝑦 to bind edges encountered on this path. Unlike the bindings for 𝑥 and 𝑧, which are unique nodes, there may well be multiple edges encountered on the path between them, and thus 𝑦 needs to be bound to a complex object encoding all such edges on a path.
Finally, we consider the class of regular queries (RQs)  [22] , which subsumes all the aforementioned classes. A regular query is a non-recursive Datalog program that is allowed to use transitive atoms of the form 𝑅 + (𝑥, 𝑦) in the body of the rules, where 𝑅 is a binary predicate, either built in, or defined in the program. In order to compare with the aforementioned languages, we consider a simple extension of GPC with projection and union, reflecting the fact that the pattern matching mechanism we formalize will be a sublanguage of a fully-fledged query language like GQL or SQL/PGQ. A GPC+ query is a set of rules Ans( x) :-𝑄 1 ; Ans( x) :-𝑄 2 ;. Ans( x) :-𝑄 𝑘 where 𝑄 𝑖 is a GPC query such that x ⊆ var(𝑄 𝑖 ) for all 𝑖. The semantics of such a query on graph 𝐺 is ⟦𝑄 1 ⟧ x 𝐺 ∪ ⟦𝑄 2 ⟧ x 𝐺 ∪ • • • ∪ ⟦𝑄 𝑘 ⟧ x 𝐺 where ⟦𝑄 𝑖 ⟧ x 𝐺 = 𝜇 ( x) | ∃𝑝 (𝑝, 𝜇) ∈ ⟦𝑄 𝑖 ⟧ 𝐺 for all 𝑖.
An equivalent GPC+ query is Ans(𝑥, 𝑦) :-𝑄 where 𝑄 is the GPC query shortest (𝑥) [ :𝑎 --→ (𝑧) :𝑏 --→ 1. ∞ () ← -1. ∞ (𝑧) :𝑐 --→] 1. ∞ (𝑦). Basically, we introduce a fresh variable 𝑧 which binds to the node from which we need to find a nonempty 𝑏-labelled path to an anonymous node, and then we return to the same node, thus allowing us to encode an answer inside of a single path. Since we only care about the endpoints in all of these query classes, the restrictor shortest is enough. This idea is then applied inductively in order to capture regular queries. □ Complexity. When it comes to evaluating graph queries, one is used to dealing with high complexity. For instance, checking whether there is a query answer with a restrictor simple or trail on top is known to be NP-hard (in data complexity)  [3, 4, 19, 20, 25] , and yet this feature is supported both by the GQL standard  [13]  and by concrete languages such as Cypher  [16].
The reason that we study the problem like this, however, is that this is what the GQL standard asks for. In our analysis, we will use Turing machines with output tape (in order to enumerate the results), and we will bound the size of the work tape the machine uses. The main result of this section is the following: Theorem 12. The problem Enumerate answers can be solved by a Turing machine using exponential space (in 𝐺 and 𝑄). If we consider the query 𝑄 to be fixed (data complexity), then the machine uses only polynomial space. Proof sketch. The basic idea is to enumerate all possible answers (𝑝, 𝜇) in increasing length of 𝑝, and check, one by one, whether they should be output. If we consider a single pattern with a restrictor on top, e. g. , 𝑄 = 𝜌𝜋, this approach works as described, and the size of the possible paths (and thus also mappings 𝜇), can be bounded by a size that is exponential in the size of 𝑄 and 𝐺, and polynomial if we assume 𝑄 to be fixed.
For instance, with (: 𝐴) 𝑥 --→ 0. ∞ (: 𝐵) looking for paths between 𝐴 and 𝐵, one could return the total length 𝑥. length of each matched path. However, adding aggregation is problematic. To see why, consider the simple aggregate ♯(𝑥) for a group variable 𝑥, which counts the number of bindings of that variable. Now assume we extend the language with arithmetic conditions of the form 𝑡 1 = 𝑡 2 , where 𝑡 1 and 𝑡 2 are terms built from values 𝑦. 𝑘 and ♯(𝑥) by means of addition "+" and multiplication "•". These already pack huge expressive power: Proposition 14. The data complexity of GPC with arithmetic conditions is undecidable. In view of this, the current approach of GQL is to only allow aggregates in the outputs of queries (no operations on them are permitted). But it is a general open direction to understand how to tame and use the power of aggregates in a graph language.
Bag semantics. Relational calculus (first-order logic) is interpreted under set semantics, but SQL uses bag semantics, and so does GQL. In the basic version of GPC we opted for set semantics, following the relational calculus precedent, but it is necessary to study bag semantics as an extension of GPC. Nulls and bound conditional variables. We have left out the treatment of nulls, assuming that conditions involving non-applicable nulls -i. e. , values 𝛿 (𝑥, 𝑘) where the property 𝑘 is not defined for 𝑥 -evaluate to false. Following SQL (and the current GQL proposals) they would instead evaluate to unknown, leading to many known issues  [11]. In addition, one could expand the language with a predicate that checks whether a conditional variable is bound, as done, in fact, in GQL. Scoping of variables.
Consider the pattern (𝑥) -→ (𝑦) -→ (𝑧) ⟨𝜃 ⟩ -→ (𝑢), where 𝜃 is 𝑥. 𝑘 + 𝑢. 𝑘 = 𝑦. 𝑘 + 𝑧. 𝑘. To evaluate this compositionally, for the subexpression (𝑦) -→ (𝑧) ⟨𝜃 ⟩ we need to know the values of 𝑥. 𝑘 and 𝑢. 𝑘, which do not occur locally. This necessitates looping over all pairs of nodes in the graph, turning the evaluation into a computationally challenging task. Moreover, if the pattern from 𝑦 to 𝑧 appears under repetition, the evaluation procedure becomes much less clear. Despite these issues, GQL plans to offer such kind of features, which therefore need to be thoroughly investigated. Label expressions. GQL will offer complex label expressions  [13] , and these too can be added to the calculus as an extension. Enhancing conditions. We assumed that data values come from one countable infinite set of constants, very much in line with the standard presentations of first-order logic.
In reality, of course, data values are typed, and such typing must be taken into account (at the very least, for the study of aggregation, to distinguish numerical properties). Furthermore, one could permit explicit equalities between singleton variables in conditions (currently, such variables implicitly join when they are repeated in a pattern). Other language features. GQL is not limited to pattern matching. Similarly to Cypher, it provides relational operations on tabular representations of answers. In this paper we focused on the abstraction of pattern matching alone. For a follow-up that considers additional features of GQL in a syntax that more closely resembles the actual language, see  [15].
ACKNOWLEDGMENTS This work was supported by the following grants: a  Leverhulme Trust   Research Fellowship ;  EPSRC  grants  N023056  and  S003800 ;  Agence Nationale de la Recherche  projects  ANR-21-CE48-0015  ( Verigraph ),  ANR-18-CE40-0031  ( QUID ),  ANR  project  EQUUS   ANR-19-CE48-0019  which is funded by the  Deutsche Forschungsgemeinschaft (DFG ,  German Research Foundation ) -project number  431183758 ; Poland's  National Science Centre  grant  2018/30/E/ST6/ 00042 ;  ANID Millennium Science Initiative Program   ICN17_002 , and  ANID Fondecyt  regular project  1221799. We thank the anonymous reviewers for their constructive feedback. We are also grateful to the members of ISO's SQL/GQL committee, and especially  Fred Zemke , for their comments.
Model adaptations The biochemical model of metabolism takes up and modifies that of Li and Wang  [5]. The original model is written in MATLAB code. It has been translated into symbolic code in Python, which is used to directly generate the C++ code of the system of equations as well as the associated Jacobian matrix, for direct integration into PhysiCell. The differential equations describe the one-or two-way reaction flows and take the following form  [19]  which is an extended form of a Michaelis-Menten equation, reversible and extensible to several substrates [S] or several products [P]: v net = V max f • [S] K ms -V maxr • [P] K mp 1 + [S] K ms + [P] K mp (3) here V max f and V maxr are respectively the maximum speeds of the reaction in the direct (forward) and reverse (backward) directions.
In the code, these equations are simplified automatically using the symbolic calculation software Sympy  [22]. Incoming transport of lactate and protons r21 reverse = 0. 2 • (1 - 1 e 2•(Lactate out -Lactate) + 1 ) • Lactate out Lactate out + 0. 1 • Regulation pH e /pH i The first term of the incoming transport is a constant fixed here at 0. 2 and which is linked to the maximum speed of the incoming flows by the MCT transporters. If the maximum outflow value is 1, the maximum inflow is only 20% as efficient in the experiments of Xie et al. [6]. Again this parameter could be adjusted but it was not necessary here to do it dynamically. The second term is the counterpart of the first term in the outflow equation. It is subtracted from 1 in order to increase the inflow when the concentration of extracellular lactate is close to or greater than the intracellular one and conversely to bring it to 0 when Lactate > Lactate out.
The popularity of 𝑘-mer-based methods has recently led to the development of compact 𝑘-mer-set representations, such as simplitigs/Spectrum-Preserving String Sets (SPSS), matchtigs, and eulertigs. These aim to represent 𝑘-mer sets via strings that contain individual 𝑘-mers as substrings more efficiently than the traditional unitigs. Here, we demonstrate that all such representations can be viewed as superstrings of input 𝑘-mers, and as such can be generalized into a unified framework that we call the masked superstring of 𝑘-mers. We study the complexity of masked superstring computation and prove NPhardness for both 𝑘-mer superstrings and their masks. We then design local and global greedy heuristics for efficient computation of masked superstrings, implement them in a program called KmerCamel🐫, and evaluate their performance using selected genomes and pan-genomes.