A SmartTool to modify a grid so that it matches specified values at specific points
Algorithm by Les Colin - WFO Boise, ID
Python Implementation by Tim Barker - WFO Boise, ID
SERP is a GFE SmartTool that changes grids by adding a “difference grid” onto the current grid. The
difference grid is calculated by fitting a surface of “serpentine curves” to differences between the
original grid values, and the values desired at specific points. The user specifies the desired values
at each point with sliders in a dialog. The list of points can come from either pre-defined lists, or the
current GFE sample points. The result is a smoothly changed grid, which retains small-scale detail
existing in the original grid, but which matches the point values exactly.
The concept of modifying a grid at certain points while keeping the small-scale grid information is
probably easier to understand by looking at an example.
Take the following MinT grid. GFE Sample points have been overlaid on the image to highlight the
MinT at certain cities.
The grid has a lot of topographic variability that we want to keep, but we want to modify the grid such
that the values at some of the “sampled” cities are different. For example, let’s say that we want to
change the temperature at Boise (the sample value of 61 near the center of the grid) to 66 degrees.
When we start the serp tool, we get a dialog box with several options for the tool. For now, let’s just
use the Zone Cities sample set, and with elevation adjustment off.
When you click on Run, the tool brings up a dialog box, where you use slider bars to set the values at
the Zone Cities:
The full dialog can have many cities on it, and you control the labels, locations, maximum number of
points in a column, etc. via the configuration section of the tool.
Now, we said for our example that we wanted to raise the temperature at Boise from 61 to 66
degrees. That is a change of +5 degrees. So, we set the slider for Boise to 66:
The number in parenthesis next to the slider shows that this will be a change of +5 degrees.
Finally, click on OK at the bottom of the dialog and the MinT grid then changes to:
The temperature value at the Boise sample point has changed to 66. If you carefully compare this
image to the original, you will also see that the sample values at none of the other sample points has
changed. This is not just coincidence, but required. By leaving the slider bars for the other cities
alone, we actually specified that the temperature not change at those cities. However, the 5 degree
change has also not been applied only at the Boise gridpoint. Instead, it has been “spread out” over
nearby gridpoints. In fact, the difference between the original grid and the final grid looks like this (the
color table shows areas where the temperature warms with orange/yellow colors, and areas where
the temperature cools with blue/green colors):
The algorithm is smoothly fitting a “change grid” to your specified change values at the pre-defined
points. Note however, that by raising the temperature by 5 degrees at Boise, and not changing it at
other nearby locations, the “shape” of the area that warms is non-circular. The warming “spreads out”
further in directions where a “no-change” point is far away, but only spreads out a small distance
where a no-change point is nearby. In some ways, this may not be what you wanted. If your intent
was only to raise the temperature at Boise and some nearby areas by 5 degrees, then you should
have specified the area explicitly, and raised the temperature 5 degrees using the adjust tool. By
specifying changes at specific points, you are allowing the curve fitting algorithm to determine how to
distribute those changes spatially.
This example is fairly simplistic. If we only wanted to raise the temperature at Boise by 5 degrees,
while keeping the temperature at other cities the same, the serp tool is probably the wrong tool to
use. However, in more complex cases, the serp tool can be helpful for quickly defining complex
patterns of changes over many locations.
For example, say that we want to modify temperatures with a complex pattern like this:
To generate these changes with other tools could take many steps, and would likely require you to
use several different tools. Using serp, you can generate such changes very quickly with a single
tool, in a single step. The resulting MinT field looks like this:
You can see that even while making rather complex “large-scale” changes to the MinT field, the
small-scale detail is preserved.
“Sample Set:” option:
Up to this point, we have been using sample points at fixed and pre-specified points. In the
configuration section, you can specify multiple lists of pre-determined points, and you control which
points are in the lists, how they are labeled, where they are located, etc. However, you can also
specify that the “current” set of sample points in the GFE be used. For example, suppose we have
our GFE display set up like this:
We have intentionally turned on the “display lat/lon” option for the sample points, so that we can
reference them easier later on. Now in the serp tool options, we choose “Current Samples”:
and the slider bars to specify the values come out looking like this:
You will note that the tool has no way to “label” the slider bars other than the latitude/longitude of the
points. The forecaster may have placed samples in any location, so there is no reliable way to label
these points with a city name, or other meaningful name. Since the lat/lon is displayed in the slider
bar dialog box, we earlier turned on the “show lat/lon” option for the sample points in our GFE.
Suppose we want to modify the point that was 61 degrees to be 66 degrees, so we set the slider bar
The modified MinT field will come out like:
It is worth pointing out, once again, that because of the specified changes at only a few points, the
algorithm comes up with changes to the MinT grid that actually look like this:
Where the changes have been “spread out” over the rest of the grid.
Elevation Adjustment option:
The elevation adjustment option allows you to fit the changes to your specified points not only
spatially, but also with respect to elevation. The result can be quite complicated, but might be
appropriate if you want to mainly influence features near the same area, and at nearly the same
For an example, lets start with the same MinT grid we have been using all along, but let’s concentrate
in the mountainous regions north of Boise, near McCall. The topography image in this area looks like
this (McCall is the sample point with an elevation of 5002 feet):
The original MinT grid in this area looks like this:
If we simply raise the temperature at McCall from 50 to 55 without the elevation factor on, we get a
new field that looks like this:
And the changes look like this:
Now, if we turn on the elevation adjustment in the serp tool options:
And make the same change of 5 degrees at McCall, the change grid comes out like:
Some of the points that are relatively “close” to McCall spatially, but are relatively “far” from McCall in
terms of elevation, have now changed less drastically than when we had the elevation adjustment
turned off. The relative “weight” given to elevation versus distance is controlled by the elevation
factor in the serp tool options. The default of 36 gives reasonable values. The value of 36 means
that 36 feet of elevation difference is equal to a horizontal distance of 1 kilometer away.
You can change the elevation factor in the serp tool dialog. If you make the factor smaller, say for
example, 12, then 12 feet of elevation difference is equal to 1-km horizontal distance. In other words
12 feet is now equal to 2-km horizontal distance. Essentially, this means that elevation is twice as
“influential” in the algorithm. Conversely, if you make the elevation factor larger, elevation becomes
less influential in the algorithm.
Let’s look at an example to illustrate the influence of the elevation factor. If you make the same 5
degree change at McCall, but use an elevation factor of 6, you get changes that look like this:
You can see that some gridpoints very close to McCall, but with much different elevations, are now
getting changed very little by the serp tool. Conversely, areas further away from McCall, but at nearly
the same elevation, are getting changed more than then they were originally.
If you go to the extreme, and set the elevation factor to 1, distance has virtually no effect, and
elevation is the only factor determining how much temperature is changed. The changes look like
In this extreme case, gridpoints that are nearly the same elevation as McCall get changed nearly the
same amount, no matter how far away they are from McCall.
If you make the elevation factor larger than the default. You reduce the impact of elevation. For
example, setting the factor to 50 makes the elevation changes look like:
If you go to the extreme and set the elevation factor to 100, the changes are essentially the same as
if you had the elevation adjustment off:
When running the serp tool on vector grids that contain both a magnitude and direction, the tool
consults the GFE Vector Edit Mode setting to determine whether to modify magnitude only, direction
only, or both. For example, if we have a wind field that looks like this:
And the Vector Edit Mode is set to “Magnitude Only”:
We are presented with a dialog box with sliders for the magnitude at each site:
If we then change the wind speed at Boise from 4 to 9 knots:
The modified grid becomes:
And the changes that were made to the magnitude look like:
On the other hand, if the Vector Edit Mode is set to Direction Only:
Then we are presented with a dialog box with sliders for each site, where we can set values for the
Lets say we set the direction at Boise to 190 degrees (a change of +90 degrees):
Then the modified grid becomes:
Note that only the direction has been changed, the wind speed (or magnitude) has remained
If the vector edit mode is set to both:
The dialog box provides a text edit box with the current values (in direction@magnitude format), and
you can modify those values as you see fit:
For example, if we modify the value at Boise from “100@4” to “190@15”:
The resulting grid looks like:
Where both speed and direction have been modified.
1. Made the Serp code consistent among all tools that use the Serp method. In fact, the
Serp tool now uses the code in the ObjAnal Utility to do the actual serp calculations.
Made the serp code faster and use less memory in the process.
1. Various changes to the algorithm that calculates the weighting of points so that many points clustered in a
particular area do not overwhelm the influence of points that are more “remote” from each other.
2. Control points that lie off the GFE grid are now properly ignored.
3. Control points that would lie in the same gridcell as another control point are now properly ignored.
4. Removed the choice of “change mode” versus “actual values mode”, and made the changes always
visible in the dialog where the values are specified.
5. Fixed another problem for sites that use a non-square GFE domain.
1. Fixed a problem for parameters with non-integer precision (i.e., QPF has precision of 0.01 and SnowAmt
has precision of 0.1).
1. Fixed a problem for sites that use a non-square GFE domain.
2. Changed the default setting to have Elevation Adjustment ON, and added a configuration parameter so
that a site can set the default to OFF if desired.
1. Fixed resolution calculation for parms with precision other than integer (i.e., QPF that has resolution of
0.01 (by default) and SnowAmt that has resolution of 0.1 (by default))
2. Fixed code that rounds values to nearest precision so that it should work with RPP versions before and
after RPP 20 (the SmartScript round routine changed in RPP 20).
1. Numerous changes to increase the speed of the tool have been implemented. They will probably wont be
noticed unless you are running serp with dozens of control points.
2. The resolution for different parms is now derived directly from the IFPS server, rather than being
hardcoded into the tool code.
3. The dialog box for setting control point values is now created internally by the tool, such that if there are
more than a certain number of “control points”, it will break the dialog box up into columns. You can
control the maximum number of points in a column with the MaxPointsInColumn value in the configuration
4. A small change in the serp calculation that accounts for “clustering” of points has been implemented.
Now a cluster of points very close together will not overwhelm a single point far away.
5. The values for the elevation adjustment have been changed to be in feet/km rather than feet/gridpoint.
This means that the same elevation adjustment values can be used on grids with different grid-resolutions
with the same effect. The defaults were changed so that they basically correspond to the old defaults.
1. Modified so that when editing “vector” grids, it obeys the setting of the Vector Edit Mode, and allows
modifications to the Magnitude Only, Direction Only, or Both. When editing both magnitude and direction,
an “entry” box is provided for each point, with the current value in “dir@spd” format (in this case, it does
not matter if you set the “changes” or “actual values”).
1. A new option to modify the “final” or “actual” values with the slider bars, rather than just the “change
2. A new option to have several different sample sets, as well as use the current set of sample points
displayed in GFE.
3. A new option to fit the change grid using both distance and elevation. You can control the relative
importance of elevation in this algorithm.
4. Easier configuration, without having to calculate the x and y grid locations of the points. You now only
need to specify the lat/lon.