dataesr/scientific-paragraphs-categorization huggingface dataset:
This review of the current status of the HFR global network highlights the major challenges for data production and applications that can be addressed at a global level to properly inform choices to direct the future evolution of HFR networks as coastal ocean observing platforms. In terms of applications, further efforts are needed in the development of novel signal processing methodologies for allowing the operational delivery of other information (e. g. , waves and wind maps) as well as to exploit synergy between HFR and other multi-platform observing systems (e. g. , satellite, gliders, drifters). Secondly, the use of HFR surface-velocity fields for improving operational high-resolution forecast models through data assimilation is emerging strongly. Nevertheless, use of the surface current measurements to improve the model downward through the water column represents an additional challenge  (Paduan and Washburn, 2013) , as well as the combined assimilation of HFR data with satellite altimetry and multiplatform observations.
HFR site sustainability has emerged as a challenge in those countries (e. g. , Canada) where the HFR sites are owned and operated by universities in the context of finite research programs, and also in regions where HFR sites have been operated for a long time and confronted by "aging infrastructure" without renewal of hardware. One of the top priority issues is the maintenance of continued financial support to preserve the infrastructure and core service already implemented, but also funding to extend the networks at diverse national scales for an overall spatial coverage. The need for data standardization, harmonization and integration has also emerged. The future integration of the HFR data from the MARACOOS network into CMEMS-INSTAC in April 2020 (tentative date) could be considered the first step toward this goal.
ACKNOWLEDGMENTS We would like to thank  Zdenka Willis  for the vision to establish the  Global High Frequency Radar Network. We would also like to thank the  NOAA IOOS, RITMARE, JERICO-NEXT, INCREASE, SeaDataCloud, IMPACT ,  SICOMAR-Plus ,  SENER-CONACyT Hidrocarburos programs and Korean Ministry of Ocean and Fisheries. We are very grateful to all the people who kindly provided the information of their radar and related activities.
Model structure A kinetic metabolic model was developed to describe the central carbon metabolism of a microalgae platform, including glycolysis, TCA (tricarboxylic acid) cycle, pentose phosphate pathway, total lipid synthesis, starch synthesis, amino acids metabolism, energy metabolism and biomass synthesis. The metabolic network (Fig. 1 ) was first built according to databases such as KEGG, Meta-Cyc, DiatomCyc, BioCyc as well as from literature  [18, 20, 21]. In this work, Chlorella protothecoides cells were considered as a unique compartment with no specific intracellular compartments such as mitochondria, chloroplast, vacuoles, vesicles and nucleus. Energy metabolism was considered as a global reaction where de novo synthesis and substrate level phosphorylation were combined in a unique pathway.
All the ordinary differential equations of metabolites were provided as in Additional file 1: Table  S1. The ordinary equation for biomass was described by dX dt = V growth * X , listed in Additional file 1: Table  S1  (Eq. 22). Where V growth is the specific growth rate, X is the biomass concentration. The cell specific growth rate V growth was described by Eq. 30 in Table  2. A pro- gram generating automatically the Matlab code and Fig. 1  The model metabolic network for heterotrophic Chlorella protothecoides differential equations for a specific metabolic network of reactions was developed and used (S. Peres and M. Jolicoeur, unpublished). The ordinary differential equations system were performed using Matlab (the MathWorks Inc. , Natick, MA, USA) with the "ode23" solver to get the model simulations result.
Model parameters estimation The model has 77 parameters, which include 34 maximum flux rates, 38 enzyme half-saturated constants, and 5 growth coefficients for the 5 growth precursors contributing to biomass synthesis. Initial metabolite concentrations (i. e. at t = 0) were taken from experimental data, which include 24 intracellular metabolites distributed in 8 pathways covering 30 metabolic reactions  [19]  or from literature (Table  3 ). Initial kinetic parameter values (V max , K m ) for each flux and enzymes in the model were taken within ranges found in the enzyme database BRENDA (http://www. brend a-enzym es. org), and the respective units (mmol/L) were converted to comply with the model (mmol/gDW) by dividing 10 gDW/L biomass obtained in our culture. First estimates of maximal flux rates (V max ) have been calculated from experimental data  [19] , or from BRENDA.
Sensitivity analysis was performed by changing each parameter from -70 to + 150% one at a time while holding others constant. From the Matlab optimization toolbox, the "linsqurfit" sub-routine was used to identify model parameter values. This process of parameter calibration was continued until minimizing the objective function, i. e. the simulated results closely following experimental data. Final parameter values of the model are shown in Table  4. Confidence intervals of estimated parameters were evaluated using the Matlab subroutine "nlparci. m" (Table  4 ). It is clear there is no unique solution for parameter values in such an underdetermined system.
All the flux values were normalized to an uptake flux of 100 mmol g -1 DW h -1 glucose. Red arrows represents the flux direction for the four reversible reactions the enzyme activity. Some reactions or pathways (i. e. their kinetic parameters) such as the maximum specific growth rate, PPP pathway and TCA cycle, showed a low sensitivity level, which suggest these are robust pathways. Final parameter values and the 95% confidence intervals for the sensitive parameters are shown in Table  4. They are all within ranges found in the BRENDA databank.
Acknowledgements The authors are grateful to the  Shandong Provincial Natural Science Foundation  ( ZR2019BC099 ) for the financial support (RX). And are grateful to the " Ressources Aquatiques Québec (RAQ) ", a  collaborative Grant  ( RS-171172 ) from the  "Fonds de recherche du Québec-Nature et technologies (FQRNT)"  for a financial support (MJ, JSD, RT), and to the National Science and  Engineering Council of Canada (NSERC Discovery  Grant No. 093865-RGPIN2014-04329 ) for a financial support (MJ), as well as to  China Postdoctoral Science Foundation  ( 2019M650167 ) for the financial support (RX).
The simulator allows us to simulate two different types of oscillation spectra: i) oscillation spectra computed on the basis of the so-called Universal Pattern by  Mosser et al. (2011)  optionally including mixed-modes following the asymptotic gravity mode spacing  (Mosser et al. 2012b ) and ii) oscillation spectra computed using a given set of theoretical frequencies pre-computed with the ADIPLS pulsation code  (Christensen-Dalsgaard 2008). The instrumental noise level is quantified by carrying out realistic simulations of the instrument at CCD pixel level using the Plato Image Simulator (PIS) for three-month observation sequences. These simulations are performed for different stellar magnitudes, and for both the beginning of life (BOL 4 ) and end of life (EOL 5  ) observation conditions.
The Plato Image Simulator To quantify the instrumental systematic errors, we generate timeseries of small imagettes with the Plato Image Simulator (PIS). This simulator, developed at the LESIA-Observatoire de Paris since the early phases of the PLATO project, has very similar capabilities as the PLATOSim code  (Marcos-Arenal et al. 2014). PIS can simulate imagettes representative of PLATO CCDs. It includes various sources of perturbations, such as shotnoise (photon noise), readout noise, background signal, satellite jitter, long-term drift, smearing, digital saturation, pixel response non-uniformity (PRNU), intra pixel response nonuniformity (IPRNU), charge diffusion, and charge transfer inefficiency (CTI). Since our goal is to quantify systematic errors, we turned off all random sources of noise in our instrumental simulations, except in the calculation of the NSR, see Sect.
Simulation parameters and data sets The flux of each simulated star behaves differently according to their magnitude, position over the CCD, and even position within a pixel (hereafter named intra-pixel position). In order to cover the largest combination of these factors, we use PIS to run 630 artificial star simulations using a combination of: -9 stellar magnitudes (from V=9 to V=13 with a step of 0. 5), -14 focal plane positions over the focal plan (from 1. 41 • to 18. 08 • from the optical centre), -5 intra-pixel positions for each of the 14 focal plane positions. The simulations are carried out using the parameters relevant for BOL and EOL conditions. Thus, regarding EOL simulations, the CTI is enabled and the mean optical transmission is assumed to be lower than the BOL one. The CTI model used by PIS requires specifying the number of trap species and their characteristics in terms of density, release time, and cross sections.
Analysis of systematic errors in terms of PSD We compute the PSD associated with each corrected light-curve, both for the BOL and EOL data sets. Two examples are shown in Fig. 6  at the BOL and the EOL for a star located at a given position in the field of view and at the sub-pixel position P 0 (pixel corner). These PSDs are compared with the PLATO requirements in terms of allowed systematic errors at V=11. At the EOL, the requirements are marginally exceeded in the frequency range [10 µHz -100 µHz]. This is a consequence of the presence of CTI. We stress that we expect to be able to correct for the CTI. However, this correction is not yet fully modelled and hence cannot yet be reliably quantified. Accordingly, the predictions for the EOL have to be considered conservative at this moment. We find that the PSD of the residual light-curve can satisfactory be fitted with a function of the form: I(ν) = H 1 ν 1 ν α 1 + H 2 1 + (2πτ 2 ν) α 2 , ( 33 ) where H 1 , α 1 , H 2 , τ 2 and α 2 are the fitted parameters, and ν 1 = 1/T 1 with T 1 = 90 days (three months).
Simulated stellar oscillation spectra As a preliminary remark, we stress that the goal of the simulator is not to provide state-of-the-art modelling of a given target but rather to be able to mimic the main characteristics of objects of interest. Accordingly, we did not carry out a quantitative and extensive comparison between outputs of our simulator and light-curves (or equivalently PSD) obtained from high-precision photometric observations, from space missions such as CoRoT and Kepler. However, to illustrate the quality and the relevance of the simulated light-curves, we performed a qualitative comparison with Kepler observations. Three Kepler targets were selected according to the quality of the data and their evolutionary status: a main sequence star (16 Cyg B -KIC 12069449), a sub giant (KIC 12508433) and a giant on the Red Giant Branch (KIC 009882316).
6 ) as a result of Charge Transfer Inefficiency (CTI). However, some mitigation options for the CTI are currently under study (e. g. charge injection, increasing the camera shielding). Although the procedure is not yet fully established, existing correction algorithms can be implemented in the context of PLATO (e. g. Short et al. 2013; Massey et al. 2014). The PIS code is however not adapted to generating in a massive way simulated long-duration light-curves (e. g. up to two years in the case of PLATO). This is why a parametric description of the systematic errors expected in the time domain has been derived from the PIS simulations. This model reproduces both the residual long-term flux variations due to the instrument as well as the jumps induced by the mask-updates for those of the targets (the large majority of the targets of sample P5) for which photometry is extracted on-board.
Acknowledgements. This work has benefited from financial support by  CNES  in the framework of its contribution to the PLATO mission. It has made use of data from the  European Space Agency (ESA) mission Gaia  (https: //www. cosmos. esa. int/gaia),processed by the Gaia Data Processing and Analysis Consortium (DPAC, https://www. cosmos. esa. int/web/gaia/dpac/consortium). Funding for the DPAC has been provided by national institutions, in particular the institutions participating in the Gaia Multilateral Agreement. We acknowledge T. Prod'homme and  D. Tiphéne  for the useful discussions we had about various CCD effects. We thank the anonymous referee for his/her remarks which enabled us to improve significantly the simulator and the present article.
The PSLS source code is available for download from the PSLS website (http://psls. lesia. obspm. fr) as well as from Zenodo. org (http://doi. org/10. 5281/zenodo. 2581107). The source code is free: you can redistribute it and/or modify it under the terms of the GNU General Public License (for more details see http://www. gnu. org/licenses). The present paper describes the version 0. 8.
Automatic map generalization is a complex task that is still a research problem and requires the development of research prototypes before being usable in productive map processes. In the meantime, reproducible research principles are becoming a standard. Publishing reproducible research means that researchers share their code and their data so that other researchers might be able to reproduce the published experiments, in order to check them, extend them, or compare them to their own experiments. Open source software is a key tool to share code and software, and CartAGen is the first open source research platform that tackles the overall map generalization problem: not only the building blocks that are generalization algorithms, but also methods to chain them, and spatial analysis tools necessary for data enrichment.
Reproducible Research in Map Generalization There is not a unique way to generalize a map and the past attempts to automate this complex process led to very different prototypes, which most of the time, can be neither compared nor combined. This limitation does not really allow map generalization research to build upon past research: even if we know past proposals of models and algorithms, we cannot reuse the prototypes and their code. Open science can be a solution to this problem by promoting reproducibility of research and collaboration  (Munafò et al. , 2017). Reproducible research requires the availability to other researchers of the data and code used in a published study, which might be challenging regarding the code in computational science  (Peng, 2011) , and regarding both the data  (Ostermann & Granell, 2017)  and the code  (Singleton et al.
, 2016)  in geographical information science. If we go back to map generalization, sharing software components to foster reproducibility is not a new idea  (Edwardes et al. , 2007; Stoter et al. , 2009). Past research mainly focused on the use of web services for map generalization, with the development of the WebGen platform  (Neun & Burghardt, 2005; Edwardes et al. , 2007)  that was further developed and enriched by several research projects  (Foester et al. , 2008; Foester et al. , 2010; Klammer, 2013). The web services provided by the WebGen platform are generalization algorithms and enrichment processes, i. e. the building blocks of an automated generalization process. Other studies then focused on the issue of the orchestration of these web services to build a fully automated process that uses these web services  (Gould, 2012; Regnauld et al.
Platform Architecture The CartAGen platform is a GIS library focused on map generalization, but it was not completely built from scratch. It is built upon the GeOxygene Java library 2   (Bucher et al. , 2012) , which implements OGC/ISO specifications and contains advanced GIS capabilities for research, such as data matching, conflation or data quality assessment. It is also based on very common open source Java libraries, such as JTS 3  for geometry computing, or GeoTools 4  for handling GIS files and coordinate systems. The CartAGen architecture is based on a centralized data schema, following the principles of multiple representation database modeling  (Balley et al. , 2004; Mustière & van Smaalen 2007). Generic feature types are created for the usual map features, e. g. buildings, roads, rivers (Figure  2 ), with attributes that can be useful in a map generalization process (i.
e. building height and nature in Figure  2 ), and attributes that usually describe such features (i. e. the fact that the building can be eliminated at some point of the generalization process in Figure  2 ). With such a centralized schema, algorithms and generalization processed are coded to work on instances of the schema whether they come from national mapping agency data or from OpenStreetMap, they are generic and reusable. The matching of a user dataset to this centralized data schema is done only once when datasets are imported (i. e. use of the delegation design pattern).
Skeletonization / covering Medial axis skeleton,  (Haunert & Sester, 2008) , roundabout collapse Point set hulls Typification Bend schematization  (Lecordix et al. , 1997 )  (Burghardt & Cecconi, 2007) , airports, Kmeans Aggregation  (Savino & Touya, 2017 )  (Regnauld, 1998) ,  (Damen et al. , 2008)  Exaggeration Polygon dilation,  (Mustière, 2001) ,  (Lecordix et al. , 1997)  Displacement Least squares push   (Sester, 2005)  (Ruas, 1998) , gradient descent displacement Enhancement  (Lokhat & Touya, 2016) , agent based squaring Table  1. Generalization algorithms currently implemented in CartAGen. Experiments were carried out to parallelize the algorithms from CartAGen  (Touya et al. , 2017b) , to show that they can be applied to very large datasets, using a third party framework.
Data Enrichment To automate generalization processes, data enrichment methods are essential to characterize the initial data and identify key patterns, spatial relations, or complex features. This is why many data enrichment techniques are available in CartAGen: creating blocks and cities out of roads and buildings, creating road complex features  (Touya, 2010)  such as strokes, roundabouts (Figure  3 ), dual carriageways, or finding groups of aligned buildings. The centralized schema allows the storage of such enrichment as persistent features of the dataset.
CartAGen for Open Science Reproducible research requires the availability to other researchers of the data and code used in a published study. Other researchers should be able to reproduce the experiments to contradict them, extend them, or to compare them to other approaches. CartAGen only applies to the availability of code/methods, and only this part of the topic is discussed here. Ostermann & Granell (2017)  state that we should distinguish reproducibility and replicability. Reproducibility is the possibility to reproduce exactly the same experiments. Replicability is the possibility to reproduce a similar experiment but at a different scale. To enable replicability, pseudo-code and formulas, or the source code are required. So publishing papers with experiments carried out with CartAGen enables replicability, at least regarding the code/method side of the problem.
To enable reproducibility, we need executable tools or precise step-by-step information, which goes beyond the access to source code. Both are possible with CartAGen, but giving a URL link to the source code in CartAGen is not enough to make it reproducible, the code should be given with a step-bystep tutorial to exactly reproduce an experiment. Ostermann & Granell (2017) make another interesting point on the date of the research to reproduce: the older the research is, the harder it is to reproduce or replicate because the code constantly changes and old version might become unavailable. This is the case with CartAGen, and a good practice with reproducibility should be to tag the versions of the code for a given experiment with the DOIs of the papers that used that code.
Simple Access to CartAGen Even if CartAGen is made for a developer use, because of the maturity of the code, a simple access to its functionalities is also enabled. CartAGen can be used with a graphic user interface (GUI) that is quite similar to a GIS interface (Figure  4 ). Geographic data can be imported with the GUI and generalization can be performed using the default menu. This GUI was mainly designed for developer users, but tutorials 7  show how to trigger some algorithms or an agent-based generalization on user data. Another possibility for a simple access to CartAGen is to use a QGIS plugin that runs CartAGen code from QGIS. There are quite few existing plugins, but a tutorial is provided to create a plugin for QGIS in python, for a given CartAGen algorithm.
Using CartAGen in National Mapping Agencies Research in map generalization has long been driven by the needs of National Mapping Agencies (NMA) and for a few years, several automatic processes have been used in production, using commercial software solutions  (Duchêne et al. , 2014). Providing automatic solutions for NMAs is not the purpose of CartAGen platform that is dedicated to research. But CartAGen is already fully integrated with PostGIS, and loosely with QGIS, which are open source software that are used in some NMAs to produce maps. And many of the CartAGen algorithms and processes are not available in the existing commercial software, and could improve the existing automatic productions presented in  (Duchêne et al. , 2014). This is why we believe that automatic processes for NMAs could be built based on CartAGen in the future.
Machine Learning As map generalization is a complex task that requires some specific cartographic knowledge that is not easy to reproduce in a computer program, machine learning techniques were tried in the early days of automated map generalization research  (Weibel et al. , 1995). Since then, it was regularly used for data enrichment or for the orchestration of the generalization process (a good review is available in  (Karsznia & Weibel, 2018) ). The main recent advances in the domain of machine learning are due to the success of deep neural network, and such methods are also being experimented on map generalization problems, with a focus on building generalization for now  (Ma, 2017; Sester et al. , 2018). CartAGen is not meant to be a machine (or deep) learning library as open source libraries such as PyTorch, TensorFlow or Keras that can handle map images as well as other images.
OpenStreetMap Generalization If most generalization processes were designed to make topographic maps with data from national mapping agencies, now OpenStreetMap is becoming the major data source to make topographic maps at multiple scales all over the world. And most existing generalization processes are not really adapted to OSM characteristics, and mainly its heterogeneity of level of detail, accuracy or completeness  (Touya et al. , 2017a). For instance, Figure  6  shows buildings lying inside a river bed because of an inconsistent capture of the features. Here consistency is restored thanks to a least squares adjustment, similar to the models proposed for generalization  (Harrie, 1999; Sester, 2005) , prior to generalization. Figure  6. OSM buildings displaced by least squares to restore some consistency with the river  (Touya et al.