Search This Blog

Friday, September 16, 2016

Using HEC-ResSim to model an irrigation network

I have developed a simple example to show how to create an irrigation network in HEC-ResSim.  This development includes creating a diversion from a reservoir on the main stem of a river to move water to dummy reservoirs.  The reason I use the dummy reservoirs is for decision making in the irrigation network.  The rules are relatively simple based on moving a percentage of inflow to the diversion and a percentage downstream of the dummy reservoir, but added complexity is possible.  It is up to the user to decide if HEC-ResSim is the proper choice for their situation, but this example will demonstrate the potential use of HEC-ResSim.

Below is a schematic of my sample watershed setup.  To the right is the main stream with the sample irrigation network being on the left.  There is a diversion from the main reservoir to "dummy" reservoir number one, and a diversion from "dummy" reservoir number one to "dummy" reservoir number two.  Notice that I used diversions and placed them in the watershed setup module.

In the reservoir network, I add my reaches.  For this example, I simply used null routing.  Also, notice that I added a diversion out of the system.  For this example, I assumed that all water getting into the irrigation system would be used with none returning to the main stream.  If there was some return water, I could have diverted something less than 100% of the flow out of the system.

For the reservoir on the main stream, I have the diversion along with an outlet that allows flow to remain in the main stream below the dam.  I give each outlet a capacity of 1,000 cfs.  This is shown below.  "Dummy" reservoir number one has the same physical components and "Dummy" reservoir number two has only one outlet to release flow downstream of the dam.  ("Dummy" reservoir outlets not shown).

For the reservoir on the main stream, 50% of the inflow is diverted and 50% of the inflow is passed downstream of the dam.  This is done by applying a rule to the diversion and applying a rule to the controlled outlet at the dam.  This rule is a function of the inflow into the reservoir.  The rule for the diversion is shown below.  At "dummy" reservoir number one, 60% of the inflow is diverted downstream and 40% is diverted to "dummy" reservoir number two.

In the simulation, the inflow at the head of the irrigation canals is .01 cfs.  This gives HEC-ResSim some inflow at the upstream end, but it is not significant enough to impact the results.  Basically, all inflow into the irrigation network comes from the main reservoir.  I begin the main reservoir at the top of conservation.  I assume that it is simply controlling where the inflow is to go, so I don't want it to store inflow or empty storage.  The dummy reservoirs are placed at the top of the inactive pool.  The rules will move the incoming inflow to the proper location, and I did not want any excess to be released due to the "dummy" reservoir moving into the flood pool.  You may want to consider using an artificially large storage for the dummy reservoirs to avoid any unintended encroachment into the flood pool.

The results for the main reservoir are shown below for 02Jan2015 at 22:00 hours to 04Jan2015 at 02:00 hours.  In these results, we can see flow in (third column) is equal to flow out (fourth column).  We can also see the the flow from the main outlet (second to last column) is equal to the flow from the diversion (last column) since they both release 50% of the inflow.

For the coding of the rules at reservoir, "dummy 1", I used a specified release rule that was a function of the previous value of Pool Net Inflow.  The results are shown below.  The inflow (column 3) is equal to the total outflow (column 4).  Note that there is a delay of one time step since we are using previous value of inflow.  The release to the reach downstream of the dam (second to last column) is equal to 60% of the inflow while the release to the diversion to reservoir, "dummy 2", is equal to 40% of the inflow.

We can check the flow in the reach below the confluence of the irrigation canal and the main stem.  This reach is shown in yellow below.  These results should match the outflow from the main reservoir that stays in the main stream since none of the irrigation diversions are being returned to the main stream.  The comparison of these values is shown below.  We can see that these values match.  Recall that null routing was used so there is not attenuation or lag to the releases.

Wednesday, August 24, 2016

Specifying a plant factor and generation pattern for hydropower in HEC-ResSim

This post will detail the coding of a plant factor and a generation pattern for hydropower in ResSim.

This example was created using a simple one reservoir model.

Before I coded in the hydropower rules, I ran the model without any rules.  Once the simulation begins on January 10, 2015, ResSim sets the release (green line in bottom plot) to zero since the pool is below the top of conservation (elevation 50 ft) as is shown by the green line in the top plot.  The release increases to match inflow on January 14, 2015, to hold the pool at the top of conservation.  This figure will aid us in seeing the impact of the hydropower rule.  The internal logic of ResSim wants to hold all inflow when the pool is below top of conservation.  The power rule will not allow this to happen.

The image below shows the development of the hydropower rule.  The plant factor in this example is set to 100% for the entire conservation pool.  It can vary with varying conservation pool levels if that is desired.

In the hydropower rule, we also want to specify a generation pattern.  In the image below, I have specified two 3-hour patterns, one in the morning and one in the afternoon (shown by the 1.0 value in the second column).

Below is the result from that simulation.  In this simulation, there are two defined generation periods per day.  Also, notice that the pool elevation is dropping due to the power generation requirement.

In the image below, I have changed the plant factor to 50% for all conservation pool levels.

This changed the flow in the first few days of the simulation since ResSim is trying to generate 50% of the installed capacity of the power plant.  With the higher pool elevation, less release is required to generate 50%.  However, as the pool continues to fall, the hydraulic capacity of the plant is set to its maximum in an attempt to generation 50% of the installed capacity.

For the 50% plant factor simulation, I have also included the power plot.  I have set the installed capacity to 10 MW.  In the plot below (referring to the top plot for this explanation), you can see that 50% (or 5 MW) is generated on January 10 and January 11 along with a portion of January 12.  After that, a declining pool elevation causes a lower head differential.  With the hydraulic capacity of the power plant limited to a value of 5,000 cfs, ResSim cannot meet the 50% generation requirement.  So, it releases up to the hydraulic capacity and generates as much as it can.  The dashed red line is showing the desired generation while the dotted-dashed green line is showing the generating capability.  You can see on January 10 and January 11 that there is the capability to generate power above 5 MW.  However, beginning on January 12, the green dotted-dashed line intersects the red dashed line indicating that the generating capability has fallen below the desired generation.

One final image showing a plant factor of 20%.  In this simulation, we have enough inflow to cause a rebound in the pool elevation.  It can be seen that higher pool elevations lead to less release being required to achieve 20% of the installed capacity.

Time step determination in HEC-ResSim

This post covers two issues:

1.)  Can daily data be used for a 1-hour time step simulation in ResSim?

2.)  What is the difference in using period average and instantaneous in the alternative editor?

To answer the first question, it is important to understand how ResSim will handle simulation time step and input data.

  • If the computation time step is less than the original interval of the input time series data (in other words, using an hourly time step with daily data), then the input data will be interpolated at the new desired interval.
  • If the computation time step is an interval greater than the original interval of the input time series data, the computation time step will become the interval at which data input is read.  So, a six hour simulation time step using hourly inflow data will read the inflow data every 6 hours.  
The figure below shows the inflow data given at one time each day.

The model, however, is run on an hourly time step.

This model simulated with no errors.  In the figure above, notice that "Period Average" is selected.  With this option selected, the inflow data is constant over the entire time step giving a stair step presentation of the data.  The inflow data is the dark line.  It becomes coincident with the release (green line) on 14Jan2015.

When instantaneous is selected as the flow computation method, the stair step pattern goes away.

Due to this difference in how the data is interpolated, the inflow values vary slightly at each time step.  Below is a table of a small portion of the inflow time series.

From this table, we can see that the inflow is 400 cfs at midnight on January 14 and 800 cfs at midnight on January 15.  So, we would expect to see inflow values between 400 cfs and 800 cfs throughout January 15 when using an hourly time step.  The table below show the differences in the values when using period average and instantaneous.

Note that the average of the instantaneous values gives the period average value.  In other words, the average of 566.7 cfs (10:00 instantaneous value) and 583.3 cfs (11:00 instantaneous value) is 575.0 cfs (11:00 period average value).

Friday, August 19, 2016

Developing Stream Alignment in HEC-ResSim

Special thanks to Joan Klipsch of HEC for providing information about this topic.  

Setting up a stream alignment can be challenging in HEC-ResSim.  In my examples so far on the blog, I have used simple stick diagrams for my examples.  This doesn't affect the ResSim computations, but you will typically import a GIS shapefile for your stream alignment.  Below, I have included Joan's recommendations (in Bold) along with my suggestions (in Italics).  I would also recommend that you refer to the August 10, 2015 post describing how to develop a model.

  • Each river in your stream alignment should be represented by a single continuous line.  If you created the stream alignment by importing from a shapefile, verify that the flow direction of each stream is correct (the zero tick mark should be at the downstream end).  Each confluence (stream junction) should be checked to be sure it is truly connected - look for the bright green halos.  Additionally, you will get an error message when you try to draw in your reservoir if the direction of the stream alignment is incorrect.  You will think you are drawing in the reservoir upstream to downstream, but ResSim will inform you that you are trying to draw them in downstream to upstream.  
  • In the figure below, you can see that the individual stream segments are not one continuous line due to the presence of numerous green halos.  Normally, the green dots (stream nodes) should only show up at the top and bottom of a river or at a confluence with a tributary (confluences should have those bright green halos; the halos indicate properly connected "stream junctions").  I would send the alignment shown in the figure below back to my GIS staff for corrections.

  • The above alignment will still work, but it can be a challenge to draw the routing reaches on it and you are stuck with the stream alignment's discretization for the maximum length of your reaches since you will not be able to draw a reach across the stream junction that connects the pieces.  Additionally, if this is going to be used in a CWMS (Corps Water Management System) model, I want to control where reaches begin and end rather than it being a function of how the shapefile was developed.  The location of the reaches should be controlled by where the routing parameters change or by the location where inflow has been computed by a model such as HEC-HMS.

  • Another potential issue with drawing reaches occurs when the Junction element that you are trying to connect your reach to is not exactly located at the stream junction beneath it (sometimes, they are ever so slightly upstream of the stream junction).  To avoid this problem, I employ one or both of the following techniques:
    • Create a watershed configuration and draw computation points in the watershed setup module at all stream junction.  I would draw in all my reservoirs here as well.  When you place a computation point at or very near a stream junction, ResSim will prompt you to identify where the computation point should be located.  I always answer "at the stream junction".  Once I have all the computation points defined, I can then create a network in the reservoir network module based on my configuration.  When I do this, all my computation points become Junction elements in the network and they are located exactly where they belong.  I have also added the junctions in the reservoir network directly by zooming in tight on the confluence and putting the junction there.  Even doing it that way it still seems to miss the confluence at times.  I like Joan's recommendation better.
    • When I draw my reaches, I start from the bottom of the watershed and work my way up.  I realize this my be counter intuitive, since the reaches are drawn from upstream to downstream, but by working my way from bottom up, I usually avoid most the reach draw problems caused by the junctions not being in exactly the right place.  This draw order usually place new junctions (as needed) in the most right place for the reach to connect to.  Note that the individual reaches are still drawn from the upstream end of the reach to the downstream end of the reach, but Joan is recommending to start with the most downstream reach first, then the second most downstream reach, etc.  
  • Create your network based on the configuration.  If, while drawing in your reaches in your network, you find problems, go back to watershed setup, fix what is causing the problem, then start over with a new network or update your network from the configuration.  Once you have all your reaches and diversion added to the network, put in the pool data for your reservoirs and create at least one outlet.  Then create a "zones only" operation set (no rules).  Next, identify inflows at the headwater junctions and create an alternative.  Set the time step, operation sets, initial conditions, and then map a dummy inflow time series (use a constant value that can be passed by your single outlet) to each inflow location.  Finally, create a short simulation in which to test your alternative.  Once you have the alternative computing, follow the water…work your way from upstream to down verifying that the flows are summing up correctly and water is not appearing or disappearing unexpectedly.  This is a major step in model development.  It helps you verify the connectivity and gives you a chance to find potential problems and “fix things” without too much getting in your way, especially “operations”.   I consider it important when developing any model, simple or complex, but the bigger or more complex the model, the more vital this step becomes.  I would also add that you want to set your reservoir elevation to the top of conservation in the lookback period.  This will avoid having ResSim hold or release some of the constant inflow.  Once you have this "no rules" model working, I recommend building and testing the model one rule at a time.  This allows for a better understanding of how each rule impacts the system and makes debugging the model much faster.  For information about how to do this, see the July 19, 2016 post (with linked video) discussing "Replace from base" and "Save to base".  These options are useful for model development in the simulation module.   

Tuesday, July 19, 2016

Using "Replace from base directory" and "Save to base directory" in HEC-ResSim

This post shows the use of "Replace from base directory" and "Save to base directory" in HEC-ResSim.

The Reservoir Network Module will show the base model.  It may be desirable, however, to develop and test rules in the Simulation Module before you save them to the base model.  If you are happy with the behavior of the new rule, simply save it to the base directory.  If you prefer to not use the new rule, you can simply overwrite it by replacing from the base directory.

This video shows the use of these options:

Friday, June 17, 2016

Error message of "Start Date must be after Lookback Date" (Windows date and language settings)

Special thanks to HEC for providing me with additional information regarding this error message:

"Many international users get that error because ResSim only understands dates when the Windows date and language settings are set to US English.  So, even when they set up their dates properly, ResSim may return that error unless they make a change to the Windows date and language setting."

Below is a link to instructions on how to make that change:

Tuesday, June 14, 2016

Using Python Dictionary Script in ResSim

This post shows how to use the Python dictionary script created in the 29 April 2016 post within HEC-ResSim.

The model used to show this example is a simple one reservoir model with 1,500 cfs entering the model at its upstream end (CP1).

The top of conservation is at 50 ft.

This model utilizes a scripted rule that is applied to both the Flood Control zone and the Conservation zone.

When you create a scripted rule, the script editor appears.  Your code will be entered after the "# add your code here" comment.

The code looks very similar to the Python script shown in the earlier post.  However, in the earlier post, I showed pool_elev as a constant since it was not connected to the ResSim model.  Now that the script is in the ResSim model, I can access the pool elevation at each time step of the simulation.  It is performed with two lines of code explained in more detail below.  The pool elevation and release are related in the rating dictionary.  So, for instance, a release of 1,000 cfs is related to elevation 50 ft while a release of 1,200 cfs is related to elevation 60 ft.

To get the pool elevation at each time step, I first need to access the pool elevation time series.  This is done by double-clicking "Pool Elev" for the reservoir of interest in the interface found to the left of the code.  

 The following appears in the code after double clicking "Pool Elev".

This is indicating that I want to access the pool elevation time series for "reservoir one".  I then make it an object by assigning that statement to pool_ts (this can be any name that you decide).


I then obtain the value at the previous time step of that object.  I prefer to extract the previous value on computed values such as the pool elevation since the current value may not have been computed.

Other than the two lines of code shown above, the code should look very similar to what I developed in the 29 April 2016 posting.  With it already having been tested outside of ResSim, the incorporation into ResSim was relatively easy.

The value of the rule at each time step and the type of rule are then sent to ResSim via the line of code shown below.  It is already present in ResSim when you initially create a scripted rule.  You simply need to indicate if it is a minimum release rule (RULETYPE_MIN), maximum release rule (RULETYPE_MAX), or specified release rule (RULETYPE_SPEC).  Additionally, the value of the rule is also indicated.  For this script, the value of "project_rel" is used as the value of the scripted rule.

The results of the simulation are shown below.  After the lookback period, the release drops to zero since the pool is in the conservation zone and no minimum release is required.  Once it rises into the flood pool (above 50 ft), ResSim wants to release as much as possible, however, the script limits this release.  Since the maximum release is interpolated based on the pool values provided in the dictionary, the release increases with increasing pool elevation.