Seasonal Water Yield (SWY) - 'Constant' model discrepancy : Water Balance

Dear Community,

As a part of a research project, we are demonstrating the utility of ecosystem services modeling for the pre-project evaluation of watershed development programs. This we hope will enable scoping out potential opportunities for interventions.

We ran the SWY model for 3 watersheds representative of different dominant LU classes. We have some observations and doubts from our experience using the InVEST model.

We noticed when we take the annual water balance for the watershed, P=ET+QF+L, there always exists a small quantity (P-ET-QF-L), let us call this term model discrepancy, that remains constant for a given input data. The constant does not change with changes in model parameters or changes in the biophysical table. Does a model discrepancy close to zero imply the model is calibrated for the given set of inputs? What in your opinion is the physical meaning of this small quantity?

For example, P = 49.5 Mm3, AET = 21.4 Mm3, QF = 14.2 Mm3, L = 8.0 Mm3; P-AET-QF-L = 5.9 Mm3.

Further, we have observational data for a small sub-catchment (~25 Ha), but no discharge data for the larger study area. Can we alternatively calibrate the model for the small watershed and use the calibrated model parameters for the large watershed (~2500 Ha)?

Looking forward to your feedback and interactions.

Hi @BDass ,

I’m not immediately sure what’s going on here, but could you share your complete inputs with me so that I can take a closer look? A file sharing service like google drive or dropbox is usually best. Feel free to email them to if you’d prefer.

I don’t personally have any experience with calibrating this model on watersheds of such varying size, but offhand I’d be wary of calibrating against a watershed that is different from the watershed of interest. @swolny , @RafaSchmitt , any suggestions here?


Hi BDass,
your calibration approach can be done (calibrate for small watershed, use for larger one). Indeed, that is a common reason for hydrologic modeling: use the model to extrapolate for unmonitored parts of a catchment (though this comes with certain caveats on which there is extensive literature).
Regarding the calibration itself, please take a look at a recent paper:

Hamel, P., Valencia, J., Schmitt, R., Shrestha, M., Piman, T., Sharp, R.P., Francesconi, W., Guswa, A.J., 2020. Modeling seasonal water yield for landscape management: Applications in Peru and Myanmar. Journal of Environmental Management 270, 110792. Redirecting

1 Like

Hi @BDass , thanks for sending your inputs! I’m trying to reproduce the specific issue you’re describing, and while there are discrepancies, the differences between the expected P and the calculated P are pretty close to being numerical noise (all are only off from the expected by +/- 1E-4 or smaller), so I’m not yet convinced that there’s an issue with the model because several of these computational steps will be subject to the accumulation of floating-point error along a flow path.

But also, I’m not sure that I’m correctly reproducing what you’re seeing. Could you also provide these inputs so that I can try to match what you’re seeing? I’ll need your:

  • Threshold flow accumulation
  • alpha_m
  • beta
  • gamma


1 Like

Hi @jdouglass,
Following are the requested parameters.

  • Threshold flow accumulation = 20
  • alpha_m = 1/12
  • beta = 1
  • gamma = 0.08

In your reply, I did not understand what you meant by “…the differences between the expected P and the calculated P…”.

In our calculations, we first computed the water balance components (P, AET, QF, and L) from their respective raster files using the zonal statistics tool in QGIS. This gives us the water balance component, say, Precipitation, in mm. We converted the output in mm to Mm3 by multiplying the computed value by the pixel area. The discrepancy we find is computed by evaluating P – AET – QF – L, and this difference remains constant for any given catchment, and changes are made only to the biophysical table (CN and Kc).


Hi @denzilroy ,

Thanks for these parameters!

Are you saying that you had summed all the pixel values across the whole landscape here, or were you using some other vector? I just want to be sure that we’re comparing the same values here.

It sounds like you’re running 2 scenarios with 2 different biophysical tables, and for each scenario, computing sum(P) - sum(AET) - sum(QF) - sum(L) (where sum() is across all pixels in the catchment). And what you’re seeing is that the result of sum(P) - sum(AET) - sum(QF) - sum(L) is nonzero when you would expect it to be zero. Is that correct?

Could you send me your second biophysical tables so I can take a look?


Hi @jdouglass,
I think we are thinking alike so far.

Yes. To clarify, sum(P) will be in units of mm. I multiply sum(P) by pixel area (870x870 m2), and convert it to units of Mm3 by dividing the resulting product by 10^9. Likewise, for sum(AET), sum(QF) and sum(L).

Yes. We run the model for different scenarios defined by changes in the biophysical table. I have shared them here for your reference.
scenario0.csv (549 Bytes)
scenario1.csv (584 Bytes)
scenario2.csv (550 Bytes)

Yes. Spot on.


OK great, thanks for those tables and the extra information @denzilroy !

Having taken a closer look at this, I’m very confident that the ‘constant’ model discrepancy you’re seeing is due to the accumulation of floating-point error and is normal computational behavior. There is no biophysical meaning of this quantity.

There are multiple factors at play here that are affecting the numerical precision:

  1. Because the IEEE754 floating-point specification is inherently an approximation of the numbers we wish to represent, most floating-point numbers are, in fact, slightly off from our desired value, creating approximation error. This error cannot be avoided, only minimized.
  2. When operating on a series of approximate values, the approximation error accumulates with each mathematical operation.
  3. Although all mathematical operations will inherently accumulate this approximation error, graph traversal problems (such as routing water across the landscape, as is done in Seasonal Water Yield) will visit more pixels than we often expect and further accumulate error as a result.
  4. Then, summing these pixel values across the whole landscape will further accumulate the approximation error into something that feels like it may be biophysically significant, but is not.

So then looking at your landscape, when I calculate the water balance balance = P - AET - QF - L for each pixel individually (not converting the units), you can see that the results are very close to 0. Because of the accumulated approximation error, I’m comfortable dismissing these as numerical noise and they should be treated as 0.



@jdouglass, thank you for the engaging explanation. We now have a name that more closely explains the numbers - accumulation of floating-point error. I also appreciate the tip on checking whether we can dismiss the error or not, i.e., it helps to look at the difference at the pixel level, and if distributed around and close to zero, we can safely dismiss it.

The explanation resolves my original query. Thank you.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.