Lesson 4 - Exercise: Modeling Seasonal Variables in a Lookup Table

Now that we have learned the basics of referencing Calendar Time Run Properties, let’s do an Exercise to get a bit more comfortable with them.

We are going to start with a model we built in a previous Exercise.  You should have saved a model named Exercise8.gsm.  Open the model now. (If you failed to save that model, you can find the Exercise, named Exercise8_Evaporating_Pond2.gsm, in the “Exercises” subfolder of the “Basic GoldSim Course” folder you should have downloaded and unzipped to your Desktop.)

This simple model has an evaporating pond.  The following assumptions remained unchanged:

• The pond is initially empty.
• There is a constant inflow to the pond of 10 m3/day.
• We will assume that the pond’s capacity is so large that we don’t need to specify an Upper Bound (as we won’t reach it).
• The evaporation rate is controlled by the surface area of the pond: 
  Evaporation rate  = k * A
  where k has units length/time and A is the surface area. The variable k is a measure of the rate at which water evaporates from the pond. 

In the original model (Exercise8), k was represented by a constant value of 0.7 cm/day. Obviously, however, we would expect this value to vary by season (and, in fact, it would also vary diurnally).

In this model, we are going to make k a function of the month of the year according to the following table:

To do this, we only have to change three things in the existing file:

1. First, let’s turn this into a calendar-based model with a Start Time of 1/1/2017 and an End Time of 1/1/2020 with a 1 day timestep.
2. Delete the Data element named “Evaporation_Rate” and replace it with a Lookup Table of the same name.
3. Edit the Expression element named “Evaporation” to correctly reference the Lookup Table.

The tricky part here is how to define the Lookup Table (which we discussed in detail in Unit 8, Lesson 5).  Obviously, we somehow want to represent the information in the table above in a Lookup Table. In this case, what is the independent variable?  It is the month of the year. 

Stop now and try to build and run the model.

Once you are done with your model, save it to the “MyModels” subfolder of the “Basic GoldSim Course” folder on your desktop (call it Exercise13.gsm). If, and only if, you get stuck, open and look at the worked out Exercise (Exercise13_ Evaporating_Pond3.gsm in the “Exercises” subfolder) to help you finish the model.

Your new model structure should look something like this:

So how do we define the Lookup Table to properly represent the seasonality in the evaporation rate? The key point to understand is that we want to vary the evaporation rate by month, and to do so we are going to reference the Lookup Table using the “Month” Run Property.  The Month Run Property is dimensionless and varies from 1 to 12 during a simulation.  So in this case, the independent variable is simply a dimensionless value (and we will assign it a Name of “Month”).  The Lookup Table is defined as follows:

The data is entered as follows:

We then reference the Lookup Table (in the Expression named “Evaporation”) like this:

Note that we don’t have to worry about any interpolation or extrapolation settings for the Lookup Table because we know that the value we are sending it (Month) will always be an integer between 1 and 12, inclusive.

If we run this model (for 3 years), the results look like this:

As you can see, the pond volume follows a cyclical pattern, reaching a low value in the middle of the year (due to the higher evaporation rate) and reaching a peak around January or February (due the lower evaporation rate).

Note that this model shows a step pattern from month to month (instead of varying smoothly).  This is actually not realistic (it is likely that it would vary smoothly over the month; there is no physical reason for the flows to change sharply at the beginning of each month!).  The reason for this behavior is that we have specified the evaporation rate on a monthly basis (it is held constant for the entire month, since the Run Property Month stays constant over each month, and then changes sharply at the beginning of each month).  In reality, it would change over the month. However, since the data represent average monthly values, we must hold it constant (it would be inappropriate to do otherwise).  This is actually a common simulation issue: you will often have some input data at a fine level of discretization (e.g., daily), while other data is only available at a coarser level (monthly). To represent the dynamics (and the daily data) properly, you need to use a small timestep (e.g., daily), but will then see step-like behavior due to the more coarsely-defined input.  In some cases, you may be able to make some assumptions and convert the monthly values to daily values (so that they vary smoothly), but in most cases this would be inappropriate (you would need some information on the nature of the day to day changes and trends).