dataesr/scientific-paragraphs-categorization huggingface dataset:
The interface makes both the simulator and the connectivity-generating library replaceable and therefore gives maximum flexibility to the modeler. In this article we first describe the connection generator interface. As an example of a connectivity-generating library, we then give a brief overview of CSA and of different software libraries that support it using CSA in Python and C++ code. We show how the connection generator interface has been integrated in the NEST simulator (http://www. nest-simulator. org; Gewaltig and Diesmann, 2007) , enabling the use of connection libraries such as CSA, before describing its use from higher software layers, such as the PyNN framework. Finally, we provide benchmarks for different use case scenarios of the interface.
THE CONNECTION GENERATOR INTERFACE To allow users to flexibly choose among simulators and libraries which generate connectivity, we have developed an interface that abstracts the simulator and the connectivity-generating library from each other, making both the simulator and the connectivity description library replaceable. A connectivity-generating library, such as csa or libcsa of section 3. 3, is used to create an object, a connection generator, representing network connectivity. In the case of a CSA library, this object is a connection-set, but it could also be a graph constructed from graph primitives. The connection generator interface provides a C++ level interface to such objects which allows software external to the connectivity-generating library to efficiently iterate through connections represented by the object.
In the example shown in Figure  1 , the connection generator interface is used to combine a Python-scripted simulator with a Python-scripted connectivity-generating library. A connectivity generating object is assembled at the Python level. If libcsa is used, the resulting object will be a C++ object with a Python wrapper (see lower two boxes to the right in the figure). The object is used by a C++ simulator kernel (lower box to the left) to specify network connectivity. By providing connectivity-generating software that implements the connection generator interface as dynamically linked libraries, multiple such libraries can be loaded into the Python runtime environment and used simultaneously without a need to recompile the simulator.
LIBNEUROSIM If the C++ header file for the connection generator interface definition and its supporting code were placed in the simulator or connectivity-generating library source trees, it would be duplicated over simulators or libraries. As new versions of the interface are developed, the situation would quickly become unmanageable. The connection generator interface has the desirable property that it is a symmetric abstraction barrier: it both allows a given simulator to use any library supporting the API and allows the same library to be used from any simulator supporting the API. To create a space in which to put interfaces and other code of generic use for neuronal network simulation software, we have developed the neurosim library (http://software. incf. org/software/libneurosim). More precisely, libneurosim is a software package which currently consists of two main component libraries: libneurosim, providing C++ level support code and libpyneurosim, providing Python support code.
libneurosim provides the ConnectionGenerator interface (Figure  1 , bottom). It also contains a registry for XML parser functions. Different types of connection generators can be described by different XML-based languages. For example, the csa library can serialize connection-set expressions using a MathML-based language. A connectivity-generating library may provide a parser for one or more such languages. Conversely, the same XML-based language might be used by one or more connectivity-generating libraries. The XML parser registry maps XML tags identifying specific languages to specific connection libraries. The interface to the registry consists of three static methods in the connection generator interface: void selectCGImplementation (std::string tag, std::string library): Associate the parent node tag tag with the library library.
IMPLEMENTATIONS There currently exist three implementations of CSA. They internally represent connection-sets as iterators and CSA expressions as trees of such iterators. The original implementation is written in C++ and is part of the SPLIT simulation library  (Djurfeldt et al. , 2005). It was used to specify the connectivity of the KTH cortex model  (Djurfeldt et al. , 2008 )-a model with three hierarchical levels of structure. The second implementation is written in Python and is available as the Python library csa. Here, the aims were 1. to get an easily usable and extensible demonstration of CSA and 2. to experiment with new ways to implement CSA. This implementation has been released as free software under the GPL and is available at the INCF software center (http://software. incf. org/software/csa).
A third implementation in C++, libcsa, is currently under development and will also be released under the GPL. It provides Python bindings such that CSA objects can be formed by Python level expressions with similar syntax as used with the csa library. For further information about this syntax, the reader is referred to the tutorial in the csa package. The benchmarks in this article (section 6) were performed using the latter two implementations in Python and C++, csa and libcsa.
USING CONNECTION GENERATORS IN NEST NEST is a simulator for large networks of point neurons or neuron models with few electrical compartments (http://www. nest-simulator. org; Gewaltig and Diesmann, 2007). It is suited for a broad range of neuronal network modeling approaches and runs on a large variety of computer architectures. NEST is parallelized using OpenMP (OpenMP Architecture Review Board, 2008) and MPI (Message Passing Interface Forum, 1994) and scales well on ordinary desktop computers to large clusters of multi-core processors and supercomputers  (Helias et al. , 2012). The network description is a script, written either in SLI, NEST's built-in simulation language, or in Python, using the Python interface to NEST (PyNEST;  Eppler et al. , 2009). To build a network in NEST, the user first creates the neurons of the network and devices for stimulation and measurement using the Create function and then connects the elements with each other.
TOPOLOGY MODULE To ease the creation of complex networks with spatial structure, NEST provides the Topology Module  (Plesser and Enger, 2013). It supports the user in connecting neurons and initializing synapse parameters based on their topological relationships in the network. In contrast to the CSA, the topology module is very much tailored to building structured networks consisting of layers in NEST with minimal overhead. The CSA has a wider focus in that it is simulator-independent and supports arbitrary connectivity patterns that can also include repetitive elements. We are currently investigating if future versions of the Topology Module can be based on the CSA.
1). In the current implementation, only arities 0 and 2 are supported. CGParse takes a serialized version of a connection generator in the string xml and returns the corresponding ConnectionGenerator object. A special use of this function exists on supercomputers, where Python is often not available on the compute nodes, or where the memory and performance penalty would not be acceptable and a pure SLI-based solution is preferable. CGParseFile takes a file name fname and parses the serialized version of a connection generator contained therein. CGSelectImplementation takes an XML tag tag representing the parent node of a serialized connection generator and the name of a library library to provide a parser for such an XML file. This information determines which library should carry out the parsing for CGParse and CGParseFile.
In order to use the new interface in NEST, the user first has to construct a ConnectionGenerator object. This can be done at the Python level by either using csa or the Python bindings of libcsa (see section 3. 3). When PyNEST is used, this object can be directly given to CGConnect, which wraps the ConnectionGenerator object into a SLI Datum of type connectiongeneratortype that can be handed over to NEST's simulation kernel. It is then iterated at the C++ level in case of libcsa, or by calling back into Python in case of csa. Another way to construct a ConnectionGenerator object is by parsing an XML serialization of the object. Such a serialization could be created at the Python level, created by an external tool, or written by hand. At the SLI level this serialization can then be given to one of the SLI functions CGParse or CGParseFile, which reinstantiate the original object using the functions fromXML or fromXMLFile in the connection generator API.
This object (of type connectiongeneratortype) can be given to SLI's version of the CGConnect function. Note that the step of creating the serialization of the ConnectionGenerator can also be carried out on another machine. In this way, simulations using CSA can be run on machines where Python is not available. Figure  3  shows the different entities in NEST involved in a user call to CGConnect in PyNEST. After setting the masks for the connection generator to tell it which neurons are local and which are remote (see section 2. 1), the NEST kernel iteratively calls next(). This function returns source and target indices, and values for weight and delay if the arity of the connection generator is 2, until there are no more connections. The connections are internally established one by one calling NEST's basic Network::connect() function at the C++ level.
USING CONNECTION GENERATORS IN PyNN PyNN (http://www. neuralensemble. org/PyNN; Davison et al. , 2009)  is a simulator-independent API for describing neuronal networks in Python. Given a PyNN/Python model description, the user can choose which simulator to use without needing to change the model script. This is achieved through a set of simulator backends. Each backend is a Python module that implements the API for a specific simulator, for example by providing a mapping from standard model names and units in PyNN to simulator-specific ones. In PyNN, a neuronal network is built from Populations of neurons and Projections between them. Each Projection is created by a Connector, which knows how to set up the individual connections. Different Connectors exist and allow to set up a variety of different deterministic and probabilistic connection patterns.
To enable them to be simulator-independent, each Connector is implemented in terms of lower-level commands, typically one-to-one or convergent connect functions, available in all simulators. However, because these commands are low-level this approach entails a certain performance penalty due to transfer of source/target lists and connection parameters and function call overhead. To overcome the problem of excessive data transfers between PyNN and the simulator, a backend can supply customized Connector implementations that are more efficient than using the default, simulator-independent implementations. Such custom implementations can be iterated and expanded at the simulator level and thus avoid overhead. Moreover, they allow efficient parallelization at the lower software layers. Prior to the creation of the connection generator interface, however, the limitation of this was that a separate custom implementation had to be written for each PyNN Connector.
The iteration over the connections can then take place at the C++ level in NEST using the connection generator interface (see section 4). This greatly reduces the overhead and thus improves the runtime and scalability of connection generation (see section 6). implementations of CSA (csa, libcsa) scale excellently with slopes around 2 for the random mask, independent of the software layer (C++ or Python) at which the iteration was carried out. However, in Figure  4 , the vertical offsets and the increasing slopes of the curves for the generic CSAConnector which iterates at the Python/PyNN level suggest that the current implementation of this connector together with calls through different software layers to setup individual connections adds a significant overhead to the process of connection generation.
To demonstrate the scalability of the implementations, we carried out both strong and weak scaling benchmarks, using CSA's random mask ρ(p) with a probability p = 0. 1 (Figures  4C, D ). For each of these, the number of MPI processes was varied from 1 to 48. In the strong scaling benchmark (Figure  4C ), the number of MPI processes was varied while keeping the total number of neurons in the network fixed at 48,000. This resulted in approx. 230 million connections being created. It is easily visible that iteration of the CSA object at the Python level in the current PyNN implementation of the original CSAConnector is detrimental to the scalability. In contrast, it is possible to obtain near perfect scaling if the iteration of the CSA object is carried out from the C++ layer. Using the C++ implementation of CSA, it is, however, possible to gain another order of magnitude compared to the Python version.
COMPARISON TO NATIVE INTERFACES To compare the performance of the connection generator interface to more traditional ways of setting up connectivity, we also performed performance and scaling benchmarks of the native interfaces for random connectivity in PyNN and NEST. Note that NEST does not provide a Bernoulli trial based connection scheme such as used by FPC in PyNN and the random mask in CSA (see section 3. 2) and RCC was chosen because it is the function that most closely resembles such a method. The use of RCC results, however, in a bias toward the other methods over NEST, as it requires iterative calls to RCC from the Python level, which entail a certain overhead in SLI, PyNEST and the C++ implementation of RCC itself (data not shown). The population size benchmark (Figure  5A ) again used one MPI process and varied the number of neurons from 10 2 to 10 5 with about one sample per order of magnitude.
SOFTWARE VERSIONS AND BENCHMARK SCRIPTS All benchmarks were using csa revision 119 from http://svn. incf. org/svn/csa, libcsa from an internal git repository (git@wand. pdc. kth. se:libcsa. git, version 3ef2db519a), the development version of PyNN from https://github. com/NeuralEnsemble/PyNN/ (version db76c748cd) and NEST revision r10722 from the internal Subversion repository. The L A T E X sources of this article, the benchmark scripts and all data we obtained are available from https://github. com/mdjurfeldt/pns2csa.
DISCUSSION AND OUTLOOK We have developed and demonstrated a novel way to connect a simulator and external connectivity-generating software through the connection generator interface. It supports dynamic loading of connection generators without the need for recompilation of either simulator or generators. Benchmarks show good scaling when using connection-set algebra libraries from NEST and PyNN through the connection generator interface. The availability of this and associated interfaces lets users flexibly choose a connectivity-generating library independently of the simulator used, and thereby grants greater freedom for describing models. The first version of the interface presented here was intentionally made simple, as a proof of concept, and there are several possible directions of development for its functionality.
Currently, parameters are passed as doubles. This could be generalized to other data types. For parallel simulators, connection generators may need access to the MPI communicator in which case it needs to be passed through the connection generator interface. Instead of using a fixed iteration order, the order could be specified by the simulator. Iteration order could also be unspecified, giving opportunities for optimizing iteration on the part of the connectivity-generating library. In order to maintain backward compatibility as new revisions of the interface are developed, interface versioning could be introduced. One temporary limitation in the current implementations of the NEST ConnectionGeneratorModule and the PyNN CSAConnector is that value sets for the connection generator can only be used if their arity is 0 (no parameters) or 2 (weight and delay).
ACKNOWLEDGMENTS This work was partially done under the  INCF Multiscale Modeling Program. It is partially supported by the  Helmholtz Association: HASB  and portfolio theme SMHB, the  Jülich Aachen Research Alliance (JARA) , the VSR computation time grant  JINB33  on the JUQUEEN supercomputer in Jülich, and  EU  Grant  269921  (BrainScaleS). The authors would like to thank  Randall Munroe  of http://www. xkcd. orgfor granting the permission to use one of his drawings in Figure 3.
Abstract Fire is an important global ecological process that determines the distribution of biomes, with consequences for carbon, water, and energy budgets. The modelling of fire is critical for understanding its role in both historical and future changes in terrestrial ecosystems and the climate system. This study incorporates the process-based prognostic fire module SPITFIRE into the global vegetation model ORCHIDEE, which was then used to simulate the historical burned area and the fire regime for the 20th century. For 2001 For -2006 , the simulated global spatial extent of fire occurrence agrees well with that given by the satellite-derived burned area datasets (L3JRC, GLOB-CARBON, GFED3. 1) and captures 78-92 % of global total burned area depending on which dataset is used for comparison.
The simulated global annual burned area is 329 Mha yr -1 , which falls within the range of 287-384 Mha yr -1 given by the three global observation datasets and is close to the 344 Mha yr -1 given by GFED3. 1 data when crop fires are excluded. The simulated long-term trends of burned area agree best with the observation data in regions where fire is mainly driven by the climate variation, such as boreal  Russia (1920 Russia ( -2009)) , and the US state of  Alaska and Canada (1950-2009). At the global scale, the simulated decadal fire trend over the 20th century is in moderate agreement with the historical reconstruction, possibly because of the uncertainties of past estimates, and because land-use change fires and fire suppression are not explicitly included in the model. Over the globe, the size of large fires (the 95th quantile fire size) is systematically underestimated by the model compared with the fire patch data as reconstructed from MODIS 500 m burned area data.
In this study, we have incorporated the SPITFIRE fire model  (Thonicke et al. , 2010 ) into the global land surface model ORCHIDEE  (Krinner et al. , 2005). This has allowed us to simulate global fire activity during the 20th century, and to perform an in-depth model evaluation of burned area, and fire regime, including fire numbers and fire size. The present study focuses on evaluating the model's performance at simulating the processes of ignition, fire size distribution and burned area. Quantification of fire CO 2 emission as a component of the terrestrial carbon balance will be presented in a companion paper (Part 2). Specifically, the objectives of the present study are: (1) to evaluate the simulated burned area using multiple datasets including satellite-derived burned area data, government fire agency survey data, and historical reconstruction of burned area over the 20th century  (Sects.
Model description The processes and equations of the fire model SPITFIRE, as described by  Thonicke et al. (2010) , were implemented in the vegetation model  ORCHIDEE (Krinner et al. , 2005). The SPITFIRE model operates on a daily time step, consistent with the STO-MATE sub-module in ORCHIDEE, which simulates vegetation carbon cycle processes (photosynthates allocation, litterfall, litter and soil carbon decomposition). The major processes within SPITFIRE are briefly described below with applicable minor modifications (see  Thonicke et al. , 2010  for more detailed information). 1. Potential ignition includes ignitions by both lightning and human activity. Remotely sensed lightning flash counts  (Cecil et al. , 2012)  were obtained from the High Resolution Monthly Climatology of lightning flashes by the Lightning Imaging Sensor-Optical Transient Detector (LIS/OTD) (http://gcmd.
nasa. gov/records/ GCMD_lohrmc. html). The LIS/OTD dataset provides annual mean flash rate over the period of 1995-2000 on a 0. 5 • grid with a monthly time step. This annual data was used each year throughout the simulation. Following  Prentice et al. (2011) , the proportion of lightning flashes that reach the ground with sufficient energy to ignite a fire is taken as 0. 03. This value differs from that in the original SPITFIRE model as implemented in LPJ-DGVM  (Thonicke et al. , 2010) ; there a cloud-toground (CG) flashing ratio of 0. 2 was used, followed by a further ignition efficiency of 0. 04. To estimate potential ignitions by humans, the original Eqs. (  3 ) and (4) in  Thonicke et al. (2010)  were modified for the purpose of unit adjustment, as below: I H = PD × 30. 0 × e -0. 5× √ PD × a(ND)/10 000 (1) where I H is the daily ignition number (1 day propensity of people to produce ignition events; it is a spatially explicit parameter in the  Thonicke et al.
(2010)  LPJ-DGVM implementation, but following  Venevsky et al. (2002) , a(ND) is assumed to be a global constant of 0. 22 in our simulation. -1 km -2 ), The spatial distribution of a(ND) used by  Thonicke et al. (2010)  is given in Supplement Fig. S1. The a(ND) values for many regions are within 50 % of the uniform value used here, although northern Australia is an exception. Test simulations showed that using a uniform a(ND) value rather than the original spatial dataset has little influence on the simulated regional burned area (see Supplement Fig. S2 ). 2. Fire numbers are derived by scaling the potential ignitions (which include both human and lightning ignitions) using the fire danger index (FDI), which is derived by comparing the simulated daily fuel moisture to a Plant Functional Type (PFT) dependent moisture of extinction.
Input dataset and the simulation protocol The six-hourly climate fields used to drive the model were from the CRU-NCEP dataset (http://dods. extra. cea. fr/store/p529viov/cruncep/V4_1901_2012/readme. htm). Population density for the 20th century was retrieved from the History Database of the Global Environment (HYDE) as compiled by the Netherlands Environmental Assessment Agency (http://themasites. pbl. nl/tridion/en/themasites/hyde/download/ index-2. html). years of the fire-disturbed spin-up excluding all crops, for which fires are not simulated). For the current simulation, the vegetation dynamics module of ORCHIDEE was turned off, i. e. , the simulation used a static current-day vegetation distribution map (converted into the 13-PFT map in ORCHIDEE based on the IGBP 1 km vegetation map, http://webmap.
ornl. gov/wcsdown/dataset. jsp?ds_id=930), and no land-cover change was included. Agricultural fires are not simulated in ORCHIDEE, even though the model has two PFTs that approximately represent C3 and C4 crops (but without realistic speciesspecific phenology). Magi et al. (2012)  show that agricultural fire seasons differ significantly from those of natural fires, warranting a special treatment of agricultural fires in global fire modelling  (Li et al. , 2012). Agricultural fires make up a rather small proportion of the total global amount in terms of both burned area (4. 3 % according to the GFED3. 1 dataset) and carbon emissions (less than 2 % according to GFED3. 1). Further, deforestation fires are not explicitly simulated. Evidences show that deforestation fires occur during the "time window" when climate is dry enough to allow complete burning  (van der Werf et al.