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

1. Clarify terminology early (Section 1):

   • Define “uptake”, “accounting”, “residual moisture”, and “arrival grid” explicitly.
   • Consider a graphical workflow diagram.

2. Equations (6)–(9):

   • Include variable definitions in-line with the equations, especially for readers not familiar with the 2008 method.

3. Section 2.5: Too long and fragmented. Suggest splitting into:

   • "Core algorithm parameters" (∆q, RHc, sh),
   • "Grid and output configuration",
   • "Optional diagnostics".

4. 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.

5. Code availability: Ensure a DOI or stable link is provided. Consider creating a GitHub/Zenodo archive.

6. 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.

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.