Disturbance behaviors

Disturbance behaviors simulate different kinds of forest disruption. These behaviors cause tree damage and death due to a variety of processes.

In this document:
Disturbance parameters
Harvest
Planned episodic mortality
Storm disturbance
Storm damage applier
Storm killer
Selection harvest
Windstorm

Disturbance parameters

Note: the Harvest and Planned episodic mortality behaviors do not have their parameters entered through the Parameters Window. Set up these behaviors using the Edit Episodic Events Window.

Harvest

How it works

SORTIE can implement complex silvicultural treatments. Harvest events are defined by species, timestep, amount to remove, type of cut, and area of the plot. You can define as many harvest events as you wish. For information on planting new seedlings, see the Planting behaviors topic.

There are three types of harvest: gap cut, partial cut, and clear cut. The primary function of entering the harvest type is to control substrate composition after the harvest occurs. In a partial cut harvest, though, you have more flexibility in choosing which trees are cut. You can define up to four size classes, and specify the amount of trees to remove in one of four ways: as a percentage of total basal area, as an absolute amount of basal area, as a percentage of total tree density, or as an absolute amount of tree density. Trees of any size except seedlings can be cut.

The Harvest behavior selects the trees to remove in the same way for all three harvest types. When it is determining which trees to remove, it starts by finding the largest tree in the area of the plot affected by the harvest. It works its way through the trees from largest to smallest, assessing whether to cut each one until it either runs out of trees or reaches its cut target. This process preferentially removes the largest trees in each size range, unless the harvest is a percentage of density cut, in which case all trees in the target size ranges have an equal probability of being cut. If Harvest is cutting a percentage of basal area or an absolute amount of basal area, it will only cut a tree if its basal area will not cause the total to be more than the target. This means that, for basal-area-defined cuts, the Harvest behavior may skip some bigger trees and cut smaller ones in order to more exactly cut its target. Each species is cut separately. So, a request to remove 20% of three species will remove 20% of each of them, no matter what their relative proportions to each other.

Trees that are harvested are removed immediately. When light is calculated for that timestep, gaps opened up by the harvest will be visible. If there are behaviors which apply to stumps, a stump is created for each logged tree. Otherwise, the tree completely disappears.

The actual amount of tree harvest may not be exactly what was specified, since the Harvest behavior can't remove part of a tree to get the numbers right. The behavior stores how much it actually cut each timestep in the Harvest Results grid. To optimize the accuracy of the Harvest behavior, use larger cut ranges and high proportions of the plot area to make sure there is a big pool of trees to choose from.

How to apply it

There are two ways to add Harvest events to a SORTIE run. To define a new harvest, use the Edit Episodic Events Window. If you are a user of a previous version of SORTIE and have a harvest regime file you would like to use, there are instructions for adding it to your run in the Adding to a parameter file topic.

Episodic Mortality

How it works

The Episodic Mortality behavior allows you to replicate tree-killing events with the same level of control you have when defining Harvest events. A planned mortality episode can simulate disease, an insect outbreak, fire, or the like. The main difference between Harvest and Episodic Mortality is that the Episodic Mortality behavior can create snags, or standing dead trees. A large snag proportion can significantly affect the light and substrate dynamics of a SORTIE run.

Defining a mortality episode is like defining a partial cut harvest. (Mortality episodes have no automatic impact on substrate dynamics like harvest events do, although the newly dead trees may be a source of harvest input.) You can define up to four size classes, and specify the amount of trees to kill in one of four ways: as a percentage of total basal area, as an absolute amount of basal area, as a percentage of total tree density, or as an absolute amount of tree density. Trees of any size except seedlings can be cut.

When the Episodic Mortality behavior is determining which trees to remove, it starts by finding the largest tree in the area of the plot affected by the mortality episode. It works its way through the trees from largest to smallest, assessing whether to kill each one until it either runs out of trees or reaches its cut target. This process preferentially removes the largest trees in each size range, unless the event is defined by a percentage of density, in which case all trees in the target size ranges have an equal probability of being killed. If Episodic Mortality is removing a percentage of basal area or an absolute amount of basal area, it will only kill a tree if its basal area will not cause the total to be more than the target. This means that, for basal-area-defined cuts, the behavior may skip some bigger trees and cut smaller ones in order to more exactly cut its target. Each species is cut separately. So, a request to remove 20% of three species will remove 20% of each of them, no matter what their relative proportions to each other.

What happens to dead trees depends on the rest of the run. If there are other behaviors in the run that deal directly with snags or create them, then the run is "snag-aware". In this case, all adult trees killed are turned into snags (saplings never become snags). If the run is not "snag-aware", then the trees are marked as dead. When/if the dead tree remover behavior runs, the dead trees will be removed at that time. These dead trees are available as input to Substrate.

The actual amount of trees killed may not be exactly what was specified, since the Episodic Mortality behavior can't remove part of a tree to get the numbers right. The behavior stores how much it actually cut each timestep in the Mortality Episode Results grid. To optimize the accuracy of the behavior, use larger kill ranges and high proportions of the plot area to make sure there is a big pool of trees to choose from.

How to apply it

To define planned mortality episodes, use the Edit Episodic Events Window.

Storm disturbance

This behavior simulates the effects of wind damage from storms. Its function is to assess whether or not storms have occurred in the current timestep, and if they have, how much damage they have caused. This behavior does not actually cause any trees to be damaged; that is the function of the Storm damage applier behavior.

How it works

Storm severity is assessed on a scale from 0 (no damage) to 1 (total damage). This interval of storm severity values is subdivided into ten storm severity classes. You assign each storm severity class a return interval. The reciprocal of the return interval gives the annual probability of each type of storm.

To decide whether storms occur, the behavior compares a random number to the annual probability of each storm severity class. For timesteps that are longer than one year, the behavior repeats the random number test for each year in the timestep. This process is repeated for each storm severity class separately. This means that multiple storms can occur in a single timestep, and if the timestep is longer than one year, there can be multiple storms in the same severity class.

If a storm occurs, the behavior calculates the amount of damage that occurs. A storm's damage index (severity) is randomly chosen within the boundaries of its severity class. The damage is stored in a grid called Storm Damage. The final output of the behavior is a map of storm damage (severity) across the plot, as an index between 0 and 1. If multiple storms occur, the damage is additive, up to a maximum value of 1 (total damage).

The way storm damage is calculated depends on two things: the pattern of storm susceptibility across the plot (entered in the Plot Storm Susceptibility Pattern parameter), and the method of storm damage application (entered in the Storm Damage Application parameter). Storm susceptibility is measured on a scale from 0 (not susceptible to damage) to > 1 (highly susceptible to damage). The pattern of storm susceptibility can be either "Uniform", meaning all locations within the plot have a susceptibility of 1, or "Mapped", meaning that you will provide a map with a susceptibility for each location in a grid called Storm Susceptibility. The method of storm damage application can be either "Deterministic", meaning that each location receives the storm's severity index, or "Stochastic", meaning that the storm's severity index provides a mean around which individual location severities are randomized.

There are three possible probability distribution functions for stochastic damage application: normal, lognormal, and negative binomial.

The normal distribution is:

Normal function

where σ is the function standard deviation. Mean is zero in this equation; the final value is reached by adding the function result to the mean.

The lognormal distribution is:

Lognormal function

where ζ is the function mean and σ is the standard deviation.

The negative binomial distribution is:

Negative binomial function

where u is the function mean and k is the clumping parameter. This is Equation 3.103 from Hilborn and Mangel.

Combining these two parameters provides four possibilities for the way a storm's damage is applied:

  1. Mapped Deterministic. The damage index for a location equals the susceptibility of that location multiplied by the storm's severity index.
  2. Mapped Stochastic. The storm severity for each location is determined by performing a random draw on a probability distribution function, with the overall storm severity providing the function mean. Each location's severity is multiplied by its susceptibility to arrive at the final storm damage index for that location.
  3. Uniform Deterministic. All plot locations are directly assigned the storm's severity index.
  4. Uniform Stochastic. The storm damage index for each location is determined by performing a random draw on a probability distribution function, with the overall storm severity providing the function mean.

How to apply it

Add the behavior to the behavior list for your run. A few rules:

Storm damage applier

The purpose of this behavior is to apply storm damage to individual trees. This behavior decides which trees are damaged when a storm has occurred and how badly. It also keeps track of the time since damage for damaged trees, and after a "healing period" returns them to healthy (undamaged) status.

There are three possible damage categories for a tree: no damage, medium damage, and heavy damage. Other behaviors can use the damage categories to determine what effects the storm damage had on a tree (slow growth, death, etc).

How it works

The behavior Storm disturbance determines whether a storm has occurred. When it does, an individual tree can either get no damage, medium damage, or heavy damage. The tree's probability of damage in a given damage category is:

where:

This behavior uses a random number to determine what damage category a tree falls in. If the random number is less than the probability for medium damage, the tree is undamaged. If the random number is greater than the probability for medium damage but less than the probability for heavy damage, the tree gets medium damage. If the random number is greater than the probability for heavy damage, the tree gets heavy damage.

If a tree is damaged, a counter is set for time since damage. This behavior checks this counter every timestep. When the amount of time specified in the Number of Years Damaged Trees Take to Heal has passed, the tree is considered healed and no longer has a record of storm damage.

If a damaged tree is damaged again in a new storm, it gets the most severe damage category that can apply to it and must go through the maximum healing time again in order to become undamaged.

How to apply it

Apply this behavior to the trees that can receive storm damage. You may not apply this behavior to seedlings. If you wish to use the Storm killer behavior to create snags from storm-killed trees, you must apply this behavior to the snag tree type. Along with this behavior, you must also add the Storm disturbance behavior.

Storm killer

This behavior kills trees damaged in storms. It decides which damaged trees die, and if they become snags, it manages the snag population by causing snag tip-up and removal. This behavior does not decide which trees get damaged in a storm; that is the job of the Storm damage applier behavior.

How it works

Trees that have received medium or heavy damage from the Storm damage applier behavior have a certain probability of survival. (Undamaged trees, and any trees with a DBH smaller than the values set in the Minimum DBH for Storm Damage, in cm parameter, are ignored.) The probability is:

where:

Once the survival probability has been calculated, this behavior uses a random number to determine whether it lives or dies. Damaged trees are only at risk of dying at the time of the storm that damages them; if they survive it, this behavior will not try to kill them again even if they are still damaged. A certain proportion of heavily damaged trees that die create tip-ups. The probability of this is in the parameter Storm - Prop. Heavy Damage Dead Trees that Tip Up.

If snags are used in this run, those trees that die in either damage category (except for tip-ups) become snags. A time-since-damage counter is set for each of these snags. After the amount of time specified in the Number of Years Storm-Damaged Snags Last has passed, this behavior will remove those snags, "killing" them. They are not available for later processes such as substrate. This behavior will not do anything to any snag that it did not kill. If snags are not used in this run, trees that die have a flag set indicating that they are dead. They are available during the timestep in which they die to substrate and other processes, in exactly the same manner as trees that die due to natural mortality. They will be subject to the same cleanup and removal processes as well.

If a heavily-damaged dead tree tips up, and snags are used in the run, the tip-up becomes a snag that has its "dead" flag set to true. It is available during the timestep in which it dies to substrate and other processes, in exactly the same manner as other snags that die due to natural mortality. It is subject to the same cleanup and removal processes as well. If snags are not used in the run, then tip-ups are treated like all other storm-killed trees.

Saplings that are killed in storms never become snags. They are killed in the manner described above for trees that die in a non-snag run. Existing snags are never at risk for storm damage or mortality, but the behavior must be applied to the snag tree type in order to cause storm-killed adults to become snags.

How to apply it

Apply this behavior to the trees that can be killed in storms. You must also apply the Storm damage applier behavior to the same trees. You may not apply this behavior to seedlings. If you wish to have storm-killed trees become snags, you must apply this behavior to the snag tree type. This may cause snags to appear due to natural mortality and other causes; you must use other behaviors to manage these snags.

You must also have any kind of mortality behavior applied to each tree species and life history stage to which this behavior is applied.

Selection harvest

This behavior allow you to specify target basal areas for a tree population as a method of harvest input, instead of designing specific harvest events.

How it works

You can specify up to four DBH ranges. You provide the lower and upper DBH bounds of these ranges, and the target amount of basal area for each. Each timestep, this behavior calculates the amount of basal area in each of these ranges. If it is greater than the target, this behavior signals to the Harvest behavior that it should remove enough basal area to bring each range back down to its target basal area. Since Harvest actually does the tree removal, see that behavior's documentation for the method used. If the amount of basal area in any given range is less than the target, no trees are cut in that range.

How to apply it

Add this behavior to your run. Harvest is also needed in the run, and should be placed after Selection Harvest in the behavior order.

Windstorm

Windstorm kills trees due to storm events. It is similar to the other storm behaviors, with a few key differences. For those long-time users of SORTIE, this is the same as the Windstorm submodel in the pre-6 versions of SORTIE.

How it works

Using the parameters, you provide a general "shape" of storm intensity. SORTIE then decides which storms occur each timestep, and which trees die as a result.

This behavior defines 11 storm return intervals: 1, 5, 10, 20, 40, 80, 160, 320, 640, 1280, and 2560 years. Each has a set annual probability: for example, an 80-year return interval storm has an annual probability of 1/80, or 0.0125. For each year of each timestep, for each return interval, SORTIE generates a random number to decide whether a storm of that return interval will occur. This means that there can be multiple storms in a timestep, or no storms at all. In a multi-year timestep, a storm of a given return interval can happen more than once.

You give each return interval a storm severity value, between 0 and 1. These are defined in the Windstorm - Severity for X Year Return Interval Storm parameters. A severity of 0 means no tree mortality; a severity of 1 approaches 100% mortality.

For each storm that occurs, Windstorm decides what trees will die as a result. A tree's probability of mortality is calculated as follows:

exp(a + c*s*DBH^b)/(1+exp(a + c*s*DBH^b))
where:

Below severity 0.1, the model becomes unreliable; so in that case, the severity is treated as a straight probability of mortality for all trees. For example, if a storm occurs of severity 0.05, all trees have the same 5% chance of dying. If a storm return interval's severity is set to 0, then that storm never occurs.

It is possible for a storm to occur and kill no trees, especially if it is a very mild storm or the forest has no large trees. Unlike the other SORTIE storm behaviors, there is no damaged-but-alive state. After a windstorm a tree is either dead or in perfect health.

Storm events happen "independently". Every time a storm happens, all eligible trees have a separate chance of mortality. Of course, the storms can never truly be independent. A storm can only kill the trees that another storm hasn't already killed.

Trees killed in a windstorm are treated like trees killed in natural mortality. They will form snags if the run uses snags, and are available for processes such as substrate.

Seedlings and snags are never killed by storms. For adults and saplings, only those trees to which the Windstorms behavior has been applied will be considered for storm mortality; and of those trees, only those trees with a DBH larger than the value in the Windstorm - Minimum DBH for Windstorm Mortality parameter can be killed.

You can delay the introduction of windstorms into the run using the Windstorm - Timestep to Start Storms parameter. If this value is greater than 0, no storms will occur until that timestep is reached.

Information on what storms occurred during a run is saved in the Windstorm Results grid. This grid lists how many storms occurred each timestep, and the basal area and density killed of each species in that storm.

How to apply it

Add this behavior to your run and apply it to saplings and/or adults of any species. If you wish to get results on storm events, save the Windstorm Results grid data in a detailed output file. You can then view the contents of this grid as a table using SORTIE's data visualization system.


Last updated: 22-Mar-2006 07:49 AM