Raven

Thank you, Rob!
Would it be the case also for annual runoff volume error?

Hi Anya, I'm not sure which metric you are referring to in this case. In general Raven uses all of the overlapping simulation and observed data in the calculation unless otherwise specified, if that helps.

Rob

I want to check that I fully understand advective transport in Raven (tracers or tracking concentrations).

How is it possible to have a concentration > 1 mg/L ?

For example, in the Alouette2 tutorial, the snowmelt pollutograph reaches >1.1 mg/L for a few time steps.

To my understanding, the concentration potentially could be greater than 1.0 because the modeled melt generated could be greater than the runoff -- some of the melt generated from the snowpack has went into the groundwater (or other reservoirs) rather than making it out as river discharge at a particular timestep.

I noticed that the Alouette2.rvi did not mention the "FAST_RESERVOIR", which here appears to be the topsoil -- and while it is "fast" it is not delivering all of the snowmelt that it receives as discharge immediately. So I tagged the FAST_RESERVOIR snowmelt component as zero:

:Transport SNOWMELT
:FixedConcentration SNOWMELT SNOW 1.0
:FixedConcentration SNOWMELT FAST_RESERVOIR 0.0
:FixedConcentration SNOWMELT SLOW_RESERVOIR 0.0

Then I reran the model, and for most time steps the snowmelt concentration fell. The max concentration fell by nearly half to 0.67 mg/L. So it appears that during periods of high snowmelt, a lot of water is lost to the topsoil, which while a fast reservoir, is not instantaneous.

As I understand another consideration for using tracers is whether the reservoir we are tracking has full storage or not. For example, a glacier or snowpack in a model may have capacity to store water and may not be full. So if we are interested in raw melt generated, then we could check those storages and if not full, artificially fill them.

So for tracing concentrations, if I understand correctly, we are tracking the net mass flux between reservoirs? (here from SNOW to all other reservoirs) -- not just as a fraction (mg/L) of discharge? So to to properly track e.g. snowmelt contribution to discharge, what would we need to do? (which by definition shouldn't exceed 1.0)

I just want to make sure I fully understand how the tracing works.

Thanks!
Ben

Hi Ben,

We adopt an initial fixed concentration of 1 mg/L for convenience of interpretation, but could have used any other value.

Tracer routines help track how much each storage compartment in the model contributes to the modelled outflow. It is expressed as a concentration which can then be multiplied by modelled outflow to obtain a mass flow. When the starting concentration is 1.0 mg/L (and ranges between 0..1), this mass flow directly represents a percentage of the discharged water mass that originated from the host storage compartment.

The missing tag of 0 mg/L for the SNOWMELT tracer in the FAST_RESERVOIR is likely a typo (I'm double checking this with the Teaching Team). Common practice for any tracer setup is to set :FixedConcentration values to 0 for all subsequent stores that the initial reservoir drains to. You're right in that the FAST_RESERVOIR is supposed to represent a conductive topsoil layer that routes water more quickly than the underlying SLOW_RESERVOIR (although it is not instantaneous).

Storage capacities can be better tracked with the WatershedStorage.csv output - this gives you the storage of each compartment at every time step. In this file for the Alouette2 example, you will also find a column for Glacier storage in [mm].

One plausible scenario I can think of in this case where the outflow concentration is >1 mg/L for the SNOWMELT tracer is when percolation rates into groundwater stores are faster than baseflow rates that flush groundwater into surface water. This means that there is a net groundwater recharge and thus a net accumulation of synthetic tracer mass in the groundwater store.

I was able to reproduce your result where the snowmelt pollutograph reaches >1.1 mg/L and plot the storage time series:



Here you can see that the topsoil (soil [0]) storage often reaches full capacity. Perhaps this and the high concentrations suggest a story of lag times and multiple melt event signals superimposed on each other? Or maybe this is just an interesting numerical artefact of not tagging :FixedConcentration FAST_RESERVOIR 0.0 in the tracer routine.

Hope this clarifies things.
Simon

Hi,

I'm finishing up a GUI for Raven and I have a few questions regarding mostly the hydrologic processes.

Can "MULTIPLE" be used for the to and from compartments of all algorithms?
"Overflow" is written ":Overflow" and ":-->Overflow" in the documentation. Do both do the same thing?

It also seems like the Table A.1 (page 151) is not up to date, as some algorithms and compartments are missing. Would you happen to have a newer table for the hydrologic processes? There are also a few errors I think, such as the process ":Convolution" instead of ":Convolve" and ":CanopyEvap" instead of ":CanopyEvaporation"

I have also noticed a small error on page 136, the command ":PotentialMeltMethod [method]" is written ":PotentialMelt [method]".

Thank you!
Francis

Hi Francis

Sorry that this question slipped through the cracks.

MULTIPLE can only be used for some algorithms where it is appropriate. Specifying it for something like baseflow will likely result in an error. There is an internal check in Raven to see if the MULTIPLE command can be parsed for the given process.

:Overflow and :-->Overflow are in fact the same, I believe it is retained for backwards compatibility with previous versions.

You are correct in that Table A.1 is not comprehensive. There is a set of 'database' files now maintained with the Raven source code that is meant to keep this type of information updated (a non-authoritative copy is kept with the RavenR package, linked here so you can see what it looks like) https://github.com/rchlumsk/RavenR/blob/master/inst/extdata/RavenProcessConnections.dat

The process should indeed be :Convolve, not :Convolution. :CanopyEvaporation is also correct instead of :CanopyEvap

I will forward these for inclusion in the next iteration of the manual. I would recommend that you take a look at the Raven source code and the ParseInput.cpp file specifically for determining which commands are actually used in Raven, and which are deprecated or typos in the manual.

In addition, please feel free to email us and share (if appropriate) your work with the Raven GUI. There have been other efforts on this front and we may be able to help you out or share in this effort.

Cheers,
Robert

Francis wrote:Hi,

I'm finishing up a GUI for Raven and I have a few questions regarding mostly the hydrologic processes.

Can "MULTIPLE" be used for the to and from compartments of all algorithms?
"Overflow" is written ":Overflow" and ":-->Overflow" in the documentation. Do both do the same thing?

It also seems like the Table A.1 (page 151) is not up to date, as some algorithms and compartments are missing. Would you happen to have a newer table for the hydrologic processes? There are also a few errors I think, such as the process ":Convolution" instead of ":Convolve" and ":CanopyEvap" instead of ":CanopyEvaporation"

I have also noticed a small error on page 136, the command ":PotentialMeltMethod [method]" is written ":PotentialMelt [method]".

Thank you!
Francis

Hi Robert,

No worries! I didn't have a lot of time to work on it recently. Thank you for the information, I will look at the source code and the RavenR file you provided.

And sure, I will email you the project!

Thank you,
Francis