diff --git a/conda.recipe/meta.yaml b/conda.recipe/meta.yaml index bd08baa..02561d1 100644 --- a/conda.recipe/meta.yaml +++ b/conda.recipe/meta.yaml @@ -1,6 +1,6 @@ package: name: nanofase - version: {{ GIT_DESCRIBE_TAG }} + version: 0.0.4 source: path: .. @@ -22,4 +22,10 @@ requirements: about: home: https://nerc-ceh.github.io/nanofase - license: BSD 3 Clause \ No newline at end of file + license: BSD 3 Clause + summary: Nanomaterial exposure in the environment + description: | + NanoFASE is a multimedia spatiotemporal model of nanomaterial + fate and exposure in the environment. + dev_url: https://github.com/nerc-ceh/nanofase + doc_url: https://nerc-ceh.github.io/nanofase \ No newline at end of file diff --git a/doc/output.md b/doc/output.md index 4ef5bee..2059d60 100644 --- a/doc/output.md +++ b/doc/output.md @@ -1,6 +1,6 @@ -# Data output +# Output data -Data output is handled by the [`DataOutput`](../src/Data/DataOutputModule.f90) class and configured in the [model config file](../config/config.example.nml). Output is to a series of text files: +Data output is handled by the [`DataOutput`](../src/Data/DataOutputModule.f90) class and configured in the [model config file](https://github.com/NERC-CEH/nanofase/blob/develop/config.example/config.example.nml). Output is to a series of text files: - `summary.md`: A plain-text summary of the model simulation, including compartmental mean PECs. These means are simply a summary of what is output in the following CSV files. - `output_water.csv`: Output data for every waterbody. @@ -11,7 +11,7 @@ Data output is handled by the [`DataOutput`](../src/Data/DataOutputModule.f90) c ## Configuration -The `&output` group in the [model config file](../config.example/config.example.nml) is responsible for configuring data output. The following options are available: +The `&output` group in the [model config file](https://github.com/NERC-CEH/nanofase/blob/develop/config.example/config.example.nml) is responsible for configuring data output. The following options are available: - `write_metadata_as_comment`: Should metadata (largely column descriptions) be writen to the header of each CSV file as `#` delimited comments? Top tip: If you turn metadata on and are using Pandas to read the data, then make sure to use the `comment` argument when reading the CSV: `df = pd.read_csv('output_water.csv', comment='#')`. *Defaults to true.* - `include_waterbody_breakdown`: For surface waters, should data for each waterbody be output, or should it be aggregated to grid cell level? *Defaults to true.* diff --git a/docs/_config.yml b/docs/_config.yml index 106705c..59d7eed 100644 --- a/docs/_config.yml +++ b/docs/_config.yml @@ -3,7 +3,7 @@ title: NanoFASE author: Sam Harrison -copyright: "2022" +copyright: "2024" logo: logo.png # Force re-execution of notebooks on each build. diff --git a/docs/_toc.yml b/docs/_toc.yml index a591d4b..633755c 100644 --- a/docs/_toc.yml +++ b/docs/_toc.yml @@ -11,8 +11,13 @@ parts: - file: getting-started/test-scenario - caption: Users chapters: - - file: users/example-workflows + - file: users/input-data + sections: + - file: users/nanofase-data + - file: users/netcdf-namelist-input + - file: users/parameter-reference - file: users/output + - file: users/example-workflows - file: users/temporal-period - file: users/batch - file: users/checkpointing @@ -26,4 +31,7 @@ parts: - caption: Developers chapters: - file: developers/conventions - - file: developers/io-units \ No newline at end of file + - file: developers/io-units + - caption: Reference + chapters: + - file: references \ No newline at end of file diff --git a/docs/img/flowdir.gif b/docs/img/flowdir.gif new file mode 100644 index 0000000..9a63523 Binary files /dev/null and b/docs/img/flowdir.gif differ diff --git a/docs/references.bib b/docs/references.bib index 783ec6a..8c5e64e 100644 --- a/docs/references.bib +++ b/docs/references.bib @@ -1,56 +1,143 @@ --- --- -@inproceedings{holdgraf_evidence_2014, - address = {Brisbane, Australia, Australia}, - title = {Evidence for {Predictive} {Coding} in {Human} {Auditory} {Cortex}}, - booktitle = {International {Conference} on {Cognitive} {Neuroscience}}, - publisher = {Frontiers in Neuroscience}, - author = {Holdgraf, Christopher Ramsay and de Heer, Wendy and Pasley, Brian N. and Knight, Robert T.}, - year = {2014} -} - -@article{holdgraf_rapid_2016, - title = {Rapid tuning shifts in human auditory cortex enhance speech intelligibility}, - volume = {7}, - issn = {2041-1723}, - url = {http://www.nature.com/doifinder/10.1038/ncomms13654}, - doi = {10.1038/ncomms13654}, - number = {May}, - journal = {Nature Communications}, - author = {Holdgraf, Christopher Ramsay and de Heer, Wendy and Pasley, Brian N. and Rieger, Jochem W. and Crone, Nathan and Lin, Jack J. and Knight, Robert T. and Theunissen, Frédéric E.}, - year = {2016}, - pages = {13654}, - file = {Holdgraf et al. - 2016 - Rapid tuning shifts in human auditory cortex enhance speech intelligibility.pdf:C\:\\Users\\chold\\Zotero\\storage\\MDQP3JWE\\Holdgraf et al. - 2016 - Rapid tuning shifts in human auditory cortex enhance speech intelligibility.pdf:application/pdf} -} - -@inproceedings{holdgraf_portable_2017, - title = {Portable learning environments for hands-on computational instruction using container-and cloud-based technology to teach data science}, - volume = {Part F1287}, - isbn = {978-1-4503-5272-7}, - doi = {10.1145/3093338.3093370}, - abstract = {© 2017 ACM. There is an increasing interest in learning outside of the traditional classroom setting. This is especially true for topics covering computational tools and data science, as both are challenging to incorporate in the standard curriculum. These atypical learning environments offer new opportunities for teaching, particularly when it comes to combining conceptual knowledge with hands-on experience/expertise with methods and skills. Advances in cloud computing and containerized environments provide an attractive opportunity to improve the effciency and ease with which students can learn. This manuscript details recent advances towards using commonly-Available cloud computing services and advanced cyberinfrastructure support for improving the learning experience in bootcamp-style events. We cover the benets (and challenges) of using a server hosted remotely instead of relying on student laptops, discuss the technology that was used in order to make this possible, and give suggestions for how others could implement and improve upon this model for pedagogy and reproducibility.}, - booktitle = {{ACM} {International} {Conference} {Proceeding} {Series}}, - author = {Holdgraf, Christopher Ramsay and Culich, A. and Rokem, A. and Deniz, F. and Alegro, M. and Ushizima, D.}, - year = {2017}, - keywords = {Teaching, Bootcamps, Cloud computing, Data science, Docker, Pedagogy} -} - -@article{holdgraf_encoding_2017, - title = {Encoding and decoding models in cognitive electrophysiology}, - volume = {11}, - issn = {16625137}, - doi = {10.3389/fnsys.2017.00061}, - abstract = {© 2017 Holdgraf, Rieger, Micheli, Martin, Knight and Theunissen. Cognitive neuroscience has seen rapid growth in the size and complexity of data recorded from the human brain as well as in the computational tools available to analyze this data. This data explosion has resulted in an increased use of multivariate, model-based methods for asking neuroscience questions, allowing scientists to investigate multiple hypotheses with a single dataset, to use complex, time-varying stimuli, and to study the human brain under more naturalistic conditions. These tools come in the form of “Encoding” models, in which stimulus features are used to model brain activity, and “Decoding” models, in which neural features are used to generated a stimulus output. Here we review the current state of encoding and decoding models in cognitive electrophysiology and provide a practical guide toward conducting experiments and analyses in this emerging field. Our examples focus on using linear models in the study of human language and audition. We show how to calculate auditory receptive fields from natural sounds as well as how to decode neural recordings to predict speech. The paper aims to be a useful tutorial to these approaches, and a practical introduction to using machine learning and applied statistics to build models of neural activity. The data analytic approaches we discuss may also be applied to other sensory modalities, motor systems, and cognitive systems, and we cover some examples in these areas. In addition, a collection of Jupyter notebooks is publicly available as a complement to the material covered in this paper, providing code examples and tutorials for predictive modeling in python. The aimis to provide a practical understanding of predictivemodeling of human brain data and to propose best-practices in conducting these analyses.}, - journal = {Frontiers in Systems Neuroscience}, - author = {Holdgraf, Christopher Ramsay and Rieger, J.W. and Micheli, C. and Martin, S. and Knight, R.T. and Theunissen, F.E.}, - year = {2017}, - keywords = {Decoding models, Encoding models, Electrocorticography (ECoG), Electrophysiology/evoked potentials, Machine learning applied to neuroscience, Natural stimuli, Predictive modeling, Tutorials} -} - -@book{ruby, - title = {The Ruby Programming Language}, - author = {Flanagan, David and Matsumoto, Yukihiro}, - year = {2008}, - publisher = {O'Reilly Media} +@article{lazar_2010, + title = {An assessment of the fine sediment dynamics in an upland river system: {INCA}-{Sed} modifications and implications for fisheries}, + volume = {408}, + issn = {0048-9697}, + shorttitle = {An assessment of the fine sediment dynamics in an upland river system}, + url = {http://www.sciencedirect.com/science/article/pii/S0048969710001749}, + doi = {10.1016/j.scitotenv.2010.02.030}, + abstract = {There is a need for better links between hydrology and ecology, specifically between landscapes and riverscapes to understand how processes and factors controlling the transport and storage of environmental pollution have affected or will affect the freshwater biota. Here we show how the INCA modelling framework, specifically INCA-Sed (the Integrated Catchments model for Sediments) can be used to link sediment delivery from the landscape to sediment changes in-stream. INCA-Sed is a dynamic, process-based, daily time step model. The first complete description of the equations used in the INCA-Sed software (version 1.9.11) is presented. This is followed by an application of INCA-Sed made to the River Lugg (1077km2) in Wales. Excess suspended sediment can negatively affect salmonid health. The Lugg has a large and potentially threatened population of both Atlantic salmon (Salmo salar) and Brown Trout (Salmo trutta). With the exception of the extreme sediment transport processes, the model satisfactorily simulated both the hydrology and the sediment dynamics in the catchment. Model results indicate that diffuse soil loss is the most important sediment generation process in the catchment. In the River Lugg, the mean annual Guideline Standard for suspended sediment concentration, proposed by UKTAG, of 25mgl−1 is only slightly exceeded during the simulation period (1995–2000), indicating only minimal effect on the Atlantic salmon population. However, the daily time step simulation of INCA-Sed also allows the investigation of the critical spawning period. It shows that the sediment may have a significant negative effect on the fish population in years with high sediment runoff. It is proposed that the fine settled particles probably do not affect the salmonid egg incubation process, though suspended particles may damage the gills of fish and make the area unfavourable for spawning if the conditions do not improve.}, + number = {12}, + journal = {Science of The Total Environment}, + author = {Lazar, Attila N. and Butterfield, Dan and Futter, Martyn N. and Rankinen, Katri and Thouvenot-Korppoo, Marie and Jarritt, Nick and Lawrence, Deborah S. L. and Wade, Andrew J. and Whitehead, Paul G.}, + month = may, + year = {2010}, + keywords = {Atlantic salmon, INCA, Lugg, Process-based model, Sediment, Semi-distributed}, + pages = {2555--2566} +} + +@article{zhiyao_2008, + title = {A simple formula for predicting settling velocity of sediment particles}, + volume = {1}, + issn = {1674-2370}, + url = {http://www.sciencedirect.com/science/article/pii/S167423701530017X}, + doi = {10.1016/S1674-2370(15)30017-X}, + abstract = {Based on the general relationship described by Cheng between the drag coefficient and the Reynolds number of a particle, a new relationship between the Reynolds number and a dimensionless particle parameter is proposed. Using a trial-and-error procedure to minimize errors, the coefficients were determined and a formula was developed for predicting the settling velocity of natural sediment particles. This formula has higher prediction accuracy than other published formulas and it is applicable to all Reynolds numbers less than 2×105.}, + number = {1}, + urldate = {2017-05-23}, + journal = {Water Science and Engineering}, + author = {Zhiyao, Song and Tingting, Wu and Fumin, Xu and Ruijie, Li}, + month = mar, + year = {2008}, + keywords = {sediment transport, sediment particle, settling velocity, spherical particle, trial-and-error method}, + pages = {37--43} +} + +@article{fekete_2001, + title = {Scaling gridded river networks for macroscale hydrology: {Development}, analysis, and control of error}, + volume = {37}, + copyright = {Copyright 2001 by the American Geophysical Union.}, + issn = {1944-7973}, + shorttitle = {Scaling gridded river networks for macroscale hydrology}, + url = {https://onlinelibrary.wiley.com/doi/abs/10.1029/2001WR900024}, + doi = {10.1029/2001WR900024}, + abstract = {A simple and robust river network scaling algorithm (NSA) is presented to rescale fine-resolution networks to any coarser resolution. The algorithm was tested over the Danube River basin and the European continent. Coarse-resolution networks, at 2.5, 5, 10, and 30 min resolutions, were derived from higher-resolution gridded networks using NSA and geomorphometric attributes, such as river order, shape index, and width function. These parameters were calculated and compared at each resolution. Simple scaling relationships were found to predict decreasing river lengths with coarser-resolution data. This relationship can be used to correct river length as a function of grid resolution. The length-corrected width functions of the major river basins in Europe were compared at different resolutions to assess river network performance. The discretization error in representing basin area and river lengths at coarser resolutions were analyzed, and simple relationships were found to calculate the minimum number of grid cells needed to maintain the catchment area and length within a desired level of accuracy. This relationship among geomorphological characteristics, such as shape index and width function (derived from gridded networks at different resolutions), suggests that a minimum of 200–300 grid cells is necessary to maintain the geomorphological characteristics of the river networks with sufficient accuracy.}, + language = {en}, + number = {7}, + urldate = {2024-06-19}, + journal = {Water Resources Research}, + author = {Fekete, Balázs M. and Vörösmarty, Charles J. and Lammers, Richard B.}, + year = {2001}, + note = {\_eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1029/2001WR900024}, + pages = {1955--1967} +} + +@article{arvidsson_2011, + title = {Challenges in {Exposure} {Modeling} of {Nanoparticles} in {Aquatic} {Environments}}, + volume = {17}, + issn = {1080-7039}, + url = {https://doi.org/10.1080/10807039.2011.538639}, + doi = {10.1080/10807039.2011.538639}, + abstract = {Managing the potential environmental risks of nanoparticles requires methods to link nanoparticle properties with macro-scale risks. This study outlines challenges in exposure modeling of nanoparticles in aquatic environments, such as the role of natural organic matter, natural colloids, fractal dimensions of agglomerates, coatings and doping of particles, and uncertainties regarding nanoparticle emissions to aquatic environments. The pros and cons of the exposure indicators mass concentration, particle number concentration, and surface area are discussed. By applying colloid chemistry kinetic equations describing particle agglomeration and sedimentation for the case of titanium dioxide nanoparticles, a limited exposure assessment including some of the factors mentioned is conducted with particle number concentration as the exposure indicator. The results of the modeling indicate that sedimentation, shear flows, and settling are of less importance with regard to particle number based predicted environmental concentrations. The inflow of nanoparticles to the water compartment had a significant impact in the model, and the collision efficiency (which is affected by natural organic matter) was shown to greatly affect model output. Implications for exposure modeling, regulation, and science are discussed. A broad spectrum of scientific disciplines must be engaged in the development of exposure models where nano-level properties are linked to macro-scale risk.}, + number = {1}, + urldate = {2020-04-30}, + journal = {Human and Ecological Risk Assessment: An International Journal}, + author = {Arvidsson, Rickard and Molander, Sverker and Sandén, Björn A. and Hassellöv, Martin}, + month = jan, + year = {2011}, + keywords = {environmental risk assessment, fate modeling, nanoparticles, titanium dioxide}, + pages = {245--262} +} + +@article{tufenkji_2004, + title = {Correlation {Equation} for {Predicting} {Single}-{Collector} {Efficiency} in {Physicochemical} {Filtration} in {Saturated} {Porous} {Media}}, + volume = {38}, + issn = {0013-936X}, + url = {https://doi.org/10.1021/es034049r}, + doi = {10.1021/es034049r}, + abstract = {A new equation for predicting the single-collector contact efficiency (η0) in physicochemical particle filtration in saturated porous media is presented. The correlation equation is developed assuming that the overall single-collector efficiency can be calculated as the sum of the contributions of the individual transport mechanismsBrownian diffusion, interception, and gravitational sedimentation. To obtain the correlation equation, the dimensionless parameters governing particle deposition are regressed against the theoretical value of the single-collector efficiency over a broad range of parameter values. Rigorous numerical solution of the convective−diffusion equation with hydrodynamic interactions and universal van der Waals attractive forces fully incorporated provided the theoretical single-collector efficiencies. The resulting equation overcomes the limitations of current approaches and shows remarkable agreement with exact theoretical predictions of the single-collector efficiency over a wide range of conditions commonly encountered in natural and engineered aquatic systems. Furthermore, experimental data are in much closer agreement with predictions based on the new correlation equation compared to other available expressions.}, + number = {2}, + urldate = {2020-06-15}, + journal = {Environmental Science \& Technology}, + author = {Tufenkji, Nathalie and Elimelech, Menachem}, + month = jan, + year = {2004}, + note = {Publisher: American Chemical Society}, + pages = {529--536} +} + +@article{meesters_2014, + title = {Multimedia {Modeling} of {Engineered} {Nanoparticles} with {SimpleBox4nano}: {Model} {Definition} and {Evaluation}}, + volume = {48}, + issn = {0013-936X}, + shorttitle = {Multimedia {Modeling} of {Engineered} {Nanoparticles} with {SimpleBox4nano}}, + url = {http://dx.doi.org/10.1021/es500548h}, + doi = {10.1021/es500548h}, + abstract = {Screening level models for environmental assessment of engineered nanoparticles (ENP) are not generally available. Here, we present SimpleBox4Nano (SB4N) as the first model of this type, assess its validity, and evaluate it by comparisons with a known material flow model. SB4N expresses ENP transport and concentrations in and across air, rain, surface waters, soil, and sediment, accounting for nanospecific processes such as aggregation, attachment, and dissolution. The model solves simultaneous mass balance equations (MBE) using simple matrix algebra. The MBEs link all concentrations and transfer processes using first-order rate constants for all processes known to be relevant for ENPs. The first-order rate constants are obtained from the literature. The output of SB4N is mass concentrations of ENPs as free dispersive species, heteroaggregates with natural colloids, and larger natural particles in each compartment in time and at steady state. Known scenario studies for Switzerland were used to demonstrate the impact of the transport processes included in SB4N on the prediction of environmental concentrations. We argue that SB4N-predicted environmental concentrations are useful as background concentrations in environmental risk assessment.}, + number = {10}, + urldate = {2017-03-28}, + journal = {Environmental Science \& Technology}, + author = {Meesters, Johannes A. J. and Koelmans, Albert A. and Quik, Joris T. K. and Hendriks, A. Jan and van de Meent, Dik}, + month = may, + year = {2014}, + pages = {5726--5736} +} + +@article{davison_2005, + title = {The relationship between potentially erosive storm energy and daily rainfall quantity in {England} and {Wales}}, + volume = {344}, + issn = {0048-9697}, + doi = {10.1016/j.scitotenv.2005.02.002}, + abstract = {Erosive storm energy is the primary driver of soil detachment, and hence a major determinant of transfer of sediment and particulate phosphorus (P) to surface waters. Modelling of sediment and P loss at catchment scale, for example for the development of catchment and national mitigation policies, requires a spatially interpolated estimate of variation in erosion risk. To this end we present a method of estimating total rainfall erosivity, as kinetic energy (KE), for any location in England and Wales, from daily rainfall data or monthly climate data. Analysis of detailed, high-resolution records from eleven contrasting sites showed strong predictive correlations between daily rainfall quantity and associated daily total kinetic energy estimated from hourly rainfall intensities. The coefficients showed systematic seasonal variation, with greatest KE per unit of rainfall in late summer and autumn months. In contrast, no systematic spatial variation was found as a function of location or continentality index. The relationships were integrated with probability distributions of rainfall quantity per rain day derived from spatial climate data (monthly rainfall totals and numbers of rain days). The resulting map captures and quantifies the effects of rainfall quantity and intensity patterns on risk of sediment detachment, and as such provides a critical input layer to catchment-scale models of sediment and P transfer.}, + language = {eng}, + number = {1-3}, + journal = {The Science of the Total Environment}, + author = {Davison, P. and Hutchins, M. G. and Anthony, S. G. and Betson, M. and Johnson, C. and Lord, E. I.}, + month = may, + year = {2005}, + pmid = {15907507}, + keywords = {Geologic Sediments, Models, Theoretical, Fresh Water, England, Phosphorus, Rain, Wales, Water Movements, Water Pollutants, Chemical}, + pages = {15--25} +} + + +@article{morgan_2008, + title = {Modified {MMF} ({Morgan}–{Morgan}–{Finney}) model for evaluating effects of crops and vegetation cover on soil erosion}, + volume = {33}, + copyright = {Copyright © 2007 John Wiley \& Sons, Ltd.}, + issn = {1096-9837}, + url = {https://onlinelibrary.wiley.com/doi/abs/10.1002/esp.1530}, + doi = {10.1002/esp.1530}, + abstract = {Modifications are made to the revised Morgan–Morgan–Finney erosion prediction model to enable the effects of vegetation cover to be expressed through measurable plant parameters. Given the potential role of vegetation in controlling water pollution by trapping clay particles in the landscape, changes are also made to the way the model deals with sediment deposition and to allow the model to incorporate particle-size selectivity in the processes of erosion, transport and deposition. Vegetation effects are described in relation to percentage canopy cover, percentage ground cover, plant height, effective hydrological depth, density of plant stems and stem diameter. Deposition is modelled through a particle fall number, which takes account of particle settling velocity, flow velocity, flow depth and slope length. The detachment, transport and deposition of soil particles are simulated separately for clay, silt and sand. Average linear sensitivity analysis shows that the revised model behaves rationally. For bare soil conditions soil loss predictions are most sensitive to changes in rainfall and soil parameters, but with a vegetation cover plant parameters become more important than soil parameters. Tests with the model using field measurements under a range of slope, soil and crop covers from Bedfordshire and Cambridgeshire, UK, give good predictions of mean annual soil loss. Regression analysis of predicted against observed values yields an intercept value close to zero and a line slope close to 1·0, with a coefficient of efficiency of 0·81 over a range of values from zero to 38·6 t ha−1. Copyright © 2007 John Wiley \& Sons, Ltd.}, + language = {en}, + number = {1}, + urldate = {2018-09-25}, + journal = {Earth Surface Processes and Landforms}, + author = {Morgan, R. P. C. and Duzant, J. H.}, + month = jan, + year = {2008}, + keywords = {soil erosion, erosion modelling, vegetation}, + pages = {90--106} } diff --git a/docs/references.md b/docs/references.md new file mode 100644 index 0000000..3677f3d --- /dev/null +++ b/docs/references.md @@ -0,0 +1,5 @@ +# References + +```{bibliography} +:style: plain +``` \ No newline at end of file diff --git a/docs/theory/conceptual-structure.md b/docs/theory/conceptual-structure.md index 81a73f5..d2ae127 100644 --- a/docs/theory/conceptual-structure.md +++ b/docs/theory/conceptual-structure.md @@ -20,9 +20,9 @@ classDiagram BedSedimentLayer --o "1" Reactor ``` -Here, `Environment` represents the geographical area that we wish to model (e.g. a river catchment), which is divided into a number of `GridCell`s to give spatial resolution. Each `GridCell` can one or more `SoilProfile`s, which are split vertically into one or more `SoilLayer`s to give vertical resolution down the soil profile. `GridCell`s can also contain up to eight `WaterBody` objects (see [](surface-water-network)), each of which is an abstraction of a specific type of waterbody, such a `RiverReach` or `EstuaryReach`. Unlike `SoilProfile`s, `WaterBody` objects are linked across `GridCell`s to model the flow of water, sediment and contaminants around the environment. Each `WaterBody` contains a `BedSediment`, which is further split into a vertical distribution of `BedSedimentLayer`s. The final object is the `Reactor`, which is responsible for modelling the physical and chemical state of the contaminant being modelled. +Here, `Environment` represents the geographical area that we wish to model (e.g. a river catchment), which is divided into a number of `GridCell`s to give spatial resolution. Each `GridCell` can one or more `SoilProfile`s, which are split vertically into one or more `SoilLayer`s to give vertical resolution down the soil profile. `GridCell`s can also contain up to eight `WaterBody` objects (see [](conceptual-structure:surface-water-network)), each of which is an abstraction of a specific type of waterbody, such a `RiverReach` or `EstuaryReach`. Unlike `SoilProfile`s, `WaterBody` objects are linked across `GridCell`s to model the flow of water, sediment and contaminants around the environment. Each `WaterBody` contains a `BedSediment`, which is further split into a vertical distribution of `BedSedimentLayer`s. The final object is the `Reactor`, which is responsible for modelling the physical and chemical state of the contaminant being modelled. -(surface-water-network)= +(conceptual-structure:surface-water-network)= ## Surface water network *To be completed...* \ No newline at end of file diff --git a/docs/users/input-data.md b/docs/users/input-data.md new file mode 100644 index 0000000..1d8b905 --- /dev/null +++ b/docs/users/input-data.md @@ -0,0 +1,9 @@ +# Input data + +The model requires a NetCDF file of spatio(temporal) input data, and a Fortran namelist file for constants. The config file is responsible for telling the model where these input data are located (via the `&data` group). There are two options for generating these input data files: +* *Recommended*: Use the [NanoFASE data module](https://github.com/nerc-ceh/nanofase-data) - see [](nanofase-data). This is a Python script that compiles multiple spatio(temporal) input files into the main NetCDF file, at the same time as deriving secondary variables from these data, which are required by the model. +* Manually creating (or editing a copy of) the NetCDF and namelist files. This is not recommended for compiling new data (though can be useful for editing existing data) due to the requirement for a range of [secondary derived variables](netcdf-namelist-input:secondary-derived-variables) that would have to be calculated manually. If you wish to go down this route, see [](netcdf-namelist-input) for details of the variables required in the NetCDF and constants namelist file. + +The complete list of parameters required by the model is givin in [](parameter-reference). Example NetCDF and constants files are given in the [data.example](https://github.com/NERC-CEH/nanofase/tree/develop/data.example) directory. + +% draw diagram of data input components \ No newline at end of file diff --git a/docs/users/nanofase-data.md b/docs/users/nanofase-data.md new file mode 100644 index 0000000..3e6aabe --- /dev/null +++ b/docs/users/nanofase-data.md @@ -0,0 +1,253 @@ +# Compiling data with the NanoFASE data module + +The *NanoFASE data module* is a collection of Python scripts that are used to compile input data for the model. It is recommended to use these scripts over and above manually compiling the NetCDF and constants namelist file required by the model, as the data module scripts take care of deriving a variety of [secondary derived variables](netcdf-namelist-input:secondary-derived-variables), amongst other reasons. + +## Getting started + +```{note} +The data module is currently only available as standalone scripts, rather than a Python package. This means that you must manually download the repository and set up a computational environment (install the correct packages) to be able to run the scripts, as detailed below. In the future, we will create a Python package from these scripts to ease this process. +``` + +Clone a copy of the repository from GitHub: + +```bash +$ git clone git@github.com:NERC-CEH/nanofase-data.git +$ cd nanofase-data +``` + +Use Conda (or Mamba) to create a new environmental and install the required packages: + +```bash +$ conda env create -f environment.yaml +$ conda activate nanofase-data +``` + +If you don't want to use Conda/Mamba, then the `environment.yaml` file lists the packages that need to be installed. + +## Basic usage + +The main script is `nanofase_data.py`: + +``` +(nanofase-data) $ python nanofase_data.py --help +usage: nanofase_data.py [-h] [--output OUTPUT] {create,edit,constants} file + +Compile or edit data for the NanoFASE model. + +positional arguments: + {create,edit,constants} + do you wish to create from scratch, edit the data or create a constants file? + file path to the config file (create/edit tasks) or constants file (constants task) + +options: + -h, --help show this help message and exit + --output OUTPUT, -o OUTPUT + where to create the new constants file (for constants task) +``` + +### Creating a new dataset + +Specifying the "create" option compiles a new NetCDF dataset and Fortran namelist constant file: + +```shell script +(nanofase-data) $ python nanofase_data.py create /path/to/config.create.yaml +``` + +An annotated example config file is given: [`config.create.example.yaml`](https://github.com/NERC-CEH/nanofase-data/blob/develop/config.create.example.yaml). The file is quite self-explanatory, but a [full description is given below](nanofase-data:config). + +The two files will be output to the paths specified in the config file. + +### Editing an existing dataset + +To edit an existing NetCDF dataset, specify the "edit" option: + +```shell script +(nanofase-data) $ python nanofase_data.py edit /path/to/config.edit.yaml +``` + +An annotated example config file is given: [`config.edit.example.yaml`](https://github.com/NERC-CEH/nanofase-data/blob/develop/config.edit.example.yaml). This is similar (but not identical) in format to the creation config file, except only those variables you with to edit should be specified (all other variables are left as-is). Documentation for the config file is [provided below](nanofase-data:config). + +Certain variables can't be edited: `flow_dir`, `is_estuary`. Create a new dataset instead if you wish to change these variables. + +The Fortran namelist file cannot be edited using this method and you should instead edit the file directly. + +### Only creating a new constants file + +To simply convert a constants YAML file to a Fortran namelist file, you can use the `constants` option: + +```shell script +(nanofase-data) $ python nanofase_data.py constants /path/to/constants.yaml -o /path/to/constants.nml +``` + +No config file is required. The location of the newly created constants file is given by the `-o` or `--output` argument. + +```{admonition} Tips +:class: tip +- All rasters must be the same CRS as the `flow_dir` raster, and this must be a projected raster. In addition, all rasters except for `land_use` must be the same resolution as `flow_dir`. They can cover a larger geographical region and the module will automatically clip them to the correct size. +- Support for different file types is a bit sporadic at the moment. We suggest sticking the raster files for spatial variables, raster or CSV files for spatiotemporal variables (with 1 file per timestep for raster files) and shapefiles for point sources. You will trigger errors if you use an unsupported file. +- Example input data files are given in [`data.example/`](https://github.com/NERC-CEH/nanofase-data/tree/develop/data.example). Running the model using the example config files uses these data. +``` + + +(nanofase-data:config)= +## Creating a config file + +A config file must be provided when running the `nanofase_data.py` script in `create` or `edit` mode. Examples for creation and editing are given: +- [`config.create.example.yaml`](https://github.com/NERC-CEH/nanofase-data/blob/develop/config.create.example.yaml) +- [`config.edit.example.yaml`](https://github.com/NERC-CEH/nanofase-data/blob/develop/config.edit.example.yaml) + +The examples are annotated and should be self-explanatory. However, there are a few areas that need further documentation: + +### Setup + +The `create` and `edit` config files follow a similar layout. A variety of setup data is required and in the examples is placed at the top of the file. This includes file paths to input and output path, and model config info (e.g. timestep info): + +```yaml +# Setup +nanomaterial: TiO2 # Name of the nanomaterial. Not used in model. +output: + nc_file: ./data.nc # Where do you want the output NetCDF file to be stored? + constants_file: ./constants.nml # Where do you want the output constants file to be stored? +constants_file: ./data.example/thames_tio2_2015/constants.yaml # Where is the input constants file? +land_use_config: ./data.example/thames_tio2_2015/land_use.yaml # Where is the input land use config file? +root_dir: ./data.example/thames_tio2_2015/ # Root dir, can be used in path variables below as +iso3: GBR # iso3 code for country modelled +time: + n: 365 # Number of timesteps to run the model for + dt: 86400 # Length of each timestep in seconds + start_date: 2015-01-01 # Start date for the model run +``` + +```{warning} +The `time` options *do not* clip temporal data with a pre-specified time dimension to this time period. Rather, they impose this time period when compiling the NetCDF file. +``` + +#### Constants file - `output.constants_file` + +The NanoFASE data module generates two files, a NetCDF dataset and a Fortran namelist constants file. The NetCDF dataset holds spatial and/or temporal data, encompassing *most* of the data required by the NanoFASE model. The constants file holds data for variables which are constant in space and time. The main reason for including this as a separate text-based file is to provide an easier way to edit constant variables, using a text editor rather than having to write a script or using NetCDF utilities to do so. + +The data module simply converts the YAML constants file provided into a Fortran namelist file. The location of this YAML file should be given in the config file: + +```YAML +constants_file: /path/to/constants.yaml +``` + +Note this conversion only happens in `create` and `constants` mode and there is no utility to edit the Fortran namelist file via the data module. Instead, if you wish to edit the file, you can just use a text editor to do so. + +#### `root_dir` + +The `root_dir` variable can be used to specify a directory which can be used in the `path` property of each parameter (see [](nanofase-data:parameters)), for example to point to a directory in which all the data are stored. If `` is included in a `path` property, the value of `root_dir` will be substituted. For example: + +```yaml +... +root_dir: /path/to/data +... +flow_dir: + type: raster + path: flow_dir.tif # Evaluates to /path/to/data/flow_dir.tif +runoff: + type: csv + path: runoff.csv # Evaluates to /path/to/data/runoff.csv +``` + +(nanofase-data:land-use)= +#### Land use config - `land_use_config` + +The module maps between common land use classes (e.g. those provided by [CORINE](https://land.copernicus.eu/pan-european/corine-land-cover)) and the simpler, grouped land use classes used within the NanoFASE model by way of a land use config file. If `land_use_config` is not provided in the config file, [`land_use.default.yaml`](https://github.com/NERC-CEH/nanofase-data/blob/develop/land_use.default.yaml) is used instead - we recommend you use the CORINE land cover map, resampled to the correct CRS and stick with this default. The land use map itself is provided as a raster in by the `land_use` parameter. + +For reference, the NanoFASE land use categories are: + +```{list-table} +:header-rows: 1 + +* - Index value `l` + - Land use category +* - 1 + - `urban_no_soil` +* - 2 + - `urban_parks_leisure` +* - 3 + - `urban_industrial_soil` +* - 4 + - `urban_green_residential` +* - 5 + - `arable` +* - 6 + - `grassland` +* - 7 + - `deciduous` +* - 8 + - `coniferous` +* - 9 + - `heathland` +* - 10 + - `water` +* - 11 + - `desert` +* - 12 + - `other` +``` + + +(nanofase-data:parameters)= +### Parameters + +The setup section is followed by a list of parameters, each of which must have at least a `path` and `type` property. If `units` are included, the module will automatically convert them to the correct units on compilation. The units must follow the format used by the [Pint package](https://pint.readthedocs.io/en/stable/) and be in its [default list of units](https://github.com/hgrecco/pint/blob/master/pint/default_en.txt) (which is very extensive, so it probably will be). `source` and `references` can be used to add these attributes to the NetCDF file, but are metadata only and not used by the model. + +For example, for the parameter `soil_bulk_density`, we have a GeoTIFF raster file at `soil_bulk_density.tif`, and its units are t/m3, which we need the data module to convert to the [required model units of kg/m3](netcdf-namelist:soil-bulk-density): + +```yaml +soil_bulk_density: + type: raster + units: t/m**3 + path: soil_bulk_density.tif +``` + +A few parameters require additional information: + +```{margin} Time-varying emissions +Individual model runs have constant emissions for the whole run. However, individual model runs can be chained together in a multi-year model run, each year having different areal emissions. See [](batch). This is how multi-year simulations with varying areal emissions are currently performed. +``` + +(nanofase-data:point-emissions)= +#### Point source emissions and temporal profiles + +Unlike areal source emissions, which are (currently) constant throughout the model run, point sources can have a temporal profile applied and this makes their input a little more complicated than most variables (though I am working on making it simpler than it currently is). + +Point source emissions are provided by a shapefile. Each point within the shapefile should have a number of variables: + - Source type: A string to categorise this source. This is used to apply different temporal profiles to different sources (currently a maximum of one temporal profile is supported). Named `profile` in [example data](https://github.com/NERC-CEH/nanofase-data/tree/develop/data.example). + - Value variable: The value for this point source. Named `emission` in [example data](https://github.com/NERC-CEH/nanofase-data/tree/develop/data.example). + +The names of these variables (columns) are specified in the config: + +```yaml +emissions_point_water_pristine: + type: shapefile + value_var: emission # The name of the value variable in the shapefile + path: ... + source_type_col: profile # The name of the source type variable in the shapefile +``` + +**Temporal profiles** for a shapefile can be specified by the `temporal_profile` property. This should point to a CSV file (example given [here](https://github.com/NERC-CEH/nanofase-data/blob/develop/data.example/test-scenario/emissions_temporal-profile_2015.csv)), with `ISO3`, source type and factor columns. The name of the source type and factor columns can be specified in the config file: + +```yaml +emissions_point_water_pristine: + ... + temporal_profile: + path: /path/to/temporal_profile.csv + source_type_col: Emission_source_type # The name of the column giving the source type + for_source_type: P2 # The value of source_type_col in the shapefile for which this temporal profile should apply + factor_col: Factor # Which column gives the temporal factor? +``` + +The source type column is cross-referenced with the `source_type_col` column for the shapefile and only those points with matching source types have this temporal profile applied to them. In the example data, profiles with source type `P2` are given this temporal profile. + +Note that for the moment, only daily temporal factors are allowed and temporal profiles are for each year, and thus when the temporal profile CSV file is filtered by ISO3 and source type, it should contain 365-366 rows (depending on whether it is a leap year or not). + +```{note} +We appreciate that the way of specifying point source emissions is currently rather awkward. This is likely to be updated to a cleaner (and probably more prescriptive, in terms of column/variable names) interface in the future. +``` + +### Full parameter schema + +The full list of model parameters, including whether they are required by the NanoFASE data module, is given in the [](parameter-reference). \ No newline at end of file diff --git a/docs/users/netcdf-namelist-input.md b/docs/users/netcdf-namelist-input.md new file mode 100644 index 0000000..f13bffa --- /dev/null +++ b/docs/users/netcdf-namelist-input.md @@ -0,0 +1,475 @@ +# NetCDF and namelist input data + +The model requires a NetCDF file of spatio(temporal) parameters and a Fortran namelist file of constants. The config file is responsible for telling the model where these input data are located (via the `&data` group). + +The recommended way of generating these files is to use the [NanoFASE data module](https://github.com/nerc-ceh/nanofase-data). See [](nanofase-data) for details of how to use this data module. + +This page gives a breakdown of the parameters required in the NetCDF and Fortran namelist file. These are mostly similar to those required by the NanoFASE data module, but also contains a selection of secondary derived variables that are calculated by the NanoFASE data module from its inputs. Example NetCDF and constants files are given in the [data.example](https://github.com/NERC-CEH/nanofase/tree/develop/data.example) directory. + +## NetCDF file + +The NetCDF file stores any data that aren't constant (0D). Parameters have at least one of the following dimensions, as denoted in brackets after the variable name on this page: +* `t`: Time dimension +* `x`, `y`: Spatial dimensions +* `d`: Number of spatial dimensions, always equal to 2 +* `w`: Index of inflow to a grid cell, maximum of 7 +* `box`: Used to define the bounding box of the grid cells, always equal to 4 to represent each side of the bounding box +* `p`: Index of point source within a grid cell +* `l`: Index representing land use categories + +```{warning} +If you are manually creating this NetCDF file, pay careful attention to units, which might *not* be the conventional units used for these parameters. Notably, the length of the model timestep is used as a unit (e.g. m/timestep as the unit for runoff), meaning that changing timestep length means re-calculating these input data. +``` + +### Environmental parameters + +This selection of parameters pertains to the geographical region modelled, such as its climate, topography and soil properties. + +(input-data:dem)= +`int dem(y, x)` +: *Optional, if not present then default slope of 0.0005 m/m is assumed. Units: dm. Standard name: `height_above_mean_sea_level`.* \ +Digital elevation model (height above mean sea level). In the model, this is only used to calculate slope, whilst in the NanoFASE data module, it is used to calculate numerous [secondary variables](netcdf-namelist-input:secondary-derived-variables) for input to the model. + +`float quickflow(t, y, x)` +: *Required. Units: m/timestep. Standard name: `surface_runoff_flux`.* \ +Also called surface runoff, this is the component of runoff that is responsible for driving soil erosion. + +`float runoff(t, y, x)` +: *Required. Units: m/timestep. Standard name: `runoff_flux`.* \ +This is the total runoff (subsurface and surface) that is routed by the model to provide surface water flows. + +`float precip(t, y, x)` +: *Required. Units: m/timestep. Standard name: `rainfall_flux`.* \ +Amount of precipitation, used to drive soil percolation. + +`float evap(t, y, x)` +: *Optional, defaults to 0. Units: m/timestep. Standard name: `water_evapotranspiration_flux`.* \ +Amount of evapotranspiration. + +(netcdf-namelist:soil-bulk-density)= +`float soil_bulk_density(y, x)` +: *Required. Units: kg/m3.* \ +Bulk density of soil, which is assumed constant in time. + +`float soil_water_content_field_capacity(y, x)` +: *Required. Units: cm3/cm3. Standard name: `volume_fraction_of_condensed_water_in_soil_at_field_capacity`.* \ +Water content of the soil at field capacity, as a fraction. Assumed constant in time. + +`float soil_water_content_saturation(y, x)` +: *Required. Units: cm3/cm3. Standard name: `volume_fraction_of_condensed_water_in_soil`.* \ +Water content of the soil at saturation, as a fraction. Assumed constant in time. + +`float soil_hydraulic_conductivity(y, x)` +: *Required. Units: m/s. Standard name: `soil_hydraulic_conductivity_at_saturation`.* \ +The hydraulic conductivity of the soil, which is assumed constant in time. + +`float soil_texture_clay_content(y, x)` +: *Required. Units: kg/kg. Standard name: `volume_fraction_of_clay_in_soil`.* \ +Clay content of the soil, as a fraction. Assumed constant in time. + +`float soil_texture_sand_content(y, x)` +: *Required. Units: kg/kg. Standard name: `volume_fraction_of_sand_in_soil`.* \ +Sand content of the soil, as a fraction. Assumed constant in time. + +`float soil_texture_silt_content(y, x)` +: *Required. Units: kg/kg. Standard name: `volume_fraction_of_silt_in_soil`.* \ +Silt content of the soil, as a fraction. Assumed constant in time. + +`float soil_texture_coarse_frag_content(y, x)` +: *Required. Units: kg/kg.* \ +Coarse fragment content of the soil, as a fraction. Assumed constant in time. + +`float soil_usle_c_factor(y, x)` +: *Required. Unitless.* \ +Universal Soil Loss Equation cover management factor. + +`float soil_usle_p_factor(y, x)` +: *Required. Unitless.* \ +Universal Soil Loss Equation support practice factor. + +`float soil_usle_ls_factor(y, x)` +: *Required. Unitless.* \ +Universal Soil Loss Equation slope length and steepness factor. + +(netcdf-namelist-input:land-use)= +`float land_use(l, y, x)` +: *Required. Unitless.* \ +The fraction of the grid cell that is each of the NanoFASE model land use categories, indexed by `l`. The categories along this dimension are given by the following table: + +```{list-table} +:header-rows: 1 + +* - Index value `l` + - Land use category +* - 1 + - `urban_no_soil` +* - 2 + - `urban_parks_leisure` +* - 3 + - `urban_industrial_soil` +* - 4 + - `urban_green_residential` +* - 5 + - `arable` +* - 6 + - `grassland` +* - 7 + - `deciduous` +* - 8 + - `coniferous` +* - 9 + - `heathland` +* - 10 + - `water` +* - 11 + - `desert` +* - 12 + - `other` +``` + +(netcdf-namelist-input:is-estuary)= +`ubyte is_estuary(y, x)` +: *Required if config `include_estuary = .true.`, unitless.* \ +Boolean variable dictating whether a grid cell's waterbodies are estuaries (instead of freshwaters). 0 represents false, 1 represents true. This parameter is only required if the config option `include_estuary` is `.true.`, otherwise the model assumes there are no estuaries. + +### Nanomaterial properties + +Most nanomaterial properties are constant, and therefore included only in the constants namelist file. However, it is possible to input two parameters relating to the attachment of nanomaterials to the soil matrix as spatial parameters, to account for the spatial heterogeneity of soil affecting these parameters. If both parameters are present, the model will use the `soil_attachment_rate` preferentially over the `soil_attachment_efficiency` (which is used to internally calculate attachment rates). + +`float soil_attachment_rate(y, x)` +: *Optional, `soil_attachment_efficiency` used to calculate rate if not present. Unit: /s.* \ +The rate at which nanoparticles attach to the soil matrix. + +`float soil_attachment_efficiency(y, x)` +: *Optional, value in constants namelist file used if not present. Unitless.* \ +The attachment efficiency represents the probability that a collision between a nanoparticle and the soil matrix results in the sticking (attachment) of the nanoparticle. + +### Emissions + +The following parameters are used to define the emissions of nanomaterials to the environment. These are either *areal* (diffuse) emissions - assumed average across each grid cell, or *point* emissions, which are only to waters and snapped to the nearest waterbody within the model. Atmospheric inputs are provided by their own parameters, but are treated the same as areal emissions. Each point emission parameter actually has two parameters associated with it: the emission itself, and the exact (x, y) coordinates associated with that emission. If any of these parameters are excluded, they are presumed to be zero. + +For brevity, we condense the multiple parameters using `[x|y]` notation. For example, `emissions_areal_[water|soil]_[pristine|transformed|matrixembedded|dissolved]` represents eight parameters: `emissions_areal_water_pristine`, `emissions_areal_water_transformed`, etc. + +`float emissions_areal_[water|soil]_[pristine|transformed|matrixembedded|dissolved](y, x)` +: *Optional, defaults to 0. Units: kg/m2/timestep.* \ +Diffuse source emissions of pristine, transformed or matrix-embedded NM to waters or soils. + +`float emissions_atmospheric_[dry|wet]depo_[pristine|transformed|matrixembedded|dissolved](y, x)` +: *Optional, defaults to 0. Units: kg/m2/timestep.* \ +Emissions of pristine, transformed or matrix-embedded NM via atmospheric dry or wet deposition. Assumed to be split between soils and water according to the surface area of these compartments within each grid cell. + +`float emissions_point_water_[pristine|transformed|matrixembedded|dissolved](p, y, x)` +: *Optional, defaults to 0. Units: kg/timestep.* \ +Point source emissions of pristine, transformed or matrix-embedded NM to waters. The dimension `p` represents the number of point sources within a grid cell. + +`float emissions_point_water_[pristine|transformed|matrixembedded|dissolved]_coords(d, p, y, x)` +: *Required for one form (pristine, transformed etc) if value given for corresponding point source. Units: m.* \ +The projected (x, y) coordinates of the point source with same `p, y, x` indices. Only one coordinate is required across the different forms (pristine, transformed, matrix-embedded and dissolved), and therefore this variable only needs to be provided one. If coordinates for multiple forms are specified, the model will use only one in order of preference: dissolved, transformed, matrix-embedded, pristine. For example, if `emissions_point_water_pristine_coords` and `emissions_point_water_dissolved_coords` are provided, the value for `emissions_point_water_dissolved_coords` will be used for all of the forms from this point source. + +```{note} +We appreciate that dealing with point sources can be unintuitive. This is likely to be changed to be more logical in future versions of the model. +``` + +(netcdf-namelist-input:calibration-params)= +### Calibration parameters + +The following parameters related to sediment dynamics are intended to be calibrated against observed suspended sediment concentrations. They can either be constant across the entire modelled region - and therefore specified in the constants namelist file instead of the NetCDF file - or spatial. If specified in both the NetCDF and constants namelist file, the NetCDF parameter is used. + +`float resuspension_alpha(y, x)` +: *Optional, defaults to value in constants namelist, unitless.* \ +Shear velocity coefficient, used to calculate resuspension flux. Corresponds to parameter $a_7$ in {cite:t}`lazar_2010`. + +`float resuspension_beta(y, x)` +: *Optional, defaults to value in constants namelist, units: s2/kg.* \ +Entrainment coefficient, used to calculate resuspension flux. Corresponds to parameter $a_8$ in {cite:t}`lazar_2010`. + +`float deposition_alpha(y, x)` +: *Optional, defaults to value in constants namelist, unitless.* \ +Calibration parameter used to control sediment deposition. Corresponds to the parameter set to 38.1 in Equation 11 of {cite:t}`zhiyao_2008`. + +`float deposition_beta(y, x)` +: *Optional, defaults to value in constants namelist, unitless.* \ +Calibration parameter used to control sediment deposition. Corresponds to the parameter set to 0.93 in Equation 11 of {cite:t}`zhiyao_2008`. + +`float bank_erosion_alpha(y, x)` +: *Optional, defaults to value in constants namelist, units: kg/m.* \ +Bank erosion scaling factor, used to calculate sediment yield from bank erosion. Corresponds to parameter $a_9$ in {cite:t}`lazar_2010`. + +`float bank_erosion_beta(y, x)` +: *Optional, defaults to value in constants namelist, unitless.* \ +Bank erosion non-linear coefficient, used to calculate sediment yield from bank erosion. Corresponds to parameter $a_{10}$ in {cite:t}`lazar_2010`. + +`float sediment_transport_a(y, x)` +: *Optional, defaults to value in constants namelist, units: kg/m2/km2.* \ +Sediment transport capacity scaling factor. Corresponds to parameter $a_4$ in {cite:t}`lazar_2010`. + +`float sediment_transport_b(y, x)` +: *Optional, defaults to value in constants namelist, units: m2/s.* \ +Sediment transport capacity direct runoff threshold. Corresponds to parameter $a_5$ in {cite:t}`lazar_2010`. + +`float sediment_transport_c(y, x)` +: *Optional, defaults to value in constants namelist, unitless.* \ +Sediment transport capacity non-linear coefficient. Corresponds to parameter $a_6$ in {cite:t}`lazar_2010`. + + +(netcdf-namelist-input:secondary-derived-variables)= +### Secondary derived variables + +These are variables that are only required by the NetCDF file and not the NanoFASE data module. The latter uses the above input variables to derive these secondary variables. + +`int crs` +: *Required.* +The `crs` variable is an empty variable whose attributes define the Coordinate Reference System used by the model, to comply with CF conventions and to enable the dataset to be read by various spatial data software. It is recommended to include a `spatial_ref` and `crs_wkt` attribute, though the latter is the only used by the model internally (and only to write to the output data). + +`int t(t)` +: *Required, coordinate variable, units: seconds since start of simulation period.* \ +Coordinate variable that maps timestep index to a real timestamp. + +`int x(x)` +: *Required, coordinate variable, units: metres from origin of projected CRS.* \ +Coordinate variable that maps spatial x index to a real projected x position. + +`int y(y)` +: *Required, coordinate variable, units: metres from origin of projected CRS.* \ +Coordinate variable that maps spatial y index to a real projected y position. + +`int grid_shape(d)` +: *Required. Unitless* \ +Number of grid cells along each (x, y) grid axis. + +`float grid_res(d)` +: *Required, units: metres* \ +Grid resolution - the size of each grid cell. + +`float grid_bounds(box)` +: *Required, units: metres* \ +Coordinates of the bounding box for the model grid, in order (left, top, right, bottom). + +The following variables are ultimately deduced from the [digital elevation model](input-data:dem) (DEM) and are used to define the surface water network within the model, meaning the surface water network is automatically deduced and does not need to be provided as an input (see [](conceptual-structure:surface-water-network)). + +```{figure} ../img/flowdir.gif +--- +align: right +--- +``` + +`int flow_dir(y, x)` +: *Required, unitless* \ +Flow direction of water in the grid cell, relating to the topography and deduced from the [DEM](input-data:dem). Uses the standard eight-direction (D8) flow direction encoding. + +`short outflow(y, x, d)` +: *Required, unitless* \ +The (x, y) index of the outflow grid cell. + +`short inflows(y, x, w, d)` +: *Required, unitless* \ +The (x, y) indices of the inflowing grid cells, of which there may be up to 7 (see [](conceptual-structure:surface-water-network)). + +`short n_waterbodies(y, x)` +: *Required, unitless* \ +The number of waterbodies in each grid cell. + +`ubyte is_headwater(y, x)` +: *Required, unitless* \ +Is this cell a headwater with no inflows? 0 represents false, 1 represents true. + + +## Constants namelist file + +Parameters that are constant across space and time are provided via a text-based [Fortran namelist file](https://jules-lsm.github.io/vn4.2/namelists/intro.html). This file is split into separate groups: `allocatable_array_sizes`, `nanomaterial`, `water`, `sediment`, `soil` and `earthworm_densities`. + +```{note} +As well as the below parameters, the model also accepts a host of parameters related to biotic uptake. This process is still experimental and so these parameters are not yet documented. +``` + +(netcdf-namelist-input:allocatable-array-sizes)= +### `allocatable_array_sizes` group + +One of the quirks of Fortran namelist files is that any parameter in the namelist that is an allocatable array must have a corresponding parameter in the file that is the size of the array, so that the model can allocate the correct amount of memory before reading the array in. This means that every array parameter in the NanoFASE model constants namelist has a corresponding parameter in the `allocatable_array_sizes` group, which is named the array parameter name prepended with `n_`. + +If you are using the NanoFASE data module (see [](nanofase-data)) - which is recommended - you don't have to worry about these allocatable array sizes, as the module automatically writes the `allocatable_array_sizes` group when compiling input data. + +For completeness, the array size parameters that must be specified, if their corresponding array parameter is present, is as follows: + +``` +n_default_nm_size_distribution +n_default_spm_size_distribution +n_default_matrixembedded_distribution_to_spm +n_vertical_distribution +n_porosity +n_spm_density_by_size_class +n_intial_mass +n_fractional_composition_distribution +n_estuary_mouth_coords +``` + +### `nanomaterial` group + +`nm_density` +: *Required, units: kg/m3.* \ +The average density of the nanomaterial modelled. + +`default_nm_size_distribution` +: *Required, unitless* \ +An array of the same length as the number of NM size classes (given by config). This is used to apply a proportion of NM mass in each size class to emissions data. It is a percentage, so as an example, if a model configuration has five size classes, and the mass was distributed evenly across them, then `default_nm_size_distribution = 20, 20, 20, 20, 20`. + +### `water` group + +See also [](netcdf-namelist-input:constant-calibration-params). + +`river_attachment_efficiency` +: *Required, unitless.* \ +The attachment efficiency represents the probability that a collision between a nanoparticle and suspended particulate matter in rivers results in the sticking (attachment) of the nanoparticle, thus yielding is available for sediment deposition. + +`k_diss_[pristine|transformed]` +: *Optional, defaults to 0, units: /s.* \ +Dissolution rate of pristine or transformed NMs. + +`k_transform_pristine` +: *Optional, defaults to 0, units: /s.* \ +The rate at which pristine NM transforms to the `transformed` form. + +`river_meandering_factor` +: *Optional, defaults to calculation based on grid size, unitless.* \ +Meandering factor to account for rivers not being straight lines. If not present, meandering factor is estimated from the grid cell size, according to $f_m = 1.024 - 0.077 * \ln (200 / (dx + dy))$ {cite:p}`fekete_2001`. + +`[min|max]_water_temperature` +: *Optional, defaults to 4oC (min) or 21oC (max), units: oC.* \ +Average minimum or maximum water temperature across the year. Calculates daily water temperature timeseries using a cosine curve based on these values. + +`min_water_temperature_day_of_year` +: *Optional, defaults to 32, unitless.* \ +Day of the year on which the minimum water temperature usually occurs, as an integer. Defaults to 32, which represents the first day of February. Used along with min/max water temperature to calculate water temperature timeseries. + +`shear_rate` +: *Optional, defaults to 10 /s, units: /s.* \ +Shear rate at the water-sediment interface, used for calculating resuspension. Defaults to 10 /s {cite}`arvidsson_2011`. + +#### Estuary parameters + +Parameters pertaining to the estuary are required if the model domain has an estuary, as specified by the [`is_estuary` spatial variable](netcdf-namelist-input:is-estuary) and config `include_estuary` option. Otherwise, these parameters can be excluded. + +`estuary_tidal_m2` +: *Required if model domain has estuary, unitless.* \ +The M2 component of the tidal harmonics. + +`estuary_tidal_s2` +: *Required if model domain has estuary, unitless.* \ +The S2 component of the tidal harmonics. + +`estuary_mouth_coords` +: *Required if model domain has estuary, units: m.* \ +Position of the estuary mouth as (x, y) coordinates. Used to calculute upstream estuary dimensions based on exponential regression dependent on distance to estuary mouth. + +`estuary_[mean_depth|width]_exp[a|b]` +: *Required if model domain has estuary, unitless.* \ +Parameters `a` and `b` controlling the dependence of the estuary mean depth or width on distance to the mouth. For example, parameters `estuary_width_expa` and `estuary_width_expb` are used to calculate the width of the estuary upstream by a distance of `d` by the relation `width = estuary_width_expa * exp(-estuary_width_expb * d)`. + +`estuary_meandering_factor` +: *Optional, defaults to calculation based on grid size, unitless.* \ +Meandering factor to account for estuaries not being straight lines. If not present, meandering factor is estimated from the grid cell size, according to $f_m = 1.024 - 0.077 * \ln (200 / (dx + dy))$ {cite:p}`fekete_2001`. + +`estuary_attachment_efficiency` +: *Required if model domain has estuary, unitless.* \ +The attachment efficiency represents the probability that a collision between a nanoparticle and suspended particulate matter in the estuary results in the sticking (attachment) of the nanoparticle, thus yielding is available for sediment deposition. + + +### `soil` group + +`darcy_velocity` +: *Optional, defaults to 9e-6 m/s, units: m/s.* \ +The Darcy approach velocity is used to calculate the attachment rate of NMs. A default of 9e-6 m/s is used {cite:p}`tufenkji_2004,meesters_2014`. + +`default_porosity` +: *Required, unitless.* \ +Porosity of the soil profile. + +`hamaker_constant` +: *Required, units: J.* \ +Soil Hamaker constant, which is used to calculate the attachment rate of NMs. + +`particle_density` +: *Required, units: kg/m3.* \ +Average density of soil particles. + +`erosivity_[a1|a2|a3|b]` +: *Required, unitless.* \ +These four parameters are used to calculate a soil erosivity factor for use in predicting soil erosion yields. Based on a Revised Universal Soil Loss (RUSLE), with R-factor calculated from rainfall kinetic energy (see {cite:t}`davison_2005`) and K-factor based on a modified Morgan-Morgan-Finney {cite:p}`morgan_2008`. + +`soil_attachment_efficiency` +: *Optional, defaults to 0 if corresponding parameter not present in NetCDF file, unitless.* \ +The attachment efficiency represents the probability that a collision between a nanoparticle and the soil matrix results in the sticking (attachment) of the nanoparticle. If a spatial version of this parameter is not present in the NetCDF file, this constant value is used. + +### `sediment` group + +`porosity` +: *Required, unitless.* \ +Average sediment porosity. + +`initial_mass` +: *Required, units: kg/m2.* \ +Array that must be the same length as the number of sediment size classes (`n_spm_size_classes` in config), representing the mass of each sediment size class at the start of the model run. + +`fractional_composition_distribution` +: *Required, unitless.* \ +Array that must be the same length as the number of sediment fractional compositions (`n_fractional_compositions` in config). Represents the default distribution of sediment mass across fractional compositions, as a percentage. + +`default_spm_size_distribution` +: *Required, unitless.* \ +Array that must be the same length as the number of sediment size classes (`n_spm_size_classes` in config). This is the default size distribution applied to sediment particles, as a percentage, when there is no other information, such as from soil erosion yields. + +`default_matrixembedded_distribution_to_spm` +: *Required, unitless.* \ +Array that must be the same length as the number of sediment size classes (`n_spm_size_classes` in config). This is the default size distribution that is used to proportion matrix-embedded releases of NM to sediment size classes. + +`spm_density_by_size_class` +: *Required, units: kg/m3.* \ +Array that must be the same lenth as the number of sediment size classes (`n_spm_size_classes` in config). Represents the density of the sediment in each size class. + +```{note} +There are also a handful of parameters related to sediment enrichment, but this process is not fully implemented yet and therefore not documented. +``` + + +(netcdf-namelist-input:constant-calibration-params)= +### Sediment calibration parameters + +If spatial sediment calibration parameters (see [](netcdf-namelist-input:calibration-params)) are not provided, the model uses constant equivalents provided in the constants namelist file, split across the `soil` and `water` groups. The description and units remain as per for the NetCDF file. Note that the sediment transport capacity parameters are in the `soil` group, whilst the remaining parameters are in the `water` group. Different resuspension parameters can be provided for estuary and freshwaters, and if no value for estuary is given, the freshwater value is used. If the parameters are not present in either the NetCDF or constants namelist file, the following defaults are used: + +``` +&water + resuspension_alpha = + resuspension_beta = + resuspension_alpha_estuary = + resuspension_beta_estuary = + deposition_alpha = 38.1_dp + deposition_beta = 0.93_dp + bank_erosion_alpha = 1e-9_dp + bank_erosion_beta = 1.0_dp +\ + +&soil + sediment_transport_a = 2e-9_dp + sediment_transport_b = 0.0_dp + sediment_transport_c = 0.2_dp +\ +``` + +(netcdf-namelist-input:earthworms)= +### `earthworm_densities` group + +This group is a list of earthworm densities per NanoFASE land use category, plus the vertical distribution of these earthworm densities across soil layers. All parameters are required and have units of individuals/m2. The following values are reasonable estimates across the different land use categories in the UK, for a 3-layer soil profile with depths of 5, 15 and 20 cms, respectively. + +``` +&earthworm_densities + arable = 30 + coniferous = 150 + deciduous = 400 + grassland = 250 + heathland = 20 + urban_capped = 0 + urban_gardens = 150 + urban_parks = 250 + vertical_distribution = 50, 35, 15 +/ +``` diff --git a/docs/users/parameter-reference.md b/docs/users/parameter-reference.md new file mode 100644 index 0000000..027aa72 --- /dev/null +++ b/docs/users/parameter-reference.md @@ -0,0 +1,107 @@ +# Model parameter reference + +This section is a comprehensive reference for model input parameters, including what file(s) they should be specified in, what their defaults are, and ideas for where to source them from. + +For information on how to compile and input these parameters into the model, see [](input-data). + +The **Name(dimensions)** column includes the following dimensions for use in the NetCDF file: +* `t`: Time dimension +* `x`, `y`: Spatial dimensions +* `d`: Number of spatial dimensions, always equal to 2 +* `w`: Index of inflow to a grid cell, maximum of 7 +* `box`: Used to define the bounding box of the grid cells, always equal to 4 to represent each side of the bounding box +* `p`: Index of point source within a grid cell +* `l`: Index representing land use categories + +A handful of 1D arrays are present in the constants file. Note that the constants namelist file also requires allocatable array size variables to define the length of these arrays - see [](netcdf-namelist-input:allocatable-array-sizes). These are handled automatically by the NanoFASE data module and *not* included in this reference. The array dimensions used in the constant files are: +* `nm`: NM size classes, length must equal `n_nm_size_classes` in the model config file. +* `spm`: Suspended sediment size classes, length must equal `n_spm_size_classes` in the model config file. +* `fc`: Sediment fractional compositions, length must equal `n_fractional_compositions` in the model config file. +* `soil_l`: Soil layers, length must equal `n_soil_layers` in the model config file. +* `sed_l`: Sediment layers, length must equal `n_sediment_layers` in the model config file. + +The **Units** columns gives the internal model units, and therefore those required by the NetCDF and constants namelist. "dt" is the length of the model timestep, for example, is the model has a timestep of one day, then "kg/timestep" means "kg/day". The NanoFASE data module is capable of converting units of spatial data (not constants), and therefore any reasonable units can be used for the data input to this - as long as these units are specified in the config file. + +The **Specified in** column indicates which file the model parameter should be included in: +* {bdg-primary}`data.nc` The spatio(temporal) NetCDF file input directly to the model. +* {bdg-secondary}`constants.nml` The constants namelist file input directly to the model. +* {bdg-success}`config.yaml` The main config file of the [NanoFASE data module](nanofase-data), which lists spatio(temporal) variables that are compiled into the NetCDF file. Though the data themselves aren't in this file, it provides the path to where the data are. +* {bdg-danger}`constants.yaml` The constants YAML file that the [NanoFASE data module](nanofase-data) converts to the constants namelist file. + +Data in the constants file are grouped, and this is denoted in the **Name(dimensions)** column as {bdg-dark-line}`group` `parameter_name`. + +The **Potential source** column gives ideas for where the data may be sourced from. These are particularly relevant to European scenarios. + +## Environmental parameters + +### Meteorological and hydrological parameters + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/met-hydro-parameters.csv +``` +```` + +### Surface water parameters + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/surface-water-parameters.csv +``` +```` + +### Soil and terrestrial parameters + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/soil-terrestrial-parameters.csv +``` +```` + +### Sediment parameters + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/sediment-parameters.csv +``` +```` + +## Nanomaterial parameters + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/nanomaterial-parameters.csv +``` +```` + +## Emissions + + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/emission-parameters.csv +``` +```` + +## Calibration parameters + +The calibration parameters relate to sediment dynamics, but are included in a separate table for ease of reference. They can all either be specified as spatial or constant, with the spatial version being used preferentially if both are present. + +Generally, the model should be calibrated against observed sediment concentrations using these parameters. For example, for the UK, the [Environment Agency Water Quality Data Archive](https://environment.data.gov.uk/water-quality/view/landing) could be used. + +````{div} full-width +```{csv-table} +:header-rows: 1 +:file: parameters/calibration-parameters.csv +``` +```` + +## Secondary derived variables + +The spatial variables that are derived by the NanoFASE data module, and therefore required in the NetCDF file but not as input to the data module, are documented here: [](netcdf-namelist-input:secondary-derived-variables). \ No newline at end of file diff --git a/docs/users/parameters/calibration-parameters.csv b/docs/users/parameters/calibration-parameters.csv new file mode 100644 index 0000000..6227ba1 --- /dev/null +++ b/docs/users/parameters/calibration-parameters.csv @@ -0,0 +1,21 @@ +{bdg-dark-line}`group` Name(dimensions) ,Specified in ,Data type ,Required or optional ,Model units ,Description +"`resuspension_alpha(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",\-,"Shear velocity coefficient, used to calculate resuspension flux." +{bdg-dark-line}`water` `resuspension_alpha` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required if not present in spatial data ,\-,As above +{bdg-secondary-line}`water` `resuspension_alpha_estuary` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to `water . resuspension_alpha` ",\-,"As above, for estuaries " +"`resuspension_beta(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",s2/kg ,"Entrainment coefficient, used to calculate resuspension flux. Corresponds to parameter $a_8$ in {cite:t}`lazar_2010`. " +{bdg-dark-line}`water` `resuspension_beta` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required if not present in spatial data ,s2/kg ,As above +{bdg-dark-line}`water` `resuspension_beta_estuary` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to `water . resuspension_beta` ",s2/kg ,"As above, for estuaries " +"`deposition_alpha(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",\-,Calibration parameter used to control sediment deposition. Corresponds to the parameter set to 38.1 in Equation 11 of {cite:t}`zhiyao_2008`. +{bdg-dark-line}`water` `deposition_alpha` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 38.1 ",\-,As above +"`deposition_beta(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",\-,Calibration parameter used to control sediment deposition. Corresponds to the parameter set to 0.93 in Equation 11 of {cite:t}`zhiyao_2008`. +{bdg-dark-line}`water` `deposition_beta` ,{bdg-primary}`constants.nml` {bdg-secondary}`constants.yaml` ,float ,"Optional, defaults to 0.93 ",\-,As above +"`bank_erosion_alpha(y, x)` ",{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to value in constants ",kg/m ,"Bank erosion scaling factor, used to calculate sediment yield from bank erosion. Corresponds to parameter $a_9$ in {cite:t}`lazar_2010`. " +{bdg-dark-line}`water` `bank_erosion_alpha` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 1e-9 ",kg/m ,As above +"`bank_erosion_beta(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",\-,"Bank erosion non-linear coefficient, used to calculate sediment yield from bank erosion. Corresponds to parameter $a_{10}$ in {cite:t}`lazar_2010`. " +{bdg-dark-line}`water` `bank_erosion_beta` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 1.0 ",\-,As above +"`sediment_transport_a(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",kg/m2/km2 ,Sediment transport capacity scaling factor. Corresponds to parameter $a_4$ in {cite:t}`lazar_2010`. +{bdg-dark-line}`soil` `sediment_transport_a` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 2e-9 ",kg/m2/km2 ,As above +"`sediment_transport_b(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",m2/s ,Sediment transport capacity direct runoff threshold. Corresponds to parameter $a_5$ in {cite:t}`lazar_2010`. +{bdg-dark-line}`soil` `sediment_transport_b` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 0 ",m2/s ,As above +"`sediment_transport_c(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,"Optional, defaults to value in constants ",\-,Sediment transport capacity non-linear coefficient. Corresponds to parameter $a_6$ in {cite:t}`lazar_2010`. +{bdg-dark-line}`soil` `sediment_transport_c` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 0.2 ",\-,As above diff --git a/docs/users/parameters/emission-parameters.csv b/docs/users/parameters/emission-parameters.csv new file mode 100644 index 0000000..704239d --- /dev/null +++ b/docs/users/parameters/emission-parameters.csv @@ -0,0 +1,25 @@ +Name(dimensions),Specified in,Data type,Required or optional,Model units,Description +"`emissions_areal_water_pristine(y, x)`
+`emissions_areal_water_transformed(y, x)`
+`emissions_areal_water_matrixembedded(y, x)`
+`emissions_areal_water_dissolved(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",kg/m2/dt,"Diffuse source emissions of pristine, transformed or matrix-embedded NM to waters." +"`emissions_areal_soil_pristine(y, x)`
+`emissions_areal_soil_transformed(y, x)`
+`emissions_areal_soil_matrixembedded(y, x)`
+`emissions_areal_soil_dissolved(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",kg/m2/dt,"Diffuse source emissions of pristine, transformed or matrix-embedded NM to soils." +"`emissions_atmospheric_drydepo_pristine(y, x)`
+`emissions_atmospheric_drydepo_transformed(y, x)`
+`emissions_atmospheric_drydepo_matrixembedded(y, x)`
+`emissions_atmospheric_drydepo_dissolved(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",kg/m2/dt,"Emissions of pristine, transformed or matrix-embedded NM via atmospheric dry deposition. Assumed to be split between soils and water according to the surface area of these compartments within each grid cell." +"`emissions_atmospheric_wetdepo_pristine(y, x)`
+`emissions_atmospheric_wetdepo_transformed(y, x)`
+`emissions_atmospheric_wetdepo_matrixembedded(y, x)`
+`emissions_atmospheric_wetdepo_dissolved(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",kg/m2/dt,"Emissions of pristine, transformed or matrix-embedded NM via atmospheric wet deposition. Assumed to be split between soils and water according to the surface area of these compartments within each grid cell." +"`emissions_point_water_pristine(p, t, y, x)`
+`emissions_point_water_transformed(p, t, y, x)`
+`emissions_point_water_matrixembedded(p, t, y, x)`
+`emissions_point_water_dissolved(p, t, y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",kg/dt,"Point source emissions of pristine, transformed or matrix-embedded NM to waters. The dimension `p` represents the number of point sources within a grid cell. See [](nanofase-data:point-emissions) for how point source emissions should be specified in the NanoFASE data module, including specification of a temporal profile via a separate sidecar file." +"`emissions_point_water_pristine_coords(d, p, y, x)`
+`emissions_point_water_transformed_coords(d, p, y, x)`
+`emissions_point_water_matrixembedded_coords(d, p, y, x)`
+`emissions_point_water_dissolved_coords(d, p, y, x)`",{bdg-primary}`data.nc`,float,"Required for one form (pristine, transformed etc) if value given for corresponding point source.",m,"The projected (x, y) coordinates of the point source with same `p, y, x` indices. Only one coordinate is required across the different forms (pristine, transformed, matrix-embedded and dissolved), and therefore this variable only needs to be provided one. If coordinates for multiple forms are specified, the model will use only one in order of preference: dissolved, transformed, matrix-embedded, pristine. For example, if `emissions_point_water_pristine_coords` and `emissions_point_water_dissolved_coords` are provided, the value for `emissions_point_water_dissolved_coords` will be used for all of the forms from this point source. Not required in NanoFASE data module as data are provided by shapefiles (see [](nanofase-data:point-emissions))." diff --git a/docs/users/parameters/met-hydro-parameters.csv b/docs/users/parameters/met-hydro-parameters.csv new file mode 100644 index 0000000..b835025 --- /dev/null +++ b/docs/users/parameters/met-hydro-parameters.csv @@ -0,0 +1,6 @@ +Name(dimensions),Specified in,Data type,Required or optional,Model units,Description,Potential source +"`dem(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Required in {bdg-success}`config.yaml`, optional in {bdg-primary}`data.nc`",dm,"Digital elevation model (height above mean sea level). In the model, this is only used to calculate slope, which defaults to 0.0005 m/m. In the NanoFASE data module, it is used to calculate numerous [secondary variables](netcdf-namelist-input:secondary-derived-variables) for input to the model. Standard name: `height_above_mean_sea_level`",[Copernicus DEM](https://spacedata.copernicus.eu/collections/copernicus-digital-elevation-model) +"`quickflow(t, y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,Required,m/dt,"Also called surface runoff, this is the component of runoff that is responsible for driving soil erosion. Standard name: `surface_runoff_flux`",Usually obtained from a hydrological model +"`runoff(t, y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,Required,m/dt,This is the total runoff (subsurface and surface) that is routed by the model to provide surface water flows. Standard name: `runoff_flux`,Usually obtained from a hydrological model +"`precip(t, y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,Required,m/dt,"Amount of precipitation, used to drive soil percolation. Standard name: `rainfall_flux`",[Copernicus E-OBS](https://cds.climate.copernicus.eu/cdsapp#!/dataset/10.24381/cds.151d3ec6?tab=overview) or [CEH-GEAR](https://doi.org/10.5285/dbf13dd5-90cd-457a-a986-f2f9dd97e93c) for the UK +"`evap(t, y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, defaults to 0",m/dt,Amount of evapotranspiration. Standard name: `water_evapotranspiration_flux`,"[Nistor et al, 2022](https://doi.org/10.3390/atmos13050772) (data available [here](https://doi.org/10.5281/zenodo.5899476))" diff --git a/docs/users/parameters/nanomaterial-parameters.csv b/docs/users/parameters/nanomaterial-parameters.csv new file mode 100644 index 0000000..6e9e4ad --- /dev/null +++ b/docs/users/parameters/nanomaterial-parameters.csv @@ -0,0 +1,10 @@ +{bdg-dark-line}`group` Name(dimensions),Specified in,Data type,Required or optional,Model units,Description +{bdg-dark-line}`nanomaterial` `nm_density`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,kg/m3,The average density of the nanomaterial modelled +{bdg-dark-line}`nanomaterial` `default_nm_size_distribution(nm)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,"Used to apply a proportion of NM mass in each size class to emissions data, as a percentage" +{bdg-dark-line}`soil` `soil_attachment_efficiency`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to 0 if corresponding parameter not present in NetCDF file",\-,"The attachment efficiency represents the probability that a collision between a nanoparticle and the soil matrix results in the sticking (attachment) of the nanoparticle. If a spatial version of this parameter is not present in the NetCDF file, this constant value is used." +"`soil_attachment_rate(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, `soil_attachment_efficiency` used to calculate rate if not present",/s,The rate at which nanoparticles attach to the soil matrix +"`soil_attachment_efficiency(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,"Optional, value in constants file used if not present",\-,The attachment efficiency represents the probability that a collision between a nanoparticle and the soil matrix results in the sticking (attachment) of the nanoparticle +{bdg-dark-line}`soil` `hamaker_constant`,{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float,Required,J,"Soil Hamaker constant, which is used to calculate the attachment rate of NMs." +{bdg-dark-line}`water` `river_attachment_efficiency`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,"The attachment efficiency represents the probability that a collision between a nanoparticle and suspended particulate matter in rivers results in the sticking (attachment) of the nanoparticle, thus yielding is available for sediment deposition." +{bdg-dark-line}`water` `k_diss_pristine`
`k_diss_transformed`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to 0",/s,Dissolution rate of pristine or transformed NMs. +{bdg-dark-line}`water` `estuary_attachment_efficiency`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required if model domain has estuary,\-,"The attachment efficiency represents the probability that a collision between a nanoparticle and suspended particulate matter in estuaries results in the sticking (attachment) of the nanoparticle, thus yielding is available for sediment deposition." diff --git a/docs/users/parameters/sediment-parameters.csv b/docs/users/parameters/sediment-parameters.csv new file mode 100644 index 0000000..9cbaa2d --- /dev/null +++ b/docs/users/parameters/sediment-parameters.csv @@ -0,0 +1,7 @@ +{bdg-dark-line}`group` Name(dimensions),Specified in,Data type,Required or optional,Model units,Description +{bdg-dark-line}`sediment` `porosity`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,Average sediment porosity +{bdg-dark-line}`sediment` `initial_mass(spm)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,kg/m2,The mass of each sediment size class at the start of the model run. +{bdg-dark-line}`sediment` `fractional_composition_distribution(fc)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,"The default distribution of sediment mass across fractional compositions, as a percentage." +{bdg-dark-line}`sediment` `default_spm_size_distribution(spm)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,"The default size distribution applied to sediment particles, as a percentage, when there is no other information, such as from soil erosion yields." +{bdg-dark-line}`sediment` `default_matrixembedded_distribution_to_spm(spm)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,\-,The default size distribution that is used to proportion matrix-embedded releases of NM to sediment size classes. +{bdg-dark-line}`sediment` `spm_density_by_size_class(spm)`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required,kg/m3,The density of the sediment in each size class. diff --git a/docs/users/parameters/soil-terrestrial-parameters.csv b/docs/users/parameters/soil-terrestrial-parameters.csv new file mode 100644 index 0000000..47802e8 --- /dev/null +++ b/docs/users/parameters/soil-terrestrial-parameters.csv @@ -0,0 +1,22 @@ +{bdg-dark-line}`group` Name(dimensions) ,Specified in ,Data type ,Required or optional ,Model units ,Description ,Potential source +"`soil_bulk_density(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,kg/m3 ,Bulk density of the soil profile ,[ESDAC Soil Bulk Density](https://esdac.jrc.ec.europa.eu/content/soil-bulk-density-europe) +"`soil_water_content_field_capacity(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,cm3/cm3 ,"Water content of the soil at field capacity, as a fraction. Standard name: `volume_fraction_of_condensed_water_in_soil_at_field_capacity` ",[ESDAC Soil Hydraulic Properties](https://esdac.jrc.ec.europa.eu/content/maps-indicators-soil-hydraulic-properties-europe) +"`soil_water_content_saturation(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,cm3/cm3 ,"Water content of the soil at saturation, as a fraction. Standard name: `volume_fraction_of_condensed_water_in_soil` ",[ESDAC Soil Hydraulic Properties](https://esdac.jrc.ec.europa.eu/content/maps-indicators-soil-hydraulic-properties-europe) +"`soil_hydraulic_conductivity(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,m/s ,The hydraulic conductivity of the soil. Standard name: `soil_hydraulic_conductivity_at_saturation` ,[ESDAC Soil Hydraulic Properties](https://esdac.jrc.ec.europa.eu/content/maps-indicators-soil-hydraulic-properties-europe) +"`soil_texture_clay_content(y, x)` `soil_texture_sand_content(y, x)` `soil_texture_silt_content(y, x)` `soil_texture_coarse_frag_content(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,kg/kg ,"Clay, sand, silt or coarse fragment content of the soil, as a fraction. ",[ESDAC Topsoil Physical Properties](https://esdac.jrc.ec.europa.eu/content/topsoil-physical-properties-europe-based-lucas-topsoil-data) +"`soil_usle_c_factor(y, x)` `soil_usle_p_factor(y, x)` `soil_usle_ls_factor(y, x)` ",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,float ,Required ,\-,"Universal Soil Loss Equation cover management (C), support practice (P) and slope length and steepness (LS) factors. ","ESDAC [C-factor](https://esdac.jrc.ec.europa.eu/content/cover-management-factor-c-factor-eu), [P-factor](https://esdac.jrc.ec.europa.eu/content/support-practices-factor-p-factor-eu) and [LS-factor](https://esdac.jrc.ec.europa.eu/content/ls-factor-slope-length-and-steepness-factor-eu)" +"`land_use(l, y, x)` ",{bdg-primary}`data.nc` ,float ,Required ,\-,"The fraction of the grid cell that is each of the NanoFASE model land use categories, indexed by `l`. [See here](nanofase-data:land-use) for land use categories. This is an internal parameter only required in the model NetCDF file. The NanoFASE data module takes a more conventional land use raster (see next row) and converts it to this parameter. ","[CORINE Land Cover](https://land.copernicus.eu/en/products/corine-land-cover) raster, pre-processed by the NanoFASE data module" +"`land_use(y, x)` ",{bdg-success}`config.yaml` ,int ,Required ,\-,"Raster of land use classes, which are mapped to NanoFASE land use categories. If data are CORINE, the mapping should work automatically - see [Land use config](nanofase-data:land-use). This is the only spatial data that can be higher resolution than the model resolution (the higher the resolution, the more accurate that the above model parameter `land_use(l, y, x)` will be) ",[CORINE Land Cover](https://land.copernicus.eu/en/products/corine-land-cover) raster +{bdg-dark-line}`soil` `darcy_velocity` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,"Optional, defaults to 9e-6 m/s ",m/s ,"The Darcy approach velocity is used to calculate the attachment rate of NMs. A default of 9e-6 m/s is used {cite:p}`tufenkji_2004,meesters_2014`. ", +{bdg-dark-line}`soil` `default_porosity` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required ,\-,Porosity of the soil profile. , +{bdg-dark-line}`soil` `particle_density` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required ,kg/m3 ,Average density of soil particles. , +{bdg-dark-line}`soil` `erosivity_a1`
`erosivity_a2`
`erosivity_a3`
`erosivity_b` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required ,\-,"These four parameters are used to calculate a soil erosivity factor for use in predicting soil erosion yields. Based on a Revised Universal Soil Loss (RUSLE), with R-factor calculated from rainfall kinetic energy (see {cite:t}`davison_2005`) and K-factor based on a modified Morgan-Morgan-Finney {cite:p}`morgan_2008`. ", +"{bdg-dark-line}`earthworm-densities` `arable`
+`coniferous`
+`deciduous`
+`grassland`
+`heathland`
+`urban_capped`
+`urban_gardens`
+`urban_parks` ",{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required ,individuals/m3 ,Density of earthworms in each [NanoFASE land use category](nanofase-data:land-use). ,"[See here](netcdf-namelist-input:earthworms) for reasonable estimates for the UK. Could be deduced from earthworm density maps, e.g. [for Europe](https://doi.org/10.1016/j.apsoil.2015.08.015)." +{bdg-dark-line}`earthworm-densities` `vertical_distribution(soil_l)` ,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float ,Required ,\-,"Percentage of the earthworms in each soil layer, used to distribute the densities across the soil profile. ", diff --git a/docs/users/parameters/surface-water-parameters.csv b/docs/users/parameters/surface-water-parameters.csv new file mode 100644 index 0000000..b6f026b --- /dev/null +++ b/docs/users/parameters/surface-water-parameters.csv @@ -0,0 +1,11 @@ +{bdg-dark-line}`group` Name(dimensions),Specified in,Data type,Required or optional,Model units,Description,Potential source +"`is_estuary(y, x)`",{bdg-primary}`data.nc` {bdg-success}`config.yaml` ,ubyte,Required if config option `include_estuary = .true.`,\-,"Boolean variable dictating whether a grid cell's waterbodies are estuaries (instead of freshwaters). 0 represents false, 1 represents true. This parameter is only required if the config option `include_estuary` is `.true.`, otherwise the model assumes there are no estuaries","Could be deduced from land use maps, such as [CORINE Land Cover](https://land.copernicus.eu/en/products/corine-land-cover)" +{bdg-dark-line}`water` `river_meandering_factor`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to calculation based on grid size",\-,"Meandering factor to account for rivers not being straight lines. If not present, meandering factor is estimated from the grid cell size, according to $f_m = 1.024 - 0.077 * \ln (200 / (dx + dy))$ {cite:p}`fekete_2001`.","Could be deduced from river network vectors, such as [OS Open Rivers](https://www.ordnancesurvey.co.uk/products/os-open-rivers)" +{bdg-dark-line}`water` `min_water_temperature`
`max_water_temperature`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to 4oC (min) or 21oC (max)",oC,Average minimum or maximum water temperature across the year. Calculates daily water temperature timeseries using a cosine curve based on these values., +{bdg-dark-line}`water` `min_water_temperature_day_of_year`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,int,"Optional, defaults to 32",\-,"Day of the year on which the minimum water temperature usually occurs, as an integer. Defaults to 32, which represents the first day of February. Used along with min/max water temperature to calculate water temperature timeseries.", +{bdg-dark-line}`water` `shear_rate`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to 10 /s",/s,"Shear rate at the water-sediment interface, used for calculating resuspension. Defaults to 10 /s {cite}`arvidsson_2011`.", +{bdg-dark-line}`water` `estuary_tidal_m2`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required if model domain has estuary,\-,The M2 component of the tidal harmonics.,Estuary authorities such as the Thames Port Authority +{bdg-dark-line}`water` `estuary_tidal_s2`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required if model domain has estuary,\-,The S2 component of the tidal harmonics.,Estuary authorities such as the Thames Port Authority +{bdg-dark-line}`water` `estuary_mouth_coords`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required if model domain has estuary,m,"Position of the estuary mouth as (x, y) coordinates. Used to calculute upstream estuary dimensions based on exponential regression dependent on distance to estuary mouth.",Estuary authorities such as the Thames Port Authority +{bdg-dark-line}`water` `estuary_mean_depth_expa`
`estuary_mean_depth_expb`
`estuary_width_expa`
`estuary_width_expb`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,Required if model domain has estuary,\-,"Parameters `a` and `b` controlling the dependence of the estuary mean depth or width on distance to the mouth. For example, parameters `estuary_width_expa` and `estuary_width_expb` are used to calculate the width of the estuary upstream by a distance of `d` by the relation `width = estuary_width_expa * exp(-estuary_width_expb * d)`.","Could be calibrated from vector map data showing width of rivers, or estuary monitoring data with depths" +{bdg-dark-line}`water` `estuary_meandering_factor`,{bdg-secondary}`constants.nml` {bdg-danger}`constants.yaml` ,float,"Optional, defaults to calculation based on grid size",\-,"Meandering factor to account for estuaries not being straight lines. If not present, meandering factor is estimated from the grid cell size, according to $f_m = 1.024 - 0.077 * \ln (200 / (dx + dy))$ {cite:p}`fekete_2001`.","Could be deduced from land use maps, such as [CORINE Land Cover](https://land.copernicus.eu/en/products/corine-land-cover)" diff --git a/src/Data/DataInputModule.f90 b/src/Data/DataInputModule.f90 index ad9adc5..1a88c5b 100644 --- a/src/Data/DataInputModule.f90 +++ b/src/Data/DataInputModule.f90 @@ -802,7 +802,7 @@ subroutine parseConstantsDatabase(me, constantsFile) real :: darcy_velocity, default_porosity, particle_density, & estuary_tidal_S2, estuary_mean_depth_expA, estuary_mean_depth_expB, estuary_width_expA, & estuary_width_expB, estuary_tidal_M2, estuary_meandering_factor, nm_density, river_meandering_factor, & - water_temperature, deposition_alpha, deposition_beta, bank_erosion_alpha, bank_erosion_beta, shear_rate, & + deposition_alpha, deposition_beta, bank_erosion_alpha, bank_erosion_beta, shear_rate, & min_water_temperature, max_water_temperature real(dp) :: hamaker_constant, resuspension_alpha, resuspension_beta, & resuspension_alpha_estuary, resuspension_beta_estuary, k_diss_pristine, k_diss_transformed, & @@ -837,7 +837,7 @@ subroutine parseConstantsDatabase(me, constantsFile) namelist /water/ resuspension_alpha, resuspension_beta, resuspension_alpha_estuary, resuspension_beta_estuary, & k_diss_pristine, k_diss_transformed, k_transform_pristine, estuary_tidal_m2, estuary_tidal_s2, estuary_mouth_coords, & estuary_mean_depth_expa, estuary_mean_depth_expb, estuary_width_expa, estuary_width_expb, estuary_meandering_factor, & - river_meandering_factor, water_temperature, river_attachment_efficiency, estuary_attachment_efficiency, & + river_meandering_factor, river_attachment_efficiency, estuary_attachment_efficiency, & deposition_alpha, deposition_beta, bank_erosion_alpha, bank_erosion_beta, shear_rate, min_water_temperature, & max_water_temperature, min_water_temperature_day_of_year namelist /sediment/ porosity, initial_mass, fractional_composition_distribution, & @@ -886,10 +886,11 @@ subroutine parseConstantsDatabase(me, constantsFile) resuspension_alpha_estuary = 0.0_dp resuspension_beta_estuary = 0.0_dp soil_attachment_efficiency = defaultSoilAttachmentEfficiency + darcy_velocity = defaultSoilDarcyVelocity k_diss_pristine = default_k_diss_pristine k_diss_transformed = default_k_diss_transformed k_transform_pristine = default_k_transform_pristine - estuary_meandering_factor = 0.0 + estuary_meandering_factor = 0.0 ! If meandering factors are zero, they are calculated from cell size river_meandering_factor = 0.0 porosity = 0.0 shear_rate = defaultShearRate @@ -933,8 +934,9 @@ subroutine parseConstantsDatabase(me, constantsFile) me%defaultMatrixEmbeddedDistributionToSpm = default_matrixembedded_distribution_to_spm / 100.0 me%soilDarcyVelocity = darcy_velocity me%soilDefaultPorosity = default_porosity + ! TODO Hamaker constant really should be a NM property as it depends on NM material, see https://doi.org/10.1021/es100598h me%soilHamakerConstant = hamaker_constant - me%soilParticleDensity = particle_density + me%soilParticleDensity = particle_density ! TODO can we calculate this from soil texture (clay, silt, sand) etc? me%soilConstantAttachmentEfficiency = soil_attachment_efficiency me%soilErosivity_a1 = erosivity_a1 me%soilErosivity_a2 = erosivity_a2 diff --git a/src/DefaultsModule.f90 b/src/DefaultsModule.f90 index 16aeae2..86f6790 100644 --- a/src/DefaultsModule.f90 +++ b/src/DefaultsModule.f90 @@ -72,11 +72,10 @@ module DefaultsModule ! Defaults for constants real, parameter :: defaultSoilAttachmentEfficiency = 0.0 + real, parameter :: defaultSoilDarcyVelocity = 9e-6_dp ! [m/s] Tufenkji et al, 2004: https://doi.org/10.1021/es034049r real, parameter :: default_k_diss_pristine = 0.0 real, parameter :: default_k_diss_transformed = 0.0 real, parameter :: default_k_transform_pristine = 0.0 - real, parameter :: defaultEstuaryMeanderingFactor = 1.0 - real, parameter :: defaultRiverMeanderingFactor = 1.0 real, parameter :: defaultShearRate = 10.0 ! Arvidsson et al, 2009: https://doi.org/10.1080/10807039.2011.538639 real, parameter :: defaultMinWaterTemperature = 4.0 ! Thames River real, parameter :: defaultMaxWaterTemperature = 21.0 ! Thames River diff --git a/src/GridCell/GridCellModule.f90 b/src/GridCell/GridCellModule.f90 index 01351ad..2d44290 100644 --- a/src/GridCell/GridCellModule.f90 +++ b/src/GridCell/GridCellModule.f90 @@ -112,18 +112,18 @@ function createGridCell(me, x, y, isEmpty) result(rslt) me%y, & 1, & me%n_river, & - me%area, & - me%q_precip_timeSeries, & - me%q_evap_timeSeries & + me%area, + me%q_precip_timeseries, & + me%q_evap_timeseries & ) & ) - allocate(me%colSoilProfiles(1)%item, source=soilProfile) - allocate(me%distributionSediment, source=me%colSoilProfiles(1)%item%distributionSediment) + allocate(me%colsoilprofiles(1)%item, source=soilprofile) + allocate(me%distributionsediment, source=me%colsoilprofiles(1)%item%distributionsediment) - ! Only proceed if there are no critical errors (which might be caused by parseInputData()) - if (.not. rslt%hasCriticalError()) then - ! Add RiverReaches to the GridCell (if any are present in the data file) - call rslt%addErrors(.errors. me%createReaches()) + ! only proceed if there are no critical errors (which might be caused by parseinputdata()) + if (.not. rslt%hascriticalerror()) then + ! add riverreaches to the gridcell (if any are present in the data file) + call rslt%adderrors(.errors. me%createreaches()) end if end if