Heureka Wiki - User contributions [en]

Forest Data Results

2026-03-27T08:10:48Z

Osskyn: Added missing result variable 'Species Richness'

This result group contains: [[ResultCategoryDescription::State for each treatment unit. Results include data for each treatment unit, alternative and time period. Please note that species-wise data is placed in a separate group (Data per Species).]]

{| {{table}}
| align="left" style="background:#f0f0f0;width: 30%;"|'''Variable name'''
| align="left" style="background:#f0f0f0;width: 20%;"|'''Unit'''
| align="left" style="background:#f0f0f0;width: 50%;"|'''Description'''
|-
| Mean Age (excl. overstorey)||yr||Mean total age for non-overstorey trees, basal area weighted if established stand, arithmetic of main saplings if young stand
|-
| Mean Age ||yr||Basal area weighted mean age all trees, including overstorey trees.
|-
| Mean Age Main Saplings||m||Mean age of main saplings
|-
| Stand Age||yr||Years since regeneration
|-
| Basal area (incl. overstorey)||m<sup>2</sup>/ha||Basal area including overstorey trees
|-
| Basal area (excl. overstorey)||m<sup>2</sup>/ha||Basal area excl. Overstorey
|-
| Basal area (overstorey)||m<sup>2</sup>/ha||Basal area of overstorey trees (retention-, seed- and shelterwood trees)
|-
| Closure||unitless||Ratio between the volume of the forest, compared to the volume that would be optimal to harness the wood production potential of the site. In young stands, the number of main saplings is used instead of volume.
|-
| {{DgvLink}} ||cm ||Basal area weighted mean diameter of trees, excluding overstorey trees
|-
| {{DgvLink}} Overstorey||cm ||Basal area weighted mean diameter of overstorey trees
|-
| {{HgvLink}}||m||Basal area weighted mean height for non-overstorey trees
|-
| {{HgvLink}} Overstorey||m||Basal area weighted mean height for overstorey trees (retention-, seed- and shelterwood trees)
|-
| Mean Height Main Saplings (arithmetic)||m||Arithmetic mean height for main saplings (calculated as weighted averaged using calculated crop tree probabibilites as weights)
|-
| Mean Height All Saplings (arithmetic)||m||Arithmetic mean height for all saplings
|-
| SI Management||H100 m||Site index for management to be used when calculating minimum final felling age (LSÅ)
|-
| Dominant Species||species||Regeneration species or species with largest basal area or stems
|-
| Dominant Height||m||Dominant height based on the 100 largest trees (with respect to tree diameter) per ha of dominant species
|-
| Dominant Height From {{DgvLink}}||m||Dominant height calculated with a function using Hgv as explantory variable (Björn Elfving)
|-
| Dominant Height From Trees||m||Dominant height calculated from tree list
|-
| Initial Min Final Felling Age||yr||Initial minimum final felling age (in year 0).
|-
| Min Final Felling Age||yr||Minimum final felling age. This can change over time if the next generation is regenerated with another species, or if climate models are applied (cf. SIS (projected) below).
|-
| Volume (incl. overstorey)||{{m3skLink}}||Volume (incl. overstorey)
|-
| Volume overstorey||{{m3skLink}}||Volume of overstorey trees (retention-, seed- and shelterwood trees)
|-
| Volume (excl. overstorey)||{{m3skLink}}||Volume (excl. overstorey)
|-
| Volume ≥ 8cm dbh (incl. overstorey)||{{m3skLink}}||Volume of trees ≥ 8 cm dbh (incl. overstorey)
|-
| Stems||stems/ha||Stem density (all trees)
|-
| <div id="Regeneration Species">Regeneration Species</div>||[[Definition:SpeciesCode|SpeciesCode]]||Species for which the current rotation was regenerated (if even-aged management), or dominant species if regeneration species is unknown
|-
| Species Richness||species'||The number of unique species' within a treatment unit. Uncommon species' are often grouped into categories, as a result, this value will often be underestimated.
|-
| Waiting State||true/false||True if young stand that has not yet reach 2-3 meters height and is waiting to be activated. Interpolated state.
|-
| SIS (projected)||H100 m ||[[Variable:SiteIndex|Site index]] determined from site index factors, and adjusted for climate change if climate model is actived.
|-
| SIH (estimated)||H100 m ||see [[Variable:SiteIndexH (SIH)]]. Calculated with site index equations for height development of dominant trees. H100, for birch H50.
|-
|
|}

[[Category:Result Variables]]

ControlTable Treatment Program Generator

2025-06-19T13:34:31Z

Osskyn: /* Treatment timing - Tactical planning */

[[Category:Control Tables|Treatment Program Generator]]
[[Category:Reference Manual]]
Overview of parameters in control table Treatment Program Generator. This table is [[ControlTableDescription::available in PlanWise and StandWise and contains settings for how management programs are constructed]].

Usage: see [http://heurekaslu.org/help/index.html?kontrolltabell_treatment_progr.htm Heureka online help documentation].

== Treatment timing - General ==
Allows you to control how treatment programs are generated.

====Management System====
:Type of management system to generate treatment programs for:
:'''EvenAged''' generates alternatives for even-aged management.
:'''Uneven-aged (CCF)''' generates alternatives for continuous cover management (also referred to as CCF, uneven-aged, selective felling, or selection harvesting).
:'''Unmanaged''' generates an alternative without any treatments.

====Thinning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of first thinning.

====High Priority Thinning Criteria====
:If a stand is so dense that the thinning grade suggested by the thinning guide exceeds this value, then the thinning is not allowed to be postponed further.

====Rotation Age Adjustment Factor====
:Rotation age adjustment factor. Lowest final felling age is multiplied with this factor. For example, factor 1.1 means that the miniumm rotation age allowed is increased by 10%.

====Final Felling Period Min====
:Defines the minimum number of 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.

====Final Felling Period Max====
:Defines the maximum number 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.



==Treatment timing - Strategic planning ==
====Always Cleaning====
:True: Only save programs that include cleanings, if cleaning is recommended according to Cleaning settings.
:False: Programs without cleanings are also saved, even if cleaning is possible/recommended according to Cleaning settings.

====Always Thinning====
:True: If thinning is possible before a certain final felling period, then only programs with thinnings are saved, given that final felling period.
:False: Programs without thinnings are also saved, even if thinning is possible according to thinning guide.

====Cleaning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of cleaning.

====Max Number of Thinnings====
:Defines the maximum number of thinnings to be simulated in a treatment unit, in the same generation.

====Min Years Between Thinning and Final Felling====
:Defines the minimum number of years years between thinning and final felling.

====Min Years Between Two Thinnings====
:Defines the minimum number of years between thinnings simulated in a treatment unit.

====Treatment Priority====
:Defines the order, by '''Prio1''', '''Prio2''', and '''Prio3''', in which treatments are to be generated in the alternative programs.

==Treatment timing - Tactical planning==
Note that "tactical planning" is about much more than to generate stand management programs, but PlanWise support for tactical planning is limited to this. This mean the tactical TPG could be used for generating forest input data to some other (external) model for tactical planning, that takes into account for example road planning.

====Include Final Felling====
If true, final felling is included if possible during the tactical planning horizon. If false, final felling is ignored as an option during the tactical horizon.

====Include Thinning====
If true, thinning is included if possible during the tactical planning horizon. If false, thinning is ignored as an option during the tactical horizon.

== Fertilization ==
Allows you to control if and how fertilization programs are generated.

====FertilizationPolicy====
:Allows you to select the type of system to generate alternative programs (in treatment units where site and stand restricitions are met) according to:
:'''FP_NONE''' generates alternatives without any fertilization (default).
:'''FP_FIRSTTHIN''' generates alternatives with fertilization prior to first thinning.
:'''FP_FINALFELLING''' generates alternatives with fertilization prior to final felling.
:'''FP_FINALFELLING_TIMESTWO''' generates alternatives with two fertilizations, with a time interval of five years, prior to final felling.
:'''FP_LASTTHIN_AND_FINALFELLING''' generates alternatives with fertilization prior to last thinning and final felling.
:'''FP_EVERY_THIN''' generates alternatives with fertilization prior to all thinnings.
:'''FP_EVERY_HARVEST''' generates alternatives with fertilization prior to all harvests.
:'''FP_INTENSIVE''' generates alternatives with intensive fertilization, performed already in young stands and repeated with a certain time interval. ''Note that certain site restrictions must be met to allow for intensive fertilization.''
:'''FP_EVERY_TEN_YEARS''' generates fertilization every ten years, irrespective of occurence of harvesting.

==Biofuel Extraction ==
Settings to determine if biofuel should extracted after an harvest operation.

====FinalFelling====
Set to true if biofuel should be extracted after final

====Thinning====
Set to true if biofuel should be extracted after thinning.

====SelectionFelling====
Set to true if biofuel should be extracted after selection felling.

==Treatment Proposals==
====Apply Proposals====
:True: User-defined treatment proposals should be applied, if available.
:False: Ignore treatment proposals.

====Override Min Final Felling Age====
:True: Final felling proposals are always applied.
:False: If mean age calculated by Heureka is less than minimum final age then the final felling proposal is not applied.

====Override Thinning Check====
:True: Thinning proposals are always applied.
:False: If thinning is not applicable in the given period according to the condition used by Heureka then the thinning proposal is not applied.

====Treatment Proposals Missing====
Handling of stands that have no treatment proposals.
:'''NoActivity''': Do not apply any treatments during first 10 years to stands that have no proposals.
:'''LetPtgDecide''': Generate treatment programs according to control category settings.

ControlTable Treatment Program Generator

2025-06-19T13:34:05Z

Osskyn: Undo revision 11041 by Osskyn (talk)

[[Category:Control Tables|Treatment Program Generator]]
[[Category:Reference Manual]]
Overview of parameters in control table Treatment Program Generator. This table is [[ControlTableDescription::available in PlanWise and StandWise and contains settings for how management programs are constructed]].

Usage: see [http://heurekaslu.org/help/index.html?kontrolltabell_treatment_progr.htm Heureka online help documentation].

== Treatment timing - General ==
Allows you to control how treatment programs are generated.

====Management System====
:Type of management system to generate treatment programs for:
:'''EvenAged''' generates alternatives for even-aged management.
:'''Uneven-aged (CCF)''' generates alternatives for continuous cover management (also referred to as CCF, uneven-aged, selective felling, or selection harvesting).
:'''Unmanaged''' generates an alternative without any treatments.

====Thinning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of first thinning.

====High Priority Thinning Criteria====
:If a stand is so dense that the thinning grade suggested by the thinning guide exceeds this value, then the thinning is not allowed to be postponed further.

====Rotation Age Adjustment Factor====
:Rotation age adjustment factor. Lowest final felling age is multiplied with this factor. For example, factor 1.1 means that the miniumm rotation age allowed is increased by 10%.

====Final Felling Period Min====
:Defines the minimum number of 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.

====Final Felling Period Max====
:Defines the maximum number 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.



==Treatment timing - Strategic planning ==
====Always Cleaning====
:True: Only save programs that include cleanings, if cleaning is recommended according to Cleaning settings.
:False: Programs without cleanings are also saved, even if cleaning is possible/recommended according to Cleaning settings.

====Always Thinning====
:True: If thinning is possible before a certain final felling period, then only programs with thinnings are saved, given that final felling period.
:False: Programs without thinnings are also saved, even if thinning is possible according to thinning guide.

====Cleaning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of cleaning.

====Max Number of Thinnings====
:Defines the maximum number of thinnings to be simulated in a treatment unit, in the same generation.

====Min Years Between Thinning and Final Felling====
:Defines the minimum number of years years between thinning and final felling.

====Min Years Between Two Thinnings====
:Defines the minimum number of years between thinnings simulated in a treatment unit.

====Treatment Priority====
:Defines the order, by '''Prio1''', '''Prio2''', and '''Prio3''', in which treatments are to be generated in the alternative programs.

==Treatment timing - Tactical planning==
Note that "tactical planning" is about much more than to generate stand management programs, but PlanWise support for tactical planning is limited to this. This mean the tactical TPG could be used for generating forest input data to some other (external) model for tactical planning, that takes into account for example road planning.

====Include Final Felling====
If true, final felling is included if possible during the tactical planning horizon. If false, final felling is ignored as an option during the tactical horizon.

====Include Thinning====
If true, thinning is included if possible during the tactical planning horizon. If false, thinning is ignored as an option during the tactical horizon.

====Include Unmanaged====
If true, a program without harvesting during the tactical horizon is included. If false, all programs generated must include a harvest treatment during the tactical planning horizon.

== Fertilization ==
Allows you to control if and how fertilization programs are generated.

====FertilizationPolicy====
:Allows you to select the type of system to generate alternative programs (in treatment units where site and stand restricitions are met) according to:
:'''FP_NONE''' generates alternatives without any fertilization (default).
:'''FP_FIRSTTHIN''' generates alternatives with fertilization prior to first thinning.
:'''FP_FINALFELLING''' generates alternatives with fertilization prior to final felling.
:'''FP_FINALFELLING_TIMESTWO''' generates alternatives with two fertilizations, with a time interval of five years, prior to final felling.
:'''FP_LASTTHIN_AND_FINALFELLING''' generates alternatives with fertilization prior to last thinning and final felling.
:'''FP_EVERY_THIN''' generates alternatives with fertilization prior to all thinnings.
:'''FP_EVERY_HARVEST''' generates alternatives with fertilization prior to all harvests.
:'''FP_INTENSIVE''' generates alternatives with intensive fertilization, performed already in young stands and repeated with a certain time interval. ''Note that certain site restrictions must be met to allow for intensive fertilization.''
:'''FP_EVERY_TEN_YEARS''' generates fertilization every ten years, irrespective of occurence of harvesting.

==Biofuel Extraction ==
Settings to determine if biofuel should extracted after an harvest operation.

====FinalFelling====
Set to true if biofuel should be extracted after final

====Thinning====
Set to true if biofuel should be extracted after thinning.

====SelectionFelling====
Set to true if biofuel should be extracted after selection felling.

==Treatment Proposals==
====Apply Proposals====
:True: User-defined treatment proposals should be applied, if available.
:False: Ignore treatment proposals.

====Override Min Final Felling Age====
:True: Final felling proposals are always applied.
:False: If mean age calculated by Heureka is less than minimum final age then the final felling proposal is not applied.

====Override Thinning Check====
:True: Thinning proposals are always applied.
:False: If thinning is not applicable in the given period according to the condition used by Heureka then the thinning proposal is not applied.

====Treatment Proposals Missing====
Handling of stands that have no treatment proposals.
:'''NoActivity''': Do not apply any treatments during first 10 years to stands that have no proposals.
:'''LetPtgDecide''': Generate treatment programs according to control category settings.

ControlTable Treatment Program Generator

2025-06-19T13:33:34Z

Osskyn: Removed "Unmanaged" from Management Systems since this is now removed from Heureka

[[Category:Control Tables|Treatment Program Generator]]
[[Category:Reference Manual]]
Overview of parameters in control table Treatment Program Generator. This table is [[ControlTableDescription::available in PlanWise and StandWise and contains settings for how management programs are constructed]].

Usage: see [http://heurekaslu.org/help/index.html?kontrolltabell_treatment_progr.htm Heureka online help documentation].

== Treatment timing - General ==
Allows you to control how treatment programs are generated.

====Management System====
:Type of management system to generate treatment programs for:
:'''EvenAged''' generates alternatives for even-aged management.
:'''Uneven-aged (CCF)''' generates alternatives for continuous cover management (also referred to as CCF, uneven-aged, selective felling, or selection harvesting).

====Thinning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of first thinning.

====High Priority Thinning Criteria====
:If a stand is so dense that the thinning grade suggested by the thinning guide exceeds this value, then the thinning is not allowed to be postponed further.

====Rotation Age Adjustment Factor====
:Rotation age adjustment factor. Lowest final felling age is multiplied with this factor. For example, factor 1.1 means that the miniumm rotation age allowed is increased by 10%.

====Final Felling Period Min====
:Defines the minimum number of 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.

====Final Felling Period Max====
:Defines the maximum number 5-year periods to postpone final felling after the corresponding lowest allowable stand age has been reached.



==Treatment timing - Strategic planning ==
====Always Cleaning====
:True: Only save programs that include cleanings, if cleaning is recommended according to Cleaning settings.
:False: Programs without cleanings are also saved, even if cleaning is possible/recommended according to Cleaning settings.

====Always Thinning====
:True: If thinning is possible before a certain final felling period, then only programs with thinnings are saved, given that final felling period.
:False: Programs without thinnings are also saved, even if thinning is possible according to thinning guide.

====Cleaning Period Delay Max====
:Defines the number of periods, from a certain stand age, to vary the simulation of cleaning.

====Max Number of Thinnings====
:Defines the maximum number of thinnings to be simulated in a treatment unit, in the same generation.

====Min Years Between Thinning and Final Felling====
:Defines the minimum number of years years between thinning and final felling.

====Min Years Between Two Thinnings====
:Defines the minimum number of years between thinnings simulated in a treatment unit.

====Treatment Priority====
:Defines the order, by '''Prio1''', '''Prio2''', and '''Prio3''', in which treatments are to be generated in the alternative programs.

==Treatment timing - Tactical planning==
Note that "tactical planning" is about much more than to generate stand management programs, but PlanWise support for tactical planning is limited to this. This mean the tactical TPG could be used for generating forest input data to some other (external) model for tactical planning, that takes into account for example road planning.

====Include Final Felling====
If true, final felling is included if possible during the tactical planning horizon. If false, final felling is ignored as an option during the tactical horizon.

====Include Thinning====
If true, thinning is included if possible during the tactical planning horizon. If false, thinning is ignored as an option during the tactical horizon.

====Include Unmanaged====
If true, a program without harvesting during the tactical horizon is included. If false, all programs generated must include a harvest treatment during the tactical planning horizon.

== Fertilization ==
Allows you to control if and how fertilization programs are generated.

====FertilizationPolicy====
:Allows you to select the type of system to generate alternative programs (in treatment units where site and stand restricitions are met) according to:
:'''FP_NONE''' generates alternatives without any fertilization (default).
:'''FP_FIRSTTHIN''' generates alternatives with fertilization prior to first thinning.
:'''FP_FINALFELLING''' generates alternatives with fertilization prior to final felling.
:'''FP_FINALFELLING_TIMESTWO''' generates alternatives with two fertilizations, with a time interval of five years, prior to final felling.
:'''FP_LASTTHIN_AND_FINALFELLING''' generates alternatives with fertilization prior to last thinning and final felling.
:'''FP_EVERY_THIN''' generates alternatives with fertilization prior to all thinnings.
:'''FP_EVERY_HARVEST''' generates alternatives with fertilization prior to all harvests.
:'''FP_INTENSIVE''' generates alternatives with intensive fertilization, performed already in young stands and repeated with a certain time interval. ''Note that certain site restrictions must be met to allow for intensive fertilization.''
:'''FP_EVERY_TEN_YEARS''' generates fertilization every ten years, irrespective of occurence of harvesting.

==Biofuel Extraction ==
Settings to determine if biofuel should extracted after an harvest operation.

====FinalFelling====
Set to true if biofuel should be extracted after final

====Thinning====
Set to true if biofuel should be extracted after thinning.

====SelectionFelling====
Set to true if biofuel should be extracted after selection felling.

==Treatment Proposals==
====Apply Proposals====
:True: User-defined treatment proposals should be applied, if available.
:False: Ignore treatment proposals.

====Override Min Final Felling Age====
:True: Final felling proposals are always applied.
:False: If mean age calculated by Heureka is less than minimum final age then the final felling proposal is not applied.

====Override Thinning Check====
:True: Thinning proposals are always applied.
:False: If thinning is not applicable in the given period according to the condition used by Heureka then the thinning proposal is not applied.

====Treatment Proposals Missing====
Handling of stands that have no treatment proposals.
:'''NoActivity''': Do not apply any treatments during first 10 years to stands that have no proposals.
:'''LetPtgDecide''': Generate treatment programs according to control category settings.

Heureka Wiki

2024-11-26T13:00:58Z

Osskyn:

__NOTOC__ __NOEDITSECTION__
{{Languages|Heureka Wiki}}
{|width="100%"
|-
|style="vertical-align: top; border-right: 2em solid white; "|
{{Heureka Wiki:About}}

==Heureka Forestry DSS==
{{:Intro}}

[[About Heureka | More about Heureka and its features...]]


== Get Started ==
{{:Get_Started}}


<div style="background: #F7F7F7; border: 1px solid #999999; padding: 1em; ">
==Disclaimer==
SLU can not be held responsible for any errors in the software. Please read the license agreement: [[Heureka_EULA|Heureka EULA]]!
</div>

|}

Category:Plugins

2024-11-26T12:50:47Z

Osskyn:

[[Category:Reference Manual]]
It is possible to replace some of Heureka's built-in functions with your own plugins. You need to program such functions in C#. When you have built a plugin-function, you can place it in My Documents > Heureka > Common > Plugins-folder. After that, when you start a Heureka application (StandWise, PlanWise or RegWise), the program will scan this folder for functions that implements a certain so called interface. For example, if there is a plugin (dll) that implements the cost function interface, it will be imported to the application in run-time, and be available as an option the control tables interface.

Plugins are available for the following models:

*Single-tree growth
*Stand-level growth
*Sapling growth
*Tree volume
*Tree height
*Tree height growth
*Bark thickness
*Mortality
*Age to breast height
*Forwarder and harvester cost (time consumption)
*Optimization solvers

==Writing plugins for Heureka==
The easiest way to start writing a plugin is to use a template that we provide as a starting point [https://www.heurekaslu.se/FilerepositoryDev PluginTemplateProject.zip]. Either open the included project in Visual Studio 2015 or later, or start a new project and include only the required templates. All templates need a reference to 'Slu.Heureka.BaseLayer.dll' and to 'Slu.Heureka.DomainLayer.dll'. This library can be found with all installations of Heureka in the root of the installation directory.

Comments in the templates will tell you what Heureka expects as a return value from the functions. If a plugin needs to read settings that the user has made to, for example, the ProductionModel control table, Heureka will supply this to the plugin constructor if it finds a matching constructor that accepts a single ProductionModelControlTable as an argument. Otherwise the parameterless constructor will be used. At least one of these two constructors MUST be available.

If you want to supply custom arguments to the time consumption model, you can use the property CustomFunctionParameters, which is similar to a C# dictionary consisting of key-value pairs, see below.

'''IMPORTANT''' Plugins must have a unique Name string among plugins of the same type. Heureka uses the name to identify which plugin is currently selected.

After building the template project, the plugin .dll files are copied to the solution directory.

==Custom cost functions ==
Creating plugins for cost functions is done a bit differently. There is a plugin interface, but it is not really intended for implementing from scratch. Instead, you should either create a class that derives from *Slu.Heureka.DomainLayer.ValueModel.CostCalculatorSkogforskAdvanced, or
*Slu.Heureka.DomainLayer.ValueModel.CostCalculatorSkogforskSimple, or from the abstract class
*Slu.Heureka.DomainLayer.ValueModel.CostCalculatorBase (which the two above derive from).

Each of these implements IPlugin, so you do not have to worry about anything but overriding for example CostCalculatorSkogforskAdvanced properly. Below is a dummy dode example to calculate cost for a imagined cable logging system.
<div class="toccolours mw-collapsible mw-collapsed" style="width:70%" data-expandtext="Show code" data-collapsetext="Hide">
Code example for harvester and forwarder cost function
<div class="mw-collapsible-content">
<syntaxhighlight lang="csharp">
using System.Collections.Generic;
using Slu.Heureka;
using Slu.Heureka.BaseLayer;
using Slu.Heureka.BaseLayer.ConfigurationHandling;
using Slu.Heureka.DomainLayer.CommonForestModels;
using Slu.Heureka.DomainLayer.Forest;
using Slu.Heureka.DomainLayer.TreatmentModel;
using Slu.Heureka.DomainLayer.ValueModel;

namespace MyCostFunctions
{
public class MyLoggingCostFunction : CostCalculatorSkogforskAdvanced
{
private double _area;
private double _ayd;
private GenericPropertyArray<double> _functionParameters = new GenericPropertyArray<double>("CableLoggingCoeffs",
propertyLabel:new string[]
{
"A","B","SystemUtilization"
},
values:new double[] {0.25d, 3.0d, 0.9d},
defaultValues:new double[] { 0.25d, 3.0d, 0.9d },
descriptions:new string[] {"Param A (min/tree)",
"Param B (min/m3)",
"Utilization degree expressed as proportion"
});

/// <summary>
/// Empty constructor required for IPlugin handler
/// </summary>
public MyLoggingCostFunction () { }

public MyLoggingCostFunction (IControlCategory cc) : base(cc)
{
}

public override string Name { get { return "MyLoggingCostFunction1"; } }

public override GenericPropertyArray<double> CustomFunctionParameters
{
get { return _functionParameters; }
set { _functionParameters = value; }
}

/// <summary>
/// Initializes data needed by the models
/// </summary>
/// <param name="tUnit"></param>
/// <param name="period"></param>
/// <param name="treatment"></param>
/// <param name="results"></param>
/// <param name="value">Felling value</param>
protected override void Initialize(TreatmentUnit tUnit, int period, Treatment treatment, IList<Result> results, FellingValue value)
{
base.Initialize(tUnit, period, treatment, results, value);
int periodIndex = period == 0 ? 0 : period - tUnit.StartPeriod;
object[] treatmentInfo = (object[])results[periodIndex].Treatment(typeof(TreatmentData));
int index = FindFirstCuttingTreatment(treatmentInfo);
CalculateBasicVariables((TreatmentData)treatmentInfo[index], value);

if (Configuration.CustomHarvesterCostParameters != null &&
_functionParameters.Label == Configuration.CustomHarvesterCostParameters.Label)
{
_functionParameters = Configuration.CustomHarvesterCostParameters;
}

}

protected override double ForwarderCostFinalFelling()
{
return 0;
}

protected override double HarvesterCostFinalFelling()
{
// No cable logging required: use ordinaary function
if (Slope < SlopeType.ThirtyThreeToFifty)
return base.HarvesterCostFinalFelling();

// Add some code for calulating the cost...
// var cost = ... _functionParameters["B"]*AverageVolumeOfFelledTrees ...

return _functionParameters["SystemUtilization"] > 0 ? cost / _functionParameters["SystemUtilization"] : cost;

}

}
}

</syntaxhighlight>
</div>
</div>







==Getting Heureka to load the plugins==

Plugins are loaded from the current user's \Documents\Heureka\Common\Plugins directory. If successful, the plugin will show up in the drop-down box for that particular feature.

If a plugin failed to load, an error will show up in the 'General' output window with information of what went wrong.

Contact

2024-11-26T12:47:25Z

Osskyn:

<noinclude>
{{Languages|Contact}}
</noinclude>

;Support and general questions
:[mailto:{{HeurekaSupportMail}} {{HeurekaSupportMail}}]

;Maintenance
: The software is maintained, developed, and supported by the [http://www.slu.se/SHa Forest Sustainability Analysis] program at [https://www.slu.se/ SLU]. Heureka usually gets two new releases per year with new features and bug fixes. Check out the latest releases at [[:Category:Release|Releases]]. We recommend that all users register to receive the newsletter to get important information about the software. [http://www.slu.se/institutioner/skoglig-resurshushallning/programprojekt/sha/heureka/heureka/register/ Register here].

;Get help
: There is no dedicated personal support available. To get help, try the following:
:* '''Help documentation:''' [{{HeurekaHelpLinkEng}} {{HeurekaHelpLinkEng}}]

:* '''Technical support:''' The Heureka system is complex, and we recommend attending one of the annual Heureka courses at SLU. Usage support availability is limited, and we respond to questions when we can find the time.
::Please report bugs and errors to [mailto:{{HeurekaSupportMail}} {{HeurekaSupportMail}}]. [[Bug Tracking|Report a bug]]

:* '''Academic support:''' Academic and related analysis services within research projects can be provided. Consider involving SHa already in the application stage, both for task planning and financing matters (especially when new functionality needs development efforts). Requests and proposals on academic support and collaboration can be directed to [mailto:{{HeurekaSupportMail}} {{HeurekaSupportMail}}].
:: Extensive support matters will be charged or require academic collaboration (including supervising thesis works or co-authorship).

:* '''Commercial support:''' Requests and quotes on commercial support can also be directed to [mailto:{{HeurekaSupportMail}} {{HeurekaSupportMail}}]. Time exceeding one work hour will be charged at a consultancy rate of 1200 SEK per hour, VAT not included.
:: Service Level Agreements ensuring support availability upon request within an agreed time frame can be arranged. Please contact the SHa Program Manager for further details.

System Architecture

2024-11-26T12:31:41Z

Osskyn: /* Reports */

[[Category:System design|Architecture]]
[[Category:Developer's guide]]

== Architectural Goals and Quality ==

For Heureka, the two most important quality goals are modifiability and performance. The system should be flexible enough to allow maintenance and further development in a cost effective manner. At the same time performance should be good enough to allow simulation on large amounts of data. To a certain extent, these goals are contradictable.

In addition to this, testability is an important quality aspect. As many parts as possible should be possible to test automatically, e.g. with unit testing tools such as [http://www.nunit.org/ NUnit]. This sometimes means that sub functions must be made public so that they can be tested from external code. Over time, this goal has been proven more important than originally expected. This means that this goal has not always been met in the existing code, for instance many classes has a lot of dependencies on other classes making them harder to test.*

Other quality goals are less important:

* Security. There are no specific security requirements. The system will use security functions available in the database and operating system.
* Availability. The system is a single user application, so availability is not considered in the architecture.
* Portability. Portability is not required.

== Logical View ==

=== Forest model and Calculations ===
[[file:Forest_and_Calculations.png]]

The key entity in Heureka is the Treatment Unit, that represents a stand, i.e. an area restricted in space, with the same type of forest. A Treatment Unit is the smallest unit treatments are applied for. Each treatment unit contains one or more predictions units. A prediction unit represents a plot or a cell inside the treatment unit. Each prediction unit contains trees. Trees have [[Handling of tree states|different states]], identifying if the tree object represents a sapling, a tree, is dead and so forth. Each of these entities [[handle different time periods]].

Treatments are simulated in Heureka with different type of [[Design of Treatment Models|treatment models]] such as regeneration, fertilization, cleaning, thinning, and final felling.

Growth and yield models calculates tree related values such as volume, basal area growth, height, age, and bark thickness. With help of the growth models, a [[Calculation of growth|treatment unit can grow]], i.e. the state in a future time period can be calculated.

[[Result models]] are used to calculate different types on results. Based on the state of a treatment unit in a given time period, different types of results can be calculated, such as cost and revenue of treatments, amount of biomass in the living forest, or amount of litter added to the ground. A result model may also produce a result based on the results in other result models (e.g. the recreation model uses input from the dead wood model).

Simulation models or frameworks, allows treatment programs to be calculated for a treatment unit. A simulation model utilizes the growth and yield models, the treatment models, and sometimes also result models, to simulate different alternatives for managing a treatment unit. When growth prognosis and treatments has been simulated for a number of periods, the treatment unit (together with its prediction units and their trees and saplings) contains information about the forest state in all periods that were included in the simulation. The results can be saved in a treatment program, which contains results for all periods with the desired result models. Currently, three simulation models are implemented in Heureka: the (strategic) [[Treatment Program Generator Design|Treatment Program Generator]], the [[Tactical Treatment Program Generator Design|Tactical Treatment Program Generator]], and the [[Regional Framework Design|Regional Framework]].

An optimization model is used to create a plan. A plan consists of a selection of treatment programs (one for each treatment unit in the plan), that gives the best result according to the optimization model. An optimization model is defined using the results from the result models. Any variable produced by a result model can be used in an optimization model. Optimization models differs from other models in Heureka, these are the only models that are defined by the user (all other models are programmed into the system).

Treatment units may be classified in forest domains. A user may define a forest domain, based on variables from the result models. The forest domain is then used to configure a simulation model.

=== Data Import ===

[[file:Data_Import.png]]

A <tt>TreatmentUnit</tt> can be created from a NFI plot (Riksskogstaxeringen). In this case, a<tt>TreatmentUnit</tt> and a <tt>PredictionUnit</tt> is created for each NFI plot (if the NFI plot is splitted a <tt>TreatmentUnit</tt> and a <tt>PredictionUnit</tt> is created for each part of the plot).

Similarly FMPP data can be imported into Heureka (not shown in figure).

Another option is to import a stand register. From <tt>StandObject</tt>s in the stand register, <tt>TreatmentUnit</tt>s can be simulated. In this case, trees or saplings are created for the <tt>TreatmentUnit</tt>, based on stand level variables in the <tt>StandObject</tt>. The simulation process is stochastic, meaning that the result will be slightly different each time if repeated several times for the same <tt>StandObject</tt>.

It is also possible to get data to Heureka by making a sample design, choosing <tt>StandObject</tt>s to be inventoried, and then to make a field inventory using [[Ivent]], to get real plot data and inventoried trees and from that data create <tt>TreatmentUnit</tt>s.

The last option to get data into Heureka is to manually enter data using [[StandWise]] (not shown in figure).

All forest data is stored in a relational database.

=== Projects ===

[[file:Projects.png]]

A <tt>Project</tt> contains <tt>ControlCategories</tt> and <tt>ForestDomains</tt>. Each <tt>ForestDomain</tt> refers to a <tt>ControlCategory</tt>, and each <tt>ControlCategory</tt> contains a number of <tt>[[Design of Control Tables|ControlTables]]</tt>, each of which contains user settings for a model or a group of related models in the system.

Also, a <tt>Project</tt> contains the <tt>TreatmentUnits</tt> that the user is working with (the <tt>TreatmentUnits</tt> are actually kept in an <tt>AnalysisArea</tt>, not shown in the figure).

A <tt>Project</tt> may also contain other items, such as optimization models (not shown in the figure).

The project information is saved as files in the file system.

== Design Principles ==

=== Layering ===

[[file:layering.png|600px]]

The system is built with a layered architecture (see for example [[ISBN 0321154959|Bass et al: Software Architecture in Practice]]. The layering is based on the system logic, where each layer adds functionality from a lower layer.

The three layers are:

;Application Layer: Each application is a separate subsystem. An application connects the domain specific subsystems into the functionality provided by the application.
;Domain Layer: A large number of subsystems with different types of domain specific functionality. Each subsystem has its own logic, and in many cases also presentation and persistence services. By having the presentation in the domain layer, UI functionality can be reused between applications.
;Base Layer: General purpose support functions.

The purpose of the layering is to achieve modifiability by isolation of changes. Changes in a higher layer does not affect a lower layer at all.

The layering is not strict, meaning that a higher layer can access any lower layer.

A similar layering is proposed in IBM Rational Unified Process, and in Domain Driven Design. The advantage of layering by generality as opposed to layering by type (as proposed by Microsoft) is lower coupling and higher cohesion.

Inside a subsystem, layering by type, i.e. UI -> Logic -> DB should be done (if a subsystem has a presentation and/or persistence service). A subsystem should be able to use the logic of another subsystem without refering to the presentation or persistence service of that subsystem. The persistence service should be encapsulated inside the subsystem and not be used directly by other subsystems. The presentation service of a subsystem should be available for composition of UI.

''Unfortunately the subsystem layering has not always been used, in many cases several subsystems access the same tables in the database directly. Some subsystems are also poorly layered, e.g. with database code inside the UI, or UI code inside the logic.''

=== MVC ===

Linking between user interface and the domain model is done with the architectural pattern Model-View-Controller (Reenskaug 1979).

The model is a domain entity. When the entity is changed, it signals that with an event so that all views rendering the entity can update themselves. The event <tt>PropertyChanged</tt> is used when a property is changed, the interface <tt>IBindingList</tt> is used when a list or collection is changed. In some cases other events are also used, in <tt>Slu.Heureka.BaseLayer.ComponentModel</tt> there are a few more EventArgs that can be used. That namespace also contains the class <tt>ExtendedBindingList</tt> which is recommended for collections that can be bound.

The view is any kind of graphical control, such as a TextBox, a DataGrid, a TreeView, or a Map. The view can show and change some parts of the entity.

The controller is the object that reacts on user inputs, typically event handlers in a form.

When developing with MVC it is important not to short-circuit the view and the controller when they are implemented in the same class. The event handler should only update the model, and not trigger changes in the view directly.

=== Dependency inversion ===

To reduce dependencies between classes and subsystems, should the subsystems that need a particular service define an interface for that service. For example, the <tt>Forest</tt> subsystem needs biomass to be calculated. To avoid a direct (and circular) dependency from <tt>Forest</tt> to <tt>Biomass</tt>, the <tt>Forest</tt> subsystem declares an interface, <tt>IBiomassService</tt>, and the <tt>Biomass</tt> subsystem implements that interface.

With dependency inversation, a new problem arises, how does an object locate the needed services? There are two common approaches to solving this problem: either Dependency Injection is used, or a Service Locator is used. For Heureka, the latter approach has been used.

The subsystem <tt>Slu.Heureka.BaseLayer.Services</tt> implements a service locator. Key classes in interfaces in that subsystem are:

;IService:Interface that must be implemented by all services
;Service<T>:Generic class for accessing a service
;ServiceAttribute:Attribute that should be set on all services that should be auto loaded
;ServiceBase:Base class for implementing a service
;ServiceManager:The service locator

The <tt>ServiceManager</tt> is a Singleton. It supports auto loading of services (all services marked with the service attribute will be loaded at application startup) as well as explicit loading of services (very useful in unit tests).

The <tt>Services</tt> subsystem was introduced relatively late in the project but has proven to be very flexible and useful. In future development, it is recommended to use it more frequently to reduce dependencies in the system. The recommended approach is that when:

* A class needs to instantiate other classes (except .Net classes), a FactoryService should be implemented
* A class needs to use another subsystem, an interface to that subsystem should be implemented

Static classes and singletons should never be used, with the <tt>ServiceManager</tt> as the single exception to this rule.

=== Persisting Data ===

The system uses both the file system and RDBMS:s (SQL Server) to store data.

* Forest data (stand registers, inventory data, GIS data, treatment units etc) are stored in a RDBMS, the "ForestDb"
* Calculated results and optimization results (plans) are stored in another RDBMS, the "ResultDb"
* Project information and templates are stored in the file system (typically in the user's document folder)
* Application configuration is stored in the file system (typically in the user's application data folder)

Storgate to files are mainly done via serialization. However, a major drawback with serialization is that versioning can be a problem. Also, performance can be an issue. The subsystem <tt>Slu.Heureka.BaseLayer.SerializationManagement</tt> provides helper classes to resolve some of these issues. The classes <tt>SerializationReader</tt> and <tt>SerializationWriter</tt> improves performance drastically. A recommended practice is to always serialize a version number first. By doing this, deserialization of different versions can easily be implemented. A different problem is when a class changes its name or becomes obsolete. A solution for that problem has not been implemented in the Heureka system, but it should be possible to do it using the <tt>[[http://msdn.microsoft.com/en-US/library/system.runtime.serialization.serializationbinder |SerializationBinder]]</tt> class in the .Net framework.

For simple configuration data, the class <tt>ConfigurationStore</tt> should be used.

For control tables, a helper class that serializes control tables has been developed. Thus it is not necessary to implement serialization for control tables.

For interaction with RDBMS the following techniques are used:
;Data readers: For fast loading of objects, mainly used for forest data
;Typed data sets: Used when the user is updating data
;Custom OR-mappning: Used for the result database

Note that for the result database, custom OR-mapping is used. The result database are created automatically based on the [[Result Models]] in the system, and existing result databases will automatically be extended if new result variables and models are introduced in later versions of the system. Queries against the result database are created by SQL queries generated with reflection from the result models.

=== Error Handling ===

When an error is discovered an exception is thrown. Built-in exceptions can be used if appropriate, such as <tt>ArgumentException</tt>, <tt>ArgumentNullException</tt>, and <tt>InvalidOperationException</tt>. In other cases Heureka specific exceptions, inheriting from <tt>ApplicationException</tt>, are used.

Code that depends on exceptions in the normal flow should be avoided. For instance, if a string should be checked for a valid number it is better to use <tt>int.TryParse()</tt> than <tt>int.Parse()</tt> as the latter throws an exception of the string not is numeric. When designing classes, consider implementing similar methods allowing clients to determine beforehand if an operation is valid or not.

Exceptions should only be caught if they are to be handled, and only those exceptions that are relevant should be caught. Do not just catch and re-throw exceptions. This leads to poor performance and also destroys the call stack of the exception.

In the user interface there must be an exception handler for all code that might throw exceptions. That code should show an error message to the user if an exception is caught. Use <tt>Slu.Heureka.BaseLayer.HeurekaForms.ErrorDialog</tt> to show error messages.

The exception message should be brief. If a longer description is needed, set the <tt>HelpLink</tt> for the exception.

=== Commands ===

The Command design pattern is used to encapsulate actions that the user performs into separate objects. There are several benefits with this simple pattern, so it should be used frequently:

* Command makes it possible to implement Undo and Redo
* Command moves logic from forms into separate classes, and thus reduces the complexity of forms
* The logic in a Command can easily be used in separate forms and applications

Technically, commands belongs to the presentation services. Commands are allowed to launch dialogs and message boxes, guiding the user through a flow.

=== Reports ===

Standard reports are developed in Visual Studio as Microsoft Client Report Definitions (rdlc). These are shown in the applications with the <tt>ReportViewer</tt> component.

=== Help ===

The applications should have support for online help.

== Technical Environment ==

System Architecture

2024-11-26T12:31:18Z

Osskyn: /* Kommandon */

[[Category:System design|Architecture]]
[[Category:Developer's guide]]

== Architectural Goals and Quality ==

For Heureka, the two most important quality goals are modifiability and performance. The system should be flexible enough to allow maintenance and further development in a cost effective manner. At the same time performance should be good enough to allow simulation on large amounts of data. To a certain extent, these goals are contradictable.

In addition to this, testability is an important quality aspect. As many parts as possible should be possible to test automatically, e.g. with unit testing tools such as [http://www.nunit.org/ NUnit]. This sometimes means that sub functions must be made public so that they can be tested from external code. Over time, this goal has been proven more important than originally expected. This means that this goal has not always been met in the existing code, for instance many classes has a lot of dependencies on other classes making them harder to test.*

Other quality goals are less important:

* Security. There are no specific security requirements. The system will use security functions available in the database and operating system.
* Availability. The system is a single user application, so availability is not considered in the architecture.
* Portability. Portability is not required.

== Logical View ==

=== Forest model and Calculations ===
[[file:Forest_and_Calculations.png]]

The key entity in Heureka is the Treatment Unit, that represents a stand, i.e. an area restricted in space, with the same type of forest. A Treatment Unit is the smallest unit treatments are applied for. Each treatment unit contains one or more predictions units. A prediction unit represents a plot or a cell inside the treatment unit. Each prediction unit contains trees. Trees have [[Handling of tree states|different states]], identifying if the tree object represents a sapling, a tree, is dead and so forth. Each of these entities [[handle different time periods]].

Treatments are simulated in Heureka with different type of [[Design of Treatment Models|treatment models]] such as regeneration, fertilization, cleaning, thinning, and final felling.

Growth and yield models calculates tree related values such as volume, basal area growth, height, age, and bark thickness. With help of the growth models, a [[Calculation of growth|treatment unit can grow]], i.e. the state in a future time period can be calculated.

[[Result models]] are used to calculate different types on results. Based on the state of a treatment unit in a given time period, different types of results can be calculated, such as cost and revenue of treatments, amount of biomass in the living forest, or amount of litter added to the ground. A result model may also produce a result based on the results in other result models (e.g. the recreation model uses input from the dead wood model).

Simulation models or frameworks, allows treatment programs to be calculated for a treatment unit. A simulation model utilizes the growth and yield models, the treatment models, and sometimes also result models, to simulate different alternatives for managing a treatment unit. When growth prognosis and treatments has been simulated for a number of periods, the treatment unit (together with its prediction units and their trees and saplings) contains information about the forest state in all periods that were included in the simulation. The results can be saved in a treatment program, which contains results for all periods with the desired result models. Currently, three simulation models are implemented in Heureka: the (strategic) [[Treatment Program Generator Design|Treatment Program Generator]], the [[Tactical Treatment Program Generator Design|Tactical Treatment Program Generator]], and the [[Regional Framework Design|Regional Framework]].

An optimization model is used to create a plan. A plan consists of a selection of treatment programs (one for each treatment unit in the plan), that gives the best result according to the optimization model. An optimization model is defined using the results from the result models. Any variable produced by a result model can be used in an optimization model. Optimization models differs from other models in Heureka, these are the only models that are defined by the user (all other models are programmed into the system).

Treatment units may be classified in forest domains. A user may define a forest domain, based on variables from the result models. The forest domain is then used to configure a simulation model.

=== Data Import ===

[[file:Data_Import.png]]

A <tt>TreatmentUnit</tt> can be created from a NFI plot (Riksskogstaxeringen). In this case, a<tt>TreatmentUnit</tt> and a <tt>PredictionUnit</tt> is created for each NFI plot (if the NFI plot is splitted a <tt>TreatmentUnit</tt> and a <tt>PredictionUnit</tt> is created for each part of the plot).

Similarly FMPP data can be imported into Heureka (not shown in figure).

Another option is to import a stand register. From <tt>StandObject</tt>s in the stand register, <tt>TreatmentUnit</tt>s can be simulated. In this case, trees or saplings are created for the <tt>TreatmentUnit</tt>, based on stand level variables in the <tt>StandObject</tt>. The simulation process is stochastic, meaning that the result will be slightly different each time if repeated several times for the same <tt>StandObject</tt>.

It is also possible to get data to Heureka by making a sample design, choosing <tt>StandObject</tt>s to be inventoried, and then to make a field inventory using [[Ivent]], to get real plot data and inventoried trees and from that data create <tt>TreatmentUnit</tt>s.

The last option to get data into Heureka is to manually enter data using [[StandWise]] (not shown in figure).

All forest data is stored in a relational database.

=== Projects ===

[[file:Projects.png]]

A <tt>Project</tt> contains <tt>ControlCategories</tt> and <tt>ForestDomains</tt>. Each <tt>ForestDomain</tt> refers to a <tt>ControlCategory</tt>, and each <tt>ControlCategory</tt> contains a number of <tt>[[Design of Control Tables|ControlTables]]</tt>, each of which contains user settings for a model or a group of related models in the system.

Also, a <tt>Project</tt> contains the <tt>TreatmentUnits</tt> that the user is working with (the <tt>TreatmentUnits</tt> are actually kept in an <tt>AnalysisArea</tt>, not shown in the figure).

A <tt>Project</tt> may also contain other items, such as optimization models (not shown in the figure).

The project information is saved as files in the file system.

== Design Principles ==

=== Layering ===

[[file:layering.png|600px]]

The system is built with a layered architecture (see for example [[ISBN 0321154959|Bass et al: Software Architecture in Practice]]. The layering is based on the system logic, where each layer adds functionality from a lower layer.

The three layers are:

;Application Layer: Each application is a separate subsystem. An application connects the domain specific subsystems into the functionality provided by the application.
;Domain Layer: A large number of subsystems with different types of domain specific functionality. Each subsystem has its own logic, and in many cases also presentation and persistence services. By having the presentation in the domain layer, UI functionality can be reused between applications.
;Base Layer: General purpose support functions.

The purpose of the layering is to achieve modifiability by isolation of changes. Changes in a higher layer does not affect a lower layer at all.

The layering is not strict, meaning that a higher layer can access any lower layer.

A similar layering is proposed in IBM Rational Unified Process, and in Domain Driven Design. The advantage of layering by generality as opposed to layering by type (as proposed by Microsoft) is lower coupling and higher cohesion.

Inside a subsystem, layering by type, i.e. UI -> Logic -> DB should be done (if a subsystem has a presentation and/or persistence service). A subsystem should be able to use the logic of another subsystem without refering to the presentation or persistence service of that subsystem. The persistence service should be encapsulated inside the subsystem and not be used directly by other subsystems. The presentation service of a subsystem should be available for composition of UI.

''Unfortunately the subsystem layering has not always been used, in many cases several subsystems access the same tables in the database directly. Some subsystems are also poorly layered, e.g. with database code inside the UI, or UI code inside the logic.''

=== MVC ===

Linking between user interface and the domain model is done with the architectural pattern Model-View-Controller (Reenskaug 1979).

The model is a domain entity. When the entity is changed, it signals that with an event so that all views rendering the entity can update themselves. The event <tt>PropertyChanged</tt> is used when a property is changed, the interface <tt>IBindingList</tt> is used when a list or collection is changed. In some cases other events are also used, in <tt>Slu.Heureka.BaseLayer.ComponentModel</tt> there are a few more EventArgs that can be used. That namespace also contains the class <tt>ExtendedBindingList</tt> which is recommended for collections that can be bound.

The view is any kind of graphical control, such as a TextBox, a DataGrid, a TreeView, or a Map. The view can show and change some parts of the entity.

The controller is the object that reacts on user inputs, typically event handlers in a form.

When developing with MVC it is important not to short-circuit the view and the controller when they are implemented in the same class. The event handler should only update the model, and not trigger changes in the view directly.

=== Dependency inversion ===

To reduce dependencies between classes and subsystems, should the subsystems that need a particular service define an interface for that service. For example, the <tt>Forest</tt> subsystem needs biomass to be calculated. To avoid a direct (and circular) dependency from <tt>Forest</tt> to <tt>Biomass</tt>, the <tt>Forest</tt> subsystem declares an interface, <tt>IBiomassService</tt>, and the <tt>Biomass</tt> subsystem implements that interface.

With dependency inversation, a new problem arises, how does an object locate the needed services? There are two common approaches to solving this problem: either Dependency Injection is used, or a Service Locator is used. For Heureka, the latter approach has been used.

The subsystem <tt>Slu.Heureka.BaseLayer.Services</tt> implements a service locator. Key classes in interfaces in that subsystem are:

;IService:Interface that must be implemented by all services
;Service<T>:Generic class for accessing a service
;ServiceAttribute:Attribute that should be set on all services that should be auto loaded
;ServiceBase:Base class for implementing a service
;ServiceManager:The service locator

The <tt>ServiceManager</tt> is a Singleton. It supports auto loading of services (all services marked with the service attribute will be loaded at application startup) as well as explicit loading of services (very useful in unit tests).

The <tt>Services</tt> subsystem was introduced relatively late in the project but has proven to be very flexible and useful. In future development, it is recommended to use it more frequently to reduce dependencies in the system. The recommended approach is that when:

* A class needs to instantiate other classes (except .Net classes), a FactoryService should be implemented
* A class needs to use another subsystem, an interface to that subsystem should be implemented

Static classes and singletons should never be used, with the <tt>ServiceManager</tt> as the single exception to this rule.

=== Persisting Data ===

The system uses both the file system and RDBMS:s (SQL Server) to store data.

* Forest data (stand registers, inventory data, GIS data, treatment units etc) are stored in a RDBMS, the "ForestDb"
* Calculated results and optimization results (plans) are stored in another RDBMS, the "ResultDb"
* Project information and templates are stored in the file system (typically in the user's document folder)
* Application configuration is stored in the file system (typically in the user's application data folder)

Storgate to files are mainly done via serialization. However, a major drawback with serialization is that versioning can be a problem. Also, performance can be an issue. The subsystem <tt>Slu.Heureka.BaseLayer.SerializationManagement</tt> provides helper classes to resolve some of these issues. The classes <tt>SerializationReader</tt> and <tt>SerializationWriter</tt> improves performance drastically. A recommended practice is to always serialize a version number first. By doing this, deserialization of different versions can easily be implemented. A different problem is when a class changes its name or becomes obsolete. A solution for that problem has not been implemented in the Heureka system, but it should be possible to do it using the <tt>[[http://msdn.microsoft.com/en-US/library/system.runtime.serialization.serializationbinder |SerializationBinder]]</tt> class in the .Net framework.

For simple configuration data, the class <tt>ConfigurationStore</tt> should be used.

For control tables, a helper class that serializes control tables has been developed. Thus it is not necessary to implement serialization for control tables.

For interaction with RDBMS the following techniques are used:
;Data readers: For fast loading of objects, mainly used for forest data
;Typed data sets: Used when the user is updating data
;Custom OR-mappning: Used for the result database

Note that for the result database, custom OR-mapping is used. The result database are created automatically based on the [[Result Models]] in the system, and existing result databases will automatically be extended if new result variables and models are introduced in later versions of the system. Queries against the result database are created by SQL queries generated with reflection from the result models.

=== Error Handling ===

When an error is discovered an exception is thrown. Built-in exceptions can be used if appropriate, such as <tt>ArgumentException</tt>, <tt>ArgumentNullException</tt>, and <tt>InvalidOperationException</tt>. In other cases Heureka specific exceptions, inheriting from <tt>ApplicationException</tt>, are used.

Code that depends on exceptions in the normal flow should be avoided. For instance, if a string should be checked for a valid number it is better to use <tt>int.TryParse()</tt> than <tt>int.Parse()</tt> as the latter throws an exception of the string not is numeric. When designing classes, consider implementing similar methods allowing clients to determine beforehand if an operation is valid or not.

Exceptions should only be caught if they are to be handled, and only those exceptions that are relevant should be caught. Do not just catch and re-throw exceptions. This leads to poor performance and also destroys the call stack of the exception.

In the user interface there must be an exception handler for all code that might throw exceptions. That code should show an error message to the user if an exception is caught. Use <tt>Slu.Heureka.BaseLayer.HeurekaForms.ErrorDialog</tt> to show error messages.

The exception message should be brief. If a longer description is needed, set the <tt>HelpLink</tt> for the exception.

=== Commands ===

The Command design pattern is used to encapsulate actions that the user performs into separate objects. There are several benefits with this simple pattern, so it should be used frequently:

* Command makes it possible to implement Undo and Redo
* Command moves logic from forms into separate classes, and thus reduces the complexity of forms
* The logic in a Command can easily be used in separate forms and applications

Technically, commands belongs to the presentation services. Commands are allowed to launch dialogs and message boxes, guiding the user through a flow.

=== Reports ===

Standrd reports are developed in Visual Studio as Microsoft Client Report Definitions (rdlc). These are shown in the applications with the <tt>ReportViewer</tt> component.

=== Help ===

The applications should have support for online help.

== Technical Environment ==

Importera beståndsregister

2024-11-26T10:21:17Z

Osskyn:

{{Languages|Import_of_stand_register}}
[[Category:Database]]
[[Category:Reference Manual]]
[[Category:User's Guides]]

===Instruktioner===
Denna sida innehåller kompletterande information till instruktionerna för att importera beståndsregister, som finns här: [{{HeurekaHelpLink}}importera_bestandsregister.htm Importera_bestandsregister]

===Filspecifikation===
Notera:
*Överståndarskikt kan importeras. Detta görs genom att lägga in en extra rad direkt efter det huggningsklassbestämmande skiktet. Överståndarskiktets rad ska då innehålla samma uppgifter som det huggningsklassbestämmande skiktet förutom i de fält som beskriver överståndarskiktet, t.ex. trädslagsfördelning, grundyta, stamantal, medeldiameter och medelhöjd.
*'''Ståndortsindex anges som SIS, inte som SIH''', d.v.s. SI bedöms utifrån ståndortsfaktorer och inte övrehöjdsutveckling.

Resten av detta avsnitt är på engelska:

{{:StandRegisterFileSpecification}}

Import of stand register

2024-11-26T10:21:05Z

Osskyn:

{{Languages|Import_of_stand_register}}
[[Category:Database]]
[[Category:Reference Manual]]
[[Category:User's Guides]]

===Instructions===
See {{HeurekaHelpLinkEng}}importera_bestandsregister.htm.

===File specification===
{{:StandRegisterFileSpecification}}

Import of stand register

2024-11-26T10:19:53Z

Osskyn:

Bug Tracking

2024-11-26T10:12:21Z

Osskyn:

==Report a bug==
If you've encountered a bug or issue while using our application, we encourage you to report it so we can work on resolving it. Your feedback helps us improve the application for everyone. For most users: Send an [mailto:support.heureka@slu.se e-mail] to the support.

For internal users (members of the Heureka team): Use [http://www.heurekaslu.org/bugtrack our bugtracking system]. Request an account by sending us an [mailto:support.heureka@slu.se e-mail] with subject = "Request BugTrack account".

Before reporting, consider gathering information about the bug that will assist us in resolving the issue. Include the following details in your email if possible/relevant:

*Descriptive title: A brief description of the issue
*Application Version: The version of the application you are using (e.g., 2.23.0).
*Steps to Reproduce: A description of what you were doing when the issue occurred.
*Expected Behavior: What you expected to happen.
*Actual Behavior: What actually happened.
*Screenshots or Logs: Attach any relevant screenshots, error messages, or logs that can help us understand the issue.

Heureka Wiki:About

2024-11-26T09:48:48Z

Osskyn:

<noinclude>
{{Languages|Heureka Wiki:About}}
</noinclude>
==About this Wiki==
This Wiki contains complementary information to the [{{HeurekaHelpLinkEng}} Heureka Online Help]. Here are download links to Heureka's applications, information about each new release of Heureka, as well as technical specifications of variables, result variables, control tables. Furthermore, a lot of the models used in Heureka have a summary description.

Optimization

2024-11-26T09:29:09Z

Osskyn:

[[Category:User's Guides]]
[[Category:Optimization]]

==New help documentation==
See also {{HeurekaHelpLinkEng}}optimering.htm , under construction.

==About the optimization tool==
====Assignment problem====
The optimization problem solved in Heureka can be categorized as an '''assignment problem''': Each treatment unit should be assigned a treatment schedule. The problem types handled are linear programming (LP) and 0/1 mixed-integer linear programming (MIP or MILP). The difference between the two is how treatment schedules are assigned. If a treatment unit can be assigned one and only one alternative, then the associated decision variables are set to binary (by the user). If the management of a treatment unit can be "split" and spatial integrity is not an issue, then these variables can be treated as continuous variables (default). In this case the value of the decision variables refers to the proportion of treatment unit area that should be managed with a certain schedule. More information on decision variables is given below.

====ZIMPL====
For PlanWise a very flexible optimization tool is built-in for formulating and solving LP and MIP problems. The optimization tool is basically a graphical user interface to the [http://zimpl.zib.de/ ZIMPL optimization modelling language]. For solving a problem, external third-party solvers are used and directly linked to the optimization tool. Currently, the solvers available are listed below:

====Solvers====
For solving a problem, external third-party solvers are used and directly linked to the optimization tool. Currently, the solvers available are

*[https://www.coin-or.org/ CoinOR CLP/CBC], which is freely available under the Eclipse public license v 2.0 and included in the Heureka installation.
*[https://soplex.zib.de SoPlex], which is freely available for academic use. You will need the SCIP Windows binary (exe) file ("SCIP version 3.0 (Windows/PC 64 bit)" has been tested with Heureka), and specify the path under Settings.
*[https://www.gurobi.com Gurobi<sup>®</sup>], versions 9.0 - 11.0
*[https://www.ibm.com/support/pages/how-do-i-download-cplex-optimization-studio?mhsrc=ibmsearch_a&mhq=cplex IBM CPLEX<sup>®</sup>], version 22.1.0
*[https://www.mosek.com MOSEK<sup>®</sup>], version 7-8.1
*[https://www.fico.com/en/products/fico-xpress-solver FICO Xpress<sup>®</sup>], version 7.9

CPLEX, Gurobi, Xpress and MOSEK are very efficient, state-of-the-art solvers. They require a license, which can be obtained for free for academic use. These solvers must be obtained and installed by the user, they are not distributed with the Heureka install package.

CoinOR CLP/CBC is an efficient free alternative and performs well in benchmarks.

LpSolve is no longer supported (from version 2.20).

====Integration with prognosis data====
The optimization model is linked to a Heureka-formatted SQL Server database used for storing input data, simulation data, and result data. This enables a seamless integration with the input data required by the optimization model, as well as direct presentation of optimization results in the form of tables, graphs, and maps. This simplifies the analysis and visualization of scenarios or plans of forest development and outputs.

==Settings==
{{:Optimization_Settings}}

==Managing models==
A standard optimization model is distributed with the program. There is also the opportunity to create a new model from scratch, or to use a wizard guide to taylor an optimization model with some of the most common objective functions and restrictions. All these models can then be further modified and saved by the user.

To create and save models, used the buttons at the top of Optimization Model window, or the Model Wizard button in the Models section further down in the same window.

For more info on the Model Wizard, please confer [https://www.heurekaslu.se/help/en/index.htm?model_wizard.htm the Heureka Help]

==Editing an optimization model==
====Sets====
When you create a new model, the following set are added automatically:
* treatmentUnits: Set of all treatment units. Index = i.
* alternatives: Set of all management schedule numbers. Index = j. Note: Alternative j for one treatment unit has nothing to with alternative j for another unit. The number of available j:s varies between treatment units.
* periods: Time periods. Index = p. The length of a period is five years in strategic planning, and one year in tactical planning.
* rowNo: Index for the treatment number in a time period that a treatment unit alternative refers to.

When adding opening size constraints (from the menu Optimization > Add Opening Size Constraint), additional sets are added.

You can also add arbitrary sets manually, for e.g. organizational units, road ID columns, and so on.

====Decision variables====
When you create a new model, some basic problem elements are added automatically (the sets and some constraints), including the most important decision variables. The decision variable <code>x[i,j] </code> is always added:

x[i,j] = proportion of the area of treatment unit ''i'' that is managed with management schedule ''j''.

By default, the x[i,j] variables are continuous (non-integer) and bounded between 0 and 1. You can change the variable to binary (0/1-integer) by changing its RangeType to Binary, thus changing the problem type from LP to MIP.

A constraint called <code>maxArea </code> is also added automatically. It ensures that the area managed for each treatment unit is correct, so that the whole area (no more and no less) is assigned a schedule. Each treatment unit must be fully assigned a management. "No management" may be counted as an alternative, depending on what control categories are used when generating the alternative with the Treatment Program Generator.

====Adding an accounting variable====
Accounting variables are preferrably added to the optimization model to improve readability and simplify the writing of constraints. An accounting variable is ''defined'' - it is a function of other decision variables in the model. The definition is actually an equality constraint in the the optimization model.

One example of a useful accounting variable is total harvested volume in a period. This variable can then be used in other constraints.

To add an accounting variable:
# In the Optimization Model window, right-click in the "Variables" section and Select "Add new variable"
# Right-click on the variable and change its name from <code>"DefaultName..."</code> to something more proper, in the example below <code>volTot</code>.
# To define an indexed variable, for example to have one variable for each time period, click on Data binding > Sets, and add the index set, for example "periods". After that the variable name should have a suffix (<code>[p]</code>).
# In the syntax window, type the definition with the the expression on the left side and the name of the variable on the right-hand side of an equality-symbol marked as <code>"=="</code>. Example: An ccounting variable for total stand volume is defined, with an index p for time period. Note that before adding the variable, the parameter <code>volume[i,j,p]</code> (which is linked to the Heureka result variable Forest Data.Volume Before) must have been added. Syntax:
#:<code><nowiki>FORALL <p> IN periods DO </nowiki></code>
#:<code><nowiki> SUM <i,j> IN treatmentunits * alternatives WITH altIncluded[i,j] == 1:</nowiki></code>
#:<code><nowiki> volume[i,j,p] * area[i] * x[i,j] == volTot[p]; </nowiki></code>
'''Important!''' By default, a variable (decision or accounting) has the property RangeType set to non-negative. This means that negative values are considered infeasible. For example, a volume cannot be negative. However, some accounting variables should be allowed to take negative values, for example the net revenue in a period can be negative if costs are larger than revenues. In this case you must change its RangeType to "All".

====Adding a parameter which is linked to a prognosis variable ====
The coefficients in the LP-models (the coefficient matrix is usually denoted as '''A''') are constant values in the optimization model. In Heureka, these coefficients are generated by the Treatment Program Generator and referred to as Heureka result variables. A coefficient may represent for example stand volume for a given treatment unit, management schedule alternative, and time period.
Hence, stand volume is a variable in a prognosis, but a constant/parameter in the optimization model.

# In the Optimization Model window, right-click in the "Parameters"-section and Select "Add new parameter"
# Type a name, for example "pulpWood" (without apostrophes)
# Let "Heureka result variable" be selected
# Click Next
# Select Financial Value > PulpWood Volume Total (if this is the variable you are interested in)
# Click Finish

To check what Heureka variable a certain parameter is linked to:
# Select the parameter
# In the Properties window for the parameter (under the syntax window), under Databinding > ResultProperty, you can see what Heureka variable the parameter is bounded to. If you click on it you can change the binding.

====Adding a parameter that has a definition====
# In the Optimization Model window, right-click in "Parameters" section and Select "Add new parameter"
# Type a name, for example "totalArea" (without apostrophes)
# Select "Formula" as parameter type
# Click Next
# In the syntax window, type the defiintion, for example
#:<code><nowiki>sum <i> in treatmentunits: area[i];</nowiki></code>
#:(This can be edited later)
# Click Finish

;Note 1: When defining an accounting variable (see above), you would also add a definition to the variable itself, such as <code>== VariableName</code>. For a defined parameter, you only type the expression.
;Note 2: A shortcoming of a parameter with a formula is that you cannot preview its value.

====Adding a constraint====
# In the Optimization Model window, right-click in "Constraints" and select "Add new constraint"
# Type a name, for example "MinOldForestArea" (without apostrophes)
# Click OK
# Select the constraint in the model tree and type the definition in the syntax window. For example, to add a constraint to ensure a non-declining harvest over time, you would type:
#:<code><nowiki>forall <p> in periods with p >= 1 : TotalHarvestVolume[p] >= TotalHarvestVolume*[p-1];</nowiki></code>
#:(If you have defined an accounting variable for total harvest volume)
# Click Finish

;Note: For constraints, you do not add indices explicitly as you do with variables. In the example, we do not add "p" for periods, but the "forall"-statement will take care of generating one constraint for each time period.

;Tip: Use accounting variables in constraints to simplify reading and formulating the model, as well as to minimize problem size (considerably fewer coefficients and only a few additional variables).

====Adding opening size constraints====
The generation of an EARM-model (see Goycoolea et al 2005) <ref name="Goycoolea"> Goycoolea, M., Murray, A. T., Barahona, F., Epstein, R., Weintraub, A. 2005. Harvest scheduling subject to maximum area restrictions: Exploring exact approaches. Operations Research, 2005. Volume 53. Number 3.[http://mgoycool.uai.cl/papers/mgw04.pdf]</ref>
is automated. The original model have been adapted to suit the way management alternatives are handled in Heureka (decision variables are defined for complete treatment schedules instead of single treatment activities). To formulate and EARM-model, select Add Opening Size Constraints from menu Optimization.

To use this functionality, you must have provided a [[Import_of_forest_map_and_background_image | forest map]].
There is a built-in function to compute adjacency pairs, and enumeration of harvest blocks (combinations of polygons) that meet a given maximum opening size tolerance. (The computed adjacency pairs and their common border lengths can also be used in user-defined spatial constraints such as a URM (Unit Restriction Model)). The program can then calculate all feasible combinations of treatment units (that form harvest clusters), compute all so called cliques, and all constraints necessary. For more info, see <ref name="Goycoolea" />.

A very fast algorithm has been developed in Heureka to compute what Goycoolea et al (2005) refer to as cliques and clusters.

====Linking management in partial set-asides to parent stands====
*Partial set-asides (hänsynsytor) within stands can be handled as separate treatment units, in which no harvest activities are carried out. The development in such set-asides is in reality affected by the surroundings in the way that the risk of mortality increases in the set-aside after clear-cutting the main stand. In PlanWise, you can let the program generate alternatives for the set-aside area for each management program generated for the main stand, let the mortality be affected by when and if clear-cutting takes place in the main stand, and also choose to link nature conservation management activities to coincide with management activities in the parent stand. This is non-default, by default only one alternative is generated for the set-aside. If choosing the non-default optiona link between the set-aside and the main stand is added automatically to the optimization model. Read more here: http://heurekaslu.se/help/index.html?naturvardsatgarder.htm, section "Lämnande av hänsynsytor" (only in Swedish).

====Using neighborhood relations for habitat analyses====
Neighborhood areas can be calculated for each stand. This means that for a user-specified radius originating from the centroid of each stand, the area for every other stand that is overlapped by the circle is computed. This information can then be used in optimization models that take habitat area requirements into account (see [http://www.nrcresearchpress.com/doi/abs/10.1139/x10-232#.Uz5hhfmSx8E Öhman et. al 2011]). The necessary variables can be added to any optimization model, for modification of the habitat conditions to reflect the species of interest.

The needed model parameters, variables, and constraints for including a habitat demands are pre-formulated in Heureka and can automatically be included in the model formulation of an optimization problem. This is done by adding neighbourhood constraints available in the optimization tab (Optimization / Add Neighborhood Constraints). After this is done the user must specify three parameters in the optimization model:
*the stand specific conditions that should be fulfilled before a stand qualifies as a habitat (the habitat condition parameter, habitatCondition[i,j,p),
*the amount of suitable habitat required within a stand's neighbourhood for the stand to be qualified as habitat (minHabitatAreaInNeighbourhood)
*the minimum proportion of the entire forest that should meet the habitat conditions in each period (minTotalHabitatAreaProportion)
Before solving the optimization problem, the user must also run the tool ”compute stand neighbourhood” to calculate the area of each other stand that is within the neighboring area of a stand. When this tool is executed the parameter standNeighbourhood is filled out.

==Solving problems and saving optimization results==
When a problem has been formulated and is ready to be solved, and you have run the Treatment Program Generator (TPG), the problem is ready to be solved:
#Right-click in the optimization model tree view, and select "Compile and Solve"
#Select the TPG result that the optimization model will be solved for and click OK
#Wait until the solver has finished

After solving, you will see the problem status in the output window (at the bottom). If you have obtained a feasible solution the solution status will be reported as "Optimal". To be able to view the optimization results in [[User'27s_guide_to_PlanWise#Analyzing_Results | reports]], you must first '''save the optimization result'''. You do this by clicking on the button "Save Optimization Result", at the top of the Optimization Model window.

====Infeasible solution?====
If the problem status is Infeasible, no solution has been found. There are two main reason why this may occur:
*There is some error in the optimization model.
*No solution exists. The constraints are too severe.

To identify the cause of the problem, include constraints, one by one, in a systematic order. Try to solve the problem after including each constraint.
;Note: Do not exclude the constraint "maxArea".

==Importing optimization solutions from external sources==
You can use an external analytics software to solve your optimization problem outside the interface of PlanWise, for example AIMMS, AMPL, Python or R. It is then possible to import that solution to PlanWise, for example to use the report tool to build charts. See the Help for further instructions.

== References ==
<references />

Optimization

2024-11-26T09:28:32Z

Osskyn:

[[Category:User's Guides]]
[[Category:Optimization]]

==New help documentation==
See also {{HeurekaHelpLinkEng}}optimering.htm , under construction.

==About the optimization tool==
====Assignment problem====
The optimization problem solved in Heureka can be categorized as an '''assignment problem''': Each treatment unit should be assigned a treatment schedule. The problem types handled are linear programming (LP) and 0/1 mixed-integer linear programming (MIP or MILP). The difference between the two is how treatment schedules are assigned. If a treatment unit can be assigned one and only one alternative, then the associated decision variables are set to binary (by the user). If the management of a treatment unit can be "split" and spatial integrity is not an issue, then these variables can be treated as continuous variables (default). In this case the value of the decision variables refers to the proportion of treatment unit area that should be managed with a certain schedule. More information on decision variables is given below.

====ZIMPL====
For PlanWise a very flexible optimization tool is built-in for formulating and solving LP and MIP problems. The optimization tool is basically a graphical user interface to the [http://zimpl.zib.de/ ZIMPL optimization modelling language]. For solving a problem, external third-party solvers are used and directly linked to the optimization tool. Currently, the solvers available are listed below:

====Solvers====
For solving a problem, external third-party solvers are used and directly linked to the optimization tool. Currently, the solvers available are

*[https://www.coin-or.org/ CoinOR CLP/CBC], which is freely available under the Eclipse public license v 2.0 and included in the Heureka installation.
*[https://soplex.zib.de SoPlex], which is freely available for academic use. You will need the SCIP Windows binary (exe) file ("SCIP version 3.0 (Windows/PC 64 bit)" has been tested with Heureka), and specify the path under Settings.
*[https://www.gurobi.com Gurobi<sup>®</sup>], versions 9.0 - 12.0
*[https://www.ibm.com/support/pages/how-do-i-download-cplex-optimization-studio?mhsrc=ibmsearch_a&mhq=cplex IBM CPLEX<sup>®</sup>], version 22.1.0
*[https://www.mosek.com MOSEK<sup>®</sup>], version 7-8.1
*[https://www.fico.com/en/products/fico-xpress-solver FICO Xpress<sup>®</sup>], version 7.9

CPLEX, Gurobi, Xpress and MOSEK are very efficient, state-of-the-art solvers. They require a license, which can be obtained for free for academic use. These solvers must be obtained and installed by the user, they are not distributed with the Heureka install package.

CoinOR CLP/CBC is an efficient free alternative and performs well in benchmarks.

LpSolve is no longer supported (from version 2.20).

====Integration with prognosis data====
The optimization model is linked to a Heureka-formatted SQL Server database used for storing input data, simulation data, and result data. This enables a seamless integration with the input data required by the optimization model, as well as direct presentation of optimization results in the form of tables, graphs, and maps. This simplifies the analysis and visualization of scenarios or plans of forest development and outputs.

==Settings==
{{:Optimization_Settings}}

==Managing models==
A standard optimization model is distributed with the program. There is also the opportunity to create a new model from scratch, or to use a wizard guide to taylor an optimization model with some of the most common objective functions and restrictions. All these models can then be further modified and saved by the user.

To create and save models, used the buttons at the top of Optimization Model window, or the Model Wizard button in the Models section further down in the same window.

For more info on the Model Wizard, please confer [https://www.heurekaslu.se/help/en/index.htm?model_wizard.htm the Heureka Help]

==Editing an optimization model==
====Sets====
When you create a new model, the following set are added automatically:
* treatmentUnits: Set of all treatment units. Index = i.
* alternatives: Set of all management schedule numbers. Index = j. Note: Alternative j for one treatment unit has nothing to with alternative j for another unit. The number of available j:s varies between treatment units.
* periods: Time periods. Index = p. The length of a period is five years in strategic planning, and one year in tactical planning.
* rowNo: Index for the treatment number in a time period that a treatment unit alternative refers to.

When adding opening size constraints (from the menu Optimization > Add Opening Size Constraint), additional sets are added.

You can also add arbitrary sets manually, for e.g. organizational units, road ID columns, and so on.

====Decision variables====
When you create a new model, some basic problem elements are added automatically (the sets and some constraints), including the most important decision variables. The decision variable <code>x[i,j] </code> is always added:

x[i,j] = proportion of the area of treatment unit ''i'' that is managed with management schedule ''j''.

By default, the x[i,j] variables are continuous (non-integer) and bounded between 0 and 1. You can change the variable to binary (0/1-integer) by changing its RangeType to Binary, thus changing the problem type from LP to MIP.

A constraint called <code>maxArea </code> is also added automatically. It ensures that the area managed for each treatment unit is correct, so that the whole area (no more and no less) is assigned a schedule. Each treatment unit must be fully assigned a management. "No management" may be counted as an alternative, depending on what control categories are used when generating the alternative with the Treatment Program Generator.

====Adding an accounting variable====
Accounting variables are preferrably added to the optimization model to improve readability and simplify the writing of constraints. An accounting variable is ''defined'' - it is a function of other decision variables in the model. The definition is actually an equality constraint in the the optimization model.

One example of a useful accounting variable is total harvested volume in a period. This variable can then be used in other constraints.

To add an accounting variable:
# In the Optimization Model window, right-click in the "Variables" section and Select "Add new variable"
# Right-click on the variable and change its name from <code>"DefaultName..."</code> to something more proper, in the example below <code>volTot</code>.
# To define an indexed variable, for example to have one variable for each time period, click on Data binding > Sets, and add the index set, for example "periods". After that the variable name should have a suffix (<code>[p]</code>).
# In the syntax window, type the definition with the the expression on the left side and the name of the variable on the right-hand side of an equality-symbol marked as <code>"=="</code>. Example: An ccounting variable for total stand volume is defined, with an index p for time period. Note that before adding the variable, the parameter <code>volume[i,j,p]</code> (which is linked to the Heureka result variable Forest Data.Volume Before) must have been added. Syntax:
#:<code><nowiki>FORALL <p> IN periods DO </nowiki></code>
#:<code><nowiki> SUM <i,j> IN treatmentunits * alternatives WITH altIncluded[i,j] == 1:</nowiki></code>
#:<code><nowiki> volume[i,j,p] * area[i] * x[i,j] == volTot[p]; </nowiki></code>
'''Important!''' By default, a variable (decision or accounting) has the property RangeType set to non-negative. This means that negative values are considered infeasible. For example, a volume cannot be negative. However, some accounting variables should be allowed to take negative values, for example the net revenue in a period can be negative if costs are larger than revenues. In this case you must change its RangeType to "All".

====Adding a parameter which is linked to a prognosis variable ====
The coefficients in the LP-models (the coefficient matrix is usually denoted as '''A''') are constant values in the optimization model. In Heureka, these coefficients are generated by the Treatment Program Generator and referred to as Heureka result variables. A coefficient may represent for example stand volume for a given treatment unit, management schedule alternative, and time period.
Hence, stand volume is a variable in a prognosis, but a constant/parameter in the optimization model.

# In the Optimization Model window, right-click in the "Parameters"-section and Select "Add new parameter"
# Type a name, for example "pulpWood" (without apostrophes)
# Let "Heureka result variable" be selected
# Click Next
# Select Financial Value > PulpWood Volume Total (if this is the variable you are interested in)
# Click Finish

To check what Heureka variable a certain parameter is linked to:
# Select the parameter
# In the Properties window for the parameter (under the syntax window), under Databinding > ResultProperty, you can see what Heureka variable the parameter is bounded to. If you click on it you can change the binding.

====Adding a parameter that has a definition====
# In the Optimization Model window, right-click in "Parameters" section and Select "Add new parameter"
# Type a name, for example "totalArea" (without apostrophes)
# Select "Formula" as parameter type
# Click Next
# In the syntax window, type the defiintion, for example
#:<code><nowiki>sum <i> in treatmentunits: area[i];</nowiki></code>
#:(This can be edited later)
# Click Finish

;Note 1: When defining an accounting variable (see above), you would also add a definition to the variable itself, such as <code>== VariableName</code>. For a defined parameter, you only type the expression.
;Note 2: A shortcoming of a parameter with a formula is that you cannot preview its value.

====Adding a constraint====
# In the Optimization Model window, right-click in "Constraints" and select "Add new constraint"
# Type a name, for example "MinOldForestArea" (without apostrophes)
# Click OK
# Select the constraint in the model tree and type the definition in the syntax window. For example, to add a constraint to ensure a non-declining harvest over time, you would type:
#:<code><nowiki>forall <p> in periods with p >= 1 : TotalHarvestVolume[p] >= TotalHarvestVolume*[p-1];</nowiki></code>
#:(If you have defined an accounting variable for total harvest volume)
# Click Finish

;Note: For constraints, you do not add indices explicitly as you do with variables. In the example, we do not add "p" for periods, but the "forall"-statement will take care of generating one constraint for each time period.

;Tip: Use accounting variables in constraints to simplify reading and formulating the model, as well as to minimize problem size (considerably fewer coefficients and only a few additional variables).

====Adding opening size constraints====
The generation of an EARM-model (see Goycoolea et al 2005) <ref name="Goycoolea"> Goycoolea, M., Murray, A. T., Barahona, F., Epstein, R., Weintraub, A. 2005. Harvest scheduling subject to maximum area restrictions: Exploring exact approaches. Operations Research, 2005. Volume 53. Number 3.[http://mgoycool.uai.cl/papers/mgw04.pdf]</ref>
is automated. The original model have been adapted to suit the way management alternatives are handled in Heureka (decision variables are defined for complete treatment schedules instead of single treatment activities). To formulate and EARM-model, select Add Opening Size Constraints from menu Optimization.

To use this functionality, you must have provided a [[Import_of_forest_map_and_background_image | forest map]].
There is a built-in function to compute adjacency pairs, and enumeration of harvest blocks (combinations of polygons) that meet a given maximum opening size tolerance. (The computed adjacency pairs and their common border lengths can also be used in user-defined spatial constraints such as a URM (Unit Restriction Model)). The program can then calculate all feasible combinations of treatment units (that form harvest clusters), compute all so called cliques, and all constraints necessary. For more info, see <ref name="Goycoolea" />.

A very fast algorithm has been developed in Heureka to compute what Goycoolea et al (2005) refer to as cliques and clusters.

====Linking management in partial set-asides to parent stands====
*Partial set-asides (hänsynsytor) within stands can be handled as separate treatment units, in which no harvest activities are carried out. The development in such set-asides is in reality affected by the surroundings in the way that the risk of mortality increases in the set-aside after clear-cutting the main stand. In PlanWise, you can let the program generate alternatives for the set-aside area for each management program generated for the main stand, let the mortality be affected by when and if clear-cutting takes place in the main stand, and also choose to link nature conservation management activities to coincide with management activities in the parent stand. This is non-default, by default only one alternative is generated for the set-aside. If choosing the non-default optiona link between the set-aside and the main stand is added automatically to the optimization model. Read more here: http://heurekaslu.se/help/index.html?naturvardsatgarder.htm, section "Lämnande av hänsynsytor" (only in Swedish).

====Using neighborhood relations for habitat analyses====
Neighborhood areas can be calculated for each stand. This means that for a user-specified radius originating from the centroid of each stand, the area for every other stand that is overlapped by the circle is computed. This information can then be used in optimization models that take habitat area requirements into account (see [http://www.nrcresearchpress.com/doi/abs/10.1139/x10-232#.Uz5hhfmSx8E Öhman et. al 2011]). The necessary variables can be added to any optimization model, for modification of the habitat conditions to reflect the species of interest.

The needed model parameters, variables, and constraints for including a habitat demands are pre-formulated in Heureka and can automatically be included in the model formulation of an optimization problem. This is done by adding neighbourhood constraints available in the optimization tab (Optimization / Add Neighborhood Constraints). After this is done the user must specify three parameters in the optimization model:
*the stand specific conditions that should be fulfilled before a stand qualifies as a habitat (the habitat condition parameter, habitatCondition[i,j,p),
*the amount of suitable habitat required within a stand's neighbourhood for the stand to be qualified as habitat (minHabitatAreaInNeighbourhood)
*the minimum proportion of the entire forest that should meet the habitat conditions in each period (minTotalHabitatAreaProportion)
Before solving the optimization problem, the user must also run the tool ”compute stand neighbourhood” to calculate the area of each other stand that is within the neighboring area of a stand. When this tool is executed the parameter standNeighbourhood is filled out.

==Solving problems and saving optimization results==
When a problem has been formulated and is ready to be solved, and you have run the Treatment Program Generator (TPG), the problem is ready to be solved:
#Right-click in the optimization model tree view, and select "Compile and Solve"
#Select the TPG result that the optimization model will be solved for and click OK
#Wait until the solver has finished

After solving, you will see the problem status in the output window (at the bottom). If you have obtained a feasible solution the solution status will be reported as "Optimal". To be able to view the optimization results in [[User'27s_guide_to_PlanWise#Analyzing_Results | reports]], you must first '''save the optimization result'''. You do this by clicking on the button "Save Optimization Result", at the top of the Optimization Model window.

====Infeasible solution?====
If the problem status is Infeasible, no solution has been found. There are two main reason why this may occur:
*There is some error in the optimization model.
*No solution exists. The constraints are too severe.

To identify the cause of the problem, include constraints, one by one, in a systematic order. Try to solve the problem after including each constraint.
;Note: Do not exclude the constraint "maxArea".

==Importing optimization solutions from external sources==
You can use an external analytics software to solve your optimization problem outside the interface of PlanWise, for example AIMMS, AMPL, Python or R. It is then possible to import that solution to PlanWise, for example to use the report tool to build charts. See the Help for further instructions.

== References ==
<references />

Install database

2024-11-26T09:19:19Z

Osskyn:

{{Languages|Install_database}}

See http://heurekaslu.org/help/en/index.html?skapa_databas.htm

Version 2.0.0

2024-11-26T08:16:10Z

Osskyn:

Version 2.0.0.0
{{Languages|Version 2.0.0}}
[[Category:Release]]
[[Newsdate::2014-04-04]] [[language::en| ]]

<startFeed />
==Summary==
<feedDate>2014-04-04</feedDate>
<endFeed />
*Version 2 represents a more well-tried program.
*Several efforts have been made to improve and simplify the user interface.
*Some changes of the growth and yield functions have been implemented, and you should expect slight changes of results, even if you run an identical analysis and on the same data.
*There is now a possibility to take into account price- and cost changes over time.

<startFeed />
====Important note!====
For already imported stand registers that have been used as input data (and not only to link with existing data), it is recommended that you '''re-simulate the forest data via menu Data Management > Stand Register > Simulate Treelist (Datahantering > Beståndsregister > Simulera träddata).''' As a result, the tree ages and heights for young stands will be more consistent with the input data.
<feedDate>2014-04-04</feedDate>
<endFeed />

(see [[#Improved handling of mean age in young stands|section below]])
[[image:SimulateTreeList.png|400px|none]]

<startFeed />
==Changes in the user interface ==
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />

====First steps to simplified use: Hiding seldom used parameters ====
There is indeed an overwhelming number of parameters that confront the user of a Heureka application. Therefore, a simplified view of the so called control tables is now available. By choosing this, you will only see a subset of parameters, those we consider the most important for normal users to have access to. You can also customize what parameters to display in the simplifed view. You can change freely between Advanced and Simplified View, it is only how and what parameters are displayed that is affected. You can access the simplifed view via menu Settings > Advanced/Simplified View. When using Simplified View, only one table is displayed for each control category, instead of one table for each control table in the control category. A table will show all parameters with non-default values, and all parameters that have been added to the simplified view.
<feedDate>2014-04-04</feedDate>
<endFeed />
see [http://heurekaslu.org/help/index.html?detaljerad_eller_foerenklad_vy.htm help documentation]

<startFeed />
====Modified start page ====
The start page has been redesigned and displays news from SHa and release notes.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
====Project page removed ====
The project page contained information on the name of the project and the database connections. This information has been moved to the start page and the project page has been removed.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
====Modified page for Initial State Overview====
In PlanWise and RegWise, the Intial State Overview page has been redesigned and shows more diagrams than before. You can also copy data from the page to Excel.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
====Improved display of forest domain contents====
In PlanWise and RegWise, the visual structure of the contents of a forest domain has been improved, so that is easier to distinguish between conditions and control category connections.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />

====Possibility to add comment to forest domain====
In PlanWise and RegWise, you can add comments to a forest domain. Just right-click on a forest domain and select Edit/Show comment.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />

====More symbols and line colors====
In StandWise, PlanWise and RegWise, graph symbols and lines have more variation.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />

==== Settings dialog collects application settings in one place ====
From menu Tools, you can open the Settings-dialog (meny Vertyg > Inställningar). It contains performance settings, log file settings, settings for what control tables should be added to new control categories by default, user interface settings (language, simplified view), and optimization settings (default solver and solver settings).
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==Growth-and yield model changes==
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
====Changed default choice for growth model====
The default choice of using a whole stand growth model for calibrating the single-tree calculations is inactivated when creating a new project. This parameter is found in control table Production Model as "Growth Model Whole-Stand", and has been changed to "None", meaning that Björn Elfving's single-tree functions are used alone, without calibrating them with the stand-level growth model. The reason is not more accurate growth predictions per se, the differences between the models are rather small, but the single-tree growth functions used alone gives a smoother transition from the young stand phase to the established phase, at least in numerous cases tried.

The default function choice for calculating tree diameters for sapling trees (parameter "Sapling Diameter Model" in control table Production Model) has also been changed, from "NystromSoderberg" to "Elfving", for the same reason.

For existing projects, it is not critical to change these parameters, but if you do detailed stand-level analysis for example and find it annoying that the annual increment marks a drop or sudden increase when a stand leaves the young stand phase and enters the established phase, consider testing the new default settings.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== New mortality model ====
A new mortality model is available and used as default model in new project. For existing projects (created in previous program version), we recommend that you select this model instead. The model is called "Elfving" and is selected in control table Production Model. With the old model, mortality in non-dense stands have been calculated with a somewhat "primitive" model (Göte Bengtsson 1978), with a fixed mortality precentage for each species. The new model is a single-tree model based on a large set of NFI-data (Rikskogstaxeringens data). The new model also replaces the single-tree mortality model by Fridman & Ståhl which has been used until now to distribute mortality to trees. The latter is in it basic form a stochastic model, while the new one is determinstic, and therefore better suited for Heureka. <feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Improved handling of mean age in young stands ====
For already imported stand registers that have been used as input data (and not only to link with existing data), it is recommended that you '''re-simulate the forest data via menu Data Management > Stand Register > Simulate Treelist (Datahantering > Beståndsregister > Simulera träddata).''' As a result, the tree ages and heights for young stands will be more consistent with the input data.

For an established stand, Heureka calculates the mean age (variable "ForestData.MeanAge excl overstorey") as the basal area weighted mean age of the trees. For a young stand, the variable is calculated as a weighted arithmetic mean age, where the calculated probabilities for crop trees (beräknade huvudstamssannolkheter) are used as weights. In established stands (mean height ≥ 7 m), tree ages are by default calibrated so that the calculated mean age and the mean age imported (for example from the stand register) are the same. This calibration has not been applied for young stands. The reason for this is that the imported mean age for young stands has not been used if a mean height has been available. In that case, the mean age has been based on the calculated sapling ages, which in turn depend on tree heights and site index. This have resulted in a more model-driven than data-driven approach, which is probably good since data for young stands are often reported as very uncertain. If relying too much on the age/height relation in young stands, there is a risk that the calculated growth for young stands with a large height/age ratio is overestimated. In stands where there have been a few years of large height growth, these few years constitute a large part of the total age of the stand and will affect growth much more in relative terms than is the case for an older stand. As a drawback, the ages for young stands calculated in Heureka have often differed from the mean ages in the stand register. Several measures has been taken to handle this, and some more will be available later this year in version 2.1.
*One change is that by default, mean heights for young stands are ignored when simulating tree list. When simulating tree lists from stand register data, you will find a new check box "Let system automatically calculate tree heights for young stands". The corresponding function is available when entering data manually, in the sapling simulator dialog you can choose "Calculate from age" (see Figure 2a and 2b). Using this option (which is default) will result in more robust height/age-relations in young stands, and smaller differences between stand register age and age calculated by Heureka.
*Sapling ages can now be calibrated so that the mean arithmetic age of main saplings should be close to the entered mean age of the stand. The use of this calibration is activated in control table ProductionModel, parameter Calibrate Age Young Stand, which is set to True in new projects. You should change this parameter when you open old projects. Before this calibration, the program projects the growth for the number of years that differs between the mean age calculated by the model (as a function of tree heights), and the entered mean age.
*Another improvement is that the start up of a young stand has been refined to better match the usage of five-year period lengths. When not using this function (by unchecking the check box), tree heights will be calibrated so that the mean height for each species is as close as possible to the entered mean height.

The variable "ForestData.Stand Age" (see above) could also be useful when the mean ages calculated in Heureka are not consistent with those in the register data. Heureka creates a tree list not until the mean height is 2 m. For smaller stands, a "waiting" period is used, and once the period is reached when the stand is at least 2 m, the stand is "activated".
<feedDate>2014-04-04</feedDate>
<endFeed />

[[Image:PlantSimulatorDialog_CalculateFromAge.png|400px|thumb|none|Figure 2a. You can select whether the mean height of a young should be calculated by the program based on the entered stand age, or retrieved from the entered value. ]]
[[Image:SimulateTreeDataFromStandRegister.png|600px|thumb|none|Figure 2b. You can select whether the mean height of a young should be calculated by the program based on the entered stand age, or retrieved from the entered value. ]]

<startFeed />
==== Sapling type ====
When entering data manually for a young stand, the sapling type origin and age when planted can be entered for each species. Using this feature does not currently affect results much, but is more a preparation for future refinements for the modelling of young stands and regeneration.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Modified implementation of fertilization effect ====
Growth response after fertilization is calculated with a model that predicts volume growth increase on a per ha basis on each sample plot. The way this growth increment is distributed to the trees has been modified to a more exact but also a simpler and faster solution. The growth response will be marginally different than in previous versions.
<feedDate>2014-04-04</feedDate>
<endFeed />

==Price and costs changes==
<startFeed />
==== Price and cost trends ====
You can evaluate your own assumptions on future changes in real costs and prices. You can do this by setting a time point and a cost or price adjustment factor that will apply from that time and onwards. You can define different price factors for timber, pulpwood and bio fuel, and different cost factors for different treatment activites. For price lists, an additional bucking (aptering) is applied, to get the correct output for the adjusted prices. Interpolation is applied to time periods between the start period and the time point you enter.
<feedDate>2014-04-04</feedDate>
<endFeed />

See [http://heurekaslu.org/help/index.html?kontrolltabell_cost.htm Help documentation, chapter Kontrolltabell Cost, heading "Pris- och kostnadstrender"], and
[http://heurekaslu.org/help/index.html?prislistor.htm, Helpdocumentation, chapter Prislistor, heading "Pristrender"]

<startFeed />
==== Price list length corrections as percentage or absolute values ====
Until now, price list length corrections have been defined as absolute price corrections (in SEK/m3fub). Now you can choose between absolute corrections or relative prices. The pricelist included for Mellanskog has been faulty, absolute corrections were assumed but relative prices had been entered in the table.
<feedDate>2014-04-04</feedDate>
<endFeed />
Read more here: [http://heurekaslu.org/help/index.html?prislistor.htm Helpdocumentation, chapter Prislistor, heading "Timmerprislistor och kvalitetsutfall", figure 1]

==Other changes==
<startFeed />
====TreatmentUnit.MinFinalFellingAge replaced with ForestData.Initial Min Final Felling Age====
Minimum final felling (LÅF) is calculated in each time period and management alternative and depends on regeneration species. The minimum final felling at the initial state has been available as result variable TreatmentUnit.MinFinalFellingAge. This has been moved to ForestData.MinFinalFellingAge. The result database is automatically updated, but if you use the old variable in report templates or optimization problem you must change the column mapping to the new variable.

<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== High stump retention ====
You can now take into account the retention of high stumps. Leaving high stumps will affect both harvest yields (decreased) and occurrence of dead wood (increased). You can set the height of high stumps in the price list. This will keep track of the timber value for a tree if it is left as a high stump. You must also activate the retention of high stumps via control table Nature Conservation.
<feedDate>2014-04-04</feedDate>
<endFeed />
Read more here:
[http://heurekaslu.org/help/index.html?naturvardsatgarder.htm, Helpdocumentation chapter Naturvårdsåtgärder, heading "Lämnande av högstubbar"]

<startFeed />
==== Amount of dead wood affected by final felling ====
When doing final felling, the harvesting and forwarding operations destroys a considerable part of the existing dead wood. In control table Dead Wood, the advanced user can modify how much of the existing dead wood (percentage) that is removed to the last decay class (4). It is also possible to define assumptions on to what extent dead wood in set-asides within a stand (hänsynsytor) is affected.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== New result variable "Stand Age" ====
Heureka calculates mean age (variable "ForestData.MeanAge excl overstorey") as the basal area weighted mean age of trees in established stands. For a young stand, it is calculated as a weighted arithmetic mean age, where the calculated probabilities for crop trees (beräknade huvudstamssannolkheter) are used as weights. Typically, the calculated mean age does not increase by exactly the same value as the period length, since it is weighted. Also, the initial age may deviate from the input mean age, especially in young stands. Variable StandAge has been added to result category ForestData to represent age since regeneration (plus sapling age when planted which is currently hard-coded to 2 years). In period 0, it is the same as the input data, and then increases by five years per five-year period until final felling.

The variable "ForestData.Stand Age" can be used in reports and in optimization problems. For example, you could replace ForestData.MeanAge with ForestData.Stand Age to keep track of the area of bare land or young forest allowed (in the optimization model).
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Column names in tree list template used for variable mapping ====
The import routine for tree list data has been sensitive to the ordering of columns, but is now using the column names (in the same way as the import routine for a stand register). This makes the import less error-prone, but you must assure that the column names are correct.
<feedDate>2014-04-04</feedDate>
<endFeed />
(see http://heurekaslu.org/help/index.html?importera_bestand_med_provytor.htm)

==Help and support==
<startFeed />

==== New help section - overview of user interface (Swedish only) ====
A new help section gives an overview of the user interface, with sub chapters for each application.
<feedDate>2014-04-04</feedDate>
<endFeed />
see http://heurekaslu.org/help/test/index.html?oversikt_anvandargranssnitt.htm (only in Swedish)

<startFeed />
==== New user forum ====
A new user forum is available at
<feedDate>2014-04-04</feedDate>
<endFeed />
http://heurekaslu.org/forum

==Bug fixes ==
<startFeed />
==== Bugfix: Report variable net annual growth after regeneration now consistent with forest-level reports====
After regeneration, result variable GrowthData.CAI net has been calculated as annual growth since since plantation, instead of change in standing stock between periods + harvested volume in previous period divided by number of years since last period. This is not a true error, but it has given missleading results when generating forest-level reports on mean annual increment. This has been fixed.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />

==== Bugfix: Contorta volume ====
When importing contorta sample trees from FMPP data (Indelningspaketet), the tree height calibration factors were faulty, because of a mix up in the translation of species codes. This affects calculations of contorta, oak and beech volumes and heights. Contorta tree heights have been calibrated with those for beech, and vice versa. If an area has contained contorta but not beech, the tree heights for contorta has not been calibrated, and vice versa.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Bugfix: Web links in the help menu ====
Links to web page were faulty both in the help documentation and the in the programs.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Bugfix: No additional thinnings were simulated when applying user-defined thinning proposal ====
When applying imported thinning proposals, no more thinnings were simulated until final felling. This has been fixed.
<feedDate>2014-04-04</feedDate>
<endFeed />

<startFeed />
==== Bugfix: Wrong treatment proposal code given in help documentation for final felling with seed trees ====
This is not really a program bug, but a documentation error. The code for final felling with seed trees was defined as 16383 instead of 16384 on both the wiki and in the help documentation. This has been corrected. But the program has also been modified so that it recodes an imported treatment proposal code 16383 to 16384.
<feedDate>2014-04-04</feedDate>
<endFeed />

Get Started

2024-11-25T15:53:25Z

Osskyn:

{{Languages|Get Started}}

[[Category:User's Guides]]
To get started quickly, you can follow the steps below.

==Heureka Helpdoc==
You can find instructions on how to install SQL Server and Heureka here: {{HeurekaHelpLink}}

==Run StandWise==
# Start StandWise (from Start > Program > SLU).
# Run the [[StandWise_Tutorial | StandWise tutorial]].
# For more information, see [[User's guide to StandWise]].


==Run PlanWise==
# Start PlanWise (from Start > Program > SLU).
# Run the [[PlanWise_Tutorial | PlanWise tutorial]].
# For more information see [[User's guide to PlanWise]].

== Availability and Support ==
{{:Availability_and_Support}}

Dialogue Simulate / Generate Treatment Programs

2024-11-25T15:32:54Z

Osskyn:

[[Category:Control Tables|Dialogue Simulate / Generate Treatment Programs]]
[[Category:Control Tables]]

In this dialogue, you can adjust simulation or treatment program generation settings prior to starting the process. For further usage tips and instructions, please see the Heureka Help. [[https://www.heurekaslu.se/help/en/index.html?skapa_skotselprog_planvis.htm]]

== RegWise ==

The following options and settings are available in the dialogue window Simulation:

:'''Select Result Variables:''' Allows selection of which result variables to store in the result database.
:'''Start year simulation: (to be added)'''
:'''Reference year:''' Adjusts the year to which the underlying indata is projected.
:'''Simulation name (optional):''' Allows naming the simulation.
:'''Max periods:''' Sets the number of periods for which the simulation results will be stored.
:'''Random seed:'''
::The random seed is used in stochastic models if any stochastic models are enabled in the control tables. The random seed sets the order in which random numbers are drawn from random number generators. Thus, different seeds will generate different results from stochastic models. If the random seed is set to zero the seed itself will be randomly generated.
::The random seed will not affect the outcome of deterministic models.

:'''Random seed Control Categories:''' Random seed for stochastically assigning treatment units within a forest domain to control categories.
:''' Discount rate (%):''' Real discount rate used for calculating net present values.
:''' Additional periods:''' (to be added)
:'''Log trees to file:''' Allows storing tree results to files for detailed analyses and scrutinizing.

==PlanWise==
To be added.

<!--
====Dead Wood Classes====
:'''None:''' Upper volume limit (m<sup>3</sup>/ha) to be classified as "no occurence" of downed dead wood.
:'''Low:''' Upper limit (m<sup>3</sup>/ha) to be classified as "low occurence" of downed dead wood.
:'''High:''' Upper limit (m<sup>3</sup>/ha) to be classified as having "high occurence" of downed dead wood.
:If the volume is larger than the limit for High, the class is set to "Very High".

== Soil damage ==
Settings for whether any soil damages should be regarded in the simulations, with respect to recreation.

====Avoid Soil Damage====
:'''True''' means that harvesting should be donw with more carefulness to minimize soil damages. This will induce a cost. '''False''' if not.

====Soil DamageCost====
:(only if Avoid Soil Damage = '''True''' is selected above)
:Cost, in SEK per m<sup>3</sup>sk, of more careful harvests to avoid soil damages.>

ControlTable Treatment Model

2024-11-25T15:27:30Z

Osskyn:

[[Category:Control Tables|Treatment Model]]
[[Category:Reference Manual]]
Overview of TreatmentModel control table parameters.
<br>For a more detailed description of the usage, see the [http://heurekaslu.org/help/en/index.html?simulering_av_atgarder.htm help documention] chapters on simulation of treatments, for example:
*Regeneration: [http://heurekaslu.org/help/en/index.html?foryngring.htm Regeneration help documention]
*Cleaning: [http://heurekaslu.org/help/en/index.html?rojning.htm Cleaning (precommercial thinning) help documention]
*Thinning: [http://heurekaslu.org/help/en/index.html?gallring.htm#Utforande Thinning help documention]
*Final felling: [http://heurekaslu.org/help/en/index.html?slutavverkning.htm#Utforande Final Felling help documention]

In the treatment model control table you can configure how individual forest management activities are simulated.

== Regeneration - model ==
Allows you to control how forest regenerations are simulated, regarding planting, natural regeneration using seed trees, and sowing.

====Regeneration Model Type====
*Simulation: simulate regeneration from a Weibull distribution.
*Database: simulate regeneration by imputation of plot data from a database (supplied).

== Regeneration - settings ==

====Deterministic Application====
:(only if '''Simulation''' is selected) '''True''' applies deterministic regeneration model components, '''False''' do not (then stochastic).

====Mean Sapling Height When Activated====
(only if '''Simulation''' is selected)
:Defines the arithmetic mean height in meters at stand-level[plot-level?] when trees are initiated, for '''Natural regeneration''', '''Sowing''', '''Spruce plantation''', '''Pine plantation''', and '''Contorta plantation''', respectively. Development before this height is obtained by linear interpolation.

====Regeneration Year====
:Defines the number of years from time of final felling to time of regeneration, applied in simulations of '''Plantation''' and '''Sowing'''.

====Regeneration Settings====
:Defines the number of seedlings per hectare applied in '''Plantation''' (or in '''Sowing''', or in '''Natural regeneration using seed trees''', respectively) following '''Soil scarification''' (or '''Controlled burning''', or '''None''', respectively), regarding the tree species and site index. This seedling consumption table will, obviously, lead to certain regeneration costs.

====Soil Preparation Year====
:Defines the number of years from time of final felling to time of soil preparation, applied in simulations of '''Soil scarification''' and '''Controlled burning'''. Obviously, this number can not exceed settings in '''Regeneration Year'''.

== Cleaning ==
Allows you to control how cleanings, a.k.a. pre-commercial thinnings, are simulated.

====Cleaning Model====
:'''Heureka cleaning''' defines one model of tree removal, actually cutting of saplings, in the cleaning simulations.
:'''Hugin cleaning''' defines another model of tree removal, currently corresponding to the above, in the cleaning simulations.

====Deterministic Application====
:'''True''' applies deterministic cleaning model components, '''False''' do not (then stochastic).

====Mean Height Cleaning====
:'''Min''' defines the minimum arithmetic mean height in meters at stand-level when cleaning is simulated.
:'''Max''' defines the maximum arithmetic mean height in meters at stand-level when cleaning is simulated.

====Min Stems Cleaned====
:Defines the minimum number of stems per hectare to be cut in cleanings. No cleaning will be simulated if stem density is so low that less stems are able to cut, regarding all current tree species.

====Settings for Deciduous Trees====
:'''Alfa''' and '''Beta''' are coefficients in a function calculating the priority factor of deciduous tree species. Deciduous trees, i.e. all broadleaves, will then be retained in cleanings prior to coniferuous trees.

====Settings for Pine====
:'''Alfa''' and '''Beta''' are coefficients in function calculating the priority factor of pine trees. Pines, i.e. ''Pinus ssp.'', will then be retained in cleanings prior to deciduous and other coniferuous trees.

====Settings for Spruce====
:'''Alfa''' and '''Beta''' are coefficients in function calculating the priority factor of spruce trees. Spruces, i.e. ''Picea ssp.'' and ''Abies ssp.'', will then be retained in cleanings prior to deciduous and other coniferuous trees.

== Thinning or Selection Felling ==
Settings in common for thinning and selection felling

====Thinning Configuration====
Opens a dialog where you can select Thinning Algoritm and how different species should be prioritized. See [{{HeurekaHelpLinkEng}}gallring.htm Help doc on thinning settings].

The thinning algorithm that can be selected are:
:'''HuginOld''' Algorithm developed for the Hugin system. It uses three species groups, and groups trees into four diameter classes for each group. See [[Thinning]]
:'''Hugin''' Derived from HuginOld but allows you to specify more species groups, and explicit species distribution targets. The algorithm operates on a species group level in the same way as HuginOld. See [[Thinning]]
:'''LOEriksson''' defines another model of tree selection in the thinning simulations. You enter species groups in the same ways as with Hugin, but the thinning form (above/below) is entered using a relative diameter target value.

The dialog contains parameters for how thinning should be distributed over trees and species, depending on the thinning algorithm chosen.
====Relative Diameter====
(only if '''LOEriksson''' is selected)
:'''First''' defines the relationship between the mean diameters of trees cut and trees retained in first thinning of a stand, expressed in percentage.
:'''Second''' defines the relationship between the mean diameters of trees cut and trees retained in second and following thinnings of a stand, expressed in percentage.

====Thinning Algorithm Parameters====
See [[Thinning Algorithm Parameters]]

====Vary Thinning Grade====
:'''True''': thinning intensity is distributed over PredictionUnits (plots) proportionally to basal area. '''False''': Same thinning intensity on all plots in the treatment unit.

====Min Diameter Cut====
:Defines the minimum diameter, in centimeters, of trees to be cut when thinning or selection felling.

====Min Prop. Thinnable Plots====
:Min proportion of plots (impediment plots ignored) that should be thinned according to thinning guide in order for thinning to be applied. '''''Currently only available when Thinning Guide = StemDensity.'''''

====Min Thinning Grade====
:Defines the minimum thinning grade required in order to apply a thinning, in percentage of basal area, stem density or volume (depending on thinning guide), including any cutting of strip roads. Is thinning grade accoring to guide is lesser, thinning is cancelled.

====Max Thinning Grade====
:Defines the maximum thinning grade, in percentage of basal area, stem density or volume (depending on thinning guide), including any cutting of strip roads. If thinning guide suggest a larger thinning grade, it is set to Max Thinning Grade.

====Thinning System====
:'''These parameters are only used in cost functions and should not be confused with settings for how a thinning should be simulated.'''
:*NotSpecified: defines that non specified thinning types should be simulated.
:*StripRoad: defines that thinnings with strip roads should be simulated.
:*StripRoadMidFieldMachine: defines that thinnings with harvester should be simulated.
:*StripRoadMidFieldChainsaw: defines that thinnings with harvester and manual labour (with chainsaw) should be simulated.

====Harvest Striproads====
:'''True''' simulates the cutting of strip roads if a stand is thinned for the first time, '''False''' do not.

====Effective Striproad Width====
:Defines the effective width of strip roads in meters. Effective means that the harvesting machines can thread (slingra sig fram). A "threading factor" (slingerfaktor) of 75 % gives an effective strip road width of 3 m with an actual strip road width of 4 m.

====Distance Between Striproads====
:Defines the distance in meters between the centre of adjacent stip roads, used in simulation of the first thinning in a stand.

== Thinning ==
Allows you to control how thinnings are simulated.
See [[Thinning]] for a complete description.

====UMin====
(only if '''LOEriksson''' is selected as thinning algorithm in Thinning Configuration Dialog)
:Defines the minimum proportion, regarding basal area, of a single tree of all trees cut at the plot-level, expressed in percentage and value range (0, 20).

====UMax====
(only if '''LOEriksson''' is selected as thinning algorithm in Thinning Configuration Dialog)
:Defines the maximum proportion, regarding basal area, of a single tree of all trees cut at the plot-level, expressed in percentage and value range (80, 100).

====Thinning Guide====
:A thinning guide is used to determine whether thinning should or could be done, and the thinning intensity.
:'''Hugin''', '''Skogsstyrelsen''', '''Ingvar''', '''Logarithmic''' and '''Polynomial''' are defined for basal area.
:'''StemDensity''' is defined for number of trees. 

<div id="Thinning Guide Hugin Settings"></div>
<div id="Thinning Guide SKS Settings"></div>
<div id="Thinning Guide Polynomial Settings"></div>
<div id="Thinning Guide Logarithmic Settings"></div>
<div id="Thinning Guide Ingvar Settings"></div>
====Thinning Guide Settings====
:;All guides but StemDensity and Ingvar:Opens dialog with coefficients for thinning guide (such as site index and dominant height, respectively) used in calculations of the tree species' basal area, before and after thinning.

:'''Thinning Guide Stem Dens. Beta:''' Setting for thinning guide "StemDensity", parameter β = Domainant height at which first thinning should be done.

<div id="Thinning Guide Stem Dens. Delta"></div>
:'''Thinning Guide Stem Dens. Delta''':Setting for thinning guide "StemDensity". This parameter controls slope of function.

<div id="Ingvar Version for Pine, Larch and Contorta"></div>
<div id="Ingvar Version for Spruce"></div>
:'''Ingvar version''': Ingvar thinning guide (by Skogforsk) has different levels.

====Max Relative Age====
:Time for last thinning in terms of maximum relative age. If relative age is larger, then no more thinning will be simulated. Relative age is an approximation for how close a stand is to culmination of mean annual growth (MAI). It is computed as mean age divided by 1.1*LSÅ, where LSÅ = minimum eligible age for final felling according to Swedish Forestry Act.

====Min Height Thinning====
:Min dominant height required for thinning.

====Max Height Any Thinning====
:Max dominant height (m) when last thinning can be applied. '''''Currently only available when Thinning Guide = StemDensity.'''''

====Max Height First Thinning====
:Max dominant height (m) when first thinning can be applied. If dominannt height is larger and stand has never been thinned, then it is considered too late to do first thinning, due to risk of felling damages on remaining trees.

====Thinning Guide Reduction Factors====
:Thinning guide reduction factors for upper and lower curve. Applies to basal area thinning guides. Example: 0.95 for upper curve means that upper curve is lowered by 5 percent.

====Previously Thinned Threshold====
:Threshold for when stands of a given SIS is considered previously thinned if thinning history is not available. If stems/ha is lower than given value, stand is assumed to have been thinned.

=====Pine Threshold=====
:Maximum stem density (stems/ha) in pine stands to consider them as previously thinned if thinning history is missing.

=====Spruce Threshold=====
:Maximum stem density (stems/ha) in spruce stands to consider them as previously thinned if thinning history is missing.

=====Other Threshold=====
:Maximum stem density (stems/ha) in deciduous stands to consider them as previously thinned if thinning history is missing.


====Understorey Max Diameter====
:Upper diameter limit for understorey trees in thinnings (cm). Trees with dbh lesser than this value will be considered understorey trees (in mature stands, not in plantations). Note: Setting this to 0 means that no trees will be considered understorey trees.
:Default: 8 cm

====Understorey Cleaning Stems Threshold====
:Minimum understorey stem density required for understory cleaning to be performed (stems/ha). If the number of understorey stems is less than this parameter, no understorey cleaning will be performed, but the harvester cost may increase due to the hindrance of understorey. For example, with 4000 undestorey trees, the harvester productivity will decrease with 3 percent.
:Default: 800 st/ha

====Min Understorey Stems Retained====
:Minimum number of understorey trees left when understorey cleaning is done.
:Default: 200 st/ha

====Understorey Proportion Removal====
:Proportion of understorey stems to remove when and if understorey cleaning is performed (%). The program may adjust so that parameter 'Min Understorey Stems Retained' is not violated.
:Default: 90%

== Selection felling ==
(only if '''Hugin''' is selected as thinning model)
Allows you to control how selection fellings (usually applied in "continuous forestry") are simulated.

====SelectionControlParameter====
Equivalent to [[#Thinning Algorithm Parameters | Thinning Algorithm Parameters]] but other settings for selection fellings.

==Young Stand Thinning==
Criteria to determine whether a stand should be considered a young stand. Biofuel thinning is only allowed in stands classified as young. Also, to determine whether a stand is a young stand thinned for the first time (swe: förstagallring), this information is used.

====Max Relative Age====
Max relative age for a stand to be considered young. Relative age is a ratio of stand age and "mature" age, see [{{HeurekaHelpLinkEng}}relativ_alder.htm]].

====Max Age ====
Max age for a stand to be considered a young stand

====Min Height====
Minimum height for a stand to be considered young, but old enough for thinning

====Max Height====
Maximum height for a stand to be considered young

====Thinning Type====
:;Ordinary:
:;Biofuel:

====Understorey Density Trigger Biofuel Thinning====
(From version 2.11) Understorey stem density when thinning is automatically switched to biofuel thinning (stems/ha). In this case no understorey cleaning will be done. Leave blank or set to a negative number to inactivate.

== Final Felling ==
Allows you to control how final fellings (sometimes referred to as "clear cuttings") are simulated.
<br>'''See also''': [http://heurekaslu.org/help/en/index.html?slutavverkning.htm#Utforande Help chapter on final felling ]

====Min Diameter in Final Felling====
:Defines the minimum diameter, in centimeters, to be cut in the simulations.

====Seed Tree Retention====
(only if '''SeedTree''' or '''Shelterwood''' is selected)
Same as [[#ThinningControlParameter | ThinningControlParameter]]

====Shelterwood Retention====
(only if '''Seed Tree''' or '''Shelterwood''' is selected)
Note: Do not confuse with Tree Retention in control table [[ControlTable_NatureConservation | Nature Conservation]]
*RetainedBasalAreaLowSI: The basal area, in m<sup>2</sup>/ha, of seed trees and shelterwood to be retained in stands with site index less than 20 m. *RetainedBasalAreaHighSI: The basal area, in m<sup>2</sup>/ha, of seed trees and shelterwood to be retained in stands with site index greater than 20 m.
*RemovalTime: The number of years from final felling to when retained trees are cut.
*RetainDominantSpecies: If '''True''', retain trees of the dominant tree species, '''False''' do not.
*MinimumRetainedBasalArea: The minimum basal area, in m<sup>2</sup>/ha at the stand-level, of seed trees and shelterwood to be retained.
*RetainedSpecies: (only if '''RetainDominantSpecies''' is '''False''') The tree species to be retained as seed trees and shelterwood.



====Remove Existing Overstorey====
Regulates how shelterwood, seed trees or retention trees (trees left for the next rotation) will be handled. With the latest template for stand register, you will also be able to specify suggestions for treatments and control how they are used in each stand. Existing trees retained for nature conservation can also be treated separately in the new version.

====Use SI Management====
Set '''Use SI Management''' to True if you have typed values in the Site Index Management column in the stand register (version 3), and you want to use them to govern the minimum age of final felling. If you use the Forest Management Planning Package (FMPP) and have a stand register linked to it with values for the Site Index Management column, the latter will be given precedence. If SI Management is set to False, or SI Management is missing, SIS is used (Site quality index according to site factors).

== Fertilization ==
Allows you to control how fertilizations are simulated.

====FertilizerAmount====
:Defines the amount of fertilizer in kilogram per hectare used in the simulations.

====FertilizerSubstance====
:'''AN''' defines that ammonium nitrate is the active substance in fertilizations.
:'''UREA''' defines that urea, i.e. ammoniac[?], is the active substance in fertilizations.

====MaxAnnualGrowth====
:Defines the maximum annual growth, in m<sup>3</sup>sk/ha, if fertilization of the stand is to be simulated.

====MeanHeightLimitFertilization====
:Defines the minimum average height (basal area weighted) in meters if fertilization of the stand is to be simulated.

====MinConiferProportion====
:Defines the minimum proportion of conifers, in percentage of basal area, if fertilization of the stand is to be simulated.

====SiteIndex====
:'''Min''' defines the minimum site index value in meters if fertilization of the stand is to be simulated.
:'''Max''' defines the maximum site index value in meters if fertilization of the stand is to be simulated.

== Intensive Fertilization ==
Allows you to control how intensive fertilization is simulated.

''Note that intensive fertilization can only be simulated if the soil moisture is mesic or mesic-moist, in the southern part (latitude <58° N) and the central part (58-61° N) of Sweden also moist soils are possible to intensively fertilize. Moreover, the site index (H100, m) must in the northern part of Sweden (>61° N) be below G26, in the central part below G30, and in the southern part below G34, to allow for intensive fertilization.''

====HeightIntensiveFertilization====
:'''Min''' defines the minimum average height in meters if fertilization is to be initiated in the young stand.
:'''Max''' defines the maximum average height in meters if fertilization is to be initiated in the young stand.

====MinSpruceProportionIntensiveFertilization====
:Defines the minimum proportion of spruce, in percentage of basal area (or of stems per hectare), if fertilization is to be initiated in the young stand.

====MinStemsIntensiveFertilization====
:Defines the minimum number of stems per hectare if fertilization is to be initiated in the young stand.

== Biofuel ==
Allows you to control how forest fuel extractions are simulated.

====Restrictions====
:*MinSpruce: defines the minimum proportion of spruce, in percentage of basal area, if extraction is to be simulated.
:*MaxDiamStump: defines the maximum diameter, in centimeters, of the stump if extraction is to be simulated.
:*MinDiamStump: defines the minimum diameter, in centimeters, of the stump if extraction is to be simulated.

====Stump Extraction====
:Selection of species for which stumps and roots can be extracted. For each species to extract, set value to True.

====Utilization====
:*Top: defines the proportion, in percentage, of the top (incl. stem, branches, and needles) that is utilized in extraction.
:*BranchesNotTop: defines the proportion, in percentage, of the branches below the top that is utilized in extraction.
:*BranchesTop: defines the proportion, in percentage, of the branches of the top that is utilized in extraction.
:*DeadBranchesNotTop: defines the proportion, in percentage, of the dead branches below the top that is utilized in extraction.
:*DeadBranchesTop: defines the proportion, in percentage, of the dead branches of the top that is utilized in extraction.
:*NeedlesTop: defines the proportion, in percentage, of the needles of the top that is utilized in extraction.
:*NeedlesNotTop: defines the proportion, in percentage, of the needles below the top that is utilized in extraction.
:*Stump: defines the proportion, in percentage, of the stump that is utilized in extraction.

== <div id="TreeRetention"></div>Nature Conservation Activities (Tree Retention) ==
(moved here from Nature Conservation control table in version 2.9)
<br>Allows you to control if trees should be retained, as a part of the simulation of the biological considerations to be taken.

=== Tree Retention Settings ===
(only if [[#Retain Trees|Retain Trees]] = '''True''')
Allows you to control how trees are to be retained.

<div id = "Retain Trees"></div>
====Retain Trees?====
:'''True:''' Selected trees (according to settings below) should be left after final felling or after selecion felling, and left until the next final felling or selection felling at which a new decision taken what trees to retain.
:'''False:''' No nature conservation trees should be retained.

====Retained Trees/ha====
:Mumber of trees to retain (per hectare).

====Retention Priority====
:Priority settings for which trees to retain as nature conservation trees, regarding species, age and size.

====Retention Time====
:Defines for how long trees are retained (in years). After this time the retained trees will be transferred to downed, coarse woody debris (the "dead wood").

<div id = "High Stump Settings"></div>
===Retention of High Stumps===
<div id = "Leave High Stumps"></div>
====Leave High Stumps?====
:If set to True, high stumps will be "created" at final felling. Unlike retention trees, high stumps immediately become part of the dead wood pool of standing dead trees, with a volume reductions for the part of the tree that was harvested.

<div id = "High Stumpsha"></div>
====High Stumps/ha====
:Mumber of high stumps to create (per hectare).

<div id = "Height Of High Stumps"></div>

====Height of High Stumps====
:This is set in the Pricelist Manager (which control the bucking of trees when harvesting).

====High Stump Priority====
:Priority settings for which trees to leave high stumps for, regarding species, age and size.

=== Leave stems in forest after treatment ===
Allows you to control the proportion of stems to be left in the forest as deadwood, after a thinning or selection felling.

Download and install/sv

2024-11-25T15:01:06Z

Osskyn:

{{Languages|Download_and_install}}
{{DISPLAYTITLE:Nedladdning och installation}}

==Registrering==
Heurekas programvaror är gratis att används men vi vill att du registrerar dig: [{{HeurekaRegisterUrlSv}} Registreringssida]

== Licens ==
För Heurekas programvaror gäller följande licensvillkor: [[Heureka_EULA | End-User License Agreement (EULA)]].

==Systemkrav==
Windows 7, 8, 10 eller 11, 64-bit.

.NET Framework 4.8

== Instruktioner ==
Se [{{HeurekaHelpLink}}installera_heureka.htm Heurekas hjäldokumentation]

==Hämta programvaror==

====MSI (rekommenderat)====
MSI ([http://en.wikipedia.org/wiki/Windows_Installer Windows Installer]) innebär att programmet installeras som ett "vanligt" program under t ex C:\Program Files.

{{#clear_external_data:}}
{{#get_web_data:url={{HeurekaPublishUrl}}MSIversions.xml
|format=XML
|data=x86version=x86,x64version=x64,HabitatPrognosis=HabitatPrognosis,StandWise=x32Subset}}
{| cellpadding="5"
| align="left" width="200" style="background:#f0f0f0;"|'''Application'''
| align="left" width="100" style="background:#f0f0f0;"|'''Platform'''
| align="left" width="100" style="background:#f0f0f0;"|'''Version'''
| align="left" width="100" style="background:#f0f0f0;"|'''Note'''
|-
| StandWise, PlanWise, PlanEval, RegWise ||x64 (64-bit)|| [{{HeurekaPublishUrl}}MSI/Slu.Heureka.Setup_x64.msi {{#external_value:x64version}}] ||

|-
|}

====Clickonce====
"ClickOnce" innebär att programmet installeras under användares egen profil, och administratör-rättigheter behövs inte (vilket dock behövs för att installera SQL Server). Nackdelen med ClickOnce är att de olika applikationerna installerar varsin Heureka-kärna, vilket gör att programmen tar något mer plats på din hårddisk (ca 50 MB per applikation).

{{#get_web_data:url={{HeurekaPublishUrl}}ClickOnceVersions.xml
|format=XML
|data=StandWise=StandWise,PlanWise=PlanWise,PlanStart=PlanStart,RegWise=RegWise,PlanEval=PlanEval,HabitatPrognosis=HabitatPrognosis}}
{| cellpadding="5"
| align="left" width="200" style="background:#f0f0f0;"|'''Applikation'''
| align="left" width="100" style="background:#f0f0f0;"|'''Version'''
|-
| BeståndsVis (StandWise)||[{{HeurekaPublishUrl}}ClickOnce/StandWise/setup.exe {{#external_value:StandWise}}]
|-
| PlanVis||[{{HeurekaPublishUrl}}ClickOnce/PlanWise/setup.exe {{#external_value:PlanWise}}]
|-
| RegVis||[{{HeurekaPublishUrl}}ClickOnce/RegWise/setup.exe {{#external_value:RegWise}}]
|-
| PlanEval||[{{HeurekaPublishUrl}}ClickOnce/PlanEval/setup.exe {{#external_value:PlanEval}}]
|-
|}
{{#clear_external_data:}}

====Tidigare versioner====
Tidigare versioner kan hämtas här (endast som MSI):
[{{HeurekaPublishUrl}}MSI/Archive/ Arkiv]

==Hämta ytterligare Heureka-programvaror==

====PlanEvalWeb====
Se [[PlanEvalWeb]]

Download and install/sv

2024-11-25T15:00:35Z

Osskyn:

{{Languages|Download_and_install}}
{{DISPLAYTITLE:Nedladdning och installation}}

==Registrering==
Heurekas programvaror är gratis att används men vi vill att du registrerar dig: [{{HeurekaRegisterUrlSv}} Registreringssida]

== Licens ==
För Heurekas programvaror gäller följande licensvillkor: [[Heureka_EULA | End-User License Agreement (EULA)]].

==Systemkrav==
Windows 7, 8 eller 10, 64-bit.

.NET Framework 4.8

== Instruktioner ==
Se [{{HeurekaHelpLink}}installera_heureka.htm Heurekas hjäldokumentation]

==Hämta programvaror==

====MSI (rekommenderat)====
MSI ([http://en.wikipedia.org/wiki/Windows_Installer Windows Installer]) innebär att programmet installeras som ett "vanligt" program under t ex C:\Program Files.

{{#clear_external_data:}}
{{#get_web_data:url={{HeurekaPublishUrl}}MSIversions.xml
|format=XML
|data=x86version=x86,x64version=x64,HabitatPrognosis=HabitatPrognosis,StandWise=x32Subset}}
{| cellpadding="5"
| align="left" width="200" style="background:#f0f0f0;"|'''Application'''
| align="left" width="100" style="background:#f0f0f0;"|'''Platform'''
| align="left" width="100" style="background:#f0f0f0;"|'''Version'''
| align="left" width="100" style="background:#f0f0f0;"|'''Note'''
|-
| StandWise, PlanWise, PlanEval, RegWise ||x64 (64-bit)|| [{{HeurekaPublishUrl}}MSI/Slu.Heureka.Setup_x64.msi {{#external_value:x64version}}] ||

|-
|}

====Clickonce====
"ClickOnce" innebär att programmet installeras under användares egen profil, och administratör-rättigheter behövs inte (vilket dock behövs för att installera SQL Server). Nackdelen med ClickOnce är att de olika applikationerna installerar varsin Heureka-kärna, vilket gör att programmen tar något mer plats på din hårddisk (ca 50 MB per applikation).

{{#get_web_data:url={{HeurekaPublishUrl}}ClickOnceVersions.xml
|format=XML
|data=StandWise=StandWise,PlanWise=PlanWise,PlanStart=PlanStart,RegWise=RegWise,PlanEval=PlanEval,HabitatPrognosis=HabitatPrognosis}}
{| cellpadding="5"
| align="left" width="200" style="background:#f0f0f0;"|'''Applikation'''
| align="left" width="100" style="background:#f0f0f0;"|'''Version'''
|-
| BeståndsVis (StandWise)||[{{HeurekaPublishUrl}}ClickOnce/StandWise/setup.exe {{#external_value:StandWise}}]
|-
| PlanVis||[{{HeurekaPublishUrl}}ClickOnce/PlanWise/setup.exe {{#external_value:PlanWise}}]
|-
| RegVis||[{{HeurekaPublishUrl}}ClickOnce/RegWise/setup.exe {{#external_value:RegWise}}]
|-
| PlanEval||[{{HeurekaPublishUrl}}ClickOnce/PlanEval/setup.exe {{#external_value:PlanEval}}]
|-
|}
{{#clear_external_data:}}

====Tidigare versioner====
Tidigare versioner kan hämtas här (endast som MSI):
[{{HeurekaPublishUrl}}MSI/Archive/ Arkiv]

==Hämta ytterligare Heureka-programvaror==

====PlanEvalWeb====
Se [[PlanEvalWeb]]

Intro

2024-11-25T14:59:33Z

Osskyn:

<noinclude>
{{Languages|Intro}}
</noinclude>
The Heureka Forestry Decision Support System (DSS) (http://www.slu.se/SHa) is a suite of freely available softwares developed and hosted by the [http://www.slu.se Swedish University of Agricultural Sciences (SLU)]. The system covers the whole decision support process from data inventory to tools for selecting among plan alternatives with multi-criteria decision making techniques.

The software applications are intended for both large-scale and small-scale forestry and are designed for different users' specific problem areas:
*[[StandWise]] for stand-level analysis
*[[PlanWise]] for forest-level planning and analysis
*[[PlanEval]] for multi-critera decision analysis, to help comparing plans generated in PlanWise
*[[RegWise]] for regional and national scenario analysis


The system is maintained, developed and supported by the [http://heureka.slu.se/SHa Forest Sustainability Analysis] program at SLU.

The softwares are the results of a research programme carried out in collaboration with [http://www.skogforsk.se Forestry Research Institute of Sweden (Skogforsk)].

[[Category:Software]]

Definition:SlopeTypeCode

2024-11-25T14:57:15Z

Osskyn:

{{Languages|SlopeTypeCode}}
{{ForestInputData
|description = Slope type code. Corresponds to "L" in Swedish GYL (Lutning))
|I_O = Input
|type = integer
|membership = Stand level
|unit_values = 1 = 0-10 % <br>2 = 10-20 % <br>3 = 20-33 %<br>4 = 33-50 %<br>5 = >50 %
|database = StandObject and SiteData
}}
{{VariableCategory}}

Harvested Wood Products

2024-11-25T14:56:55Z

Osskyn:

{{Languages|Harvested_Wood_Products}}

See also [[Harvested Wood Products Results|description for Harvested Wood Products results]].

https://pub.epsilon.slu.se/8673/1/Wikberg_P-E_120329.pdf

https://pub.epsilon.slu.se/9320/1/Wikberg_PE_121213.pdf

Soon to be updated.

[[Category:Model]]

BreedingEffects

2024-11-25T14:55:57Z

Osskyn:

{{Languages|BreedingEffects}}
[[Category:Model|Breeding]]

Import of climate scenario

2024-11-25T14:54:42Z

Osskyn:

{{Languages|Import_of_climate_scenario}}

See http://heurekaslu.org/help/en/index.html?importera_klimatscenario.htm



[[Category:Database]]
[[Category:Reference Manual]]
[[Category:User's Guides]]
[[Category:PlanStart]]

User's guide to PlanWise

2024-11-25T13:18:02Z

Osskyn: /* New help documentation */

{{Languages|User%27s_guide_to_PlanWise}}
[[Category:User's Guides|PlanVis|PlanVis]]

==New help documentation==
A newer help documentation is available at http://heurekaslu.org/help.

== Introduction ==

PlanWise is an application for long term forestry planning, including both strategic and tactical planning. It can be considered a problem solver that helps you find solutions to problems of the type "What to do and when?".

The application can can handle full cover geographical analysis which gives the basic conditions for spatial forestry planning, enabling the consideration of landscape patterns and concentration of treatments. It also gives a better connection to short term operational planning.

The application includes two main components, a growth-and-yield simulator and an optimizer. The simulator is called the Treatment Program Generator (TPG). The TPG computes alternative treatment programs for each treatment unit (stand) in a given forest area. The optimizer is called Heureka Optimization Programming System (HOPS). It is used to formulate and solve linear programming and mixed-integer programming problems for choosing between optional treatment programs. Another component is a map viewer for visualization of forest development and management under different plans, or scenarios.

==Get Started==
The best way to get started is probably to read the [[Get Started]] section and follow the instruction for installing the software. After that you can through the tutorial suggested there or check up another one in [[Tutorials | tutorials]]. This one (only in Swedish though) is probably the current best: [[SG0060_2010 | introductury exercise used in MSc course]].

== Working with Projects ==

[[Introduction to Projects]]

[[Create a new Project]]

[[Open an existing Project]]

[[Making a copy of a Project|Making a copy of a Project (incl. Name of Objects)]]

[[Delete a Project]]

== Generating treatment programs ==

[[Control Categories, Control Tables, and Forest Domains]]

== Optimizing ==
[[Optimization | User's Guide to Optimization]]

== Analyzing Results ==
Results can be viewed in maps, tables and graphs. See [[:Category:Results | Results]].

== How Do I? ==

It is possible to look at the [[PlanWise_Tutorial|tutorial]] and you are free to do the exercises (all of them or those you find relevant). However, be aware of the fact that they were written for MSc-students that worked with earlier releases of PlanWise (e.g., screenshots and programming syntax will not be applicable).

[[Create a New Result Database]]

[[Improve Performance]]

[[Organize Windows]]

== Reference ==
[[:Category:Control Tables|Control Tables]]

[[:Category:Dialog|Common Dialogs]]

[[:Category:Error Messages|Error Messages]]

User's guide to PlanWise

2024-11-25T13:17:44Z

Osskyn: /* New help documentation */

{{Languages|User%27s_guide_to_PlanWise}}
[[Category:User's Guides|PlanVis|PlanVis]]

==New help documentation==
A newer help documentation is available at http://heurekaslu.org/help

== Introduction ==

PlanWise is an application for long term forestry planning, including both strategic and tactical planning. It can be considered a problem solver that helps you find solutions to problems of the type "What to do and when?".

The application can can handle full cover geographical analysis which gives the basic conditions for spatial forestry planning, enabling the consideration of landscape patterns and concentration of treatments. It also gives a better connection to short term operational planning.

The application includes two main components, a growth-and-yield simulator and an optimizer. The simulator is called the Treatment Program Generator (TPG). The TPG computes alternative treatment programs for each treatment unit (stand) in a given forest area. The optimizer is called Heureka Optimization Programming System (HOPS). It is used to formulate and solve linear programming and mixed-integer programming problems for choosing between optional treatment programs. Another component is a map viewer for visualization of forest development and management under different plans, or scenarios.

==Get Started==
The best way to get started is probably to read the [[Get Started]] section and follow the instruction for installing the software. After that you can through the tutorial suggested there or check up another one in [[Tutorials | tutorials]]. This one (only in Swedish though) is probably the current best: [[SG0060_2010 | introductury exercise used in MSc course]].

== Working with Projects ==

[[Introduction to Projects]]

[[Create a new Project]]

[[Open an existing Project]]

[[Making a copy of a Project|Making a copy of a Project (incl. Name of Objects)]]

[[Delete a Project]]

== Generating treatment programs ==

[[Control Categories, Control Tables, and Forest Domains]]

== Optimizing ==
[[Optimization | User's Guide to Optimization]]

== Analyzing Results ==
Results can be viewed in maps, tables and graphs. See [[:Category:Results | Results]].

== How Do I? ==

It is possible to look at the [[PlanWise_Tutorial|tutorial]] and you are free to do the exercises (all of them or those you find relevant). However, be aware of the fact that they were written for MSc-students that worked with earlier releases of PlanWise (e.g., screenshots and programming syntax will not be applicable).

[[Create a New Result Database]]

[[Improve Performance]]

[[Organize Windows]]

== Reference ==
[[:Category:Control Tables|Control Tables]]

[[:Category:Dialog|Common Dialogs]]

[[:Category:Error Messages|Error Messages]]

User's guide to PlanWise

2024-11-25T13:15:14Z

Osskyn: /* New help documentation */

{{Languages|User%27s_guide_to_PlanWise}}
[[Category:User's Guides|PlanVis|PlanVis]]

==New help documentation==
A newer help documentation is available at http://heurekaslu.org/help (currently only in Swedish).

== Introduction ==

PlanWise is an application for long term forestry planning, including both strategic and tactical planning. It can be considered a problem solver that helps you find solutions to problems of the type "What to do and when?".

The application can can handle full cover geographical analysis which gives the basic conditions for spatial forestry planning, enabling the consideration of landscape patterns and concentration of treatments. It also gives a better connection to short term operational planning.

The application includes two main components, a growth-and-yield simulator and an optimizer. The simulator is called the Treatment Program Generator (TPG). The TPG computes alternative treatment programs for each treatment unit (stand) in a given forest area. The optimizer is called Heureka Optimization Programming System (HOPS). It is used to formulate and solve linear programming and mixed-integer programming problems for choosing between optional treatment programs. Another component is a map viewer for visualization of forest development and management under different plans, or scenarios.

==Get Started==
The best way to get started is probably to read the [[Get Started]] section and follow the instruction for installing the software. After that you can through the tutorial suggested there or check up another one in [[Tutorials | tutorials]]. This one (only in Swedish though) is probably the current best: [[SG0060_2010 | introductury exercise used in MSc course]].

== Working with Projects ==

[[Introduction to Projects]]

[[Create a new Project]]

[[Open an existing Project]]

[[Making a copy of a Project|Making a copy of a Project (incl. Name of Objects)]]

[[Delete a Project]]

== Generating treatment programs ==

[[Control Categories, Control Tables, and Forest Domains]]

== Optimizing ==
[[Optimization | User's Guide to Optimization]]

== Analyzing Results ==
Results can be viewed in maps, tables and graphs. See [[:Category:Results | Results]].

== How Do I? ==

It is possible to look at the [[PlanWise_Tutorial|tutorial]] and you are free to do the exercises (all of them or those you find relevant). However, be aware of the fact that they were written for MSc-students that worked with earlier releases of PlanWise (e.g., screenshots and programming syntax will not be applicable).

[[Create a New Result Database]]

[[Improve Performance]]

[[Organize Windows]]

== Reference ==
[[:Category:Control Tables|Control Tables]]

[[:Category:Dialog|Common Dialogs]]

[[:Category:Error Messages|Error Messages]]

Heureka Wiki

2024-11-25T12:49:50Z

Osskyn:

__NOTOC__ __NOEDITSECTION__
{{Languages|Heureka Wiki}}
{|width="100%"
|-
|style="vertical-align: top; border-right: 2em solid white; "|
<div style="background: #F7F7F7; border: 1px solid #999999; padding: 1em; ">
==About this Wiki==
This Wiki contains complementary information to the [{{HeurekaHelpLinkEng}} Heureka Online Help]. Here are, for example, variable definitions and how certain models work described.
<br>
</div>
<br>
<div style="background: #F7F7F7; border: 1px solid #999999; padding: 1em; ">
==Heureka Forestry DSS==
{{:Intro}}
<br>
<br>
[[About Heureka | More about Heureka and its features...]]
</div>
<br>

<div style="background: #F7F7F7; border: 1px solid #999999; padding: 1em; ">
==Get Started==
[{{HeurekaHelpLink}} Help documentation] <br>
[[Get Started|Get Started (English)]]
</div>



<br>
<div style="background: #F7F7F7; border: 1px solid #999999; padding: 1em; ">
==Disclaimer==
SLU can not be held responsible for any errors in the software. Please read the license agreement: [[Heureka_EULA|Heureka EULA]]!
</div>
<br>
|}

Get Started

2024-11-25T10:53:35Z

Osskyn: /* Run PlanWise */

{{Languages|Get Started}}

[[Category:User's Guides]]

==Heureka Helpdoc==
You can find instructions on how to install SQL Server and Heureka here: {{HeurekaHelpLink}}

==Run StandWise==
# Start StandWise (from Start > Program > SLU).
# Run the [[StandWise_Tutorial | StandWise tutorial]].
# For more information, see [[User's guide to StandWise]].


==Run PlanWise==
# Start PlanWise (from Start > Program > SLU).
# Run the [[PlanWise_Tutorial | PlanWise tutorial]].
# For more information see [[User's guide to PlanWise]].

== Availability and Support ==
{{:Availability_and_Support}}