Lake HRUs in Raven

[vahid.mehdipour]

Hi All,

I Have a small-lakes dominated basin and even though the final results are satisfying (KGE more than 0.85) it does not work well for low flows and it yields an LNSE of -5 (the simulated values for low flows are almost zero) and I think I have to add lake HRUs. Is there any other suggestion for this issue?

The question is while I am adding a new HRU to rvh file, I know that the soil profile is "LAKE" but what are the other HRU attributes?

For example:

:Attributes AREA ELEVATION LATITUDE LONGITUDE BASIN_ID LAND_USE_CLASS VEG_CLASS SOIL_PROFILE AQUIFER_PROFILE TERRAIN_CLASS SLOPE ASPECT
9 100 270 40 -80 1 ? ? LAKE ? ? 0 ?

What are the values for the Vegetation class and land use class? Do I need to introduce a new class for lakes?

Thanks in advance,
Vahid

[Ameer]

This is an interesting question.
I would think we do not need vegetative parameters for lakes- not sure if we can put a dummy text where vegetative description is require. There is something about Lake HRU in Raven manual (page # 32) but not in great detail.
James and Rob- any thoughts on this?
Ameer

[rchlumsk]

Hi Vahid and Ameer

Good question. On the syntax, the rvh file you would specify the special HRU type (see Raven manual release v3.0 page 27 for a note on special HRUs) for the given HRU. Note that there can be multiple LAKE type HRUs in your model, anything that has LAKE* as a prefix will register as a special HRU type.

As an example, if you look at the Raven Tutorial Files for Alouette2, the GLACIER type is specified in a few HRUs as type GLACIER with the following:

Code: Select all

:HRUs
 :Attributes, ID,   AREA, ELEVATION, LATITUDE, LONGITUDE, BASIN_ID, LAND_USE_CLASS, VEG_CLASS, SOIL_PROFILE, AQUIFER_PROFILE, TERRAIN_CLASS, SLOPE, ASPECT
 :Units,      none, km2,  m,         deg,      deg,       none,     none,           none,      none,         none,            none,            deg, deg
    ....
       34,    0.232,    1500,    49.3,    -100,    1,    GLACIER,    FOREST,    GLACIER,    [NONE],    [NONE],    0,    0
       35,    2.668,    1500,    49.3,    -100,    1,    GLACIER,    FOREST,    GLACIER,    [NONE],    [NONE],    0,    180
:EndHRUs

In this case there are some landuse parameters that need to specified for the GLACIER type, which is why it has a veg class, the soil profile is specified as GLACIER again, and other types are left as none. In my models, I have setup the LAKE hru as:

Code: Select all

:HRUs                                       
   :Attributes   AREA   ELEVATION   LATITUDE   LONGITUDE   BASIN_ID   LAND_USE_CLASS   VEG_CLASS   SOIL_PROFILE   AQUIFER_PROFILE   TERRAIN_CLASS   SLOPE   ASPECT
   :Units   km2   m   deg   deg   none   none   none   none   none   none   ratio   deg
        ....
   2   5.9   408.31   xxx   -xxx   2   LAKE   LAKE   LAKE   [NONE]   [NONE]   2.2   0
   3   11.32   405.45   xxx   -xxx   3   LAKE   LAKE   LAKE   [NONE]   [NONE]   2.65   0
:EndHRUs

and just specified the VEG, LANDUSE, SOIL class types as LAKE, and specified those parameters as needed in the rvp file.

On the question of what can be done about low flows, the LAKE type is a way to get slower release. You can consider also increasing the soil storage and changing other parameters to get a slower baseflow release, if baseflow is present in the model, or consider adding those types of processes if they do not exist. Another option might be to add multiple representative lakes in the model and further discretize the model to represent a more distributed runoff response, which may add some further accuracy. Representing multiple distributed lakes is an active research topic, so there is no one clear answer to that question.

Hope that helps, let me know how it goes!
Rob

[vahid.mehdipour]

Hi Rob and Ameer,

Very many thanks for being helpful as always.

Regarding the adding lakes to my model I got surprisingly great results. Log_Nash from -5 jumped to 0.60 which is fairly enough for me as I have the KGE/NSE still more than 0.8.

I tried adding lakes in numerous ways by introducing a new class for lake in Vegetation and land-use sections, but my experience showed that only the soil profile is the most important part. Besides, the lakes' areas also play a considerable role. Once, I added the lakes one by one, and once I summed up the lakes' areas in each sub-basin and add them as one lake, and results were similar.

I have the soil capacity, baseflow, snow/rain capacity of canopies, etc. in my model and I tried to follow the hydrologic processes part of manual in detail but based on my experience working with Raven, auto-calibration (OSTRICH in particular) is a must to get the desirable results.

Rob- One more question; Now, I want to run large ensemble data (e.g. CanLead, CanRCM, etc.). What is your suggestion, should I use the gridded data format as input data or I need to process the data and organize them in different .csv files and run the base model for different rvt file? Is there any other faster tool to run the model once for different rvt files? If not, I need to run my model 150 times for different scenarios!

Again, thank you very much,
Vahid

[rchlumsk]

Hi Vahid

Glad that the lakes suggestion worked out. Good to know when your performance is 'good enough' for given purpose and not sink too much time into marginal improvements in scores :)

On the ensemble data, I am not sure I completely understand your dilemma. Are you looking at 150 rvt files, or 150 variations in rvt files and you want to experiment with them?

Assuming that you trust the data source, I would suggest ingesting the ensemble meteorologic data into Raven using a netcdf format, which Raven can handle. You could of course supply multiple gauges (including 150 rvt files in one simulation, for 150 different locations), but the netcdf is likely easier to do and will be a smaller size of files than parsing into rvt files.

Hopefully that answers your question. If you did wish to run Raven with different versions of input files for whatever reason, I don't know of any tools that can do that explicitly, but it would not be too bad to wrap Raven runs in a script to call Raven with various input file combinations nad write output to folders for later post-processing of results. One handy feature of Raven inputs that is not well-known is that you can provide input flags to Raven for all input files, such as:

Code: Select all

./Raven.exe model_name -t other_rvt_file_1234.rvt -o ./output/

to call an rvt file other than one of the same name as the rvi file. This way you could have multiple rvt files or a script to write out rvt files and give it to Raven in some batch run.

Cheers!
Rob

[vahid.mehdipour]

Thanks Rob!

Let me be more clear and explicit;

Let's say I have too many meteorological data (Temp and Precip) in .csv format and I want to run the model for that many times. What is suggestion to automate this process?

Regards,
Vahid

[rchlumsk]

Hi Vahid

I am afraid I still don't completely understand what you are looking for. If you are looking to run the model from the forcing data in csv format, you will need to convert it to .rvt format for ingestion into Raven. If you look at the example tutorial files, you can see the rvt data format; the most common is to use the :MultiData argument to pass temperature and precipitation in one rvt file per gauge (if you have more than one gauge, you will have multiple rvt files).

Once that data is in rvt format and being read by the model, you can run Raven many times using a loop in a batch script (or shell file in Linux) if you want to, depends on what kind of experiment you are running.

Hopefully that gets to your question, feel free to post back or contact me via email if not so that I can fully understand what you are trying to do.

Cheers,
Rob