the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 04 Oct 2021
LAPS v1.0.0: Lagrangian Advection of Particles at Sea, a Matlab program to simulate the displacement of particles in the ocean
Abstract. We develop a Matlab program named LAPS (Lagrangian Advection of Particles at Sea) to simulate the advection of suspended particles in the global ocean with a minimal user effort to install, set and run the simulations. LAPS uses the 3D sea current velocity fields provided by ECCO2 to track the fate of suspended particles injected in the ocean, at specific places and times, during a period of time. LAPS runs with a short configuration file set by the user and returns the distribution of the particles at the end of the advection. A continuous tracking option is also available to record the complete trajectory of the particles throughout the entire period of advection. The effect of water waves, or Stokes drift, which alter sea surface current velocities, can also be taken into account. The principle and usage of the program is detailed and then applied to three case studies. The first two cases studies are applied to suspended sediment transport. We show how LAPS simulations can be used to investigate the spatio-temporal distribution of fine particles observed by satellites in the upper ocean. We also estimated sediment deposit areas on the seafloor as a function of sediment grain sizes. The third case study simulates the dispersion of microplastic particles during a tropical cyclone, and shows how the Stokes drift, which is significant during storm events, alters the particles trajectories compared to the case where the Stokes drift is neglected.
This preprint has been withdrawn.
-
Withdrawal notice
This preprint has been withdrawn.
-
Preprint
(4293 KB)
Interactive discussion
Status: closed
-
RC1: 'Comment on gmd-2021-233', Anonymous Referee #1, 25 Oct 2021
Review of "LAPS v1.0.0: Lagrangian Advection of Particles at Sea, a Matlab program to simulate the displacement of particles in the ocean" by Mouyen et al
In this manuscript, the authors present a Matlab-based toolbox for integrating virtual particles in three-dimensional ECCO2 fields, optionally also with Stokes drift from WaveWatchIII. They show the fidelity of this code through a few examples related to tracking of sediments of the Amazon plume and plastics in the northwest Pacific Ocean.
While I strongly support the development of new Lagrangian oceanography codes, since that increases diversity and hence facilitates model comparison, I must say that I am not sure that LAPS provides sufficient unique and scientifically novel features to warrant publication in a journal like GMD. Perhaps the Journal of Open Source Software (https://joss.theoj.org/) would be a better outlet?
In particular, LAPS seems to have no added features beyond already existing codes. The authors state that its Unique Selling Point is the ease-of-use, but then leave it to the users to e.g. download the ECCO2 data themselves. They also don't discuss any tools for the analysis and plotting of the trajectory files; which is where the largest intellectual/technical challenges are for most new users. So I don't think that users without experience with running Lagrangian software can simply pick up this tool and work with it; and if they do have experience with coding then LAPS does not add much to the already-existing ecosystem of Lagrangian tools.
Beyond this fundamental problem of novelty; I also have nine major comments on the manuscript itself:
1. It is unclear whether ECCO2 and WaveWatch are in fact consistent products. Figure 1 suggests that the Stokes drift does not leave any imprint in the currents, which is strange. Are they forced by the same data products? If not, what is the impact of that?
2. There is no mention at all on the type of interpolation schemes used. Are they linear? Spline? What about temporal interpolation? How is beaching treated?
3. Algorithm 1 suggests that the timestepping scheme is simple Euler Forward? This is known to be very inaccurate. Have the authors tested this?
4. The WaveWatchIII data is interpolated to the finer ECCO2 data as this reduces interpolation time; but the authors do not mention that of course this increases storage and/or memory.
5. The unit-testcase in lines 152-160 is extremely trivial, and does not test most of the interpolation and integration schemes. I strongly encourage more thorough testing with more complex (analytical) flows
6. The discussion on depth-dependence of Stokes drift is fairly simplistic. How about the return flow discussed in e.g. Van den Bremer and Breivik? Can that be incorporated too?
7. The runtime tests are only done for very small particle umbers. Meaningful Lagrangian oceanography experiments use at least 10^5 or 10^6 particles, which is 100-1000 times larger than the tests here. How scalable is the code to these numbers of particles?
8. The assessment of model skill in Figure 4 is rather meaningless. First of all, it tests the fidelity of the ECCO2 flow fields, more than the LAPS code. And secondly, the statement that the errors are 'reasonable' (line 181) is rather meaningless. Why are these standard deviations reasonable? How did the authors decide? It would have been much stronger to have an independent criterium for accepting the fidelity
9. The analyses in Figures 7 and 8 are done with an extremely low number of particles, so there is no statistical significance at all to these results. I strongly recommend to either do these analyses much more carefully, or not at all.
Smaller comments
- line 43: Are these particles infinitesimally small? Or do they have some inertia too?
- line 49: is the 15-minute timestep hardcoded? How is it chosen? Some kind of CFL-criterium? Would it not depend also on the domain?
- line 56: Does the algorithm deal with periodic boundaries too (i.e. if the particles occupy a small region straddled by the zonal domain boundary in ECCO2 )?
- line 57: Why choose 6 degrees halo? Where does this choice come from? Is it hardcoded?
- line 98: why are these values for kappa and z_0 chosen? Are they hardcoded?
- Fig 2: Would it make sense to flip the y-axis so that (negative) depth is downward?
- line 110: Where does this equation 4 come from? This is only valid for certain range of D, right? Is this checked in the programme, so that users don't run with too large values of D?
- Table 1: I don't really see the relevance of this table for the manuscript. Leave out?
- line 111: Why is \rho_s a constant? Why not compute it directly from the ECCO2 temperature and salinity fields? That would be much more accurate!
- line 119: How is this probability defined? Is it spatially variable?
- line 143: Do I understand this statement correctly that the full particle trajectories are stored in memory?? How scalable is this, for millions of particles and thousands of time steps?
- line 168: The assumption that a drogued drifter drifts with the velocities at 15m is too simplistic. In reality, it integrates the velocities over the extent of the drogue. This would be a much better way to simulate drogued driftersCitation: https://doi.org/10.5194/gmd-2021-233-RC1 -
RC2: 'Comment on gmd-2021-233', Anonymous Referee #2, 05 Nov 2021
In this paper the authors present LAPS, a Matlab program to simulate Lagrangian advection of particles under the influence of oceanic circulation, gravity and, optionally, wave action. The simulation time stepping is fixed to 15 minutes and particle injection can either be fixed, gradual or both, with input data restricted to ECCO2 velocity and Stokes velocity fields for wave action drift. The paper presents a range of validation experiments, highlighting the impact of the Stokes drift and particle sinking features of the code on the simulation results, while highlighting the ease of use of LAPS throughout.
Unfortunately, however, beyond the introduction of a new software implementation, no distinctly novel features are presented and little discussion is provided on the challenges and trade-offs in developing Lagrangian particle tracking software. A further lack of direct comparison to existing software frameworks makes it hard to assess LAPS' role in the existing ecosystem of Lagrangian oceanography tools. No discussion is provided on the choice of interpolation schemes or the lack of parallelism in the software framework that seems to underpin the overall low number of particles used throughout the validation experiments.
More detailed comments on individual sections of the paper:
- p 2, l. 27; Only a single link to and overview to alternative software packages. A brief comparison of major differences to other software packages that points out major differnces explicitly would be preferable over a link to a general review paper.
- p. 3, l. 63: "Note that the program does not support parallel computing." Given the fairly low number of particles cited for runtime evaluation later in the paper that seems like a pretty substantial limitation. Putting the responsibility on the user to split the input files goes very much against the "ease of use" argument that seems to underpin this paper.
- p. 7, Table 2: There is little useful information conveyed in this table beyond the obvious "more partciles take more time". A more detailed breakdown of single-core performance of individual components (eg. tracking vs. no tracking, I/O overheads or normalised runtime per particle) could help make this more relevant to the paper.
- p. 8, l. 152: This seems to imply linear temporal interpolation, and bi/tri-linear spatial interpolation. It would be good to explicitly mention the interpolation schemes used and possibly give a brief rationale for the implemented choices over other methods, such as cubic or spline interpolation.
- p. 9, Figure 3: It is unclear to me what this figure adds to the paper, since no explanation or discussion is on the partcicular cases is provided.
- p. 10, Figure 4 and line 180: "Given the area covered by the global ocean, we consider that the standard deviations obtained with LAPS are reasonable." On what grounds is that based? Are there any other metrics that could strengthen this arguments?
- p. 13, l. 206: "The simulation cannot account for all processes". While there are some similarities between the simulation and the observations, and matching the full pattern is clearly challenging, I feel that a more detailed discussion and potential investigation of causes would improve this section significantly. For example, the April simulation seems to spread further south than the observations; or the July simulation seems to stick closer to the coast line than observations. Are these discrepancies purely limitations of the spatial resolution of the velocity data, or could numerical artefacts and implementation details play a role here? In addition, a visual illustration of the starting condition might also help to make the experiment setup more accessible to the reader.
- p. 16, l. 270; "A variety of factors, such as plastic density, shape, particle size, biofouling, waves, are controling the sinking of particles." One of the potential application areas of Lagrangian particle models, such as LAPS, is exploring new models and mechansms to account for such processes. Future plans for extension, or a discussion on the ease with which such extension could be added to a model could add value to the paper, either here or in the final evaluation section.
Citation: https://doi.org/10.5194/gmd-2021-233-RC2
Interactive discussion
Status: closed
-
RC1: 'Comment on gmd-2021-233', Anonymous Referee #1, 25 Oct 2021
Review of "LAPS v1.0.0: Lagrangian Advection of Particles at Sea, a Matlab program to simulate the displacement of particles in the ocean" by Mouyen et al
In this manuscript, the authors present a Matlab-based toolbox for integrating virtual particles in three-dimensional ECCO2 fields, optionally also with Stokes drift from WaveWatchIII. They show the fidelity of this code through a few examples related to tracking of sediments of the Amazon plume and plastics in the northwest Pacific Ocean.
While I strongly support the development of new Lagrangian oceanography codes, since that increases diversity and hence facilitates model comparison, I must say that I am not sure that LAPS provides sufficient unique and scientifically novel features to warrant publication in a journal like GMD. Perhaps the Journal of Open Source Software (https://joss.theoj.org/) would be a better outlet?
In particular, LAPS seems to have no added features beyond already existing codes. The authors state that its Unique Selling Point is the ease-of-use, but then leave it to the users to e.g. download the ECCO2 data themselves. They also don't discuss any tools for the analysis and plotting of the trajectory files; which is where the largest intellectual/technical challenges are for most new users. So I don't think that users without experience with running Lagrangian software can simply pick up this tool and work with it; and if they do have experience with coding then LAPS does not add much to the already-existing ecosystem of Lagrangian tools.
Beyond this fundamental problem of novelty; I also have nine major comments on the manuscript itself:
1. It is unclear whether ECCO2 and WaveWatch are in fact consistent products. Figure 1 suggests that the Stokes drift does not leave any imprint in the currents, which is strange. Are they forced by the same data products? If not, what is the impact of that?
2. There is no mention at all on the type of interpolation schemes used. Are they linear? Spline? What about temporal interpolation? How is beaching treated?
3. Algorithm 1 suggests that the timestepping scheme is simple Euler Forward? This is known to be very inaccurate. Have the authors tested this?
4. The WaveWatchIII data is interpolated to the finer ECCO2 data as this reduces interpolation time; but the authors do not mention that of course this increases storage and/or memory.
5. The unit-testcase in lines 152-160 is extremely trivial, and does not test most of the interpolation and integration schemes. I strongly encourage more thorough testing with more complex (analytical) flows
6. The discussion on depth-dependence of Stokes drift is fairly simplistic. How about the return flow discussed in e.g. Van den Bremer and Breivik? Can that be incorporated too?
7. The runtime tests are only done for very small particle umbers. Meaningful Lagrangian oceanography experiments use at least 10^5 or 10^6 particles, which is 100-1000 times larger than the tests here. How scalable is the code to these numbers of particles?
8. The assessment of model skill in Figure 4 is rather meaningless. First of all, it tests the fidelity of the ECCO2 flow fields, more than the LAPS code. And secondly, the statement that the errors are 'reasonable' (line 181) is rather meaningless. Why are these standard deviations reasonable? How did the authors decide? It would have been much stronger to have an independent criterium for accepting the fidelity
9. The analyses in Figures 7 and 8 are done with an extremely low number of particles, so there is no statistical significance at all to these results. I strongly recommend to either do these analyses much more carefully, or not at all.
Smaller comments
- line 43: Are these particles infinitesimally small? Or do they have some inertia too?
- line 49: is the 15-minute timestep hardcoded? How is it chosen? Some kind of CFL-criterium? Would it not depend also on the domain?
- line 56: Does the algorithm deal with periodic boundaries too (i.e. if the particles occupy a small region straddled by the zonal domain boundary in ECCO2 )?
- line 57: Why choose 6 degrees halo? Where does this choice come from? Is it hardcoded?
- line 98: why are these values for kappa and z_0 chosen? Are they hardcoded?
- Fig 2: Would it make sense to flip the y-axis so that (negative) depth is downward?
- line 110: Where does this equation 4 come from? This is only valid for certain range of D, right? Is this checked in the programme, so that users don't run with too large values of D?
- Table 1: I don't really see the relevance of this table for the manuscript. Leave out?
- line 111: Why is \rho_s a constant? Why not compute it directly from the ECCO2 temperature and salinity fields? That would be much more accurate!
- line 119: How is this probability defined? Is it spatially variable?
- line 143: Do I understand this statement correctly that the full particle trajectories are stored in memory?? How scalable is this, for millions of particles and thousands of time steps?
- line 168: The assumption that a drogued drifter drifts with the velocities at 15m is too simplistic. In reality, it integrates the velocities over the extent of the drogue. This would be a much better way to simulate drogued driftersCitation: https://doi.org/10.5194/gmd-2021-233-RC1 -
RC2: 'Comment on gmd-2021-233', Anonymous Referee #2, 05 Nov 2021
In this paper the authors present LAPS, a Matlab program to simulate Lagrangian advection of particles under the influence of oceanic circulation, gravity and, optionally, wave action. The simulation time stepping is fixed to 15 minutes and particle injection can either be fixed, gradual or both, with input data restricted to ECCO2 velocity and Stokes velocity fields for wave action drift. The paper presents a range of validation experiments, highlighting the impact of the Stokes drift and particle sinking features of the code on the simulation results, while highlighting the ease of use of LAPS throughout.
Unfortunately, however, beyond the introduction of a new software implementation, no distinctly novel features are presented and little discussion is provided on the challenges and trade-offs in developing Lagrangian particle tracking software. A further lack of direct comparison to existing software frameworks makes it hard to assess LAPS' role in the existing ecosystem of Lagrangian oceanography tools. No discussion is provided on the choice of interpolation schemes or the lack of parallelism in the software framework that seems to underpin the overall low number of particles used throughout the validation experiments.
More detailed comments on individual sections of the paper:
- p 2, l. 27; Only a single link to and overview to alternative software packages. A brief comparison of major differences to other software packages that points out major differnces explicitly would be preferable over a link to a general review paper.
- p. 3, l. 63: "Note that the program does not support parallel computing." Given the fairly low number of particles cited for runtime evaluation later in the paper that seems like a pretty substantial limitation. Putting the responsibility on the user to split the input files goes very much against the "ease of use" argument that seems to underpin this paper.
- p. 7, Table 2: There is little useful information conveyed in this table beyond the obvious "more partciles take more time". A more detailed breakdown of single-core performance of individual components (eg. tracking vs. no tracking, I/O overheads or normalised runtime per particle) could help make this more relevant to the paper.
- p. 8, l. 152: This seems to imply linear temporal interpolation, and bi/tri-linear spatial interpolation. It would be good to explicitly mention the interpolation schemes used and possibly give a brief rationale for the implemented choices over other methods, such as cubic or spline interpolation.
- p. 9, Figure 3: It is unclear to me what this figure adds to the paper, since no explanation or discussion is on the partcicular cases is provided.
- p. 10, Figure 4 and line 180: "Given the area covered by the global ocean, we consider that the standard deviations obtained with LAPS are reasonable." On what grounds is that based? Are there any other metrics that could strengthen this arguments?
- p. 13, l. 206: "The simulation cannot account for all processes". While there are some similarities between the simulation and the observations, and matching the full pattern is clearly challenging, I feel that a more detailed discussion and potential investigation of causes would improve this section significantly. For example, the April simulation seems to spread further south than the observations; or the July simulation seems to stick closer to the coast line than observations. Are these discrepancies purely limitations of the spatial resolution of the velocity data, or could numerical artefacts and implementation details play a role here? In addition, a visual illustration of the starting condition might also help to make the experiment setup more accessible to the reader.
- p. 16, l. 270; "A variety of factors, such as plastic density, shape, particle size, biofouling, waves, are controling the sinking of particles." One of the potential application areas of Lagrangian particle models, such as LAPS, is exploring new models and mechansms to account for such processes. Future plans for extension, or a discussion on the ease with which such extension could be added to a model could add value to the paper, either here or in the final evaluation section.
Citation: https://doi.org/10.5194/gmd-2021-233-RC2
Data sets
Datasets for "LAPS v1.0.0: Lagrangian Advection of Particles at Sea, a Matlabprogram to simulate the displacement of particles in the ocean." Maxime Mouyen, Romain Plateaux, Alexander Kunz, Philippe Steer, Laurent Longuevergne https://doi.org/10.5281/zenodo.5524113
Model code and software
LAPS Maxime Mouyen https://zenodo.org/record/5187707
Video supplement
Simulations of ocean plastic littering Alexander Kunz https://doi.org/10.6084/m9.figshare.16667302.v1
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 1,358 | 431 | 55 | 1,844 | 36 | 38 |
- HTML: 1,358
- PDF: 431
- XML: 55
- Total: 1,844
- BibTeX: 36
- EndNote: 38
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1