dataesr/scientific-paragraphs-categorization huggingface dataset:
, 1997 ), the Regional Ocean Modeling System, ROMS  (Shchepetkin and McWilliams, 2005)  and the Finite Volume Community Ocean Model, FVCOM  (Chen et al. , 2006) , can also be readily configured for new regional applications. All have their own strengths which are largely set according to the model system's development history and the user's familiarity with the system. For example, ROMS was specifically designed as a regional ocean model, and MITgcm has been a model of choice for numerous idealised process studies. On the other hand, FVCOM's unstructured mesh has made it a popular research code choice for multi-scale coastal hydrodynamics. The concepts presented here are intended to be broadly applicable to any modelling system, though the worked examples are implemented within NEMO. NEMO is an ocean modelling framework underpinned by a consortium of five large European research, climate and operational centres.
It is well supported as an international community modelling code and consequently is employed as the ocean component for 9 of the 35 widely used Coupled Model Intercomparison Project Phase 6 (CMIP6) models  (Eyring et al. , 2016 , https://pcmdi. llnl. gov/CMIP6/, last access: 27 July 2022) and is used in the CMS catalogue of freely available marine data products. As a regional model it benefits substantially from these investments of effort. However, its origins in large research and operational centres (where teams focus on specific configurations) has led, quite naturally, to barriers to NEMO being more widely used in regional applications. In our experience, each research question addressed with a regional model configuration requires a subtly different workflow. Sometimes this would be the requirement of different forcing, sometimes the use of ensemble simulations, or sometimes different domain files.
Organised workflows The key route to effective workflow reproducibility and its benefits is via systematic documentation. Central to the structure advocated here is the use of the following. i. Version control repositories for modifications to the standard NEMO source code. We arbitrarily choose git and GitHub. ii. Scripts for configuring parts of the set-up that can be automated and labour-saving. These also reside in the git repositories. iii. Recipes to describe the whole process. It was found that the recipes, which make the whole process transparent from software installation through to assessment and analysis, were especially important in democratising the build process. Even though they took some time to document, the benefit was immediate since multiple scientists and students could independently work on projects without continual reliance on overburdened NEMO specialists.
Documenting the whole process in detail was important since the recipes form a template for subsequent configurations, for which the required modifications are hard to anticipate and could vary in nature from high-performancecomputing (HPC) architecture changes to alternative boundary forcing data. We found the https://github. com (last access: 20 February 2023) platform convenient for workflow management, since the code modifications, scripts and recipes (the latter being in the form of associated wikis) could be co-located under one repository. We also found that the design of an "optimal" template repository was elusive since our various projects and experiments had subtly different requirements, making a universal template unwieldy. We found, therefore, that the most efficient approach to getting the benefits of an accelerated start on new projects was to clone and modify an existing project.
Excellent  (and inspirational)  examples of this workflow include the long-standing and extensive Canadian Salish Sea MEOPAR project documentation. In the UK the requirements have not been geographically focused and so led to an emphasis on building new relocatable configurations, starting with Lighthouse Reef in Belize (https://pynemo. readthedocs. io/en/latest/examples. html, last access: 6 January 2023) as a demonstrator. Subsequently this was iterated to build early versions of the SEAsia repository (https://doi. org/10. 5281/zenodo. 6483231, Polton et al. , 2022a) , which in turn spawned Caribbean (https://doi. org/10. 5281/zenodo. 3228088, Wilson et al. , 2019) , which was modified to have scripts to auto-build and run clean prescribed experiments using data recovery from remote storage (https://jasmin.
ac. uk, last access: 20 February 2023) and compute on a remote HPC resource (https://www. archer. ac. uk, last access: 20 February 2023). These documented experiences underpinned an ability to scale the number of new configurations, spawning configurations in the Bay of Bengal and East Arabian Sea (BoBEAS: https://doi. org/10. 5281/zenodo. 6103525, Polton et al. , 2020a ) and a number of other configurations listed in the Appendix.
There are many software containers to choose from: Docker (https: //www. docker. com, last access: 9 February 2023), Shifter (https://github. com/NERSC/shifter, last access: 9 February 2023), Charliecloud (https://hpc. github. io/charliecloud, last access: 9 February 2023), RunC (https://github. com/ opencontainers/runc, last access: 9 February 2023), Singu-larityCE (https://docs. sylabs. io/guides/3. 10/user-guide/, accessed 9 January 2023), Apptainer (https://apptainer. org, last access: 9 February 2023) and Podman (https://podman. io/, last access: 9 February 2023). Each offers its own advantages and compromises. Two that have gained a lot of traction within the scientific community over recent years are Docker (with a focus on cloud computing and local desktop deployment) and Singularity (in the realm of HPC systems).
Though this is not yet a routine part of our workflow, it has been an essential part of several successful projects, and its use continues to be explored. Example: Docker Docker is an established containerisation software package that effectively streamlines the process of building, launching and managing containers. It originally required root privileges, and message passing was not trivial. However, installing Docker and running a demonstration NEMO container on new machines was so simple that we were able to deliver workshop training to run NEMO configurations on participants' consumergrade laptops. Docker abstracted all the challenges of participants' subtly different Microsoft and Mac software libraries into a single controlled build within a container (with a Linux OS) that they could each install.
Clearly, adopting a recipe approach or even a container approach has much to offer here. Effective scripting with these tools can decrease the expertise level required to reproduce a configuration build. For established community models, such as NEMO, the resulting "configuration-defining" material can be reduced to a number of scripts and a small collection of curated files that specify and execute modifications to standard downloadable source code and datasets. Similarly effective scripting can alleviate the data storage burden associated with making the forcing data available. Atmospheric forcing, in NEMO for example, is specified via namelist definitions and is mediated through weight files that transform the original data onto the target grid. Effective scripting can be used to download the raw forcing files and generate the weight files.
In this way, a configuration with a namelist that specifies a particular forcing can be reproduced with reduced effort. https://doi. org/10. 5194/gmd-16-1481-2023 Geosci. Model Dev. , 16, 1481-1510, 2023 These recommendations require the input and forcing data to be openly available. Of course, this is not always possible if input data are commercially sensitive. This can be problematic to the scientific method, though data that have had some level of processing can sometimes be made available to satisfy both privacy and reproducibility requirements. In summary, there are a number of forcing datasets that are required, which need to be available if the configuration is to be reproducible. By way of example, for a regional operational-type ocean model (e. g. Graham et al. , 2018) , forcings include rivers, lateral boundary conditions (timevarying and tidal harmonics, as appropriate) and surface boundary conditions.
This means that an equivalent as-sessment may be applied to data from different models (e. g. NEMO, ROMS, FVCOM) and comparisons made to observations from any source (e. g. profile data from EN4,  Good et al. , 2013 , or World Ocean Database, Boyer et al. , 2018a, sources). Common diagnostics By defining classes to be built upon Xarray datasets, the powerful data handling capabilities are accessible to the framework. Furthermore, since all data loaded into the framework are of known types and properties, generic diagnostics can be written for each class, which avoids the requirement for hardwired details relating to the data origin. The data-source-specific details are abstracted to the framework. With this separation, contributors can more cleanly add to the diagnostics or the framework according to their interests and skills.
Progress in HPC performance produces simulations with increasingly larger volumes of data. These datasets increasingly require specialised tools to diagnose or manipulate. Standardised workflows for assessment can be built that abstract aspects of the high-performance computing data manipulation into generalised software libraries, thereby jointly freeing up science time whilst also increasing access to a broader range of scientific users. Furthermore, with community engagement in a standardised workflow, a broad range of specialist skills can each contribute their expertise to the mutual benefit of all the users.
Examples The concept of standard or shareable verification, or assessment, tools is not novel. Indeed, the concept is born from demonstrated successes with increased productivity (in more rapidly developing cumbersome NEMO simulations) and increased user engagement (using well-written worked examples to develop NEMO and Python skills). Many package examples exist, each with their specific motivations and specifications. Notable mentions include the following. -ESMValTool (https://www. esmvaltool. org/index. html, last access: 8 February 2023): a community diagnostic and performance metric tool for routine evaluation of Earth system models in CMIP. -COAsT (https://doi. org/10. 5281/zenodo. 7352697, Polton et al. , 2022b) : a diagnostic and assessment toolbox targeted at kilometric-scale regional models leaning heavily on the Xarray and Dask Python libraries  (Hoyer and Hamman, 2017).
The package brings simulations and observations into a common framework to facilitate assessment (see  Byrne et al. , 2022). -Pangeo (https://pangeo. io/, last access: 8 February 2023): a community project promoting open, reproducible and scalable science providing documentation, developing and maintaining software, and deploying computing infrastructure to make scientific research and programming easier. Pangeo offers scientists guides for accessing data and performing analysis using opensource tools such as Xarray, iris, Dask, jupyter and many other packages. nctoolkit (https://nctoolkit. readthedocs. io, last access: 9 February 2023): a comprehensive and computationally efficient Python package for analysing and postprocessing netCDF data. Taking an example from the open-source Python user community, much of the scientific software written is underpinned by open-source packages such as NumPy, for scientific computing  (Harris et al.
These are SEAsia, a 1/12 • South-East Asian domain (https://doi. org/10. 5281/zenodo. 6483231, Polton et al. , 2022a) , SANH, a 1/12 • South Asian domain (https://doi. org/10. 5281/zenodo. 6423211, Jardine et al. , 2022) , and SEVERN-SWOT, a 500 m macro-tidal coastal domain (https://doi. org/10. 5281/zenodo. 7473198, De Dominicis et al. , 2022) (see Fig. 2 ). Each configuration has subtly different requirements and subtly different challenges which influence configuration design, so we cite this range of examples to demonstrate a range of use case scenarios that might be instructive for the reader and to demonstrate the reproducible workflows that we are advocating. (At the time of writing these configurations are all being actively developed. Though the releases pointed to herein are static and valid, they may be improved upon.
Obtain code, compile model executables and build tools This step is to obtain the code and build the required NEMOsupported tools. This process is generic for all configurations. This step is largely software maintenance, rather than natural science, and can be largely automated once a successful workflow has been established. Official NEMO guidance can be found on the consortium web pages (https://sites. nemo-ocean. io/user-guide/setup. html, last access: 8 February 2023). As a necessary precursor to subsequent steps, we provide linked scripts and associated wiki documentation in the SEAsia repository (https://github. com/NOC-MSM/ SEAsia/, last access: 8 February 2023) as a NEMO4 worked example on ARCHER2 (https://www. archer2. ac. uk, last access: 20 February 2023). From experience we note that there is no single "best way" to structure the directory tree, and flexibility should be encouraged according to the simulation or simulations required.
At this point it is worth briefly mentioning how users can implement choices in modelling frameworks, such as NEMO, since some choices are made at compilation and are therefore hard-wired into the executable. In NEMO there are two tiers of hard-wired choices. At the upper tier choices are made that activate NEMO modules, in addition to the core ocean (OCE) physics module, for example enabling ice or biogeochemistry capability (see Sect. 4). These modules are then compiled together. At the lower tier, choices are made within modules about which code blocks need to be compiled. These are set with compiler keys (e. g. https://github. com/NOC-MSM/SEAsia/ blob/master/BUILD_EXE/NEMO/cpp_file. fcm, last access: 8 February 2023) and are used to activate, for example, MPI capability (key_mpp_mpi) and XIOS coupling (key_iomput) for input-output management.
org/10. 5281/zenodo. 6423211 (Jardine et al. , 2022) , https://doi. org/10. 5281/zenodo. 6483231 (Polton et al. , 2022a)  and https://doi. org/10. 5281/zenodo. 7473198 (De Dominicis et al. , 2022)  domains. For these new configurations, initial tests were conducted to ensure that horizontal pressure gradient errors were acceptable and that the tides were simulated accurately. Having addressed any emergent problems with these tests, additional complexity can be sequentially added: realistic initial conditions, realistic temperature, salinity and velocity open boundaries, meteorological forcing and finally freshwater forcing. In summary, the steps to create the domain file are to first create a set of coordinates for the target grid and then make a bathymetry for these coordinates. Finally, extend the domain in the z direction with the chosen types of vertical coordinates to complete the 3D discretisation of the domain.
Flood filling prior to interpolation (lateral filling of all land points with nearest-neighbour wet-point values) and downfilling isolated canyons (using e. g. SOSIE tools (https: //github. com/brodeau/sosie, last access: 27 May 2022) can address issues of bathymetric representation following interpolation. Additional smoothing of tracer fields may also be required if, for example, new straits are opened by the child grid. Furthermore, the representation of the ocean interior might be different between the two grids. For example, a pycnocline might be poorly represented between two thick levels in the parent grid, but how should this "step" be represented in a finer-resolution child with increased vertical resolution? Whatever method scheme is chosen, it is likely therefore that some spin-up will be required to let finescale features evolve.
While the former is useful in idealised set-ups, unstructured boundaries enable complex geometries defined by a supplied coordinates file. In cases where different boundaries have different requirements, it is possible to define multiple sets of unstructured open boundaries that can use different namelist options and datasets. The namelist is organised so that boundary conditions are separated into the 2D depth mean velocities and sea surface height, the 3D depth-dependent velocities (perturbations from the depth mean) and the 3D tracer fields. Tidal harmonics can also be specified as part of the 2D fields. Following the principle of building up complexity, it is worth configuring the open boundaries for the depth mean velocities first. This can include tidal harmonic forcing. The choice of boundary condition, for the 2D velocities, is primarily a choice of which radiation condition to use (e.
Areas where the boundary intersects the continental margin are particular areas of concern because the sloping bathymetry can act as a wave guide for spurious variability. A further consideration is the effect on non-physical aspects of the model, such as biogeochemistry (see Sect. 4. 1). High vertical velocities at the boundary may not be apparent due to flow relaxation at the boundary. However, tracers that are not relaxed at the boundary will feel the effect of spurious vertical currents. Following the above guidance to build sequentially, whereby complexity is incrementally introduced, it can be instructive to include open-boundary conditions with a sequence of developments. Our workflows lean heavily on the PyNEMO community Python tool (https://github. com/ NOC-MSM/PyNEMO, last access: 4 July 2022).
, 2015). Alternatively, if all the atmospheric fluxes are known, these can be supplied directly as surface boundary conditions. In addition to choosing the appropriate source and type of surface boundary condition, there are a few additional considerations to be borne in mind when preparing the atmospheric forcing dataset for a target child model that has different spatial or temporal discretisations from the parent. (1) Calendar stretching (e. g. 3 h forcing on a 360 d calendar being mapped to a Gregorian calendar). (  2 ) Land-sea masks can differ between the parent atmospheric grid and the child ocean grid. This is especially problematic when a coarse parent grid is naively interpolated onto a finer child grid. The mismatch in coastlines results in misrepresentation of near-coast heat fluxes and sea breeze dynamics but can be alleviated using flood-filling techniques whereby extrapolation and interpolation are applied separately to land points and sea points, though problems can still arise if the child grid has islands that simply do not exist in the parent grid.
Finally, subtle differences in the atmospheric data expected by the bulk formulae are a common source of error (e. g. reference levels, specific versus relative humidity, https://doi. org/10. 5194/gmd-16-1481-2023 Geosci. Model Dev. , 16, 1481-1510, 2023 net versus downward long-wave and short-wave radiation). So, as is often the case when re-purposing a complex system by modification, "trust but verify". A worked example is given in the SEVERN-SWOT repository using ERA5 surface forcing data (data access: https://www. ecmwf. int/en/ forecasts/dataset/ecmwf-reanalysis-v5, last access: 9 February 2023). The documentation includes these global data being cut down and manipulated for use in forcing a regional configuration and then running the model with one-way meteorological forcing.
Terrestrial river forcing This aspect of configuring a regional model is uniquely challenging: river flow data typically come from gauges, which are typically far upstream from the model's coastal grid point, or from hydrological models, where the data are gridded but not necessarily at fine enough resolution for the target application (e. g. many global products have a 1/4 • resolution). Pre-processing freshwater data can be particularly time-consuming, so it is worth giving careful consideration to design choice options at the outset. Where possible, consistent atmospheric precipitation and riverine data are preferred for consistent freshwater budgets. For example, the JRA-55  (Tsujino et al. , 2018)  and COREv2  (Large and Yeager, 2009)  datasets have an accompanying freshwater river dataset.
However, while consistent forcing is desirable, a dataset with a range of consistent variables may have lower accuracy than e. g. a region-specific flow-only dataset. In some strongly forced applications, forcing accuracy in specific variables may be more important than consistency across all forcing variables. See the SANH repository for an example that generates river forcing from different sources and Sect. 4. 1. 3 for specific guidance on constructing riverine biogeochemical fluxes. Having identified the data sources and the corresponding model grid points for freshwater inputs (itself a heavily labour-intensive exercise that defies straightforward automation), there are further choices to be made regarding the implementation. (i) How is the freshwater distributed horizontally? If the coastal outflow is a river delta, the freshwater load should be distributed between the tributary channels.
The worked example in the SEAsia repository details how rivers fluxes were taken from the JRA-55 dataset  (Tsujino et al. , 2018)  and mapped to the nearest coastal grid point. Subtleties for large rivers include (i) avoiding placement of domain boundaries near large river outflows and (ii) laterally spreading the coastal source points to represent deltas and also to avoid unrealistic numerical issues if outflow values are locally too large.
ncei. noaa. gov/products/world-ocean-atlas, last access: 9 February 2023), containing monthly gridded inorganic nutrients and dissolved oxygen in the upper 800 m and annual values deeper, and GLODAP  (Olsen et al. , 2016 , https://www. glodap. info, last access: 9 February 2023), containing annual gridded dissolved inorganic carbon and total alkalinity as well as inorganic nutrients and dissolved oxygen. Modelled products, such as CMS global models, using PISCES, contain simulated nutrients and phytoplankton fields. For regionally specific products, data may be available from regional consortia and programmes (e. g. North Sea Biogeochemical Climatology, NSBC (Hinrichs et al. , 2017, https://www. cen. uni-hamburg. de/en/icdc/ data/ocean/nsbc. html, last access: 9 February 2023), and the EMODnet portal  Lear et al.
Initial conditions It is generally preferable to initialise the biogeochemistry in low biological productivity periods. This reduces model uncertainty as the phytoplankton and zooplankton are at their lowest values and nutrients are mainly present in their inorganic form. In the absence of appropriate data, distributions of phytoplankton functional groups can be estimated from measured chlorophyll. Other pelagic variables for which detailed data are not available (e. g. concentrations of dissolved organic carbon, calcite and bacteria) are typically initialised to constant values, ideally derived from any available observational data in the region. Distributions of benthic variables are often difficult to estimate as there are usually few data available. Climatological profiles can be used but may not be representative of the target region of interest.
Biogeochemical models used in regional configurations Here we highlight just three biogeochemical models with which we have experience and that span a range of complexities in biogeochemical process representation. European Regional Seas Ecosystem Model (ERSEM)-specific considerations ERSEM  (Butenschön et al. , 2016 , https://github. com/ pmlmodelling/ersem, last access: 9 February 2023) was originally designed as a marine biogeochemistry and lowertrophic-level model for the temperate European shelf seas  (Baretta et al. , 1995; Wakelin et al. , 2020). However, it has found application in global settings  (de Mora et al. , 2016)  as well as in regional configurations in the other parts of the world ocean using a variety of hydrodynamic models, e. g. in the Mediterranean  (Kay et al. , 2020) , Arabian  (Sankar et al.