dataesr/scientific-paragraphs-categorization huggingface dataset:
Field observations We use existing field observations for comparison with the SiB4 simulations. Several studies have collected field data in the last 2 decades, and we used those sites where continuous hourly measurements of ecosystem COS fluxes are available for at least a month. The site name abbreviations, their locations, some of their characteristics, and basic information on the observations are summarized in Table  3. The locations of the sites are indicated in Fig. S1  in the Supplement. The measurements represent evergreen needleleaf forest (ENF); deciduous broadleaf forest (DBF); maize (MAI); winter wheat (WWT); and C 3 grasslands (C 3 -GRA), more specifically alpine grassland, prairie grassland, and savannah grassland. All COS observations were made at FLUXNET, ICOS, or AmeriFlux sites with the benefit that additional long-term Table  2.
Production parameters a Uptake parameter b a ± SD b ± SD f CA (pmol m -3 s -1 ) (1 measurements of CO 2 and water exchange  (Pastorello et al. , 2020)  are often available (see Table  S1  in the Supplement for an overview), allowing the evaluation of the SiB4 phenology when COS flux observations do not extend to a full growing season. Most of the ecosystem observations were made using the eddy-covariance (EC) technique. Kohonen et al. (2020)  summarized the different EC processing steps used by the different studies. Only at US-IB2, US-BO1, and for a part of the dataset at US-HA1 (in 2011) are the ecosystem fluxes derived by COS concentration gradients using the flux-profile (FP) technique  (Berkelhammer et al. , 2020; Commane et al. , 2015). The ecosystem fluxes determined by the EC technique can be biased due to storage (typically depletion) of COS in the canopy airspace under limited turbulent mixing.
Measurement datasets also include COS mole fractions above the canopy (except for US-ARM). These measurements have been calibrated against the NOAA-2004 COS calibration scale. Only at US-HA1 are the COS mole fractions not calibrated  (Commane et al. , 2015) , but they are validated against COS flask measurements at the station, which is part of the NOAA flask measurement network  (Montzka et al. , 2007). For further details about the site characteristics and measurement and processing procedures, we refer to the original data publications as reported in Tables  3  and S1  in the Supplement. For evaluation of the model against observations, we calculate the mean bias error (MBE, pmol m -2 s -1 ) and root mean square error (RMSE, pmol m -2 s -1 ) for monthly, daytime, and nighttime average fluxes.
Crop harvesting was included in SiB4, but the exact timing was difficult to simulate due to local weather events and considerations other than crop ripening. For example, at the US-ARM site the winter wheat harvest was on average simulated at DOY 136 for the years 2000-2019, close to the actual moment of harvest in 2012: DOY 145  (Maseyk et al. , 2014). However, for 2012 (the year matching with COS flux observations), the model simulates harvest almost 4 weeks earlier (DOY 118) than was actually the case, possibly because in 2012 the meteorological forcing data prescribed on average 14 % higher daytime temperatures than observed, while in other years they were on average only 3 % higher than observations. For the sites where COS fluxes were only measured in one part of the growing season, we assume that the timings of seasonal patterns in COS assimilation were well captured since seasonal patterns in NEE, GPP, and LE are properly simulated (Figs.
0 pmol m -2 s -1 ), ES-LM1 (6. 9 pmol m -2 s -1 ), and FI-HYY (5. 9 pmol m -2 s -1 ). The small flux values during nighttime make the modelobservation comparison sensitive to the different correction and processing procedures that were used for the different datasets. Ecosystem fluxes were only storage-corrected for FI-HYY and US-HA1. Kooijmans et al. (2017)  showed for FI-HYY that nighttime storage fluxes were on average ∼ 1 pmol m -2 s -1 in summer. Additionally, some datasets are filtered based on a friction velocity threshold, while others are not. Kooijmans et al. (2017)  noted that filtering data based on the friction velocity might bias the data towards higher nighttime COS uptake as the uptake can be expected to be limited by the COS gradient at the leaf boundary layer under low-turbulence conditions.
Given these differences between datasets and the typically large random noise of COS flux measurements, the average underestimation may not be significant overall. Still, we found a substantial underestimation of the nighttime COS uptake at the C 3 -GRA sites AT-NEU and ES-LM1 and an overestimation in summer at the DBF sites US-HA1 and DK-SOR. These biases might point to an inaccurate intercept of the Ball-Berry stomatal conductance model (g 0 , i. e. , when GPP is (near) zero) in SiB4, which is currently set to 10 mmol m -2 s -1 for all PFTs in SiB4, except for C 4 grasslands and crop types (both C 3 and C 4 ) (40 mmol m -2 s -1 ). Observed g 0 values at AT-NEU (10-65 mmol m -2 s -1 ;  Wohlfahrt, 2004)  are mostly higher than the 10 mmol m -2 s -1 used in SiB4 and support the hypothesis that the SiB4 g 0 is too low for this site.
This was consistent with our findings that, on average, SiB4 underestimates COS biosphere fluxes with both a variable and a constant COS mole fraction (Sect. 3. 1. 3). We did not find patterns in α obs that apply to all PFTs in the same way that would have helped to update α in SiB4. However, for DBF and C 3 -GRA sites we observed that the 2-weekly average α obs typically goes down with increasing air temperature for temperatures above ∼ 16 • C (Fig. S13  in the Supplement). This observation requires further investigation from hourly data points and will be further discussed in our recommendations (Sect. 4. 3).
Acknowledgements. We thank everyone that contributed to the collection of data through campaigns as well as the FLUXNET,  Ameri-Flux , and  ICOS network. Specifically , we acknowledge the  Alexander von Humboldt Foundation  for supporting the  MANIP  project with a  Max Planck Research Award  to Markus Reichstein that was used for the collection of ICOS data at ES-LM1. Data collection at FI-HYY was supported by  ICOS Finland  ( 319871 ) and the  Atmosphere and Climate Competence Center (ACCC) Flagship , funded by the  Academy of Finland  (grant number  337549 ). Data from the Sorø beech forest site (DK-SOR) have been measured, evaluated, and provided by  Kim Pilegaard  and  Andreas Ibrom  and the station team. The work was funded by the  Technical University of Denmark (DTU) , the  Independent Research Fund Denmark  ( DFF -1323-00182 ), the  Danish Ministry of Higher Education and Science  ( 5072-00008B ), and the  EU  research infrastructure projects RINGO and ICOS.
Code and data availability. The SiB4 code is available online at https://gitlab. com/kdhaynes/sib4_corral (last access: 22 July 2021). SiB4 simulation output used in this study is available at https://doi. org/10. 5281/zenodo. 5084644. COS campaign data were downloaded from the original data publications as reported in Table 3. Long-term CO 2 flux time series from FLUXNET, AmeriFlux, or ICOS were downloaded from the references listed in Table  S1. Supplement. The supplement related to this article is available online at: https://doi. org/10. 5194/bg-18-6547-2021-supplement.
Most property groups characterise only the state of the photospheric magnetic field. Some, however, characterize the state of the AR corona, either by photospheric proxies or by means of currentfree, potential magnetic field extrapolations (PFEs) or by differences between the photospheric field and that expected by a PFE. The two last columns of Table  1  indicate relevant published work, distinguishing between studies that were directly adopted in the course of the project from additional or previous studies pertinent to some predictors. It should be mentioned that, for many of the properties in Table  1 , estimating uncertainties is nontrivial. For the cases uncertainties exist, mostly in terms of σ-values in fits, these values are provided in the property database. This said, prediction algorithms (Section 2.
Flare association The NOAA/SWPC flare event list data include the universal times (UT) of their start (i. e. , onset), peak, and end, along with the flare magnitude, all obtained by the GOES spacecraft 0. 1 -0. 8 nm soft X-ray channel. Where possible, source ARs are identified from the daily NOAA/SWPC flare event lists, with their morphological properties extracted from the daily NOAA/SWPC SRS reports. NOAA ARs, flaring or not, are linked to the HMI SHARPs and the FLARECAST property database includes information on all ARs located within each SHARP FOV. The process below is followed for each SHARP during its solar disk passage: 1. SHARPs are first checked to determine whether their FOV contains the time-advanced centroid locations of NOAA-numbered ARs. This makes use of the closest SRS report before the SHARP observation, with solar differential rotation taken into account.
2. If any NOAA ARs are assigned to the SHARP, the SWPC flare event list is searched for those NOAA numbers and related flares are associated to all of that SHARP's property database entries. 3. For X-ray flares with no reported NOAA number, locations of co-temporal flares observed in ground-based Hα images (also from the NOAA/SWPC flare event list) are used to determine if the multi-wavelength flare event occurred within the SHARP's FOV (again taking solar differential rotation into account). Positive Hα flare association results in the inclusion of the respective X-ray flare. A very small fraction of flares of GOES class C and above, of the order 0. 1%, seems to miss both criteria above over the analysis period. After all SHARP-associated flares are identified, we extract the following properties for each flare: -F M : GOES peak magnitude (e.
g. , M1. 3) -τ s : Time difference (in seconds) between the SHARP observation time T 0 and the reported flare start time T s (i. e. , τ s = T s -T 0 ) τ p : Time difference (in seconds) between T 0 and the reported flare peak time T p (i. e. , τ p = T p -T 0 ) τ e : Time difference (in seconds) between T 0 and the reported flare end time T e (i. e. , τ e = T e -T 0 ). Figure  6  provides a snapshot of FLARECAST's flare data set and displays the temporal distribution of different flare classes for Solar Cycle 24 (Fig. 6a ), along with their rise time (Fig. 6b ), decay time (Fig. 6c ) and duration (Fig. 6d ) for approximately the same time coverage as that of the property database statistics in Figure  5. Rise/decay times and durations have been provided by NOAA. We consider as eligible flares only those of GOES C-class and above (i.
FLARECAST software architecture The FLARECAST architecture design was driven by the needs for modularity, portability and ability to perform and accommodate different algorithms written in various programming languages. This philosophy is best described by the top-level diagram of Figure  2  in Section 2. The diagram reflects the four processing steps of the FLARECAST pipeline: -Step 1: Acquisition and transformation of data from multiple sources (SDO/HMI & NOAA SWPC -Section 2. 2). -Step 2: Extraction of properties from the data by several algorithms (Section 2. 2). -Step 3: Prediction through implementation of several machine learning algorithms (Section 2. 3). -Step 4: Verification of the generated forecast data products (Section 4). The underlying management infrastructure controls and monitors these algorithms.
Software components The software components, represented by the blue rectangles in Figure  2 , fulfill specific tasks such as data loading, property extraction, machine learning, or verification. Generally, a software component contains several algorithms and each algorithm implements a specific variant of a task. Each property extraction or machine learning method, for example, has its own dedicated algorithm. The management infrastructure orchestrates the execution of the FLARECAST workflow. It launches the extraction algorithms as soon as new observational data arrives. After they are finished, the management infrastructure triggers the flare prediction algorithms. The management infrastructure is implemented as a collection of containers (see Section 2. 4. 6 below). In automated mode, a set of repeatedly executed computer scripts (i.
Data components The blue database symbols in Figure  2  denote individual parts of the FLARECAST data model, hereafter referred to as data components. Within the workflow, every software component (i. e. , every algorithm) reads from several and writes to precisely one data component. Like this, the software components are decoupled from each other and only have to provide a control interface (start, stop) for the management infrastructure. The management infrastructure connects to a dedicated data component for configuration and data logging. Each data component defines a generic interface to read, create, update, and delete data. The read methods include a query language for simple queries. Figure  7  illustrates this process for an example property extraction algorithm.
Docker containers All FLARECAST infrastructure components are implemented as Docker containers. Docker  10  is an open source software ecosystem (i. e. , engine) in which different Docker containers co-exist and function independently. A Docker container can be viewed as a light-weight virtual machine that hosts an arbitrarily configured software environment. This includes custom programming languages and different library versions per container. Each FLARECAST infrastructure component or algorithm is deployed in a dedicated Docker container. These containers can be installed on a high performance cluster as well as on a developer's desktop machine, making it possible to deploy  FLARECAST in different environments at the same time. A schematic of the FLARECAST Docker containers is shown in Figure  8.
Language independence As mentioned already, algorithms may be written in any programming language. This allows to re-use already existing libraries for certain tasks. Currently tested and supported are Python 2. 7 and 3. 0, the Interactive Data Language (IDL) 8. 5 and R. Other languages that can be executed on a Linux system (e. g. , Java, C++ and Perl) are not expected to generate major issues, but we must make clear that we have not systematically tested them.
Data model The design of the data model is balanced between flexible support for different kinds of data structures and strict schema definitions for better interoperability. This can be achieved through a semistructured data model. Its main structures are defined by a traditional table-based, relational data model. Individual entries of the table support weakly-typed data types (i. e. , types supported by weakly-or loosely-typed programming languages, such as C). In this sense, an algorithm can handle data types as simple as numeric values or strings simultaneously with more complex data types, such as arrays, matrices, dictionaries and whole hierarchies of objects. For the weakly-typed data types we rely on the built-in JSON data type of PostgreSQL 9. 6. Algorithms encode their output (e.
Among others, it featured participation by the EASA and NASA's CCMC. This second workshop pointed out that FLARECAST is producing and publishing results that are readily available to be used and validated, and the FLARECAST forecasting service will follow shortly. However, some convenors agreed that, in some respects, the 'fun' for FLARECAST's potential really starts now, since the greater community should think about scientific/operational projects involving the new FLARECAST 'software instrument'. Finally, in view of the strong contribution from EASA in the discussion, it is increasingly clear that aviation agencies (and the aviation industry, naturally) are becoming more engaged in space-weather impacts and associated forecast services. Therefore, the heliophysics community needs to proactively follow up with them to ensure that this opportunity for a meaningful, prolific interaction is not missed.
There were annual press releases in all official languages of the partner countries, while Consortium members were interviewed in numerous occasions by the electronic and printed media based in the partner countries. Much attention was, therefore, paid to contextualized press work to make sure that the project was broadly communicated in all participating countries and beyond. Detailed information on all three communication and dissemination elements of FLARECAST can be found on the project's website, a skeleton diagram of which is provided in Figure  9.
The FLARECAST Infrastructure: Handling and monitoring The software developed within FLARECAST is a computational resource enabling one to apply several machine-learning methods to data available in the FLARECAST property database. The software is object-oriented, with a set of objects for reading and analyzing data formats (i. e. , model learning or prediction), another set for visualizing the results and, finally, another set for storing them in appropriate prediction databases. The software has been designed and written in Python, with the pertinent software modules described in the following sections.
Data monitoring A consistent and as complete as possible coverage of the SDO/HMI archive at MEDOC is important for FLARECAST to fully exploit the JSOC data, along with the ability to promptly download the latest SDO/HMI NRT SHARPs for as long as they are available. As a result, both the archive coverage and download delays had to be monitored. Additional monitoring tools have, therefore, been developed to keep track of both the infrastructure workflow and database coverage.
Download delays monitoring Monitoring of download delays is achieved using the script in the 'delays' directory of the abovementioned Git repository. The observation date and time at which files are available at MEDOC are directly queried from the database, with year and month supplied to the script as external arguments. The output is a plot displaying the download delay (compared to the observation [i. e. , data acquisition] time) as a function of observing time for the selected month. The delay axis spans from 0 hr to 24 hr. Missing data (that could not be downloaded from JSOC) are shown as a 0-hr delay in red, while data downloaded with a delay of more than 24 hr are shown as a 24-hr delay in orange.
Infrastructure and database coverage monitoring To overview and monitor the workflow process and database coverage, the FLARECAST infrastructure provides several viewers, some of which are intended as internal tools. These tools can be found in dedicated git repositories in the INFRA project area 14. The infra viewer allows FLARECAST developers to manually start new processes and to monitor their performance. The property viewer and the prediction viewer allow to visually inspect the distribution and completeness of the data. They help system admins to better assess the quality of the data. In addition to viewers, the FLARECAST infrastructure provides a collection of API routes to analyse the data on a database level (Appendix A). These scripts iterate through the entire data set and report unexpected gaps in text form.
Performance Verification Strategy The entire verification software for the FLARECAST project is contained in the verification engine. py and verification module. py codes in the project's Stash repository 15. The starting point for the software is reading from a JSON-format configuration file. This initializes the algorithm name for the prediction method, the threshold flare intensity of interest, the base issuing time of the forecasts, the length of the forecast window, the latency of the forecast windows from their issuing times, whether magnetic and/or flare history property sets are used and, finally, the start and end date-times for the period undergoing verification. Given an input forecast window length, the software determines which issuing times to be considered for reading prediction 'algorithm config name' entries from the prediction database.
At this point, 'forecast type' and 'source predictions' are left blank as the content depends on whether forecasts are probabilities or classifications; distinction is not possible based only on 'algorithm config name' because some prediction methods generate both types. Classification forecast-observation pairs are then passed into the calc class stats() function in verification module. py, while probability forecastobservation pairs are passed into the equivalent calc prob stats() function. Both return structured results saved directly into the 'data' key at the metadata level of the output structure. Numerous skill scores are then computed for both the probabilistic and the categorical-classification format of forecasts, outlined in more detail below.
The FLARECAST Science Results FLARECAST's scientific outcome relied on the following four pillars: an investigation of new, or a revisit of potentially interesting, flare predictors (Section 5. 1); the application of machine-learning methods to flare forecasting, also enabling feature (i. e. , predictor) ranking in terms of predictor importance (Section 5. 2); exploration of, first, eruptivity studies with synthetic, 3D MHD models (Section 5. 3) and, second, the flare-CME connection (Section 5. 4). This last component shows that, importantly, the FLARECAST AR property database can be meaningfully coupled with CME catalogs such as those of the EU HELCATS project 16  or NASA's DONKI 17  to extend flare forecasting to eruptive flare (i. e. , CME onset) forecasting with expectation values of CME properties.
New and revisited flare predictors In spite of possessing one of the most comprehensive ensembles of flare predictors, FLARECAST also opted to identify additional properties that could assist in flare forecasting. In this respect, subsets of the FLARECAST property (including flare association) database were used and linked to the flaring history of ARs. Promising quantities involved photospheric shear flows  (Park et al. , 2018) , non-neutralized electric currents  (Kontogiannis et al. , 2017) , magnetic gradients  (Kontogiannis et al. , 2018) , and the differential emission measure calculated above ARs  (Gontikakis et al. , 2020). In addition, FLARECAST has taken advantage of the results of  Guerra et al. (2018) , advocating for the joint use of line-of-sight and solar-surface-vertical versions of predictors in machine learning methods, as well as of the results of  McCloskey et al.
(2009) , but at much higher quality (i. e. , spatial resolution, cadence) and with a more detailed sample of NOAA-numbered ARs (i. e. , in terms of observed times/locations, flaring activities and photospheric magnetic properties). Park et al. (2018)  further focused on flaring activity over the next 24 hours, as well as on the waiting time between major flares as a function of the shear-flow properties. We believe that the new results obtained with this improved magnetogram dataset and systematic study warrant additional investigation. The predictive potential of properties related to non-neutralized electric currents in ARs was also investigated. Intense, shear-ridden PILs are exclusive areas of non-neutralized currents that imply the injection of net currents into the corona whose associated non-potential (i.