dataesr/scientific-paragraphs-categorization huggingface dataset:
The ForeFire fire front solver  [9, 24]  has been developed to enable the use of several propagation models, as well as coupled with nested Meso-NH domains by defining fluxes for all the physical and chemical properties. Coupled with the Meso-NH atmospheric model  [21] , it has already been the subject of several investigations on relatively small fires with encouraging results, such as simulating atmospheric feedbacks in agreement with other coupled numerical models  [25] , and reproducing vertical wind velocities and temperatures in the range of what was observed during the controlled experiment FireFlux  [26]. The study proposed in this work is devoted to evaluating the ability of this code to scale up to large fires, about a hundred times the size of previous wildfires already simulated, and in extreme fire weather conditions (temperature over 40 degrees, very low air humidity, low to moderate winds).
Wildfire Propagation ForeFire is a so-called fire area simulator, with the fire font defined as the contour of the burning area. The main originalities of this code are the numerical method used and the modular and expandable software architecture, written in C++, open source and available at https://github. com/ forefireAPI/. The code can be run standalone, embedded as a software library or coupled with an atmospheric model, all with similar initialization procedures. Moreover, the front propagation is not tied to any particular velocity (ROS) or surface flux (for diagnostic/coupling) models and could be extended with user-defined models. While several methods may be used to capture fire front evolution (see  [31]  for a review of numerical interface tracking and capturing methods), the fire front advance is performed by an interface capturing Lagrangian markers method inspired by  [32]  and similar to FarSite  [6, 7, 11, 13].
Data Sources The fuel layer is derived from the National Forest Inventory and is coupled with data from the IGN BD TOPO R for road and drainage networks. The Digital Elevation Model (DEM) is extracted from IGN BD ALTI R 25-m resolution. IFN classes have been grouped according to the methodology developed in  [43]  and use the proposed characterization of the vegetation. Figure  4  presents the fuel distribution over the final burnt area, with four main classes, as well as small non-burnable area providing fuel breaks. Vegetation heterogeneity, orography or small unreported older fires influence the fire propagation at small scales. These heterogeneities are not accounted for in this work, and the chosen fuel types are taken as the best guesses. Fuel parameters (mass loading σ, height E (m), moisture content (m) and heat of combustion ∆h) used in the front velocity model for these four major classes are presented in Table  1.
Conclusions The coupled code Meso NH/ForeFire aims to be able to simulate large wildfires, solving complex fire-induced flow while implementing a high-resolution front advection method. The fire front velocity model can be parametrized with measurable properties of the fuel and is well adapted to coupled simulation, as it uses instantaneous wind speed just over the fire front to calculate the flame angle. The non-parallel version of the code has previously been used to perform simulations of real wildfires with results that qualitatively match observation in terms of fire dynamics  [9]  and atmospheric chemistry  [53]. The embedded parallel strategy demonstrated in this study ensures that the coupled model will behave in the same way as the atmospheric model and thus will benefit from further improvements.
Most of Python and R scientific packages incorporate compiled scientific libraries to speed up the code and reuse legacy libraries. While several semiautomatic solutions exist to wrap these compiled libraries, the process of wrapping a large library is cumbersome and time consuming. In this paper, we introduce AutoWIG, a Python package that wraps automatically compiled libraries into high-level languages using LLVM/Clang technologies and the Mako templating engine. Our approach is automatic, extensible, and applies to complex C++ libraries, composed of thousands of classes or incorporating modern meta-programming constructs.
Introduction Many scientific libraries are written in low-level programming languages such as Fortran, C and C++. Such libraries entail the usage of the traditional edit/compile/execute cycle in order to produce high-performance programs. This leads to low computer's processing time at the cost of high scientist's coding time. At the opposite, scripting languages such as Matlab, Octave [1, for numerical work], Sage [2, for symbolic mathematics], R [3, for statistical analyses] or Python [4, for general purposes] provide an interactive framework that allows data scientists to explore their data, test new ideas, combine algorithmic approaches and evaluate their results on the fly. However, code executed in these high-level languages tends to be slower that their compiled counterpart. Due to growing interest into data science combined with hardware improvements in the last decades, such high-level programming languages have become very popular in various scientific fields.
Nevertheless, to overcome performance bottleneck in these languages, most scientific packages of scripting languages incorporate compiled libraries available within the scripting language interpreter. For instance, SciPy  [5] , a library for scientific computing in Python, is mainly based on routines implemented in Fortran, C and C++. To access compiled code from an interpreter, a programmer has to write a collection of special wrapper functions (aka wrappers). The role of these functions is to convert arguments and return values between the data representation in each language. Although it is affordable for a library to write a few wrappers, the task becomes tedious if the library contains a large number of functions. Moreover, the task is considerably more complex and time consuming if a library uses more advanced programming features such as pointers, arrays, classes, inheritance, templates, operators and overloaded functions.
Cython  [6] , Boost. Python  [7] , SWIG  [8] , Rcpp  [9]  and F2PY  [10]  are considered as classical approaches for wrapping C, C++ and Fortran libraries to Python, R or other scripting languages but can only be considered as semi-automatic. In fact, while these approaches certainly ease the way of generating wrappers, the process of writing and maintaining wrappers for large libraries is still cumbersome, time consuming and not really designed for evolving libraries. Every change in the library interface implies a change in the wrapper code. Thus, developers have to synchronize two code bases that do not rely on the same kind of knowledge (i. e. , C++ vs wrapper definition). To solve this issue, we provide an automatic approach for wrapping C++ libraries. The critical bottleneck in the construction of an automatic approach for wrapping compiled languages libraries is the need to perform the syntactic analysis of the input code, known as parsing.
Once the code has been parsed, it is possible to analyze its result for code introspection. Code introspection is the ability to examine code components to know what they represent and what are their relations to other code components (e. g. , list all methods for a given class). Introspection of parsed code can therefore be used to automate the generation of wrappers. In the past, some solutions have been developed to automate the wrapping in Python of large C++ libraries such as Py++  [11]  and XDress  [12]. These tools require to write a priori complex scripts. These scripts are then interpreted a posteriori to edit the code abstraction and generate wrappers. Such batch processing approaches require high-level of expertise in these software and limit the ability to supervise or debug the wrapping process.
Section 4 describes the main aspects of AutoWIG's architecture and current implementations. Section 5 presents C++ coding guidelines that must be respected in order to obtain the most automated wrapping workflow. Section 6 presents different results of AutoWIG application including in particular examples for performing partial wrapping of a library, the wrapping of template libraries and the wrapping of dependent libraries using an actual C++ statistical library set case study. Note that, for the sake of simplicity in the remainder of this paper, it is assumed that the low-level programming language in which compiled libraries are written is C++, the high-level programming language for interfacing libraries is Python and, that the wrappers generated are written using the Boost. Python C++ library.
Requirements Consider a scientist who has designed multiple C++ libraries for statistical analysis. He would like to distribute his libraries and decides to make them available in Python in order to reach a public of statisticians but also less expert scientists such as biologists. Yet, he is not interested in becoming an expert in C++/Python wrapping, even if it exists classical approaches consisting in writing wrappers with SWIG or Boost. Python. Moreover, he would have serious difficulties to maintain the wrappers, since this semiautomatic process is time consuming and error prone. Instead, he would like to automate the process of generating wrappers in sync with his evolving C++ libraries. That's what the AutoWIG software aspires to achieve. Building such a system entails achieving some minimal features: C++ parsing In order to automatically expose C++ components in Python, the system requires parsing full legacy code implementing the last C++ standard.
Pythonic interface To respect the Python philosophy, C++ language patterns need to be consistently translated into Python. Some syntax or design patterns in C++ code are specific and need to be adapted in order to obtain a functional Python package. Note that this is particularly sensible for C++ operators (e. g. , (), <, []) and corresponding Python special functions (e. g. , call , lt , getitem , setitem ). Memory management C++ libraries expose in their interfaces either raw pointers, shared pointers or references, while Python handles memory allocation and garbage collection automatically. The concepts of pointer and reference are thus not meaningful in Python. These language differences entail several problems in the memory management of C++ components into Python. A special attention is therefore required for dealing with references (&) and pointers (*) that are highly used in C++.
Dependency management between components The management of multiple dependencies between C++ libraries with Python bindings is required at run-time from Python. C++ libraries tends to have dependencies. For instance the C++ Standard Template Library containers  [13]  are used in many C++ libraries (e. g std::vector, std::set). For such cases, it does not seem relevant that every wrapped C++ library contains wrappers for usual STL containers (e. g. , std::vector< double >, std::set< int >). Moreover, loading in the Python interpreter multiple compiled libraries sharing different wrappers from same C++ components could lead to serious side effects. It is therefore required that dependencies across different library bindings can be handled automatically.
Methodology A major functionality of AutoWIG is its interactivity. Interactive processing have some advantages versus batch processing. In our context, such advantages are that an interactive framework allows developers to look at the abstraction of their code, to test new wrapping strategies and to evaluate their outcomes directly. In such cases, the user must consider the following 3 steps: If an interactive workflow is very convenient for first approaches with AutoWIG, once the wrapping strategies have been chosen, batch mode workflows are of great interest. Note that the usage of the IPython console  [14]  and its %history magic function enable to save an interactive workflow into a Python file that can be executed in batch mode using the python command line.
Plugin architecture The software architecture is based on the concept of plugin (i. e. , a component with a well-defined interface, that can be found dynamically and replaced by another one with the same interface). Implementations can therefore be provided by the system or from a third-party. Plugin architectures are attractive solutions for developers seeking to build applications that are modular, adaptive, and easily extensible. A plugin manager (PM) is a component in charge of discovering and loading plugins that adhere to a specific contract. As stated above, the wrapping process is decomposed into 3 steps. Each step is governed by a specific PM: • The parser PM is in charge of the Parse step. A parser plugin implements syntactic and semantic analyses of code in order to complete an existing ASG.
Generate generator developer Traverses the abstract semantic graph and generates code given code generation rules. Table  1 : Plugin architecture of AutoWIG. Each step of the AutoWIG wrapping workflow is managed by a plugin manager that enables an easy control of the workflow outputs. Considering the finality and underlying complexity of these plugins, implementations responsibilities are shared between AutoWIG developers and end-users. The parser and generator plugins are respectively concerned with compiled and scripting languages admissible bindings. Since such implementations require a high-level of expertise and a variety of tests, they mostly concern AutoWIG developers. On the contrary, controller plugins are library dependent and only require the manipulation of the abstract semantic graph via Python code.
Thus, most of AutoWIG end-users are concerned with controller implementations. manager enables an easy control of plugin implementation (see Section 6. 3 for an example). Parsers. Currently, AutoWIG provides one parser for C++ libraries. Parsing C++ is very challenging and mainly solved by compiler front-ends  [15]  that generate abstract syntax trees (ASTs). There are many benefits in using a compiler front-end for parsing C++ code. In particular, the parser implementation simply uses the compiler front-end for performing syntactic and semantic analyses of code rather than performing itself a custom analysis of an evolving and complex language. Therefore, the implementation mainly consists in AST traversals to complete ASGs, which is a far less challenging problem. Since the development of LLVM  [16]  and Clang  [17]  technologies, the AST, used for the compilation process, is directly available in Python via the libclang Python package.
Controllers. By default, AutoWIG provides a controller for libraries respecting some recommended guidelines (see Section 5 for details): def default_controller(asg, clean=True, **kwargs): asg = refactoring(asg, **kwargs) if clean: asg = cleaning(asg) return asg This default implementation consists of the two following steps: Refactoring The refactoring of the C++ code is simulated in order to have a wrapping compliant with Python rules. In C++, some operators (e. g. , operator+) can be defined at the class scope or at the global scope. But in Python, special methods corresponding to these operators (e. g. , add ) must be defined at the class scope. Therefore during refactoring, all operators defined at the global scope, but that could be defined at the class scope, are moved as a method of the class.
Cleaning The cleaning operation removes useless nodes and edges in the ASG. A library often depends on external libraries and headers. There are therefore a lot of C++ components, defined by external headers, that are not instantiated and used by the C++ code of the actual library. First, in order to remove only these useless nodes, all nodes are marked as removable. Then, nodes defined by the internal library are marked as non-removable. Recursively, all dependencies of nodes marked as non-removable are marked as non-removable. Finally, all nodes still marked as removable are removed from the ASG. Some C++ libraries, such as armadillo  [18] , provide one self-contained header that only includes all library headers. In such cases all C++ components will be marked as external dependency and the clean parameter of the default controller should be set to False.
Generators. Currently, AutoWIG provides one generator for wrapping C++ libraries using the Boost. Python library. AutoWIG could generate wrappers in the C interface that extend the Python interpreter, but this low-level approach does not provide the abstraction needed to consider the requirements presented in Section 2. Thus, there are many benefits in using one of the semi-automatic approaches (e. g. , Boost. Python, SWIG) within wrappers code. In particular, AutoWIG uses the Boost. Python library to propose: • An automatic Python documentation using C++ documentation since documentation strings can be injected directly in wrappers. • A consistent adaptation of C++ patterns to Python thanks to globally registered type coercions, possible manipulation of Python objects in C++, and an efficient overloaded function handling.
• A consistent memory management thanks to the definition of call policies which can be used to handle references and pointers. • An automatic translation of C++ exceptions into Python errors using C++ exceptions handling and conversion into Python errors. • An automatic management of dependencies thanks to automatic crossmodule type conversions. The boost python generator was therefore designed to generate Boost. Python wrappers: def boost_python_generator(asg, nodes, module='. /module. cpp', decorator=None, closure=True, prefix='wrapper_'):. return wrappers Boost. Python uses extensively C++ class templates. However, class templates may use a huge amount of memory that can entail compilation problems. To avoid this kind of problems, our implementation mainly consists in dispatching wrapper code for C++ components (nodes) into different files: Module file A module file is created in the ASG and named according to the module parameter.
Note that enumerators, fields and methods wrappers are included in their parent scope export file. Moreover, in order to prevent name collision in Python, C++ components are wrapped in Python modules corresponding to their C++ scope. Decorator file A decorator file, named according to the decorator parameter, is created in the ASG (if decorator is not set to None). The Boost. Python library does not provide a way to wrap aliases. Moreover, for serialization purposes, member (i. e. , class scoped declarations) classes or enumerations must not be wrapped as class member but as module member. The decorator file therefore contains Python code to define aliases or produce member aliases for member classes or enumerations. Note that, in some cases, programmers want to decorate the C++ like interface into a more common Python interface.
To mark a node as non-exportable, its boost python export property has to be set to False (see Section 6. 2 for an example). Note that the boost python generator does not respect the contract of generator plugins since it requires asg and nodes as inputs, in place of requiring only asg. In fact, this implementation is used in all other generator implementations that only needs to define abstract semantic graph (asg) traversals to compute nodes that will be considered as inputs of the boost python generator: • The boost python internal generator selects all nodes that are declared in headers marked as internal dependency headers. • boost python pattern generator selects all nodes that match a reg-.
If this is not the case, Boost. Python call policies can be set to ensure proper memory management. Use C++ STL containers. In C++, containers can be expressed as C arrays (e. g. , double array  [10] ;) or pointers to arrays (double* ptrarray = array;). However, C++ components (e. g. , variables, functions) that are using C arrays or pointers to arrays are not wrapped by the boost python generator due to ambiguity. In these cases, we recommend to use C++ arrays (e. g. , std::array< double, 10 >) or dynamic arrays (e. g. , std::vector< double >), which can be effectively wrapped using the boost python generator. Derive from std::exception. In C++, exceptions provide a way to react to exceptional circumstances in programs, like runtime errors, by transferring control to special functions called handlers.
The C++ standard library provides a base classstd::exception defined in the <exception> header -especially designed to declare objects to be thrown as exceptions. By default, for a Python interfaced C++ library, Boost. Python translates a C++ exception thrown by wrapped functions or module into a Python RuntimeError. To produce better error messages, AutoWIG ensures that any exception derived from the std::exception class is correctly translated (i. e. , the error raised has the same class name and content). Pay attention to static and const overloading. Let us consider the header presented in Figure  1. We here assume that the library has been wrapped using AutoWIG in an basic Python package. >>> from basic import Overload >>> overload = Overload()  A basic header used for illustrating overloading problems.
The method void staticness(const unsigned int value) (resp. Python void constness() or void nonconstness() const) can be wrapped but as soon as static void staticness(const Overload& overload, const unsigned int value) (resp. void constness() const or void nonconstness()) is also wrapped, it will not be callable in the Python interpreter. Use namespaces. Namespaces prevent name conflicts in large projects. Symbols declared inside a namespace block are placed in a named scope that prevents them from being mistaken for identically-named symbols in other scopes. The usage of a base namespace for each C++ library (e. g. , std, boost) is highly recommended since it ease code introspection with Au-toWIG. Document with Doxygen and Sphinx. For C++ documentation, Doxygen  [20]  is one of the most standard tool for generating formatted, browsable, and printable documentation from annotated sources.
Wrapping a subset of a very large library Sometimes, for a very large library, only a subset of available C++ components is useful for end-users. Wrapping such libraries therefore requires AutoWIG to be able to consider only a subset of the C++ components during the Generate step. The Clang library is a complete C /C++ compiler. Clang is a great tool, but its stable Python interface (i. e. , libclang) is lacking some useful features that are needed by AutoWIG. In particular, class template specializations are not available in the abstract syntax tree. Fortunately, most of the classes that would be needed during the traversal of the C++ abstract syntax tree are not template specializations. We therefore proposed to bootstrap the Clang Python bindings using the libclang parser of AutoWIG. This new Clang Python interface is called Clan-gLite and is able to parse class template specializations.
As for libclang, this interface is proposed only for a subset of the Clang library sufficient enough for proposing the new clanglite parser. In order to wrap a library subset, the user need to define a controller implementation that specifies which C++ components will be considered during the Generate step. The controller implemented is the following: 1. Considering all user-defined types as non-exportable. This is done by setting the boost python export property of classes and enumerations to False (lines 3-6). 2. Considering a subset of all user-defined types as exportable. This is done by first selecting the C++ components of interest (subset) using code introspection (lines 8-13). Then, the boost python export property of all subset components is set to True (lines  [15] [16]. Assuming that the asg already contains all C++ components from the Clang library and that the clanglite controller has been defined in the Python interpreter.