Heureka Wiki - User contributions [en]

Version 2.16

2020-07-01T14:10:19Z

Rickardw:

<noinclude>
Version 2.16
{{Languages| Version 2.16}}
[[Category:Release]]
[[newsdate::2020-07-01]] [[language::en| ]]
</noinclude>
<startFeed />
{{DISPLAYTITLE:Version 2.16}}
==Summary==
<feedDate>2020-06-05</feedDate>
<endFeed />
*Version 2.16 contains bug fixes, improvements of existing functionality (mostly UI-related), and one new feature.
*The new feature allows you to include complex expressions in reports (PlanWise and RegWise). With this, you can create report variable conditions that are functions of other variables. This feature resembles the Sql Query-builder tools often found in GIS-applications.

<startFeed />
====Bug fixes and improvements====
<feedDate>2020-06-05</feedDate>
<endFeed />
<mantis>
status = resolved, closed
color = false
fixed_in_version = 2.16.0, 2.16.1, 2.16.2, 2.16.3
orderby = fixed_in_version desc, category desc
show = id,category,severity,summary,fixed_in_version,resolution
summary_as_comment = true
comment.344=Removal of overstorey propsals are now performed in the period closest to the defined year
comment.346= Production.cs always used the ProductionModelControlTable's parent ControlCategory for construction of (plugin) models, meaning the TreatmentModelControlTable supplied to plugins were the TMCT from the ProductionModelControlTable's parent ControlCategory. For built-in models, this only applied to SaplingHeightGrowthElfving, which gets its breeding settings from the TreatmentModelControlTable.
ProductionModelControlTable no longer keeps a reference to its parent ControlCategory. It was only used for this purpose, and the currently used ControlCategory is instead supplied to the plugin constructor at simulation time.
comment.342=NC-areas management programs were not saved correctly in RegWise
comment.347=Linking of retention patches to parent stands failed if AreaLevel2 and AreaLevel3 were missing.
comment.329=Wrong array was updated when program corrected DiameterType in input data
</mantis>

Version 2.16

2020-07-01T14:06:56Z

Rickardw:

<noinclude>
Version 2.16
{{Languages| Version 2.16}}
[[Category:Release]]
[[newsdate::2020-06-05]] [[language::en| ]]
</noinclude>
<startFeed />
{{DISPLAYTITLE:Version 2.16}}
==Summary==
<feedDate>2020-06-05</feedDate>
<endFeed />
*Version 2.16 contains bug fixes, improvements of existing functionality (mostly UI-related), and one new feature.
*The new feature allows you to include complex expressions in reports (PlanWise and RegWise). With this, you can create report variable conditions that are functions of other variables. This feature resembles the Sql Query-builder tools often found in GIS-applications.

<startFeed />
====Bug fixes and improvements====
<feedDate>2020-06-05</feedDate>
<endFeed />
<mantis>
status = resolved, closed
color = false
fixed_in_version = 2.16.0, 2.16.1, 2.16.2, 2.16.3
orderby = fixed_in_version desc, category desc
show = id,category,severity,summary,fixed_in_version,resolution
summary_as_comment = true
comment.344=Removal of overstorey propsals are now performed in the period closest to the defined year
comment.346= Production.cs always used the ProductionModelControlTable's parent ControlCategory for construction of (plugin) models, meaning the TreatmentModelControlTable supplied to plugins were the TMCT from the ProductionModelControlTable's parent ControlCategory. For built-in models, this only applied to SaplingHeightGrowthElfving, which gets its breeding settings from the TreatmentModelControlTable.
ProductionModelControlTable no longer keeps a reference to its parent ControlCategory. It was only used for this purpose, and the currently used ControlCategory is instead supplied to the plugin constructor at simulation time.
comment.342=NC-areas management programs were not saved correctly in RegWise
comment.347=Linking of retention patches to parent stands failed if AreaLevel2 and AreaLevel3 were missing.
comment.329=Wrong array was updated when program corrected DiameterType in input data
</mantis>

Version 2.16

2020-07-01T13:58:59Z

Rickardw:

{{DISPLAYTITLE:Version 2.16}}
==Summary==
<feedDate>2020-06-05</feedDate>
<endFeed />
*Version 2.16 contains bug fixes, improvements of existing functionality (mostly UI-related), and one new feature.
*The new feature allows you to include complex expressions in reports (PlanWise and RegWise). With this, you can create report variable conditions that are functions of other variables. This feature resembles the Sql Query-builder tools often found in GIS-applications.

<startFeed />
====Bug fixes and improvements====
<feedDate>2020-06-05</feedDate>
<endFeed />
<mantis>
status = resolved, closed
color = false
fixed_in_version = 2.16.0, 2.16.1, 2.16.2, 2.16.3
orderby = fixed_in_version desc, category desc
show = id,category,severity,summary,fixed_in_version,resolution
summary_as_comment = true
comment.344=Removal of overstorey propsals are now performed in the period closest to the defined year
comment.346= Production.cs always used the ProductionModelControlTable's parent ControlCategory for construction of (plugin) models, meaning the TreatmentModelControlTable supplied to plugins were the TMCT from the ProductionModelControlTable's parent ControlCategory. For built-in models, this only applied to SaplingHeightGrowthElfving, which gets its breeding settings from the TreatmentModelControlTable.
ProductionModelControlTable no longer keeps a reference to its parent ControlCategory. It was only used for this purpose, and the currently used ControlCategory is instead supplied to the plugin constructor at simulation time.
comment.342=NC-areas management programs were not saved correctly in RegWise
comment.347=Linking of retention patches to parent stands failed if AreaLevel2 and AreaLevel3 were missing.
comment.329=Wrong array was updated when program corrected DiameterType in input data
</mantis>

Version 2.16

2020-07-01T13:51:19Z

Rickardw:

{{DISPLAYTITLE:Version 2.16}}
==Summary==
<feedDate>2020-06-05</feedDate>
<endFeed />
*Version 2.16 contains bug fixes, improvements of existing functionality (mostly UI-related), and one new feature.
*The new feature allows you to include complex expressions in reports (PlanWise and RegWise). With this, you can create report variable conditions that are functions of other variables. This feature resembles the Sql Query-builder tools often found in GIS-applications.

<startFeed />
====Bug fixes and improvements====
<feedDate>2020-06-05</feedDate>
<endFeed />
<mantis>
status = resolved, closed
color = false
fixed_in_version = 2.16.0, 2.16.1, 2.16.2, 2.16.3
orderby = fixed_in_version desc, category desc
show = id,category,severity,summary,fixed_in_version,resolution
summary_as_comment = true
comment.344=Removal of overstorey propsals are now performed in the period closest to the defined year
comment.346= Production.cs always used the ProductionModelControlTable's parent ControlCategory for construction of (plugin) models, meaning the TreatmentModelControlTable supplied to plugins were the TMCT from the ProductionModelControlTable's parent ControlCategory. For built-in models, this only applied to SaplingHeightGrowthElfving, which gets its breeding settings from the TreatmentModelControlTable.
ProductionModelControlTable no longer keeps a reference to its parent ControlCategory. It was only used for this purpose, and the currently used ControlCategory is instead supplied to the plugin constructor at simulation time.
comment.342=NC-areas management programs were not saved correctly in RegWise
comment.347=Linking of retention patches to parent stands failed if AreaLevel2 and AreaLevel3 were missing.
comment.329=Wrong array was updated when program corrected DiameterType in input data
</mantis>

Version 1.6

2019-12-11T14:56:48Z

Rickardw: Replaced salix FTP links with heurekaslu equivalents.

{{Languages}}
[[Category:ReleaseNotes archive]]
[[newsdate::2011-11-11]]

==Summary==
Version 1.6 contains several improvements since last release in beginning of September, for example:
*We have worked a lot with a function in RegWise to improve handling and computation of the forest state at the start year.

*Parallelization of the treatment program generator in PlanWise to better utilize the computation capacity of multi-core processors has also been a large activity, in order to decrease computation times.

*An optimization model for tactical planning problems in PlanWise with road entry decisions has been developed as part of an MSc study for SCA Forest.

*Forest Domain expressions can be defined as relations between different variables.

*Dead wood is reported separately for coniferous and deciduous trees.

 '''Important''': When using period midpoints in PlanWise, period 0 now refers to a point in time (year 0). Period 1 refers to activities bewteen year 0 to 5, with midpoint 2.5. This can affect your optimization models, see below.

==New features ==
*The HabitatPrognosis is released (finally!), although we call it a beta version. See download and how-to instructions [[HabitatPrognosis | here]]. Instructions are in Swedish but the user interface is in English.

*When editing conditions in a forest domain, expressions can now hold variables with modifiers as expression types. This means that a condition can include a relation between two variables (instead of one variable and a constant value), for example MeanAge >= 1.1*MinFinalFellingAge.

*RegWise has a new method for calculating forest development to a user-defined start year. The "pre-growth-step" is independent of the settings in the actual scenarios to run. This makes it possible to use exactly the same starting condition for different scenarios when the start year is not the same as the inventory year.

*Two new thinning guides are available (see control table Treatment Model > Thinning Guide):
**One is using an up to 6-degree polynomial function to determine what basal area to trigger thinnings, and target basal area after thinning, with dominant height as power variable. The difference with the existing thinning guide (Hugin Thinning Guide), is that the latter approximates a non-linear curve with one or two intersecting straight lines.
**One is based on stem density. The implementation was financed by Bergvik Skog AB. Three new control table variables are available when selecting this thinning guide:
***[[ControlTable_Treatment_Model#Min_Prop._Thinnable_Plots | Min Prop. Thinnable Plots]]
***[[ControlTable_Treatment_Model#Max_Height_Any_Thinning | Max Height Any Thinning]]

*A parameter [[ControlTable_Treatment_Model#Min_Thinning_Grade | Min Thinning Grade]] has been added to control table Treatment Model. It determines the minimum thinning grade accepted in a thinning or selection felling.

*The default value for [[ControlTable_Treatment_Program_Generator#Cleaning_Period_Delay_Max | Cleaning Period Delay Max]] in control table Treatment Program Generator (PlanWise and StandWise) has been changed from 2 to 0. This means that the timing of cleaning is not varied, by default, and consequently that more focus is put on varying the thinning schedule and final felling period. We have found little point in varying the timing of cleanings with respect to predicted growth and yield, the difference seems marginal. Still, the net present value can indeed be affected by the timing of the cleaning, so if the purpose of an analysis is to study the optimal time for cleaning this setting should of course be modified.

*When editing a report template, the user can now choose a default view for the report (graph, table, or mixed).

*In control tables, a single variable can be reset to its default value (right-click and select "Reset to default value"). Before, you could only reset the entire table.

*Volume harvested is computed also in cleanings.

*Handling of root extraction for bio fuel has been improved, both with respect to cost calculations and possibility to select for which species that roots and stumps can be harvested (variable [[ControlTable_Treatment_Model#Stump_Extraction | Stump Extraction]] in control table Treatment Model). Only spruce stumps are harvested by default. Instead of a fixed cost, a linear function of terrain transport distance is used, and different functions are used for [[ControlTable_Cost#Harvest_Residue_Extract._Cost | thinning]] and [[ControlTable_Cost#Harvest_Residue_Extract._Cost_2 | final felling]], and in final felling, for harvest residues and [[ControlTable_Cost#Stump_Harvest_Cost | stump]].

*Strip road area is proportional to tree spacing. If spacing between trees is larger than strip road width, there will be no strip road area.

*Volume of dead wood is now reported as "Downed deadwood", and "Standing Dead Trees" for, yes, volume of lying and standing dead wood. Also, dead wood is reported separately for coniferous and deciduous trees.

==Performance improvements==
*The treatment program generator in PlanWise is faster on multi-core processor PCs (which most PC:s are today). This has been achieved through parallellization of the program so that the computer's capacity is better utilized.

*The evaluation of forest domains when running Tactical Treatment Program Generator has been very time consuming, but this has been fixed.

==Bug fixes==
*The number of selection fellings was too few under certain conditions when applying uneven-aged management (CCF).

*When calculating initial tree age a function is used to determine if a tree should be considered an overstorey tree. If so, a specific age function is used. For different reasons, this functionality had been removed, but is now re-implemented.
*For ingrown trees, the function for uneven-aged stands is now used to compute tree age, independent of whether the stand is classified as even-aged or uneven-aged. As a consequence of this fix, ingrown trees get smaller ages, which in turn gives a larger growth than before. In an example that we ran for a spruce stand with H100 = 33 m and a mean age of 68 years, a certain ingrown tree is now 29 years, compared to 59 years before the change.

* When adding a new "user defined integer set" to an optimization model, an error occured in the index for existing parameters due to a naming conflict. This has been corrected, so that a unique index is generated.

* In the Timber Pricelist editor (control table Pricelist, section Prices > Timber), there is a setting "Pulpwood proportion" for how many of the butt logs, middle logs, and top logs, respectively, that are downgraded to pulp. Probably, few users have changed these settings which are 10 % by default. However, changing these values have not lead not to expected results, because the value for top log and but log had been switched. This has been fixed. Also, the focus is always on the first tab (Pine) when opening the editor.

More bug fix reports are available [https://arbetsplats.slu.se/sites/srh/heureka/Lists/Release%20notes/Default.aspx here].

==Other stuff you should know==
*When using period midpoints in PlanWise strategic TPG, period 0 now refers to year 0, not year 2.5. Instead, the period midpoint for period 1 is year 2.5, and so forth. Hence, period 0 is not an actual period, but a point in time, followed by a series of 5-year periods. The problem have been that treatments applied in year 0, for example regeneration in recently clear cut stands, were not reported when using period midpoint, but now they are. Note that '''no regular harvesting''' will take place in period 0, only removal of existing seed trees and shelterwoods. This will probably affect existing optimization models, if you have restrictions that include harvesting in period 0. Add condition "with p > 0" when declaring such constraints, for example
:<code><nowiki>forall in periods with p > 0 do </nowiki></code>
*A set of report templates (in Swedish!) can be downloaded from https://www.heurekaslu.se/filerepository/Rapportmallar/. See the readme-file there for instructions were to put the templates. One useful template is called Översikt (Overview), check it out!

==Next release==
*Date is not decided...
*A new stand register version (2) will be released (actually PlanStart supports it but we have not documented it yet). The new version has columns for initial dead wood volume. The previous version (1) will still be supported.

Ivent/sv

2019-12-11T14:54:26Z

Rickardw: Replaced salix FTP links with heurekaslu equivalents.

{{Languages|Ivent}}

== Systemkrav ==
* Handdator med Windows Mobile version 5.0 eller senare.

== Installation ==
# Hämta filen IventSetup_2010_xx.cab från [https://www.heurekaslu.se/filerepository/Ivent/]
# Anslut handdatorn (Windows Mobile) till din PC med hjälp av ActiveSync (Windows XP) eller Mobile Device Center (Windows Vista)
# Kopiera installationsfilen för Ivent (IventSetup_2010_xx.cab) till handdatorn.
# �?ppna Utforskaren på handdatorn och installera Ivent genom att dubbelklicka på filen IventSetup_xx.cab
# Kopiera databas-filen/filerna (från [[Inventory_design | PlanStart / Inventory]]) (.sdf) till enheten, till mappen "DatabasePath" + Undermapp. DatabasePath framgår av filen app.ini (se nedan). Under DatabasePath, som kan vara t ex C:\My Documents\Databases\, måste det finnas en underkatalog, och det är i den som du lägger sdf-filen. Du kan ha olika underkataloger för olika områden. Ex. på hur det kan se ut i handdatorns filutforskare:
:*Den här enheten (del av DatabasePath och är detsamma som C:)
:**My Documents (del av DatabasePath)
:*** Databases (del av DatabasePath)
:**** Test (underkatalog)

Det kan vara nödvändigt att installera några ytterligare bibliotek, beroende på konfigurationen på handdatorn. Du hittar dessa komponenter här: [https://www.heurekaslu.se/filerepository/Ivent/ https://www.heurekaslu.se/filerepository/Ivent/]. Filerna
*: .NET Compact Framework: file NETCFv2.wce5.armv4i.cab. Troligen inte nödvändigt om du har Windows Mobile 6.0 eller senare
*: SQL Server Compact Edition: filen sql.ppc.wce5.armv4i.cab

När Ivent startas läses inställingar in från en fil som heter "app.ini" (finns i samma kat. Denna fil kan redigeras i Ivent från menyn Settings (efter vilken Ivent måste startas om!). '''Om du har kört tidigare versionen av Ivent innan du ska ta bort den gamla app.ini filen och ersätta den med någon av följande''':

* Engelsk version:
*: [https://www.heurekaslu.se/filerepository/Ivent/EnglishConfigFile/ https://www.heurekaslu.se/filerepository/Ivent/EnglishConfigFile/]

* Svensk version:
*: [https://www.heurekaslu.se/filerepository/Ivent/SwedishConfigFile/ https://www.heurekaslu.se/filerepository/Ivent/SwedishConfigFile/]

När Ivent startas läser den in information från en ini-fil. Filen heter "app.ini" och ligger i samma katalog
som Ivent körs ifrån. Exempel på ini-filens innehåll:

<pre>
DatabasePath=\My Documents\Databases\
ComPort_GPS=COM9
ComPort_Caliper=COM8

**ComPort_DME=COM7
**ComPort_HME=COM6

PosTexNumberOfValues=3
PosTexMaxDiff=1.0
**Intervall (ms)
LaserTimerIntervall=1000
...
</pre>

*Du måste eventuellt ändra portinställningarna så att de passar den mobila handenheten. TDS Nomad använder sig av två portar för Bluetooth, portarna COM8 och COM9.
*Om man ansluter klaven till COM8 så behöver man inte ändra i ini-filen.
*Om man använder en extern GPS och ansluter den till COM9 behöver man inte ändra i ini-filen.
*Dataklaven som används per default är en "Digitech Professional" med programvaran "Digitech 11". Denna har kommuncierar via Bluetooth. Det finns även stöd för Digitech Mantax, som använder sig av radiomottagare som kopplas till en traditionell serierport, som vissa handdatorer är utrustade med. Man väljer klavtyp i inställningsmenyn (kräver omstart av Ivent, precis som vid ändrings av andra inställningar i Settings-menyn).

== Testa applikationen på en vanlig PC ==
Du kan testa applikationen på en vanlig PC genom att installera en emulator och på så sätt skapa en virtuell enhet. Instruktioner:
#Ladda ner och installera [http://www.microsoft.com/downloads/details.aspx?FamilyId=3D6F581E-C093-4B15-AB0C-A2CE5BFFDB47&displaylang=en Windows Mobile 6.1 Professional Images (USA).msi]
#Starta emulatorn via Start > Alla program > Windows Mobile 6 SDK > StandAlone Emulator Images > US English > WM 6.1 Professional 240 x 400
#I emulator-fönstret visas nu en simulerad handdator. På denna kan du installera Ivent. Börja med att skapa en koppling till din PC:s hårddisk, så att du kan kopiera över installationsfilerna:
##Välj File > Configure och fliken General
##Under Shared Folder så väljer du en mapp på din hårddisk, t.ex. c:\temp. Välj gärna samma mapp där du sparade IventSetup.cab och Holmen.sdf. Mappen kommer att visas i den virtuella enheten som "Storage Card"
##�?ppna den virtuella enhetens filutforskare (via Start > Programs > File Explorer)
##Under "My Device" hittar du "Storage Card". Dubbelklicka på IventSetup.cab. Se till att välja att installera på "Device", inte på "\Storage Card"
##Skapa en ny mapp på enheten: My device > My documents > Databases > Holmen. Kopiera sedan filen Holmen.sdf dit från "Storage Card" (via Menu > Edit > Copy)
##Starta Ivent genom File > Programs på enheten. Det kan ta flera minuter för enheten att "starta"

== Användarmanual ==

[[User's guide to Ivent|Användarmanual]]

[[Category:Software]]

User's guide to Ivent

2019-12-11T14:53:26Z

Rickardw: Replaced salix FTP links with heurekaslu equivalents.

[[Category:User's Guides|Ivent|Ivent]]

== Introduction ==
Ivent is an Windows Mobile application for handheld devices. It is used for field inventory of sample plot data. [[PlanStart]] is used for setting up a sample design, and export data to Ivent, and import it back and process the collected data.

The inventory of a sample plot includes the registration of tree and site characteristics. The application can retrieve data from peripheral devices (through Bluetooth or other radio), including a digital caliper (for tree diameter measurement), a clinometer (for tree height measurement), a GPS, and a new tree positioning device ([http://www.haglofcg.com/index.php?option=com_content&view=article&id=80%3Apostex&catid=57%3Aproductsolutions&Itemid=118&lang=en PosTex]).

==Main steps==

Considerable techniqualities are involved in a field inventory. In short, a field inventory includes the following steps:
#[[Import of stand register | Import a stand register ]]
#[[Sample design | Set up a sample design]]
#Set up an [[Inventory | inventory and export data to a database file]]
#Copy the database file to the field computer
#:It is possible to distribute an inventory over several field crews just by distributing the same file created in the step above. PlanStart can handle this when importing back to the system.
#Do field inventory with Ivent
#Import field inventory data back to PlanStart
#:If you have distributed the inventory to several computers, you can import them one by one until the whole inventory is completed.

== Field inventory instructions ==

[[Media:Instruktion_Ivent.pdf | Instruction from 2008 (in Swedish)]] ''NB: This instruction is from field-studies made in summer '08 and has not been updated in accordance with the latest version of Ivent.''

[[Field inventory instruction]]

== Settings ==
In Ivent's startpage you can find the menu Settings. Some of the settings are the listed below. '''After making changes, you must restart Ivent for the changes to take effect.'''
;DatabasePath: The path to where subfolder with database files are stored. For display only. Can only be modified by editing the app.ini file directly in a text editor.
;Comport GPS: Com-port for GPS. Default = 9. If you use an external GPS och connect it to COM9 then this setting should work.
;Comport Caliper: Com-port for caliper. Default = 8. Set to 1 if you use Mantax caliper and Archer PDA
You may have to edit the port settings so that they match your mobile device. TDS Nomad uses two ports for Bluetooth, ports COM8 and COM9.
;CaliperModel: Type av computer caliper. 0 (default) = Digitech Professional (Bluetooth), 1=Digitech Mantax (radio device connected to serial port)
;Species Order: Determines the order in which [[Definition:SpeciesCode | tree species codes]] are listed when entering tree codes in forms. You can change the order by selecting a species code, and move it up or down with the buttons with arrows.
;SampleTreeSelectionMethod: Method for selecting sample trees, that is caliper trees for which additional measurements to diameter and species are made, such as age, height and barh thickness. Systematic (default) is a modifed version of the "random" algorithm, and gives a more evenly distribution of sample trees over sample plots. Both methods are PPS-methods (probability proportional to size).
;CaliperCode1:The [[Definition:SpeciesCode | species code]] in Ivent that corresponds to code nr 1 on the caliper.
;CaliperCode2:The [[Definition:SpeciesCode | species code]] in Ivent that corresponds to code nr 2 on the caliper.
;...
;CaliperCode8:The [[Definition:SpeciesCode | species code]] in Ivent that corresponds to code nr 8 on the caliper.
Currently the calipers we are familiar with only support eigth species. If there are more species, you may have to edit the species code manually in Ivent after registering it with some other, temporary code.

The settings are stored in a file called <code>app.ini</code> which is located in the same folder as the Ivent program (normally Program\Ivent). If this file is missing, a new one is automatically created by Ivent at startup (which is good if your app.ini file is corrupt). If there is a file available, the settings are read from that file at startup. This can be utilized of you have several invenntory crews with the same equipment and setup: just distribute an proper app.ini file.

====Notes====
*If you are upgrading from an older Ivent-version you should remove the old app.ini file and replace it with one of the following*:
**English version:
**:[https://www.heurekaslu.se/filerepository/Ivent/EnglishConfigFile/ https://www.heurekaslu.se/filerepository/Ivent/EnglishConfigFile/]
**Swedish version:
**:[https://www.heurekaslu.se/filerepository/Ivent/SwedishConfigFile/ https://www.heurekaslu.se/filerepository/Ivent/SwedishConfigFile/]

== Entering measurement data ==
[[Software (and hardware) instructions | User's manual to Ivent]]

== Reference ==

[[:Category:Database|Database]]

Ivent

2019-12-11T14:52:14Z

Rickardw: Replaced salix FTP links with heurekaslu equivalents.

{{Languages}}
== About Ivent ==
Ivent is an application to be installed on a handheld Windows Mobile device. It is used for field inventory of sample plots. The inventory of a sample plot includes the registration of tree and site characteristics. The application can retrieve data from peripheral devices (through Bluetooth (TM)), including a digital caliper (for tree diameter measurement), a clinometer (for tree height measurement), a GPS, and a new tree positioning device ([http://www.haglofcg.com/index.php?option=com_content&view=article&id=80%3Apostex&catid=57%3Aproductsolutions&Itemid=118&lang=en PosTex]).

== System requirements ==
* Windows Mobile device with Windows Mobile 5 or later.

== Prerequisites ==
* None.

== Installation ==
#Download IventSetup_(version).cab] from [https://www.heurekaslu.se/filerepository/Ivent/]
#Connect the Windows Mobile Device to your PC with ActiveSync (Windows XP) or with Mobile Device Center (Windows Vista)
#Copy the setup file för Ivent (IventSetup_(version).cab) to the device
#From within the device's Explorer, install Ivent by double-clicking on the setup file.
#Copy the database file created in [[Inventory_design | PlanStart / Inventory]] (.sdf) to the device, for example to folder \My Documents\Databases\XX\, where XX is s subfolder to DatabasePath which by default is set to "\My documents\Databases\" (see [[User's guide to Ivent#Settings | Ivent Settings]])

====Troubleshooting====
It may be necessary to install some additional libraries, depending on the configuration on the device. You can find these components (cab-files) here: [https://www.heurekaslu.se/filerepository/Ivent/ https://www.heurekaslu.se/filerepository/Ivent/]. The files are
:*.NET Compact Framework: file NETCFv2.wce5.armv4i.cab. Probably not necessary if you have Windows Mobile 6.0 or later
:*SQL Server Compact Edition: file sql.ppc.wce5.armv4i.cab

== User's Guide ==

[[User's guide to Ivent]]

[[Category:Software]]
[[Category:Install]]

PlanWise Tutorial

2019-12-11T14:40:40Z

Rickardw: Replaced salix FTP links with heurekaslu equivalents.

(Available only in Swedish)

==Om PlanVis==
PlanVis är ett datorprogram för att göra konsekvensanalyser och upprätta åtgärdsplaner inom skogsbruket. Analyser kan göras på heltäckande data (alla bestånd inom ett skogsinnehav) eller på ett urval (s.k. stickprovsavdelningar). Tidshorisonten kan vara alltifrån några enstaka år vid taktisk planering till mer än 100 år för avverkningsberäkningar. I PlanVis integreras indata, generering av alternativa aktiviteter, optimering och resultatredovisning. Det senare görs i form av tabeller, diagram och kartor. Vill man ha ut ytterligare resultat än de som kan tas fram direkt i PlanVis kan man göra detta utplock ur databasen. Med generering av alternativa aktiviteter menas att PlanVis kan generera ett antal olika skötselprogram för varje bestånd inom ett valt område. Ett skötselprogram är en sekvens av åtgärder, utfall och tillstånd över tiden. Som användare kan man dela in skogen i olika grupper, och skapa olika skötselinstruktioner för dessa.

Innan du fortsätter, läs användarmanualen som finns på sidan [[User%27s_guide_to_PlanWise|User's guide to PlanWise]].

==Upplägg av övning==
Första delen av övningen är en guide där du steg för steg får gå igenom grundläggande moment som installera program, skapa projekt, inspektera ingående tillstånd, skapa skogsdomäner, lära dig lite om att göra avancerade inställningar genom kontrollkategorier, skapa skötselinstruktioner (d.v.s. skötselkategorier), skapa skötselprogram, lösa optimeringsproblem samt inspektera resultat.

Andra delen av övningen är problembaserad där du får uppgifter du själv ska lösa.

==Installera PlanVis==
Installationen ska redan vara gjord på de datorer vi här använder. Annars är det bara att följa instruktionen på sidan [[PlanWise]].

==Skapa ett nytt projekt==
Se även [[:Category:Working_with_Projects | Arbeta med projekt]].
{{:Skapa nytt projekt}}

==Beräkna ingående tillstånd och visa översikt==
En översiktlig sammanställning erhålles både i tabell-/diagramform och som karta.
# Välj fliken "Analysis Area"-fönstret längst till höger. Välj här "Landscape8" (eller namnet på det område/skogsinnehav som ska analyseras).
# I huvudfönstret finns fliken "Ingående tillstånd (Initial State)". Under den finns "Details", "Forest Data Overview", och "Map". Klicka på knappen som hete "Calculate Initial State"...'''
# I fliken "Forest Data Overview" finns ett urval tillståndsvariabler, såsom medelvolym och medelålder. Denna del ska så småningom byggas ut med fler diagram och tabeller. Tills vidare, om det du söker inte finns med får du kopiera data från "Details" och göra egna diagram i t ex Excel.

==Visa ingående tillstånd i karta==
Här får man prova på kartverktyget, välj menyn "View" och därunder "Map Page". I rutan "Result:" må man välja "Current State", figur 3 (1), om ingenting visas så klicka på "Fit map to window", figur 3 (2).
{|
|[[Image:PlanVis_Tut_Fig3_withno.png|500px|thumb|left|Figur 3]]
|}
I fönstret "Map Properties" kan man välja en variabel att göra en temakarta för. Exempelvis för beståndens förrådsuppgifter;
* '''Expandera (klicka på +) "Forest Data"...'''
högerklicka på "Volume" och välj "Add Iterms Automatically". Klicka på färgerna och välj förslagsvis samma kulör men olika nyanser (för min- resp. max-värde). Markera "Width of items in gradient" och värdet "20". Detta ger en klassindelning med 20 m3sk/ha-intervall.
* '''Sedan högerklickar man på "Volume" igen och väljer "Show in Map"'''
Bland kartverktygen finns en rullgardin till vänster om "Opacity" där man kan välja att visa en bakgrund, t.ex. ett ortofoto eller en vägkarta, figur 3 (3). Vad som finns tillgängligt för aktuellt analysområde beror vilka bakgrundsbilder som i PlanStart importerades till databasen.
* '''För kartan finns också ett selekteringsverktyg, figur 3 (4)'''
Med det kan man välja en åtgärdsenhet och då visas i fönstret "Treatment Unit Properties" ett antal uppgifter för den valda enheten.

==Skapa domäner och skötselgrupper==
Toppnivån i ett projekt är analysområdet ("Analysis Area") som innehåller alla behandlingsenheter ("Treatment Units") som ska analyseras. Nästa nivå utgörs av skogsdomänerna ("Forest Domains"). En skogsdomän är en grupp av behandlingsenheter (bestånd) som uppfyller ett eller flera villkor. Villkoren ställs utifrån enheternas ingående tillstånd. Användaren anger villkoren själv och skapar därmed sina egna skogsdomäner. Man kan spara definitionen för skogsdomäner som en mall (i form av en fil på hårddisken). Denna mall kan delas med andra användare. Domäntillhörigheten är statisk genom föreliggande analyser (ett bestånd kan alltså inte t.ex. "växa in" i en annan domän än den initiala under pågående planperiod).

I början av en analys tilldelas varje behandlingsenhet en (och endast en) skogsdomän. Domänerna ställs upp i prioritetsordning och utvärderas därefter, så att den domän som står överst utvärderas först. Man kan enkelt ändra i ordningen. Om enheten inte tillhör den första domänen kontrolleras nästa domän, osv. Det finns alltså inga problem med att domäner faktiskt kan överlappa varandra. Den sista domänen är en "restdomän". Denna har inga villkor utan inkluderar alla enheter som inte hamnat i annan domän. Det finns alltså heller inga problem med att ställda villkor "glappar".

För varje skogsdomän kan man koppla särskilda skötseldirektiv genom att redigera och skapa nya kontrollkategorier ("Control Categories"). Vi kallar dessa ibland skötselkategorier. En kontrollkategori utgörs av att antal kontrolltabeller. Genom dessa styr man, bland annat, vilka åtgärder som ska simuleras och hur de ska utföras. Genom att skapa en eller flera kontrollkategorier för varje skogsdomän, kan man differentiera skötseln över de olika skogsdomänerna. ''Genom en kontrolltabell av typen "Treatment Program Generator" styr man vilka åtgärder som ska simuleras och till viss del tidpunkter för dessa. Genom en kontrolltabell av typen "Treatment Model" styr man hur åtgärderna ska simuleras (utföras).''

För att skapa skogsdomäner används verktyget "Forest Domain Builder", figur 4 (1). Exempelvis kan man skapa en domän som heter "Äldre skiktad granskog" och ange villkoren som gäller för att en åtgärdsenhet ska tillhöra denna. I exemplet nedan skapar vi domäner utifrån en befintlig s.k. målklassning som fanns angivet i beståndsregistret.

==Definiera skogsdomäner==
* '''Under "View" aktiveras "Forest Domain Builder"'''
* '''Högerklicka på "Other" och välj "Add Forest Domain" varefter dialogrutan "Edit Conditions" visas'''
* '''Under "Property" väljs "Select property..."'''
Expandera "StandObject Data" och markera "ManagementClass" (avser i detta fallet Skogsstyrelsens målklassning i s.k. Gröna skogsbruksplaner).
* '''Ange att "ManagementClass Equal" (under "Operator") NO (under "Expression")'''
NO står för Naturvårdsinriktning, lämnas Orört (till skillnad från NS, Naturvårdsinriktning som kräver någon form av Skötsel).
* '''Döp om "Forest Domain 1" till t.ex. "NO-skog"'''

Nu innehåller inte alla beståndsregister målklasser. Då får man istället utgå ifrån befintliga beståndsparametervärden. För att skapa ett skogsdomän med "Äldre skiktad granskog" skulle följande kriterier kunna gälla:
{|
|[[Image:PlanVis_Tut_Fig3b.png|500px|thumb|left|Figur 3b]]
|}
Vill du kolla hur många bestånd som hamnade i det skapade skogsdomänet högerklickar du i domänet och väljer "Evaluate forest domains" (syns i fönstret "Properties") alt. "View treatmentunit assignment...". Hamnade inga här får du kanske gå tillbaka och ändra kriterierna, "Edit conditions..." (i ovanstående exempel kanske sänka ålderskravet till t.ex. större än 70 år).

I andra lägen kanske man vill skapa ett domän för specifika bestånd (som kanske identifierats i GISet som "bestånd angränsande till sjö med häckande storlom", "bestånd med förvaltarens favoritpass", osv.), dessa id-nummer listas då, semi-kolonseparerade, "in" "TreatmentUnit.Description". Alla siffror, inkl. nollor, och mellanslag må med, vilket är lite bökigt. Alldeles strax tillkommer sådan funktionalitet att man i kartan kan markera (ett eller) flera bestånd och direkt hänföra dessa till ett domän.

Minns du att det vid importen av beståndsregistret fanns ett antal kolumner på slutet av .csv-filen som hette "UserDefinedVariable"? Om man vill ta hänsyn till genomförda GIS-analyser, t.ex. bestånd helt eller delvis inom buffertzon till område med störningskänsliga arter, bör man alltså se till att sådana uppgifter medföljer redan vid dataimport. T.ex. skulle en av kolumnerna kunna bestå av värden 0 - 100%, beroende på hur stor del av beståndets yta som är inom nämnda buffertzon. Utifrån dessa uppgifter skulle sedan olika skogsdomäner, med olika skötselformer, kunna tillämpas.

==Definiera skötselkategorier (kontrollkategorier)==
Välj fliken "Control Categories" (under "Analysis Area"), figur 4 (2). Om fönstret inte syns aktiverar du det via menyn "View".

===Inspektera och ändra befintlig kontrollkategori===
* '''Klicka på kategorin "DefaultTreatmentCategory"'''
Vi låter denna motsvara traditionellt trakthyggesbruk.
* '''Längre ner visas fönstret "Properties", figur 4 (3)'''
Om inte så aktiverar du det via menyn "View". Du kan flytta och förstora/förminska fönster på arbetsytan.
* '''Varje "ControlCategory" har ett antal kontrolltabeller'''
Ändra i dessa för "DefaultTreatmentCategory", figur 4 (4). Du hittar lite mer information på sidan [[Control_Categories%2C_Control_Tables%2C_and_Forest_Domains|Control Tables etc]]. Du kan dessutom se vad alla parametrarna betyder genom att markera dem och läsa hjälptexten längst ned i fönstret "Properties" (hovra med pekaren ifall inte all text syns).
{|
|[[Image:PlanVis_Tut_Fig4_withno.png|500px|thumb|left|Figur 4]]
|}
* '''Forts:'''
** Välj kontrolltabellen "Treatment Program Generator" (under "Control Categories"), figur 4 (4)
** Under "ManagementSystem" (i fönstret "Properties") väljs "EvenAged"
** Sätt "MaxAlternatives" till 100
** "CCDelayMax" är satt till 4 vilket betyder att slutavverkningstidpunkten får skjutas upp max 4 perioder (dvs. 20 år) jämfört med lägsta tillåtna slutavverkningsålder (LSÅ enligt Skogsvårdslagen). Du kan ändra till ett annat värde om du vill.
** Välj sedan kontrolltabellen "Treatment Model". Under "4. Thinning - model" och "4.1 Thinning – settings" kan du ändra t.ex:
*** ThinningModelType = Hugin
*** HarvestStriproads = True
*** MinDiameterThinning = 0
*** MaxThinningIntensity = 40
*** VaryThinningIntensity = True. Glöm inte att markera parametrar och läsa hjälptexterna.
** Välj slutligen tabellen "Production Model" och titta igenom inställningsmöjligheterna. Inget behövs här ändras emedan du alltid kan läsa hjälptexterna.

===Lägg till ny kontrollkategori===
* '''Högerklicka i någon tom del i fönstret "Control Categories" och välj "Add Treatment Category"'''
* '''Ändra namn på den nyskapade "TreatmentCategory2" till "Fri utveckling"'''
* '''Högerklicka på "Fri utveckling" (i fönstret "Control Categories") och välj "Edit ControlTables"
* '''Klicka på "Add..."'''
Håll ner Ctrl-tangenten och markera p.s.s. både "Production Model" och "Treatment Program Generator". Klicka på "Ok".
* '''Gör följande inställningar för denna kategori:'''
** Sätt "ManagementSystem" till "FreeDevelopment"
** Klicka på "Treatment Program Generator"
** Sätt "MaxAlternatives" till 1 (i fönstret "Properties")

Valet av "ManagementSystem" avgör vilken huvudtyp av skogsbrukssätt som ska simuleras. Man man välja mellan "EvenAged" (dvs. trakthyggesbruk), "Continuous" (hyggesfritt, t.ex. blädning) och "FreeDevelopment" (fri utveckling, inga åtgärder simuleras).

==Koppla kontrollkategori till skogsdomän==
* '''Högerklicka på domänen "NO-skog"'''
* '''Välj "Add control category connections"'''
* '''Välj "Fri utveckling" och klicka på "Ok"'''
* '''Ta bort kategorin "DefaultTreatmentCategory" från denna domän genom att markera och trycka "Delete"'''

Nu har vi angett att all skogsmark ska skötas med trakthyggesbruk, utom den NO-klassade skogen som ska lämnas orörd (till fri utveckling).

==Beräkna prislista==
* '''Under menyn "Action" väljs "Add Pricelist..."'''
* '''Välj "Add Default pricelist"'''
I nästa dialog kan du se vilka apteringsgränser, priser, etc. som gäller. Längst ner står det "Prices" och "Timber" och bredvid "Pine;Spruce". Klicka på "..." så öppnas en prislista (som är viktad, se nedan). Klicka slutligen på "Finish" och vänta tills prislistan har räknats fram. Vad som görs är att trädpriser beräknas (i kr/m3fub) för en mängd kombinationer av trädslag, diametrar och höjder. Värdet på ett träd beräknas sedan under en prognos genom att multiplicera det beräknade priset med trädvolymen. Varje träd får således ett slags genomsnittspris baserat på en prislista som har viktats utifrån ett genomsnittligt utfall av olika kvaliteter. Vi tar alltså inte hänsyn till kvaliteten på varje träd (vi har inte tillgång till den variabeln).

Har du intresse av att ändra kalkylräntan kan det göras här, i rutan bredvid "DiscountingRate" anges önskat värde i procent.

Nu är vi klara att skapa alternativa skötselprogram för varje bestånd!

==Skapa alternativa skötselprogram för varje bestånd==
* '''Under menyn "Action" väljs "Generate Treatment Programs..."'''
Följande dialog visar de resultat som kommer att sparas. Du kan låta alla vara markerade.
* (Vill tyvärr fortfarande krångla, välj följande, för fortsatta analyser nödvändiga resultat;
** "Alternative summary"
** "Data per Species"
** "Financial Value"
** "Forest Data"
** "Forest Domain"
** "Treatments".) Klicka på "Ok" och vänta (det tar några minuter). Processen kan följas längst ner i "Output Window".

==Granska simuleringsresultaten==
* '''Under fliken "Results" (långt till höger) visas alla körningar'''
Högerklicka på den du just gjort och välj "View Treatment Programs".
* '''Tabellen visar åtgärdskoder för valt bestånd (via blädder-pilarna högt upp) under en sekvens av tidsperioder (5-åriga)'''
Varje rad representerar ett alternativt skötselprogram för föreliggande bestånd.
* '''Under menyn "Action" väljs "View Alternative Details..."'''
Välj ett bestånd och ett alternativ som du vill titta närmare på under "Select alternative" och vilka data du vill granska under "Select results".

Spara projektet då och då.

''Beakta särskilt skötselprogrammen för bestånd i de nya skogsdomänerna, t.ex. att inga åtgärder görs vid fri utveckling, att "överhållning" funkat (såtillvida att ev. slutavverkning infaller först vid en relativt hög beståndsålder) eller att det vid "gransanerande gallringar" främst sker ett uttag av granvolymer (före lövvolymer).''

==Optimering==
Handledning för optimeringsverktyget finner du [[Optimization | här]].

Nästa steg består i att med hjälp av optimering välja ut ett skötselprogramalternativ (av de många vi nyss skapade) för varje åtgärdsenhet.
* '''Under menyn "Optimization" väljs "Open Optimization"'''
* '''Välj "Model8b.Hops"'''
Ev. må du söka rätt på den själv, under den delade mappen "SH0085". Här finns nu en ny version, "Model9c.Hops" som är mycket bättre (när den fungerar). För dig som kan din linjärprogrammering och även har kört Lingo eller AIMMS så kanske vissa saker känns bekanta? Man bygger upp sin optimeringsmodell genom att definiera "Sets", "Parameters", "Variables" och "Constraints".

''Förvånad att LP används i Heureka? Som namnet antyder trodde man förvisso först att någon heuristisk metod skulle nyttjas i optimeringarna emedan LP-utvecklingen liksom kommit ikapp och nu är nästan jämsides med utvecklingen av Heureka-applikationerna (!) och häri passar riktigt bra.''

* '''Högerklicka på "Model8b" i fönstret "Model Optimization Builder" och välj "Solve Model"'''
Klicka på "Ok" och vänta några minuter.
* '''Gör en temakarta för variabeln "Treatments" för att se vilka åtgärder som görs i de olika bestånden i olika perioder'''
Tag först fram fliken "Map" (ev. via menyn "View") och välj "Strategic Optimization" i rutan bredvid "Result:" (ev. må du först trycka på "Refresh"-knappen). I fönstret "Map Properties" expanderar du "Treatments" och väljer "Treatment". Högerklicka och välj "Add Items Automatically" så får du upp en dialogruta. Ta bort åtgärder som du inte vill visa (markera och klicka på "Remove"). Spara bara t.ex. "Thin(ning)" och "FinalFelling" och ändra färgerna på dessa. Högerklicka igen på "Treatment" och välj "Show in Map". Högt upp i kartfönstret finns pilar för att bläddra mellan planperioderna.

''Slutavverkas ett och samma bestånd i två på varandra följande tidsperioder? Det kan verka så emedan det eg. är fråga om delavverkning (t.ex. 75% (av beståndets yta) avverkas först, 25% under nästa 5-årsperiod). Sådant kan bli aktuellt om man har relativt få men stora bestånd (och kanske i optimeringen inkluderat ett villkor som begränsar hyggesstorleken, "_limitFinalFelling"). Ett sätt att undvika detta är att för beslutsvariabeln "_x" ändra "RangeType" till binär, alltså accepteras endast värdena 0 eller 1, optimeringen blir då emellertid svårare och kan ta rysligt lång tid.''

==Formulering av optimeringsproblem==
I Heureka har vi gjort ett verktyg för att modellera och lösa LP- och MIP-problem. Som modelleringsspråk tillämpas ZIMPL. ZIMPLs User’s Guide finns på nätet (http://www.zib.de/koch/zimpl/download/zimpl.pdf) men även sparat på datorn, under "SH0085", läs kapitel 4.2 till och med 4.5. Nedan följer sedan ett antal syntax-exempel från PlanVis.

===Kontovariabel som summerar avverkad volym i varje tidsperiod:===
<pre>FORALL IN _periods DO
SUM<i,j,r> IN _treatmentunits * _alternatives * _rowno :
_volumeHarv[i,j,p,r] * _area[i] * _x[i,j] == _volHarvTot[p];</pre>

Definitionen skrivs in direkt i ''variabelns'' definitionsfönster, men är i egentlig mening en ''restriktion''. Restriktionen motsvarar följande matematiska uttryck (restriktion) i en LP-modell:
{|
|[[Image:PlanVis_Tut_Fig5_formula.png|left]]
|}

där:

''I'' = mängden (set) av behandlingsenheter ("Treatment Units")

''J'' = mängden av (index) för tillgängliga skötselprogram

''R'' = mängden åtgärder (åtgärdsnummer) i en och samma period

''areai'' = areal för behandlingsenhet ''i'' (faktisk eller "representativ")

''volumeHarvijpr'' = avverkad volym i enhet ''i'' under period ''p'', givet att skötselprogram ''j'' tillämpas, från åtgärd ''r''

''volHarvTotp'' = summa avverkad volym under period ''p''

''xij'' = beslutsvariabel (binär) = 1 om skötselprogram ''j'' tillämpas för enhet ''i'', annars 0

===Kontovariabel som summerar volym som slutavverkas i varje tidsperiod:===
<pre>FORALL IN _periods DO
SUM<i,j,r> IN _treatmentunits * _alternatives * _rowno with _treatment[i,j,p,r]==8:
_volumeHarv[i,j,p,r] * _area[i] * _x[i,j] == _volHarvFinalFelledTot[p];</pre>

Skillnaden mot föregående uttryck är att efter "rowno" följer ett villkor att summering bara ska göras för slutavverkningsåtgärder (som har koden 8). Notera användningen av dubbla likhetstecken. ''För att visa definitionen av en definierad kontovariabel dubbelklickar du på den.''

===Kontovariabel för arealen slutavverkning i varje tidsperiod:===
Denna variabel är nästan identisk med den föregående, vi tar bara bort parametern "_volumeHarv(i,j,p,r)" från uttrycket.
<pre>FORALL IN _periods DO
SUM<i,j,r> IN _treatmentunits * _alternatives * _rowno with _treatment[i,j,p,r]==8:
_area[i] * _x[i,j] == _areaFinalFelledTot[p];</pre>
''"8" i ovanstående två uttryck är alltså det numeriska värde som motsvarar slutavverkning för parametern "_treatment". Man kan kontrollera dylikt genom att högerklicka på parametern och välja "View definition" (testa detta även för "_forestDomain" och "_trmtCategory", särskilt bra om man skapat flera nya skogsdomäner med viss sorts skötsel definierat i kontrollkategorierna).''

===Restriktion som begränsar hur stor areal som får slutavverkas i varje tidsperiod:===
<pre>FORALL IN _periods DO
_areaFinalFelledTot[p] <= 20;</pre>

Vi använder alltså den kontovariabel för slutavverkningsareal som vi skapade ovan, och lägger in restriktionen (eg. restriktionerna) att den slutavverkade arealen får vara högst 20 hektar i en och samma period. ''Om du vill inaktivera en restriktion utan att ta bort så högerklicka och välj "Exclude".''

===Lägga till ny parameter===
"Sets" och "Parameters" utgör indata till optimeringsmodellen. En parameter får sitt värde antingen genom att koppla den till resultatdata som har beräknats av skötselprogramgeneratorn eller genom att ge den en matematisk definition. ''Blanda inte ihop "variabler" som beräknas av skötselprogramgeneratorn med "beslutsvariabler" i optimeringsmodellen. För modellen är alla variabler som beräknas utanför den konstanter (dvs. element i ett "Set" eller i en "Parameter").''

Så här gör man för att skapa en ny parameter och koppla den till resultatdata:
* Högerklicka på "Parameters" och välj "Add new parameter"
Har du gått vilse bland alla fönster så under menyn "View" väljs "Model Optimization Builder".
* Låt "Heureka result variable" vara valt och klicka på "Next"
Vi ska alltså i detta läge inte skriva en ny formel, utan koppla parametern direkt till en kolumn i databasen där skötselprogramalternativen har sparats.
* Välj t.ex. "TreatmentControlCategory" under noden "Forest Domain"
* Byt parameternamnet till något bättre.
Den nya hamnar längst ner bland alla "Parameters". Ett bättre namn är ett som indikerar vad det handlar om, i rutan "Properties" och bredvid "Description" kan en ännu fylligare förklaring skrivas in.

Notera att systemet själv håller reda på indexeringen. I detta fall har vi en skötselkategori för varje behandlingsenhet, skötselprogramalternativ och period. Att vi har med period beror på att skötselkategorin kan vara olika före och efter slutavverkning (vi går inte in på detta mer i denna övning).

===Lägga till ny restriktion===
* Högerklicka på "Constraints" och välj "Add new constraint"
* Klicka på den restriktion som har skapats.
I rutan "Properties" för restriktionen väljer du "Click to add index", lägger till och väljer "_Periods[p]" för att skapa en restriktion för varje tidsperiod.

===Exempelfiler===
Dessa optimeringsfiler kan du ladda ner och öppna via meny "Optimization" > "Open optimization":
*[https://www.heurekaslu.se/filerepository/Optimization/Model9c.Hops Model9c.Hops]
Nya och andra komponenter kommer att göras tillgängliga på denna ftp-server (https://www.heurekaslu.se/filerepository/Optimization/), t.ex. skript ("SQL queries") att använda (som mall - skriv om för att få ut det du vill ha) för rapporter från resultat-databasen. Detta avser både när man vill närmre studera initialtillståndet men kanske främst planen - simulerings- och optimeringsresultatet.

''Förbättrad funktionalitet under "View" > "Optimization Result Viewer" och möjligheten att här välja en simulering/optimering och sedan skapa egna diagram (under "Diagrams" > "User defined") för att beakta resultaten gör ev. SQL queries överflödiga.''

==Tillämpade övningar==
===Kostnad för naturvårdshänsyn===
Skapa skogsdomäner för alla målklasserna:

NO = naturvårdsmål där skogen lämnas orörd

NS = naturvårdsmål med naturvårdande skötsel

PF = produktionsmål med förstärkt hänsyn (till natur- och kulturvärden)

PG = produktionsmål med generell hänsyn (till natur- och kulturvärden)

Skapa sedan lämpliga skötselkategorier för dessa och kör om "Generate Treatment Programs". Tag också fram ett scenario där ingen hänsyn tas. Tag reda på vad kostnaden (i form av minskat nuvärde) blir för att tillämpa målklassningen, jämfört med ett uteslutande produktionsinriktat skogsbruk.

Denna övning kan nog upplevas konstlad för de åtta bestånden i "Landscape8", kanske inte alla olika målklasser finns representerade i beståndsregistret etc. Mer realistiskt blir det med ett större skogsinnehav, t.ex. Östad som vi kanske istället kan använda här.

===Eget problem===
Lös något problem som du finner intressant, t.ex. maximera rekreationsindex eller se vad som händer med högre (eller lägre) virkespriser.
===Projekt Östad med Heureka===
Själva övningen finns på kursens hemsida (http://slunik.slu.se/kursfiler/SH0085/40032.0809/Heureka_Ovningsinstruktion.pdf).

För att lösa uppgifterna häri kommer man långt med skogsdomänerna och inställningar i tillhörande kontrolltabeller. I en del fall må man dock in i optimeringsmodellen och definiera nya variabler och restriktioner (befintliga parametrar kan nog räcka). Att skriva egen syntax med Heurekas modelleringsspråk är det roligaste som finns. När det går bra (dvs. när syntaxen accepteras, modellen kan kompileras och lösas och man erhåller relevanta resultat). När det går dåligt är det förstås inte fullt lika roligt. Här lite tips:
* Du kommer kanske misslyckas några gånger,
se därför till att göra försöken på ett begränsat material; stratadatat (dvs. de 230 stickprovsavdelningarna) och 10 perioder så behöver man inte vänta länge på ev. felmeddelande.
* Snegla på (och kopiera) befintliga, liknande variabler
och ändra i syntaxen så det stämmer med dina syften.
* För jämnhetsvariabeln ''s'' (eller vad du nu valt att kalla den) är variabeln ''_volHarvTot'' troligen av vikt.
Tänk dock här på indexeringen; t.ex. är perioden ''p-1'' odefinierad när man är i den första perioden.
* Vilka värden kan variabeln ''s'' förväntas anta?
Om negativa värden kan förväntas så må det vara definierat i "Properties" > "RangeType" (förslagsvis "All").
* Börja med någonting enkelt, t.ex. att virkesförrådet efter avverkning vid sista perioden inte ska understiga 140 m3sk/ha;
** Skapa en variabel som är kvoten av totalvolymen (i varje period, efter att periodens åtgärder/avverkningar genomförts) och analysområdets totala skogsmarksareal
** Högerklicka på "Variables" och välj "Add new variable"
** Ändra namnet till t.ex. "_volMean"
** Lägg till perioder som index ("Properties" > "Sets")
** Skriv den ekvation som tilldelar ett värde på ''_volMean[p]'', typ;
<pre>FORALL IN _periods DO
(_volTot[p] - _volHarvTot[p]) / 3567 == _volMean[p];</pre>
3567 ha är alltså den totala arealen (t.ex. via "Action" > "Forest Data Overview..."). På detta sätt kan man i "Output Window" se vad virkesförrådet är i samtliga perioder (inte bara i sista). Använd sen den nya variabeln i en restriktion, gör på motsvarande sätt för "Constraints" och skriv typ;
<pre>FORALL IN _periods WITH p >= 9 DO
_volMean[p] >= 140;</pre>
Här säkerställs alltså att förrådet inte understiger 140 m3sk/ha i sista perioden (lätt att justera ifall man vill att restriktionen ska gälla i flera perioder).

För variabeln (och restriktionen och slutligen målfunktionen) ''s'' blir det förstås lite knöligare. Man kan förmodligen göra på många olika sätt men här är några, mer eller mindre, pedagogiska exempel:
* Se till att skapa en ny variabel typ ''_totNPV'' och här kopiera in målfunktionen från ''_objFunc'' (så denna kan definieras som något annat än för nuvärdesmaximering, t.ex. "jämnhetsmaximering" eller åtminstone "minimering av avtagande avverkade volymer"). På köpet får du då alltid en utskrift av analysområdets totala nuvärde (i SEK, i "Output Window"), även när målfunktionen ges en annan definition.
* Det går alldeles utmärkt att definiera en variabel bara genom att ge den ett namn (och ev. i "Properties", under "Constraints" se till att "Range Type" är "All", om variabeln kan anta både positiva och negativa värden). Syntaxen, det matematiska uttrycket, som tilldelar variabeln sitt värde kan istället definieras i en restriktion. Vi börjar dock med ett exempel med en variabel med syntax, ''_harvDiff:''
<pre>FORALL IN _periods WITH p >= 1 DO
_volHarvTot[p-1] - _volHarvTot[p] == _harvDiff[p] ;</pre>
Du ser väl vad den beräknar? Lite opedagogiskt, men av stor vikt i fortsatt joxande, erhåller här en stigande avverkningsnivå ett negativt värde och vice versa, komihåg detta. Sen definierar vi en variabel utan syntax, ''_harvDiffMax''. Den erhåller istället sitt värde via den syntax som anges i restriktionen ''_minDiff:''
<pre>FORALL IN _periods WITH p >= 1 DO
_harvDiff[p] <= _harvDiffMax ;</pre>
Nu blev det kanske inte lika lätt att se vad som beräknas..? Så här kan man tänka; restriktionen - att detta villkor alltid uppfylls (här i alla perioder utom i den första - period 0) är endast fallet om ''_harvDiffMax'' är det största värdet av alla förekommande värden på ''_harvDiff''. Och restriktioner må ju uppfyllas om optimeringsproblemet ska erhålla en lösning. Kolla i ovanstående delar om du glömt vad ''_harvDiff'' var för något (och vad som avses med "störst" i sammanhanget).

Sen på tur står tillskapandet av två variabler, ''Z1'' respektive ''Z2'', som ska ingå i en målfunktion med två, sinsemellan viktade mål enligt modellen: 0.x * ''Z1'' - (1 - 0.x) * ''Z2'' (som ska maximeras eller minimeras? och varför är det ett minustecken mellan de två delmålen? borde de inte adderas?). De två målen är här lämpligen "maximerat nuvärde" respektive "jämnhet". Innan de två variablerna tillämpas i en och samma målfunktion må de relativiseras (endast kunna erhålla värden mellan 0 och 1) och samtidigt göras enhetslösa (de ska ju inte spela någon roll om de mäts i EURO, SEK, m3sk eller nånting annat) enligt modellen: ''Z1'' = relNPV = (''_totNPV'' - NPVmin) / (NPVmax - NPVmin). När du sedan ska definiera ''Z2'' gör du på motsvarande sätt och är särdeles observant på + och -.

Ovanstående finns implementerat i [https://www.heurekaslu.se/filerepository/Optimization/Model9d.Hops Model9d.Hops], redo att laddas ner från ftp-servern och laddas upp i PlanVis. Sen är det rekommendabelt att du fortsätter använda din egen modell (den modifierade Model9c) för att lösa ditt optimeringsproblem, men med möjlighet att jämföra (och ev. kopiera) definitioner och formuleringar som finns i 9d. Namngivningen av variabler och restriktioner skiljer sig säkert mycket åt, kanske även definitioner och beräkningssätt. Som en kommentar till ovanstående frågor tittar vi lite närmre på målfunktionen ''_objFunc:''
<pre>0.5 *_NPVgoal - 0.5 * _harvDiffgoal ;</pre>
Under "Properties" > "ModelDirection" ser vi att denna funktion ska maximeras. Detta är uppenbart för nuvärdet ''men inte för den avtagande avverkningsnivån''. Som vi tidigare definierat denna variabel så vill vi minimera sänkningen från en period till nästa (komihåg att det är ett positivt värde - en ökning erhåller ett negativt värde och utan begränsning uppåt (utan ett "komplett" jämnhetsvillkor) kan vi lugnt minimera en sådan målfunktion). Därför subtraherar vi de två viktade delmålen, tidigare i kursen adderade ni nog de två för då skulle båda maximeras (t.ex. nuvärde och "renbetesmarker"). För övrigt valde jag inte ovanstående 50/50-viktning som referensmodell, 25/75 blev istället så här tjusigt:
{|
|[[Image:PlanVis_Tut_Fig6.png|500px|thumb|left|Figur 6]]
|}
Visst förlorades en del i nuvärde (här, med 3% kalkylränta, 115 milj. SEK, i föregående fall 143 milj. SEK) men å andra sidan är nog kassaflödet ungefär detsamma vid de båda fallen. Totala uttagsmängden, summerat över hela planperioden: 1.21 milj. m3sk, var här något lägre än i föregående fall så kanske kan man säga allt en del av det "förlorade nuvärdet" finns kvar i skogen (som ett något större, kvarstående virkesförråd), medelförrådet vid planperiodens slut: 157 m3sk/ha. Jag skyller detta resonemang helt och hållet på Ola Lindgren (vars intressanta föreläsningsmaterial också finns på kurshemsidan; http://slunik.slu.se/kursfiler/SH0085/40032.0809/Ola_Lindgren_Del1_09.pdf samt http://slunik.slu.se/kursfiler/SH0085/40032.0809/Ola_Lindgren_Del3_09.pdf). Lägg märke till uppdelningen av volymen från slutavverkning och från gallring. Det är förvisso relativt stor skillnad mellan första och sista perioden map. andelen från gallring men utan kraftiga fluktuationer under planperioden (något som skogsindustrin säkert skulle ogillat). Vi låter detta vara en överkursuppgift (att försöka få jämnhet även map. sortiment; sågtimmer-massaved-skogsbränsle).

====Känslighetsanalyser, stratadata====
Olika uppgifter ska här lösas för respektive grupp. Samtliga grupper kan dock vänta med indelning i skogsdomäner, detta moment lämpar sig bättre vid heltäckande data. Använd istället kontrolltabeller för att generera skötselprogram i linje med er uppgift och/eller modifiera optimeringsmodellen. Man kanske vill begränsa gallringarna och kan då införa restriktionen ''_maxThinnProp:''
<pre>FORALL IN _periods DO
_thinnVol[p] <= _volHarvTot[p] * 0.3 ;</pre>
Detta har förstås föregåtts av definering av variabeln ''_thinnVol[p]'' (som i varje period beräknar differensen mellan totala volymen som avverkats och volymen som avverkats i slutavverkning). Restriktionen begränsar gallringsandelen (av volymen) till max 30% i varje period. T.ex. för att undvika de plötsligt höga andelarna i de två sista perioderna, figur 6b. Vill man införa en lägstanivå, t.ex. minst 10% gallringsvolym i varje period, rekommenderas att detta görs i en egen restriktion (istället för att försöka få med båda gränsvärdena i en och samma). ''Observera att vår optimeringsmodell bygger på linjärprogrammering och alla modeller må vara linjära - "_volHarvTot" kan då inte vara nämnare i division med täljaren "_thinnVol" (på andra sidan <=) utan multipliceras upp (på båda sidor (o)likhetstecknet).''

Om denna restriktion infördes med hänsyn till skogsindustrins önskemål om jämnhet över tiden med avseende på sortimentsutfall, ja då är ju ovanstående "gallringsandel" endast en approximation under antagande om stora mängder massaved vid gallringar (och små vid slutavverkningar). Om vi istället vill titta på andelen massaved så får vi börja med att lägga till denna parameter; högerklicka på "Parameters" och välj "Add new parameter...", ge den ett lämpligt namn (t.ex. ''_pulpVolume'') och välj "Heureka result variable". Sen är det bara att söka rätt på denna, under noden "Financial Value" finns "PulpVolumeTotal" (observera att "Total" här avser alla trädslag), välj och klicka "Finish". Observera samtidigt att här finns mycket data att välja bland men endast de som valts att följa med vid skötselprogramsgenereringen kan vi använda i optimeringsmodellens variabler, restriktioner och målfunktioner. För att beräkna den mer relevanta massavedsandelen skapas en ny variabel, t.ex. ''_volHarvPulpTot:''
<pre>FORALL IN _periods DO
SUM<i,j,r> IN _treatmentunits * _alternatives * _rowno WITH _altIncluded[i,j] >= 1:
_pulpVolume[i,j,p,r] * _area[i] * _x[i,j] * 1.2 == _volHarvPulpTot[p];</pre>
Här summeras alltså avverkad volym massaved i varje period, gånger faktorn 1.2 då den är i m3fub och vi vill förmodligen jämföra med befintliga variabeln ''_volHarvTot'' (i m3sk, se denna schablon som en snabb problemlösning för att komma vidare - givetvis finns i systemet, ända ner på enskilda träd-nivån, alla förekommande sortiments volymer angivna i rätt enhet). Variabeln ''_altIncluded'' kollas vara "1" (så summeringen endast görs för de alternativa skötselprogrammen (med index ''j'') som simulerats i resp. bestånd (med index ''i'')). Man kan dock ana något fel i syntaxen (eller i hela tänket...), se tabell 1; i kolumnen "Gallringsandel" ser vi att restriktionen max 30% funkade och kapade gallringstopparna i de två sista perioderna (se även figur 6b) och dessutom fyllde luckan i period sju, bra, men visst ser värdena i kolumnen "Timmerandel" alltför låga ut? I perioder när mer än 90% av avverkade volymer kommer från slutavverkning borde väl timmerandelen vara avsevärt högre?
{|
|[[Image:PlanVis_Tut_Fig7.png|1000px|thumb|left|Tabell 1]]
|}

====Känslighetsanalyser, heltäckande data====
För att undvika långa väntetider och överbelastning av systemet så analyseras endast Östads skifte ett ("Map ID = 1"). Dessutom minskar vi planperioden till 50 år. Då bör man erhålla ett initialtillstånd för 924 bestånd motsvarande 2332 ha skogsmark (= representativ areal) med bl.a. ett medelförråd = 167 m3sk/ha och en medelålder = 44.5 år. Skogen här avviker alltså avsevärt från den i stickprovsavdelningarna (stratadatat) varför en ny referenslösning nog bör tas fram, för att kunna jämföra med vid respektive grupps uppgifts resultat. ''Komihåg att välja er kalkylränta innan TPGn körs!''

''Dessutom verkar ett av bestånden ställa till med mycket oreda; välj bort nr. 1228 ur analysområdet (som då ska bestå av 923 bestånd motsvarande 2331 ha), en medelålders NO-skog med 0 m3sk/ha som, trots att den lämnas utan åtgärder till fri utveckling, lyckas föra in två till perioder och förlänga planeringshorisonten med tio år (och här då många gånger föra in odefinierade variabler och orimliga värden).''

Granska referenslösningen innan ni går vidare (är en jämnhetsrestriktion berättigad? borde ett lägsta utgående förråd sättas? etc.) och välj lämplig optimeringsmodell.

Uppgifterna bör sedan kunna lösas främst med indelning av analysområdet i skogsdomäner. Varje domän tilldelas sedan specifika förutsättningar via kontrolltabellerna. Det är givetvis helt ok ifall man även vill införa nya restriktioner (eller ytterligare delmål i målfunktionen) i optimeringsmodellen. Vi har ju redan nu upptäckt en brist i TPG-kontrollkategorin "ManagementSystem" där "Continuous" inte ger upphov till något nuvärde (trots att en eller flera åtgärder av typen "Selective felling" gjorts i skötselprogrammet under planperioden. Enligt uppgift ska dock volymer och kassaflöden(?) från dessa åtgärder vara medräknade).

Övningen nämner momentet "zona in lämpliga områden" och det är kanske mest lämpligt att göra i ett GIS. GIS-delen i PlanVis är dock ännu inte fullt utbyggd. Iofs. kan du titta på analysområdet i ArcMap och nyttja dina GIT-kunskaper och kanske buffra runt sjöar och vattendrag eller beakta överlappande teman som älgpass och beståndsindelning. Vill vi ha med oss sådana uppgifter må de vara med redan vid dataimporten i PlanStart och det hinns tyvärr inte. Den GIS-zoning som hinns är isåfall att du noterar intressanta bestånd (deras ID-nummer) och låter dessa utgöra ett eget skogsdomän (tillvägagångssätt beskrivs ovan). Nu kan man lika bra zona in med hjälp av befintliga beståndsparametrar, enklast med målklasserna men heller inte särskilt krångligt med kombinationer av trädslag, ålder, etc. (tillvägagångssätt beskrivs ovan). ''Komihåg att kolla så tillräckligt många bestånd hamnade i tillskapat domän, så fortsatt särbehandling av dessa kan förväntas ha genomslag i resultaten!''

Vill du i kartan se vilka bestånd som hamnade i vilka domäner väljer du under "Map Properties" > "Forest Domain" > "ForestDomain" med högerklick att först ta bort gammalt ("Remove all subitems") och sen lägga till nytt; "Add items automatically". Fortfarande bara det gamla? Se till att senaste körningen valts i rutan "Result:" (uppdatera först) och gör om.

''Som uppgift valde jag att försöka ta fram en miljö- och rekreationsanpassad plan; höga naturvärden finns idag främst representerat på "Djurgården", halvön strax öster om Östads gård. Djurgården är samtidigt ett populärt strövområde, för Alingsåsare likväl som för Göteborgare. NO-bestånden lämnas orörda (för fri utveckling) inom hela analysområdet emedan deras skydd förstärks på Djurgården. Det förstärkta skyddet här avses även öka områdets rekreationsvärden och uppnås genom överhållning och "gransanerande" gallringar i särskilda bestånd. De särskilda bestånden ligger i anslutning till Djurgårdens NO-bestånd och/eller har, vid planperiodens början, relativt hög andel gran. Observera att detta bara är ett exempel på möjligheterna i PlanVis men med relativt litet genomslag i föreliggande planeringsresultat; endast 77 st. NO-bestånd sköts med "Fri utveckling" och endast 18 st. bestånd sköts "NV-anpassat". Detta exempel sänkte nuvärdet endast med 3.3% (till 58600 SEK/ha vid 4% kalkylränta). Figur 7 visar förekommande skogsdomäner på Djurgården.''
{|
|[[Image:PlanVis_Tut_Fig7_Map.png|500px|thumb|left|Figur 7]]
|}
''Komihåg att kolla så skötselprogram genererats såsom du ville, särskilt för bestånden i dina nya skogsdomäner!''