Disturbance behaviors simulate different kinds of forest disruption. These behaviors cause tree damage and death due to a variety of processes.
In this document: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.
Competition Harvest performs harvests in a way that preferentially removes the most competitive individuals in a plot. It also decides when and how much to harvest based on criteria you give it.
Competition Harvest performs harvests when specific conditions are met in the plot. The amount harvested is also based on conditions in the plot. There are three ways to specify the timing and amount of harvesting. The desired method is set in the Competition Harvest: Harvest Type parameter. The harvest types are:
Competition Harvest uses these criteria to determine when and how much to cut. Harvests occur over the the entire plot area.
During a harvest, Competition Harvest calculates how much basal area it needs to cut. It can select trees without regard to species, or it can remove trees in a set ratio. Species ratio is set in the Competition Harvest: Amount of Harvest Per Species (0 - 1) parameter. If all values are set to 1, this means that species identity is ignored when selecting individuals for harvesting. Otherwise, the species are cut in the proportions entered. The values should add up to one. For example, if Species 1 is set to 0.25 and Species 2 is 0.75, then Competition Harvest will try to make 25% of the basal area removed come from Species 1 individuals and 75% come from Species 2. Of course, there are trade-offs between removing the most competitive individuals and making sure specific species targets are met.
When selecting trees for harvesting, Competition Harvest removes the individuals that have the greatest competitive effects on their neighbors. The neighbors of an individual are all sapling and adult trees within the radius specified in the Competition Harvest: Max Radius of Competitive Effects (m) parameter. (Seedlings, snags, and dead trees never count as neighbors.) The competitive effect (COE) of tree i on the N neighbors surrounding it is:
where:
Competition Harvest removes the tree with the highest COE value in the plot, then updates the COE of each tree in the vicinity so that the removed tree is no longer a neighbor. This process is repeated until the harvest cut target has been reached. If removing a tree will cause the harvest to overshoot its cutting target, a random number is compared to the amount of overshoot to determine if the tree will be removed, then harvest ends. If species are to be cut in a certain proportion, then separate cut targets are maintained for each species. If the highest COE individual is of a species whose cut target has been reached, it is not cut and Harvest Competition searches for the highest COE individuals of other species.
Only trees to which you have applied the Competition Harvest behavior are considered for harvesting. You can only apply the behavior to saplings and adults. You can specify a size range to cut using the Competition Harvest: Minimum DBH to Harvest and Competition Harvest: Maximum DBH to Harvest parameters.
The Competition Harvest behavior stores how much it actually cut each timestep in the Competition Harvest Results grid. Additionally (and optionally), you can give the behavior a filename with the Competition Harvest: Filename for List of Harvested Trees parameter. If a filename is present, Competition Harvest will write to this file a list of the individuals harvested each timestep for the entire run. The file is a tab-delimited text file, with a header line, and five columns: X, Y, Species, DBH, and Timestep cut.
Apply this behavior to saplings and/or adults of any species.
Behavior reference string: Competition Harvest
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.
To add harvesting to a SORTIE run, use the Edit Episodic Events Window.
Behavior reference string: harvest
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.
To define planned mortality episodes, use the Edit Episodic Events Window.
Behavior reference string: episodic mortality
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.
There are two ways storms can occur: randomly according to a storm regime of your choosing, or scheduled at certain timesteps. Both methods can be used together.
Random storms according to a storm regime
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.
The overall frequency of storms can remain constant, or it can change through time. It has been reported in Goldenburg et al 2001 that storm activity in the North Atlantic cycles along with sea surface temperature. This behavior can thus change the storm frequency over time, using either a sinusoidal pattern, a constant linear change, or both together. In the figure below, curve 1 is a basic sine wave. Curve 2 has a sinusoidal pattern plus an upwards trend.
The actual probability of an individual storm that takes place in a storm regime with a cyclical frequency is:
Note that the new probability is a baseline probability, P(Fi), multiplied by a value that adjusts the probability according to where the model is at the given time in the frequency cycle. The frequency cycle multiplier is itself made up of two terms added together. The first term is the sine curve cycling, and the second term is the overall trend upwards or downwards.
Terms in the equation:
To turn off all cyclicity and use constant storm probabilities, set Storm - Storm Cyclicity Sine Curve d to 0, Storm - Storm Cyclicity Trend Function Slope (m) to 0, and Storm - Storm Cyclicity Trend Function Intercept (i) to 1. (The other values are unimportant.) To use only the sine portion with no trend line, set both Storm - Storm Cyclicity Trend Function Slope (m) and Storm - Storm Cyclicity Trend Function Intercept (i) to 0. To use only the trend portion, set Storm - Storm Cyclicity Sine Curve d to 0.
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.
Scheduled storms
You can also schedule storms to occur at certain timesteps. Use the Edit Scheduled Storms window to do this. You specify the year (NOT the timestep) you want the storm to occur, and a minimum and maximum severity for each. The actual storm severity will be a random number between the maximum and minimum. You can schedule as many as you want, including multiple storms per timestep. If there is also a storm regime present (non-zero values for the return intervals), those storms can also occur. The storm regime storms can also happen between scheduled storms.
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, each storm's severity is recorded separately.
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 two possible probability distribution functions for stochastic damage application: normal and lognormal.
The normal distribution is:
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:
where ζ is the function mean and σ is the standard deviation.
Combining these two parameters provides four possibilities for the way a storm's damage is applied:
Add the behavior to the behavior list for your run. A few rules:
Behavior reference string: storm
This behavior simulates random browsing from herbivores.
The trees eligible for browsing are those trees to which this behavior is applied. Each species has a probability of browse that is the same for all members of that species. Each timestep, for each eligible tree, a random number is used against its species probability to decide whether the tree is browsed.
The probability of browse for a species can be constant, or it can vary each timestep. If it is constant, the probability of browse is always the value in the Random Browse - Annual Browse Probability (0-1) parameter. If the probability is to vary, a new value is drawn from a random distribution, using the value in Random Browse - Annual Browse Probability (0-1) parameter as the mean and the value in Random Browse - Browse Probability Standard Deviation as the standard deviation. This draw happens once per species per timestep; all individuals of a species always face the same probability of browse in a given timestep.
If the timestep length is more than one year, the annual probability of browse is turned into a timestep probability using TP = 1 - (1 - AP)N, where TP is the timestep probability of browse, AP is the annual probability, and N is the length of a timestep, in years.
Trees that are chosen as browsed are marked as browsed. This behavior does nothing else to them. Other behaviors, such as growth and mortality, may use this information.
Apply this behavior to any species and type of tree.
Behavior reference string: random browse
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).
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.
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 damage 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.
Behavior reference string: storm damage applier
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.
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.
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.
Behavior reference string: storm killer
This behavior kills trees based on storm severity, without an intervening damage step.
When storms occur, trees to which this behavior are applied have the following probability of mortality:
where:
Once the mortality probability has been calculated, this behavior uses a random number to determine whether it lives or dies. If more than one storm has occurred in the current timestep, each storm gets a separate, independent chance to kill trees.
Trees that die have a "dead" flag set to true and are treated in the rest of the run like trees that have died due to natural mortality.
Apply this behavior to the trees that can be killed in storms. You must also use the Storm disturbance behavior and have any kind of mortality behavior applied to each tree species and life history stage to which this behavior is applied.
Behavior reference string: storm direct killer
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.
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.
Add this behavior to your run. Harvest is also needed in the run, and should be placed after Selection Harvest in the behavior order.
Behavior reference string: SelectionHarvest
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.
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.
The overall frequency of storms can remain constant, or it can change through time. It has been reported in Goldenburg et al 2001 that storm activity in the North Atlantic cycles along with sea surface temperature. This behavior can thus change the storm frequency over time, using either a sinusoidal pattern, a constant linear change, or both together. In the figure below, curve 1 is a basic sine wave. Curve 2 has a sinusoidal pattern plus an upwards trend.
The actual probability of an individual storm that takes place in a storm regime with a cyclical frequency is:
Note that the new probability is a baseline probability, P(Fi), multiplied by a value that adjusts the probability according to where the model is at the given time in the frequency cycle. The frequency cycle multiplier is itself made up of two terms added together. The first term is the sine curve cycling, and the second term is the overall trend upwards or downwards.
Terms in the equation:
To turn off all cyclicity and use constant storm probabilities, set Windstorm - Storm Cyclicity Sine Curve d to 0, Windstorm - Storm Cyclicity Trend Function Slope (m) to 0, and Windstorm - Storm Cyclicity Trend Function Intercept (i) to 1. (The other values are unimportant.) To use only the sine portion with no trend line, set both Windstorm - Storm Cyclicity Trend Function Slope (m) and Windstorm - Storm Cyclicity Trend Function Intercept (i) to 0. To use only the trend portion, set Windstorm - Storm Cyclicity Sine Curve d to 0.
For each storm that occurs, Windstorm decides what trees will die as a result. A tree's probability of mortality is calculated as follows:
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.
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.
Behavior reference string: Windstorm
The harvesting interface allows SORTIE to work directly with another program. SORTIE tells the other program what trees are eligible for harvesting, and the other program replies with its choices. This lets users write code for harvesting without having to modify SORTIE itself.
Warning - this link between SORTIE and another program is inefficient. It may be very slow when there are large numbers of trees. It is for convenience, not speed.
You set up the Harvest Interface behavior using the Edit->Harvest Interface window. Parameters in this documentation are defined by their names on that screen.
You either create or find a separate program (an executable) that reads a text file of trees, makes decisions about which to kill, then writes those trees to kill to another text file. You tell SORTIE where to find this executable using Path and filename of the executable on the Edit Harvest Interface window.
Each harvest timestep, SORTIE writes a text file with a list of trees eligible for harvest. The trees in the list are those to which the Harvest Interface behavior is applied. You choose which trees those are in Behavior currently assigned to on the Edit Harvest Interface window. Once the file is written, SORTIE then launches your executable. Your executable writes a file in response with the list of trees it wishes SORTIE to kill.
Trees that are cut are treated exactly like those in SORTIE harvest. That is, they disappear completely and do not become snags. See the documentation on Harvest for more details. The cut details for each timestep are written to the Harvest Results grid. (Warning - if you put both the Harvest and Harvest Interface behavior in the same run, they will overwrite each other's results in the grid.)
Because the process can be slow, you can set harvests to occur less often than every timestep. To do this, use How often to harvest, in years on the Edit Harvest Interface window.
Optionally, you can also add new tree data members that are controlled by the executable. The executable can write a file with a list of trees to update, and the new values for those variables for each tree.
Each harvesting timestep, SORTIE begins by writing a file of all trees eligible for harvest. You give SORTIE the path and name of that file in Tree file that SORTIE will write on the Edit Harvest Interface window. SORTIE does not care what the filename nor file extension is. The file is tab-delimited text. It has the following format:
Line 1, two columns: Current timestep, total number of timesteps
Line 2, column names, 6+n columns: "X", "Y", "Species", "Type", "Diam", "Height", [...]
Subsequent lines, 6+n columns, one line per tree: X, Y, species number, type number, DBH/diam10, height, [...].
Species is given as a number from 0 to x - 1, where x is the number of species. The number counts the species in the order in which they are listed in the parameter file, which is the same as the order they are listed in the Tree Setup window.
Type is given as a number as well. The type numbers are:
Stumps are not available for harvesting.
The "Diam" value is diameter at 10 cm if the tree type is seedling, and DBH in all other cases. Both of these values are in cm.
The "Height" value is the height of the tree in meters.
The [...] represents additional columns that you can ask SORTIE to include. You set this up using the File columns section of the Edit Harvest Interface window. You can choose any other tree data member that applies to all of the kinds of trees to which the harvest interface is applied, including new ones that you add. The list of tree data members depends on the other behaviors in the run. The column header matches the internal SORTIE name of the data member (which is what is displayed to you when you choose new data members). You cannot change the first six default columns.
The executable writes a file in response with the trees that it wishes to harvest (Tree harvest file that the executable will write on the Edit Harvest Interface window). If you have set up new tree data members, the executable also writes a second file with a list of live trees to update (Tree update file that the executable will write on the Edit Harvest Interface window). All trees in both of these files must come from the tree list that SORTIE wrote for that timestep. No tree may appear in both files.
The file format of the user response files is identical to that of the SORTIE file, with the same columns in the same order.
Each harvest timestep, all these files are overwritten.
If there are no trees eligible for harvesting, SORTIE still writes a file with only the first two header lines (no individual tree lines). It expects the executable to do the same if it does not want trees harvested or updated.
You can request that SORTIE create new data members under the executable's control for the trees to which this behavior applies. Set this up in the New tree data members to add section of the Edit Harvest Interface window. You can create as many as you want. You can give them any name up to 9 characters long. They each hold a float value. The values are uninitialized in newly created trees.
If you want the new data members to be written to the file that SORTIE writes, make sure you put them in the list of file columns.
If new data members have been created, SORTIE expects the executable, each time it is called, to write a file with the list of trees it wishes to update, and the new values for these data members. You can only make changes to the new data members that you create. You cannot change any other attribute of a tree.
The user executable launches, runs, and quits once per harvest timestep. SORTIE waits for it to finish before resuming. This means it must do any necessary initialization and setup each harvest timestep.
The executable can be written in any language, and can do anything it wishes. The only two requirements is that it be a standalone executable, and that it produce the file of trees to harvest that SORTIE expects.
The executable should be prepared for the condition that there are no trees in the file SORTIE writes, and should write empty files if it doesn't want any trees harvested or updated.
SORTIE's behavior cannot be guaranteed in the event of a crash in the user executable.
The executable probably has its own input data for setup. If it takes arguments during launch, you can give SORTIE a string to pass to the executable in Arguments to pass to the executable on the Edit Harvest Interface window.
SORTIE provides a convenience feature for those executables that read setup parameters from a file. You may wish to set up a SORTIE batch run where your executable uses different parameters for each run. You can give SORTIE a file of all the parameters for the entire batch in a text file, and for each run, it will separate out that run's parameters and write them to a file for your executable. The parameters for a single run must be on a single line of the entire batch file, and will be written to a one-line file for the individual run. Specify the entire-batch parameters file in Parameters file for batch run, and the single-run file in Single-run parameters file for batch run on the Edit Harvest Interface window.
For example, suppose there is an executable that takes three parameters. It reads these parameters from a one-line file named "par.txt", like this:
par1 | par2 | par3 |
You can set up a batch of three runs, then set up all the parameters in a single file, like this:
par1_1 | par2_1 | par3_1 |
par1_2 | par2_2 | par3_2 |
par1_3 | par2_3 | par3_3 |
You give SORTIE this file, and tell it to write "par.txt" for each run. The first run in the batch, SORTIE will write the first line to "par.txt"; the second run in the batch, it will write the second line to "par.txt", etc.
Tips:If you are having trouble with SORTIE not finding your code's output file, try explicitly writing out directories in your code (i.e. "C:\sortie\file.txt" instead of just "file.txt").
It is easiest if you add the harvest interface after the rest of your parameter file is complete, so that you have full access to data members. Open Edit->Harvest Interface and complete the setup. This adds the harvest interface behavior to your run. To remove it, use the Model flow window.
Behavior reference string: Harvest Interface