Treatment Program Generator Design

Creating Treatment Programs for an analysis area

The class TreatmentProgramManager manages treatment program generation for an analysis area, as follows:

1. ForestDomains are evaluated and each treatment unit is assigned to a domain.
2. For each domain:
   1. Treatment units are set aside for nature conservation
   2. For treatment units that not has been set aside, the TreatmentProgramGenerator is called and treatment programs of the desired types (unmanaged, continuous management, or even aged management, given by the user) are generated
   3. For treatment units that has been set aside, unmanaged treatment programs are generated by the TreatmentProgramGenerator.

Treatment program generation requires is both performance and memory intensive. To get reasonable performance when reading from the database when treatment programs are generated, 20 treatment units are read at a time (or as many as there are left). Once treatment programs has been generated for a treatment unit, the memory allocated by that treatment unit is released (e.g. references are set to null allowing objects to be garbage collected).

Creating Continous Management and Unmanaged Treatment Programs

Creating Continous Management and Unmanaged Treatment Programs is fairly trivial. Growth prognosis is done for the treatment unit until the planning horizon has been reached.

For continous management, it is evaluated in each period if selection felling is allowed or not. If allowed, selection felling is performed.

Creating Even Aged Treatment Programs

Creating even aged treatment programs is more complex. A number of generations of the forest has to be created (a forest generation starts with regeneration and ends with final felling). An even aged treatment program must contain at least one complete generation, even if the planning horizon is shorter (net present value cannot be calculated if not a complete generation is present).

Even aged treatment programs are created based on treatment specifications (specifying when cleaning, first thinning, and final felling should be done) and fertilization policies (specifying if and how fertilization should be done). During the generation, a number of treatment specifications are evaluated, but the same fertilization policy is always applied for a given generation and control category. The latter also applies to regeneration.

Each forest domain contains one or more control categories. For each control category, it is specified if the control category is to be used in generation 1, generation 2 (and forward), or both. Treatment programs will be generated for each control category in the generation being in progress.

The diagram below illustrates the process for treatment program generation:

Each time regeneration is performed the treatment unit is grown until the regeneration has been activated on all prediction units (e.g. there are no waiting saplings).

Treatment specifications will be created each time a generation is to be completed. Then a treatment program is created for each treatment specification, up to and including a final felling treatment. Then a fertilization policy is applied if required (not shown in the figure).

Each treatment program is then checked, is the planning horizon reached and has at least one complete generation been created? If not a new generation is started. The figure above shows how new generations are simulated, there are also other (faster) possibilities to create new generations, described below.

Creating Treatment Specifications

A treatment specification contains a description on when cleaning, first thinning, and final felling can be done (cleaning and thinning can be omitted, final felling is always present in a treatment specification).

The purpose of treatment specifications is to generated all possible combinations of even aged management, based on user settings and of course the state of the treatment unit.

First it is determined when and if the treatments can be performed. For final felling lowest final felling age is calculated (according SVL, Skogsvårdslagen). For cleaning and thinning growth prognosis has to be made and in each period it is evaulated if the treatment is possible. Each treatment is then stored in a TreatmentSpecificationRange. It may look like this:

1. Cleaning period 4-5
2. Thinning period 8-10
3. Final Felling period 10-14

Thereafter the ranges are sorted in reverse priority, so that the treatment with highest priority (which will be varied most) is last. If the priority order (set by the user) is thinning - final felling - cleaning then the list above will look like this after sorting:

1. Cleaning period 4-5
2. Final Felling period 10-14
3. Thinning period 8-10

The last step is to, from the ranges, create a list of possible specifications. The class TreatmentSpecificationEnumerator creates an enumeration of all possible treatment specifications from the ranges and the class TreatmentSpecificationCollection filters the invalid permutations.

It might look like this:

Cleaning	Final Felling	Thinning	Comment
4	10	8
4	10	9
4	10	10	Filtered since cleaning and final felling not can occur in the same period
4	11	8
4	11	9
4	11	10
5	10	8
etc

(From the table it is also obvious why the treatment with the highest priority is last, it is varied most.)

Creating Generation 2-n

First time a second generation is created it must be simulated, but as the treatment program generates more programs for a treatment unit, treatment specifications and results from a generation are reused whenever possible, to get better performance.

The treatment program generator tries to create as many alternatives as possible for generation 1 and 2. If more generations are needed, generation 2 is repeated, no new alternatives are created for generation 3-n.

When a generation is finished and if it is complete (from regeneration to final felling), the treatment specification for it is saved. The treatment specifications are saved per control category, and separeted for generations that started with trees from an earlier generation (seed trees or shelterwood). The specification are sorted, with highest net present value first.

Also, treatment programs are saved when they are complete.

So when a new generation is to be started, the following conditions are evaluated:

LateGeneration

Is the generation before this generation complete? (Meaning is this generation 3 or later?)

SameControlCat

Is the same control category used in the new generation as in the previous generation?

SameStartState

Did the previous generation and this generation start with the same state regarding seed trees/shelterwood?

SavedSpecs

Are there saved specifications for the control category to be used by the new generation, with the same state regarding seed trees/shelterwood?

The desired methods of creating a new generation are (fastest first, slowest last):

CopyPreviousGeneration

Results are copied from the previous generation. No new simulation required. LateGeneration, SameControlCat, and SameStartState must be true

RepeatPreviousGeneration

Specification from previous generation is used, new simulation is done. LateGeneration and SameControlCat must be true.

CopyBestSaved

Several generations are created with result copied from saved treatment programs. No new simulation required. SameControlCat and SavedSpecs, and SameStartState must be true.

RepeatBestSaved

Several generations are created from saved specifications. New simulations required. SameControlCat and SavedSpecs must be true.

GenerateNew

Both new specifications and new simulation is done. Used when none of the methods above can be used.

A special case occurs when the treatment program generator is invoked from StandWise. In this case the copy methods above are not allowed. This is due to the fact the copied results not are stored in the treatment unit, and diagrams and tables in StandWise only shows results from the treatment unit.

A treatment program generation typically works like this:

1. First alternative of generation 1 is simulated.
   1. First alternative of generation 2 is simulated, specification is saved (GenerateNew)
      1. Only alternative of generation 3 (CopyPreviousGeneration)
   2. Second alternative of generation 3 is simulated, specification is saved (GenerateNew)
      1. Only alternative of generation 3 (CopyPreviousGeneration)
   3. etc for generation 2-3
2. Second alternative of generation 1 is simulated
   1. Alternatives 1-n for generation 2 are created by coping best alternatives 1-n from first alternative of generation 1 (CopyBestSaved)

The example above assumes that each generation either ends with retained trees, or that no generation ends with retained trees.

If more than one control category is used the scenario gets more complex. Say that two control categories are used, SeedTrees and NoSeedTrees. Generation will then be done like this:

Generation 1	Generation 2	How is generation done?
SeedTrees	SeedTrees	As above
SeedTrees	NoSeedTrees	As above, but Repeat... instead of Copy...
NoSeedTrees	SeedTrees	As above, but Repeat... instead of Copy...
NoSeedTrees	NoSeedTrees	As above