the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
The Lagrangian moisture source and transport diagnostic WaterSip V3.2
Abstract. WaterSip is a diagnostic software tool that identifies the evaporation sources and transport pathways of precipitation or water vapour over a target area based on Lagrangian model output. In addition to the geographic location, WaterSip identifies select thermodynamic properties of the moisture sources, during atmospheric transport, and during arrival over the target area. WaterSip software thereby employs the Lagrangian diagnostic algorithm for quantitative moisture source accounting of Sodemann et al. (2008b). The software tool requires output from Lagrangian particle dispersion models or trajectory models as input for the diagnostic. Moisture sources are then identified from changes in specific humidity along these trajectories at each output time step. The ratio between changes in specific humidity and the specific humidity of the air parcel allow to estimate the quantitative contribution of a moisture source to the air parcel at a specific time and location. Together with the temporal sequence, this provides the basis for identifying moisture source contributions to the final precipitation. WaterSip also identifies and aggregates further thermodynamic and geographic properties of the moisture source and during the moisture transport. Designed to operate on large datasets of regional to global domain-filling trajectories, WaterSip provides the results of the moisture source identification as gridded information in a variety of output files in netCDF format. This paper describes the relevant methodological foundations, the technical set-up and configuration, and provides a consistent example case study to illustrate the use and interpretation of the software tool and its results. Importantly, key uncertainties and caveats are described and discussed throughout the text. Users of WaterSip should be aware of these uncertainties to obtain a valid and reliable interpretation of the diagnostic results.
- Preprint
(4458 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on egusphere-2025-574', Anonymous Referee #1, 18 Mar 2025
This manuscript presents a comprehensive update and documentation of the WaterSip software (version 3.2), a diagnostic tool for identifying moisture sources and transport pathways associated with precipitation and atmospheric water vapour. The tool implements the Lagrangian diagnostic framework originally introduced by Sodemann et al. (2008), and offers support for trajectory data from models such as LAGRANTO and FLEXPART.
The manuscript is technically detailed and contains extensive explanations of the algorithmic structure, parameter configuration, example case setup, and diagnostic outputs. It represents a valuable contribution to the hydrometeorological community, particularly those using Lagrangian methods for moisture tracking. However, there are several areas where the manuscript could be improved significantly, especially in the following aspects:
- Validation of diagnostic results through comparison with observations or alternative algorithms;
- Technical clarity on certain assumptions and limitations;
- Demonstration of robustness and sensitivity through more systematic experiments;
- Improved structure and clarification of key terminology for broader accessibility.
I recommend major revisions before this manuscript is accepted for publication.
1. Lack of Model Validation and Performance Benchmarking
While the algorithmic principles of WaterSip are well-founded, the manuscript lacks quantitative validation of the diagnostic results. In particular:
- No comparison with independent observational datasets (e.g., precipitation from GPM/IMERG or ERA5 reanalysis P);
- No benchmarking against other Lagrangian diagnostics, such as WAM-2layers, FLEXPART-WATER, or isotope-enabled models (e.g., COSMOiso);
- The Lagrangian precipitation estimate P~\tilde{P}P~ is claimed to have an error of 20–30%, yet this is not demonstrated empirically in the paper.
Recommendation: Include a comparison of WaterSip-derived precipitation estimates and source regions against satellite/reanalysis precipitation and/or results from other established methods. This would help quantify accuracy and justify the use of default parameters (e.g., RHc, ∆q thresholds).
2. Insufficient Sensitivity Experiments
The diagnostic depends heavily on multiple user-defined thresholds, such as:
- Moisture uptake threshold (∆qc),
- Precipitation threshold (∆qp),
- Critical relative humidity (RHc),
- Trajectory length (L) and time step (∆t),
- Boundary-layer height scale (sh).
While some default values are provided, the manuscript does not present any systematic sensitivity tests to justify these defaults or examine result variability.
Recommendation: Provide at least one sensitivity experiment (e.g., with RHc = 60%, 80%, 90% or ∆qc = 0.1, 0.2, 0.3 g/kg/6h) using the Scandinavia case to demonstrate how output fields (e.g., source footprints, P̃) are affected. This will help users understand uncertainty and robustness.
3. Ambiguity in Treatment of Mixing vs. Precipitation
The distinction between moisture losses due to precipitation vs. dry mixing is briefly described but remains ambiguous in practical terms:
- How are “mixing events” defined and treated in the accounting algorithm?
- Are they excluded from precipitation source attribution entirely?
- How does this impact attribution over dry regions or under sub-saturated conditions?
Recommendation: Include a dedicated subsection clarifying how dry mixing events are separated and whether/how they influence the fractional contribution calculation. Provide a sample output or visualization that isolates these cases.
4. Limited Scope of Case Study
The case study over Scandinavia is informative but lacks depth and generality:
- It only covers a short period (10–20 Aug 2022) with one configuration;
- There is no validation of the Lagrangian precipitation estimates against ERA5 or in-situ observations;
- The transport features are discussed qualitatively without statistical summaries (e.g., source region contributions by %).
Recommendation:
- Add a second case study (e.g., a winter event or tropical cyclone) to demonstrate versatility;
- Include plots/tables showing the percent contribution of major source regions (e.g., local vs. oceanic);
- Overlay gridded WaterSip P~\tilde{P}P~ with observational data (e.g., E-OBS or GPCC).
5. No Performance or Computational Cost Analysis
Given the tool is designed for high-volume Lagrangian data, its computational performance, memory usage, and scalability are essential for practical adoption:
Recommendation: Add a short section or table reporting:
- Typical runtime and memory usage for the example case;
- Speedup with OpenMP threads;
- Bottlenecks or limitations for large-scale usage.
Minor Comments & Suggestions
-
Clarify terminology early (Section 1):
- Define “uptake”, “accounting”, “residual moisture”, and “arrival grid” explicitly.
- Consider a graphical workflow diagram.
-
Equations (6)–(9):
- Include variable definitions in-line with the equations, especially for readers not familiar with the 2008 method.
-
Section 2.5: Too long and fragmented. Suggest splitting into:
- "Core algorithm parameters" (∆q, RHc, sh),
- "Grid and output configuration",
- "Optional diagnostics".
-
Figures:
- Add scale bars and legends (e.g., units in mm/day);
- Some figures lack clarity (e.g., Fig. 2d – difficult to read e-p shading);
- Add observational overlay for better interpretation.
-
Code availability: Ensure a DOI or stable link is provided. Consider creating a GitHub/Zenodo archive.
-
Language & Style:
- Mostly clear, but some long and nested sentences in Section 2–3 could be simplified.
- Example: “Air parcels will only be retained for analysis…” → split into clearer bullet rules.
Conclusion
The manuscript presents a valuable and much-needed technical documentation of WaterSip V3.2 and the Lagrangian moisture source diagnostic algorithm. However, to be suitable for publication in a journal such as GMD or HESS Discussions, the following critical issues must be addressed:
- Quantitative validation of results,
- Sensitivity and uncertainty analysis,
- Clear treatment of physical assumptions (e.g., mixing vs. precipitation),
- Extended and comparative case studies.
Citation: https://doi.org/10.5194/egusphere-2025-574-RC1 - AC2: 'Reply on RC1', Harald Sodemann, 02 Jun 2025
-
CEC1: 'Comment on egusphere-2025-574', Juan Antonio Añel, 21 Mar 2025
Dear authors,
Unfortunately, after checking your manuscript, it has come to our attention that it does not comply with our "Code and Data Policy".
https://www.geoscientific-model-development.net/policies/code_and_data_policy.html
You have archived your code on a Git site. However, Git sites are not suitable for scientific publication. Therefore, the current situation with your manuscript is irregular. Please, publish your code in one of the appropriate repository (you can check our policy for examples) and reply to this comment with the relevant information (link and a permanent identifier for it (e.g. DOI)) as soon as possible, as we can not accept manuscripts in Discussions that do not comply with our policy.Please, note that if you do not fix this problem, we will have to reject your manuscript for publication in our journal.
Also, remember that you must include a modified 'Code and Data Availability' section in a potentially reviewed manuscript, containing the link and identifier of the new repository.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-574-CEC1 -
AC1: 'Reply on CEC1', Harald Sodemann, 22 Mar 2025
As requested, the model source code is now available on the zenodo archive at https://zenodo.org/records/15068066.
Best regards,
Harald Sodeann
Citation: https://doi.org/10.5194/egusphere-2025-574-AC1 -
CEC2: 'Reply on AC1', Juan Antonio Añel, 22 Mar 2025
Dear Prof. Sodemann,
Many thanks for addressing this issue so quickly.
Juan A. Añel
Geosci. Model Dev. Executive Editor
Citation: https://doi.org/10.5194/egusphere-2025-574-CEC2
-
CEC2: 'Reply on AC1', Juan Antonio Añel, 22 Mar 2025
-
AC1: 'Reply on CEC1', Harald Sodemann, 22 Mar 2025
-
RC2: 'Comment on egusphere-2025-574', Marina Duetsch, 29 May 2025
This paper describes the software WaterSip, a widely used Lagrangian moisture source diagnostic that is based on the accounting algorithm developed by Sodemann et al. (2008). Apart from diagnosing moisture sources for precipitation or vapor, WaterSip can provide information on moisture source conditions, transport, and arrival quantities. The paper gives an overview over the diagnostic method, describes how to configure and run WaterSip, and explains the different output files and variables using a test case in Scandinavia as an example. It also briefly discusses potential errors and uncertainties in the results.
WaterSip is a very powerful tool, but so far has been difficult to use due to restricted access and limited documentation. This paper will greatly enhance the accessibility and usability of WaterSip. It is well-written and nicely structured, providing useful guidelines for potential users. I also very much like the idea of providing a test case with all the necessary input and configuration files for running WaterSip, which is a good starting point for new WaterSip users. There are some problems related to the test case, but they can hopefully be fixed. Apart from that my comments are mostly minor, and I recommend publication after addressing those.
General comments
1) I tried to run WaterSip with the provided test case, but it did not really work. During compilation it first did not find the netcdfcpp.h file, and I think this is because there is a mistake in the makefile. The NETCDFINC path should be added to the compilation step instead of the linking step:
COMPILE = $(CC) $(CFLAGS) -c $(NETCDFINC)
FLINK = $(NETCDFLIB) -lnetcdf_c++4 -lnetcdf_c++ -lnetcdf -lsz -lz -ldl -lm -lpthread -lcurl -lstdc++ -fopenmp
During runtime there were some other problems:
- The startDate in the input file is after the last shortposit file provided on Zenodo. It should be changed to 20220811-000000 (or alternatively more shortposit files should be provided).
- The particle number maxPart is too low, I got the error “***ERROR: could not assign particle, maximum particle number exceeded!”. With maxPart = 100000001 it worked.
- The reading of the input file ended up in an infinite loop in Parser::skipBlanks. I had to add filestr.get() on line 688 in Parser.cpp for it to work.
- After completing 92.2%, WaterSip crashed with a segmentation fault. I did not figure out why.
2) A new version of FLEXPART has been released recently (FLEXPART11, Bakels et al., 2024). Does WaterSip work with this new version as well, or only the 10.4 version? Since the new version writes trajectory output to NetCDF files, it would probably require rewriting the routines reading the input data. However, it might be worth it because FLEXPART11 has several advantages compared to FLEXPART10.4, for example (relevant for Waterip) improved trajectory accuracy and the option to write out average instead of instantaneous values along trajectories.
3) The section on errors and uncertainties is very short, but I think it is an important section and should be extended a bit. I would suggest to add a few figures showing the sensitivity of the results for the Scandinavia case to the settings, specifically the timeStep, the uptakeThreshold and precipThreshold, and arrivalRHMin. This would be very useful for new users to understand the influence of these settings. Also some potential error sources are currently not mentioned in this section, e.g. the fact that WaterSip always assumes either only moisture uptakes or only moisture losses during one timestep but not both. This could lead to an overestimation of remote and an underestimation of local moisture sources. Or, when using WaterSip as a diagnostic for surface evaporation, the assumption that water evaporated from the location (lat,lon) where the moisture is taken up by the air parcel might not always be true.
4) I did not fully understand the (difference between the) moisture source and transport quantities. For the moisture source quantities, the values are multiplied by Δq * f * m, for the transport quantities, they are multiplied only by f * m. I think the problem is that I don’t really know what f and Δq are in this case. Are these the values after the accounting? If so, isn’t f exactly Δq/q_0? So why is then f multiplied by Δq again? I am sure this is all done correctly in the code, but it could be explained a bit better (see also my specific comments on Equations 19 & 20).
Specific comments
L9-11: This is a repetition of L2-4
L22: Bracket around Stohl and James (2004)
L74: chose -> choose
L108: Figure reference broken
L133: doe -> does
L151: What do you mean by „in case trajectories are used rather than air parcels“?
L154: I think this first sentence is not needed here.
Equation 12: Shouldn’t this be the sum over i?
L168: This is interesting. Why does this (f_tot > 1) happen? This would be a case where the algorithm from Dütsch et al. (2018) is not equivalent, because there f_tot is by definition always <= 1.
L233: Why „differences in“? Not just the source contributions themselves?
L266: Do you mean atmospheric properties? Because the positions come from the trajectory calculation, so that would be the second part of the sentence.
L314: What would be a reason for setting a maximum relative humidity?
L323: partcels -> parcels
L360-369: I didn’t understand this part with the gridRadius.
L395: Could you briefly explain what these methods do, specifically Gustafsson et al. (2010) and Dirmeyer and Brubaker (1999)?
L403: Remove „are“
L436: Closing bracket missing
L467: chose -> choose
L483: Maybe start with a brief description of the meteorological situation for the event?
L498 (and others): Sometimes day is d, dy, or day. Please be consistent.
L515: Stohl et al. (2005) or Stohl and James (2004)?
L539-L545: I don’t understand how the quantities moisture transport, air mass mixing, and rainout are obtained. Could you explain this better? For example, what is meant by gridded product of the specific humidity?
L551: I don’t understand this first sentence. Do you mean differences _in_ moisture sources and transport? But moisture sources are not shown here… (?)
L554: quantity -> quantities
L554-L557: How does the precipitation estimate by WaterSip compare to ERA5 precipitation? This would be a good validity check.
Equation 19: Shouldn’t the denominator be P_tot (without k)? And the enumerator would correspond to T^k_0 * P^k_tot?
L579: Earlier λ and φ were used for lon and lat. Please use consistent notation throughout the manuscript. How is the mean over longitudes calculated? Are the coordinates converted to a Cartesian grid first? Otherwise there would be problems for e.g. lon1=-179 and lon2=179.
Equation 20: What is M? I assume the time steps of the trajectories? You could use this also in Equation 12 for consistency. Shouldn’t Δq also appear in the denominator?
L583: zeta -> \zeta
L595: This is a detail, but wouldn’t it be better to use the land fraction itself in the averaging (instead of 0 or 1)?
L600: and Eq. 19
L604 and L617: „the“ too much.
L607: Maybe briefly explain what d-excess is or define it?
Equation 22: Is N the same as M in Equation 20? If so, use M instead?
L650: where -> were
L698: Would it be possible to provide a script for reading the .traj files? Otherwise this is difficult because of the binary format.
L763: arrival _in the_ target region?
L780: The link to the WaterSip source code does not work. The one given on Zenodo is correct.
Figure and table comments
Figures 5,6,7: I would use a different colormap. This one looks like topography and is not very intuitive for sequential values (e.g. white means high).
Figure 9: The locations of the colors don’t correspond to the labels of the colorbar. Which one is correct?
Figure 10: Are these quantities weighted by f? From Figure 10 it seems so, but the text doesn’t mention it. In (d) where can we see the time before arrival mentioned in the caption?
Table 3: Why do the uptakes have negative values?
Figure 11b: I am not sure what is shown here. The figure says specific humidity, but the text says total accounted fraction. Where do we see that „moisture uptakes of more than 10 days before arrival are mostly overwritten by later uptake events“? I would suggest to use a different colormap, because red for moist and blue for wet is a bit counterintuitive. Also jet has many other problems (irregular lightness, not perceptually uniform, not colorblind-friendly).
References
Bakels, L., Tatsii, D., Tipka, A., Thompson, R., Dütsch, M., Blaschek, M., Seibert, P., Baier, K., Bucci, S., Cassiani, M., Eckhardt, S., Groot Zwaaftink, C., Henne, S., Kaufmann, P., Lechner, V., Maurer, C., Mulder, M. D., Pisso, I., Plach, A., Subramanian, R., Vojta, M., and Stohl, A.: FLEXPART version 11: improved accuracy, efficiency, and flexibility, Geoscientific Model Development, 17, 7595–7627, https://doi.org/10.5194/gmd-17-7595-2024, 2024.
Dütsch, M., Pfahl, S., Meyer, M., and Wernli, H.: Lagrangian process attribution of isotopic variations in near-surface water vapour in a 30-year regional climate simulation over Europe, Atmospheric Chemistry and Physics, 18, 1653–1669, https://doi.org/10.5194/acp-18-1653-2018, 2018.
Sodemann, H., Schwierz, C., and Wernli, H.: Interannual variability of Greenland winter precipitation sources: Lagrangian moisture diagnostic and North Atlantic Oscillation influence, J. Geophys. Res., 113, D03 107, http://dx.doi.org/10.1029/2007JD008503, 2008.
Citation: https://doi.org/10.5194/egusphere-2025-574-RC2 - AC3: 'Reply on RC2', Harald Sodemann, 04 Jun 2025
Viewed
HTML | XML | Total | BibTeX | EndNote | |
---|---|---|---|---|---|
257 | 102 | 24 | 383 | 13 | 22 |
- HTML: 257
- PDF: 102
- XML: 24
- Total: 383
- BibTeX: 13
- EndNote: 22
Viewed (geographical distribution)
Country | # | Views | % |
---|
Total: | 0 |
HTML: | 0 |
PDF: | 0 |
XML: | 0 |
- 1