Raven

What are the implications of the “infinite steep sides” assumption for channels?

anonymous34 wrote:What are the implications of the “infinite steep sides” assumption for channels?

This assumption, whereby the channel profile is cut off abruptly at its leftmost and rightmost specified extents with vertical ‘walls’, is put in place since Raven cannot handle channel flooding beyond the extents of the profile provided – the simplest assumption is that the sides beyond this point have infinite slope. This is a simplifying assumption used for the routing of water. To avoid any potential unseen issues with this, please specify a channel profile large enough to accommodate any expected flood magnitude.

Is it possible to have different frequency data in observed data than the model timestep? If so, where is the observation data frequency specified?

anonymous34 wrote:Is it possible to have different frequency data in observed data than the model timestep? If so, where is the observation data frequency specified?

Yes, the model timestep is specified in the rvi file and the observation data frequency is specified in the rvt files. Each rvt file can have a different time interval. All timesteps are in units of days, i.e. timestep if 1.0 is daily, 0.5 would be 12 h, etc. The format 00:00:00 is not currently handled.

I am considering implementing the Muskingum method in Raven. What are some potential issues in using the Muskingum method?

anonymous34 wrote:I am considering implementing the Muskingum method in Raven. What are some potential issues in using the Muskingum method?

The Muskingum method has two stability issues, both in time and in space. While Raven will automatically decrease the timestep if stability issues are detected, it cannot dynamically account for stability issues in space. Instead an error will be reported that the number of reaches should be increased.

As an aside, it is possible to avoid spatial stability issues in the Muskingum method by increasing the dispersion coefficient. However this is a numerical fix and is not physically correct, and is not recommended.

Hi, I need to do the in-catchment and in-channel routing, but I already have the flux for each HRU from another model that I'm using, is there a way to solely do the routing using the flux data I have, without having to type in all other parameters such as precipitation and soil charactersitics?

BrianHydro,

You can run a model with just 'rainfall' supplied as the runoff from another model. This would require a hypothetical 'gauge' for each HRU that you have tied to a 'rainfall' time series or (preferred) a netCDF file of outputs from the other model. In this case your hydrological processes block would only include two entries:



You would still have to create a single soil class, but there would be no parameters associated with it. Basically you are allowing the runoff from the other model to be added to the Raven landscape as "precipitation", then be flushed directly to surface water, where it can be subjected to in-catchment and in-channel routing.

Hi, jrc

Thanks for your explaination. Apart from the precipitation part, I noticed there are certain 'required parameters' described in the manual, such as evaporation or vegetation classes, so should I create them with no parameters like the 'single soil class' you described, or just skip them and run the model anyway?

Hi BrianHydro

Raven will give you an error if you are missing a required parameter, so you could run it and see if you are missing something. But you can also use the :CreateRVPTemplate command in the rvi file and run the Raven executable, which will not actually run the model but give you an rvp template with the parameters that you require so that you can see what is needed. Some parameters may be autocalculated and not actually require values to be filled in (i.e. see page 113 of the manual for a discussion on_DEFAULT and _AUTO flags for parameters).

Hope that helps!
Rob