the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
ChemicalDrift 1.0: an open-source Lagrangian chemical fate and transport model for organic aquatic pollutants
- 1The Norwegian Meteorological Institute, Bergen, Norway
- 2Department of Environmental Sciences, Informatics and Statistics, University Ca’ Foscari of Venice, Venice, Italy
- 3CNR - National Research Council of Italy, ISMAR - Institute of Marine Sciences, Venice, Italy
- 4University of Bergen, Bergen, Norway
- 1The Norwegian Meteorological Institute, Bergen, Norway
- 2Department of Environmental Sciences, Informatics and Statistics, University Ca’ Foscari of Venice, Venice, Italy
- 3CNR - National Research Council of Italy, ISMAR - Institute of Marine Sciences, Venice, Italy
- 4University of Bergen, Bergen, Norway
Abstract. A new model for transport and fate of chemicals in the aquatic environment is presented. The tool, named ChemicalDrift, is integrated in the open-source Lagrangian framework OpenDrift, and is hereby presented for organic compounds. The supported chemical processes include the degradation, the volatilization, and the partitioning between the different phases that a target chemical can be associated to in the aquatic environment, e.g. dissolved, bound to suspended particles, or deposited to the seabed sediments. The dependencies of the chemical processes on changes of temperature, salinity, and particle concentration, are formulated and implemented. The chemical fate modelling is combined with wide support for hydrodynamics by the integration within the Lagrangian framework which provides, e.g., advection by ocean currents, diffusion, wind induced turbulent mixing, and Stokes drift generated by waves. A powerful interface to a wide range of available metocean data is made available by the integration, making the tool flexible and adaptable to different spatio-temporal scales and fit for modelling of complex coastal regions. Further inherent capabilities of the Lagrangian approach include the seamless tracking and separation of multiple sources as, e.g., pollutants emitted from ships or from rivers or water treatment plants. Specific interfaces to a dataset produced by a model of emissions from shipping, and to an unstructured-grid oceanographic model of the Adriatic Sea, are provided. The model includes a database of chemical parameters for a set of poly-aromatic hydrocarbons, and a database of emission factors for different chemicals found in discharged waters from sulphur emission abatements systems in marine vessels. A post-processing tool for generating mean concentrations of a target chemical, over customizable spatio-temporal grids, is provided. Model development and functional testing are presented, while tuning of parameters, validation, and reporting of numerical results, are planned as future activities. The ChemicalDrift model flexibility, functionalities, and potential, are demonstrated through a selection of examples, introducing the model as a valuable tool for chemical fate and transport, that can be applied to assessment of the risks of contamination by organic pollutants in the aquatic environment.
Manuel Aghito et al.
Status: open (extended)
-
AC1: 'Comment on gmd-2022-212', Manuel Aghito, 14 Nov 2022
reply
three typos found in Table2 to be fixed in final version.
Corrected values (used in the code) are:
Naphthalene
ΔHKOC,SPM = -21036
Phenanthrene
ΔHKOC,SPM = -24900
ΔHKOC,DOM = -25900
-
RC1: 'Comment on gmd-2022-212', Anonymous Referee #1, 24 Nov 2022
reply
Review of "ChemicalDrift 1.0: an open-source Lagrangian chemical fate and transport model for organic aquatic pollutants" by Aghito et al.
In this manuscript, the authors present a new modelling framework for organic pollutants, built on the OpenDrift framework. They apply the framework to three different examples, in the Baltic, North and Adriatic Seas.
The manuscript is generally well-written and easy to follow and navigate through. The figures are clear, and the inclusion of a code snippets gives a nice impression of the ease-of-use for the users in using the model. I can imagine that this manuscript is a good reference for new users of the model.
However, I do have a few very serious concerns that avoid me from recommending this manuscript for publication in GMD:
- There is essentially no validation of the code. How confident are the authors that the code works as intended? They mention functional testing in the abstract, but I could not find that in the manuscript body. Also, is there any unit testing?
- The authors also do not present any performance assessment. How does the code scale with number of elements? Can it work in parallel (OpenMP, MPI?) mode? What is the memory footprint of the additional codes, compared to the rest of OpenDrift? How is IO dealt with?
- In the examples, there is no assessment of the sensitivity of the results to choices like integration time-step, number of modeled elements, input/output-frequency etc; making it difficult for the reader to gauge how robust the results are to the user parameters.
- The code builds heavily on OpenDrift itself, and is in some way an obvious further extension of the Radionuclides extension. Most of the new code is simply an implementation of physical equations, presented without much numerical or computational consideration.
- Because of the four points above, I seriously doubt that this manuscript falls within the scope of GMD. The way it is presented, it feels more like an application of OpenDrift to a few very specific chemical processes within the context of a European project; rather than a versatile and potentially widely useable community code. Perhaps another journal (e.g. on marine pollution) might be more relevant for this work?
Furthermore, I also have some minor comments and suggestions:
- lines 8, 18, 221, 423 and other locations: At places, words like 'powerful', 'valuable', etc make it sound more like a sales-pitch than a self-critical scientific assessment. I suggest to be very careful with this self-congratulatory framing.
- line 26: Can it be assumed that all readers know what a Lagrangian model is? Also, OpenDrift could be explained in more depth
- line 66: what is a 'severe' oil spill? Why would it not work for non-severe oil spills?
- line 67: this wording suggests that the only difference between OilDrift and ChemicalDrift is the concentrations that can be tracked; but I think there are many more differences? Perhaps rephrase?
- line 73: mention here already that (re-)deposition is not taken into account?
- line 74: I don't think this statement is meant to imply that only findings from open-access literature is used (so ignoring closed-access literature)? Perhaps rephrase?
- line 85. Fig 1 caption and further: I am a bit confused whether the terms 'compartment' and 'phase' refer to the same concept, or something different. If they are the same, I suggest using only one of the terms throughout
- line 168: 'neglected' is not the right word here. Vertical velocity is a diagnostic variable in most ocean models
- line 172-174: How good is this assumption here? What is the typical error made when using this assumption in realistic scenarios?
- line 175-179: what is the physical interpretation and motivation behind this parameterization?
- line 226: k should be type-set in mathmode?
- Table 3: I'm a bit surprised that the authors use the interpolated CMEMS data here. Why not the non-interpolated original version of PHY on the MOi servers at e.g. https://www.mercator-ocean.eu/en/solutions-expertise/accessing-digital-data/product-details/?offer=4217979b-2662-329a-907c-602fdc69c3a3&system=d35404e4-40d3-59d6-3608-581c9495d86a (which also includes vertical velocity)
- line 355: while helpful for visualisation, I fear that such a representation of element 'mass' by size might be a bit misleading to some readers, who may not appreciate that elements don't actually have an actual 'size'
- line 363: 'is demonstrated'
- line 367: The statement about the Lagrangian framework here is a bit misleading. It would be perfectly possibly to run two separate tracers in an Eulerian framework and that way also separate the sources. The Lagrangian framework does have advantages, but the way it's formulated now is not one of them
-
AC2: 'Reply on RC1', Manuel Aghito, 01 Dec 2022
reply
We thank the reviewer for the useful comments. While we need to wait for feedback from all reviewers before we can give a complete and detailed answer and update the manuscript accordingly, we would like to quickly address some of the important issues pointed out.
Hope this will help understanding our choices, and we will of course try to motivate them better in the manuscript if we were not clear.
Review of "ChemicalDrift 1.0: an open-source Lagrangian chemical fate and transport model for organic aquatic pollutants" by Aghito et al.
In this manuscript, the authors present a new modelling framework for organic pollutants, built on the OpenDrift framework. They apply the framework to three different examples, in the Baltic, North and Adriatic Seas.
The manuscript is generally well-written and easy to follow and navigate through. The figures are clear, and the inclusion of a code snippets gives a nice impression of the ease-of-use for the users in using the model. I can imagine that this manuscript is a good reference for new users of the model.
However, I do have a few very serious concerns that avoid me from recommending this manuscript for publication in GMD:
---
1. There is essentially no validation of the code. How confident are the authors that the code works as intended? They mention functional testing in the abstract, but I could not find that in the manuscript body. Also, is there any unit testing?
Yes, “functional testing” was used improperly, we meant “testing of the model functionalities”, we can rephrase. Unit testing is extensively used in OpenDrift, and thus also covers the components of the new module chemicaldrift.py, except for the chemistry calculations.
Regarding validation, our strategy is to describe the model in this manuscript, which does provide some simple verification of the equations, and provide extensive evaluation in follow-up papers, where we will provide simulations on regional and European scale. This approach is also suggested in the GMD guidelines for Model description papers, quoted “Where evaluation is very extensive, a separate paper focussed solely on this aspect may be submitted” (https://www.geoscientific-model-development.net/about/manuscript_types.html#item1) and would also fit very well with the main author publication plan for the PhD degree.
The general drift and mixing parameterisations in OpenDrift are addressed and validated in many papers using OpenDrift (see https://opendrift.github.io/references.html).
The modeled processes (partitioning, degradation, and volatilization) are implemented based on formulations used in other chemical fate models, like for example the Aquatox tool by the US Environmental Protection Agency, or provided by reference textbooks like Schwarzenbach, Gschwend, Imboden - Environmental Organic Chemistry, so it is expected that these processes are calculated correctly.
The novelty is the integration of aquatic chemistry within OpenDrift, which allows to model the chemical processes at various scales and with seamless update of important parameters like temperature, salinity, mixed layer depth, SPM concentration, and to study the combined effect of ocean physics and chemistry.
We provide some simple verification that the chemical equations work as expected with the given examples, like in Fig.8, showing the expected effect of temperature and salinity on the chemical partitioning, or in Figs. 3-7, showing that chemical mass is reduced exponentially due to degradation and volatilization, and comparing the fate of two different chemicals, which is also consistent with our expectations since benzo(a)pyrene is much less volatile and has higher affinity to particles than naphthalene.
A comprehensive evaluation of the overall model is indeed very challenging. Concentrations of pollutants in the water column in marine environments are often lower than instruments limits of detection and cannot be measured. We can’t validate if we don’t have sufficient data. Moreover, chemicals in the environment are not released by a single point source like for example would be the case in a petroleum accident, so also the task of collecting all possible contamination sources (directly released to the sea by e.g. ships or oil platforms, or discharged from rivers, water treatment plants, factories, or deposited from the atmosphere) is very difficult in itself.
Nevertheless, ecotoxicological studies show that chemicals like PAHs and heavy metals can be harmful to marine species at very low concentrations, so it is important to develop tools for predicting the concentrations.
It would be a very long shot if we were attempting to provide a validation and then claiming that the model would be applicable in general, with different environmental conditions, input data obtained from different sources, and different scales.
It is more reasonable to perform parameter tuning, model calibration, and model evaluation in specific case studies. This is planned in ongoing activities and will be addressed in follow-up papers.
---
2. The authors also do not present any performance assessment. How does the code scale with number of elements? Can it work in parallel (OpenMP, MPI?) mode? What is the memory footprint of the additional codes, compared to the rest of OpenDrift? How is IO dealt with?
Trajectory calculations are difficult to parallelize in general, but many sub-components (bottlenecks) of OpenDrift are parallelized using e.g. multiprocessing module.
We have actually worked with parallelization with ChemicalDrift after the submission of the manuscript. This has been implemented using Python multiprocessing library, splitting a simulation in 64 subprocesses, each applied to chemicals discharged in separate longitude intervals, and this gave a strong reduction of the simulation time. We can simulate for example open loop scrubbers emissions of a selected chemical for a whole year (2018) and for the whole European region, using approximately 900000 Lagrangian elements, in less than 2 hours on our HPC.
The IO is inherited from OpenDrift, and is based on export to CF-compliant netCDF files, and generic import (readers), see https://doi.org/10.5194/gmd-11-1405-2018, 2018.
---
3. In the examples, there is no assessment of the sensitivity of the results to choices like integration time-step, number of modeled elements, input/output-frequency etc; making it difficult for the reader to gauge how robust the results are to the user parameters.
Sensitivity analysis is of course very important and needs to be performed. This should include physical parameters, chemical parameters, and numerical parameters like time-step and number of model elements. Given the large number of parameters and the broad range of variability and uncertainties of these, sensitivity analysis is also expected to provide different conclusions in different case studies. To give an example, while in one case study we might have accurate measurements of KOC and fOC, we know that in general these parameters are subject to huge variations in the environment. Hence, our plan has been to address sensitivity analysis as a step of model verification in follow-up papers focussing on specific case studies.
---
4. The code builds heavily on OpenDrift itself, and is in some way an obvious further extension of the Radionuclides extension. Most of the new code is simply an implementation of physical equations, presented without much numerical or computational consideration.
We focussed on describing the novelty, which is the integration of the chemistry of organic compounds in the OpenDrift framework. This is not in OpenDrift, and not in Radionuclides. All equations described in the manuscript correspond to new code implemented in ChemicalDrift.
The numerical framework is indeed largely inherited from OpenDrift, hence the focus of this manuscript is on the chemical processes, and not the numerical implementation.
---
5. Because of the four points above, I seriously doubt that this manuscript falls within the scope of GMD. The way it is presented, it feels more like an application of OpenDrift to a few very specific chemical processes within the context of a European project; rather than a versatile and potentially widely useable community code. Perhaps another journal (e.g. on marine pollution) might be more relevant for this work?
The chemical processes handled within ChemicalDrift are general, and not limited to the specific EMERGE project, although it provided funding for the development. The model can easily be used in many other applications where risk assessment of contamination of organic pollutants is useful: discharges from shipping in general, fish farms, produced waters for oil platforms, discharges from rivers, water treatment plants, deep sea mining. The integration within OpenDrift, which provides a very flexible and simple interface, will facilitate the use of ChemicalDrift in other applications.
Moreover, ChemicalDrift can easily be extended to other types of chemicals, like for example ionizable compounds, and heavy metals, and updates made after the submission of the manuscript are already available on the github repository.
The examples given in the paper are only preliminary demonstrations, presented without any quantitative analysis, for the scope of describing the model. The examples are based on EMERGE data since this is the project we have been working on. We think that follow-up papers presenting and analyzing simulation results might indeed be more suited to another journal with more focus on environmental chemistry.
-
AC3: 'Code and Data gmd-2022-212', Manuel Aghito, 01 Dec 2022
reply
Code and data for all simulations presented in the manuscript is available here
https://doi.org/10.5281/zenodo.7249446
-
CEC1: 'Reply on AC3', Juan Antonio Añel, 12 Dec 2022
reply
Dear authors,
Many thanks for publishing your code and data on Zenodo.org. I want to ask you another thing: please, could you publish the code alone in a separate repository? Currently, it is necessary to download all the data (several GB) to check the code, which is a tedious process. This way, readers and reviewers could check it independently of the data.
It would be enough to create a new Zenodo repository only with the code and add to the manuscript both the DOI of the current one and the new one.
Juan A. Añel
Geosci. Model Dev. Executive Editor
-
AC4: 'Reply on CEC1', Manuel Aghito, 12 Dec 2022
reply
Thank you very much for the good suggestion. The code without the data is ow available here https://doi.org/10.5281/zenodo.7429158
-
AC4: 'Reply on CEC1', Manuel Aghito, 12 Dec 2022
reply
-
CEC1: 'Reply on AC3', Juan Antonio Añel, 12 Dec 2022
reply
Manuel Aghito et al.
Manuel Aghito et al.
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 428 | 90 | 18 | 536 | 6 | 4 |
- HTML: 428
- PDF: 90
- XML: 18
- Total: 536
- BibTeX: 6
- EndNote: 4
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1