SH0130 2012

Lite snabbhjälp för dig som går kursen "Skoglig planering ur ett företagsperspektiv" höstterminen 2012. OBS: Vidareutvecklingen av Heureka går i en sån rasande hög fart att författaren till nedanstående text inte hunnit med i allt. Var förberedda på att vissa delar av informationen är inaktuell. Viktigaste förändringen för Er del är de nya hjälp-sidorna här - bokmärk och börja Er informationssökning här (för att sen, om det behövs, fortsätta söka på Heurekas wiki-sidor).

Systemöversikt

Heurekasystemet består av en serie fritt tillgängliga programvaror ("applikationer") för skoglig planering och analys. Systemet har utformats för att kunna räkna på flera av skogens alla värden. Visionen är att Heurekasystemet ska kunna bidra till ett både lönsammare och miljövänligare skogsbruk. De nyttor och värden som idag kan hanteras av systemet är virkesproduktion, rekreationsvärden, naturvärden och kolinlagring. Genom att dessa aspekter integreras i ett och samma system kan ett helhetsgrepp tas om planeringsproblematiken.

Systemet omfattar hela analyskedjan, från skoglig inventering av provytor, via prognosmodeller och optimering, till verktyg för att rangordna alternativ. Programvarorna är avsedda både för små- och storskogsbruket och omfattar de applikationer som syns i figur 1. De tre centrala applikationerna, som avser den geografiska nivån i analyserna (eller vad som är analysobjektet i fråga), är:

StandWise: För beståndvisa analyser, med 2D- och 3D-visualisering. En interaktiv simulator där användaren anger vilka åtgärder som ska göras och periodvis stegar sig fram (eller bak, och testar någonting annat).
PlanWise: För mer avancerad skogsbruksplanering, landskapsplanering och avverkningsberäkningar för små eller stora innehav både på kort och lång sikt. Applikationen möjliggör optimering av skogsbruket.
RegWise: För konsekvensanalyser på regional och nationell nivå.

Figur 1

Systemets kärna är gemensam för alla applikationer och består av alla de modeller som behövs för att återge en såpass realistisk utveckling av skogen som möjligt. Det rör sig, som ni säkert förstår, om flera hundra modeller. De viktigaste är de som prognosticerar skogens tillstånd, med tillväxtmodeller men även t.ex. inväxnings- och avgångsmodeller. Simuleringen av olika skogliga åtgärder (t.ex. slutavverkning, gallring, blädning, gödsling, röjning och plantering) är nära nog lika viktigt. Utfallet av nyttigheter, i morgon eller om flera hundra år, beror sedan främst på tillståndet i den framtida skogen (figur 2).

Figur 2

För att med tillräcklig precision kunna uttala sig om skogens framtida tillstånd krävs att tillväxten skattas med enskilda träd-modeller. Indatat om skogen må således vara högupplöst. Men att insamla uppgift om vartenda träd i hela den skog som ska analyseras faller på sin orimlighet. Därför förlitar man sig på stickprovsteorin och låter ett antal provytor (av viss storlek, med ett visst antal träd) per bestånd få representera skogsbestånden (figur 3). Dessa enskilda träd-uppgifter kan insamlas via fältinventering eller så kan de imputeras eller simuleras.

Figur 3

Indatat, beskrivningen av det initiala tillståndet hos den skog som avses analyseras, ska finnas i en s.k. skogsdatabas ("Forest Database"). Resultaten hamnar, föga förvånande, i en s.k. resultatdatabas ("Result Database") (figur 4). Vad som kan vara lite förvånande -eller åtminstone bra att veta- är att även intermediära resultat/alla de olika skötselprogramalternativen hamnar i resultatdatabasen. Med många behandlingsenheter, långa planeringshorisonter och mycket data som ska med i alla prognoser kan resultatdatabasen bli förhållandevis stor, förhållandevis snabbt (särskilt om du hela tiden gör fel och gör om, utan att du städar bort felaktigheter). För att verkligen kunna dela resultat med varandra bör man ha samma projektinställningar. Att vara säker på den saken kan vara svårt, men underlättas om man delar med sig av projektet genom att komprimera projektmappen och dess innehåll och låta kompisen paketera upp och öppna projektet i sin applikation.

Figur 4

Om PlanWise

PlanWise är ett datorprogram för att göra strategiska och taktiska planeringsanalyser och därifrån upprätta skogliga åtgärdsplaner. 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 PlanWise integreras indata, generering av alternativa aktiviteter, optimering och resultatredovisning. Det senare görs i form av tabeller, diagram och kartor. Med generering av alternativa aktiviteter menas att PlanWise 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 domäner och skapa olika skötselinstruktioner för dessa.

Innan du fortsätter, läs användarmanualen som finns på sidan User's guide to PlanWise.

Installationsanvisningar

Här är direktlänken (du behöver inte registrera dig): [[1]].

Om du ska köra på din egen PC måste du installera SQL Server Express (version 2005 eller 2008), se anvisningar här.

Språkinställning

Via "Tools" > "Customize" > "Language" kan du ändra till en version som är halvvägs, halvbra översatt till svenska!

Skapa projekt

Det första man gör när man har startat PlanWise är att öppna ett befintligt eller skapa ett nytt projekt. Projektet innehåller användarinställningar och datasbaskopplingar. Se även Skapa nytt projekt.

Figur 5

Figur 5 visar konfigurationen, men observera att det är fel server- och databasnamn! "Windows Authentication" innebär att du loggar in i databasen med samma uppgifter som i Windows. Om du arbetar i datasalen har du tillgång till en särskild server med färdiginstallerade databaser:

Servernamn: SQL1-1.SLU.SE\ALLA
Databas: Indata_SH0130_2012_1

Om du använder en egen PC anger du servernamn = LOCALHOST\SQLEXPRESS (eller bara .\SQLEXPRESS). Du måste i så fall först installera databasen med hjälp av SQL Server Management Studio. Hämta .bak-filen för indatabasen här.

Du ska också ange en resultatdatabas (utdatabas) på motsvarande sätt som för skogsdatabasen (indatabasen). Om du arbetar i datasalen anger du samma servernamn men en annan databas:

Servernamn: SQL1-1.SLU.SE\ALLA
Databas: Utdata_SH0130_2012_X

Det finns fyra kopior av resultatdatabasen där ni får försöka sprida ut er så gott det går - om flera användare jobbar mot en och samma resultatdatabas samtidigt kan det bli långa svarstider då man "köas".

Om du använder en egen PC skriver du bara in ett önskat namn på resultatdatabasen - programmet skapar sedan databasen när den behövs:

Servernamn: LOCALHOST\SQLEXPRESS
Databas: MinaHeurekaResultat (eller något annat, men inga mellanslag och inga å, ä eller ö!)

Observera att programvaran för PlanWise alltid måste vara lokalt installerad på den PC som används emedan datat kan finnas antingen centralt eller lokalt. Vill man ha data lokalt måste man alltså programvara installerat för dylik databashantering, t.ex. Microsofts SQL Server Express. Ett annat litet observandum är att Heureka tolkar LOCALHOST som din lokala PC emedan SQL Server (och Management Studio, där man kopplar upp sig mot fjärrserver eller "lokal server") vill att du istället anger din PCs datornamn (som du hittar under Systemegenskaper).

Analysmoment 1: Indata

Importera data

Detta är redan ordnat för kursen, men du kan läsa om hur man importerar data här. �?ven här står lite mer om indataimport, såpass att du kan bilda dig en uppfattning om att det är en del uppgifter om skogen som behövs. Det stratabaserade datasetet har uppkommit via tidigare studenters fältdatainsamlingar på �?stad, gjorda enligt Indelningspaketets inventeringsmetod, inte helt olik Ivents. Det heltäckande datasetet baseras på det beståndsregister som finns på �?stad, den skogsbruksplan förvaltaren och Skogssällskapet använder i daglig drift, varifrån enskilda träd-uppgifter simulerats av Heurekasystemet. Då "vinner" man alltså en heltäckande bild av analysområdet, och kan då t.ex. ta rumslig hänsyn, men ser du vad man riskrar förlora vid ett sådant förfarande? Har du i tidigare kurs upprättat en skogsbruksplan kanske du kan ana riskerna, särskilt vid långsiktiga prognoser och mer avancerade planeringsanalyser (t.ex. av en viss skoglig åtgärd, borde vi övergå till mer låggallring? vilken gödslingsregim borde vi använda? hur kan vi gynna löv?).

Inspektera indata

Genom att noggrannt inspektera analysområdets initialtillstånd kan man bättre förstå förutsättningarna för de förestående analyserna. Det kan vara en idé att kopiera ett antal uppgifter för alla bestånd (under "Details", du väljer vilka variabler du vill beakta under "Select Columns for Detailed View") till Excel och där fortsätta inspektionen. �?ven kartan kan ge bra information, se figur 6, här finns alltså bestånd med för en norrlänning anmärkningsvärt höga förråd, eller vad säger du (som gjort skogsbruksplan kring Umeå)?

Figur 6

Analysmoment 2: Skapa skötselprogramalternativ

Skapa domäner (dela in skogen i skötselgrupper)

Den översta nivån i en förestående analys är analysområdet ("Analysis Area") som innehåller alla bestånd - behandlingsenheter ("Treatment Units") som ska analyseras. Nästa nivå utgörs av skogsdomänerna ("Forest Domains"). En skogsdomän är en grupp av bestånd som uppfyller ett eller flera villkor. Villkoren ställs utifrån beståndens initialtillstå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 "växa in" i en annan domän än den initiala under pågående planperiod).

I början av en analys indelas varje bestånd i 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 (högerklicka och välj "Move up"). 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 sedan 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 en ny skogsdomän högerklickar man på listen till "Other"-domänet och väljer "Add forest domain...". I den följande dialogrutan anges de villkor man ställer för att ett bestånd ska tillhöra den nya domänen, se figur 7. Exempelvis kan man skapa en domän som heter "�?ldre skiktad granskog" och ange villkoren som gäller för att ett bestånd 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. Målklassanpassat skogsbruk är nog det tydligaste exemplet på varför man domänindelar och sen för vissa domäner simulerar en särskild skötsel; NO-bestånden ska normalt skötas med "icke-skötsel" (dvs. lämnas till fri utveckling).

Figur 7

OBS: Det råder ett OCH-förhållande mellan raderna, och ett bestånd har t.ex. sällan båda målklasserna NO OCH NS samtidigt. Om du vill att både NO- och NS-bestånden ska tillhöra samma skogsdomän (alltså ett ELLER-förhållande), välj då "Select multiple..." under "Expression".

Repetition:

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"

Vill du kolla hur många bestånd som hamnade i skapat skogsdomän högerklickar du i domänet och väljer "Evaluate forest domains" alt. "View treatment unit assignment...". Hamnade inga här får du kanske gå tillbaka och ändra kriterierna, "Edit conditions...".

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.

Vid importen av beståndsregistret kan man med fördel ta med annan viktig information via "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ötselinstruktioner, kunna tillämpas.

Skapa kontrollkategorier (specificera skötselinstruktioner)

Till att börja med kan påpekas att det för närvarande finns en "Default Domain Settings" som innehåller en kontrolltabell "Nature Conservation". Med hjälp av denna kan användaren simulera en generell hänsyn som avses tas, i praktiken oftast i samband med slutavverkning. Antingen nyttjas befintlig uppgift om "NCArea", dvs. antal hektar av beståndets produktiva skogsmarksareal, eller så slumpas sådan areal fram, t.ex. som 5% av hela analysområdets produktiva skogsmarksareal eller som 5% av beståndets d:o. Denna "NC-del" lämnas sedan till fri utveckling. Via "Tree Retention" kan här även simuleras lämnandet av s.k. naturvårdsträd (eller "evighetsträd", som sällan får stå i evighet, användaren kan ange när dessa träd antas vara nerblåsta - något tillvaratagande av dessa träd simuleras ej utan de får då bli del av den liggande, döda veden).

Fortsättningsvis fokuserar vi på den kontrollkategori som håller alla andra kontrolltabeller, den som kallas "Default Control Category". Under default-kategorin finns alla kontrolltabeller med alla de grundinställningar som krävs för att kunna göra en analys - eller iallafall för att kunna generera skötselprogram. Alla utom en; prislistan måste användaren själv lägga till - högerklicka på "Default Control Category" och välj "Add pricelist...". Lägg märke till att kalkylräntan anges i denna kontrolltabell.

Användaren skapar egna kontrollkategorier och till dessa lägger till de kontrolltabeller som avses editeras. Man behöver alltså bara lägga till de tabeller som man avser ändra i - om man annars nöjer sig med grundinställningarna så läser systemet dessa från default-kontrollkategorin om de inte finns i den användardefinierade kategorin.

Nedan följer en genomgång för att skapa en ny kontrollkategori, kallad "Overhallning o nat for" då den avser att överhålla skogen och använda naturlig föryngring, som ett led i naturvårdsanpassningen av skogsbruket (eller iallafall simuleringen av en sådan anpassning). Vi specificerar dylika skötselinstruktioner i två kontrolltabeller; "Treatment Program Generator" och "Treatment Model". Alla kontrolltabeller, med alla möjligheter till användarkontrollering, finns beskrivna här.

Höger-klicka i kontrollkategorifönstret och välj "Add control category>New control category"

Denna kategori hamnar nederst i trädet, ge den ett bättre namn, t.ex. "Overhallning o nat for", se figur 8.

Höger-klicka "Overhallning o nat for" och välj "Edit control tables>Add..."

Lägg till de två kontrolltabeller som avses editeras; "Treatment Program Generator" och "Treatment Model".

Först editeras i "Treatment Model" så att det självföryngras...

Tabellens grundinställningar syns i "Properties"-fönstret när den är vald. �?ndra dels vid "Regeneration Settings", klicka på "..."-knappen och ändra för samtliga ståndorter till "Regeneration Code>SeedTrees", dels vid "Type of Final Felling" till "SeedTree". En hjälptext syns för vald kontrollparameter, längst ner i "Properties"-fönstret.

Sedan editeras i "Treatment Program Generator" så skogen överhålls...

Välj tabellen och ändra i "Properties"-fönstret, framförallt vid "Final Felling Period Min" - här säkerställs att för de skötselprogram som genereras så simuleras slutavverkning först vid en tidpunkt ett antal 5-årsperioder efter LS�?. LS�? = lägsta tillåtna slutavverkningsålder enligt SVL används alltså som en referenspunkt som man förhåller sig till när skötselprogrammen spänns upp. Den är som du säkert vet läns- och ståndortsberoende. �?ndra även "Final Felling Period Max" och "Max Number of Thinnings" (så att gallring testas under tiden som bestånden överhålls). �?ndringar av en kontrollparameters default-värde syns i fet stil.

Figur 8

De två andra användardefinierade kontrollkategorierna "Fri utveckling" respektive "Kontinuitetsskogsbruk" kan du säkert fixa själv. Här är det så väl förberett att dessa skötselsystem redan finns definierade, som komplement till systemet "trakthyggesbruk" (eng: even-aged).

Koppla kontrollkategorier med skogsdomäner

Detta steg är i sin grundform enkelt, gör bara såhär:

Höger-klicka det skogsdomän, här "PF-skogar", till vilken det ska kopplas en användardefinierad kontrollkategori, här "Overhallning o nat for"

Välj "Edit control category connection...>Add..." och markera kontrollkategorin och tryck "Ok".

Du såg kanske att man kan testa att tillämpa en kontrollkategori/skötselform för den innevarande skogen (Generation 1) och en annan skötselform för kommande generationers skogar (Gen 2, som kommer att upprepa sig in i oändligheten, dvs. även gälla för Gen 3, 4,... , �??). Det kan vara intressant om man tänker sig någon form av framtida förändring av skogsskötselinriktningen som man vill analysera, t.ex. en omläggning som gynnar skogsbränslesortimentet (som man kanske tror ska bli mer efterfrågat och p.s.s. betinga ett högre pris). Men om man vill förenkla analysen och man redan vet att t.ex. PF-skogar ska skötas med ett trakthyggesbruk med naturlig föryngring och där det sker en viss överhållning så ta bort kopplingen till "Default Control Category":

Under domänet PF-skogar, höger-klicka "Default Control Category" och välj "Delete control category connection"

Det som händer nu är att till de bestånd som faller under detta domän skapas bara en uppsättning skötselprogram, enligt den användardefinierade kontrollkategorin, här "Overhallning o nat for". Man förlorar förvisso möjligheten att utvärdera kostnaden för detta skötselsystem, i förhållande till ordinarie trakthyggesbruk (med sannolikt kortare omloppstider och med plantering som föryngringsmetod), men det kanske man redan har resultat för, från en första referensanalys? Om man väljer att skapa flera olika sorters skötselprogramuppsättningar finns möjligheten att i optimeringsmodellen införa en restriktion som säkerställer att t.ex. PF-skogar alltid sköts med en viss sorts skötsel.

Låt systemet beräkna skötselprogramalternativ

Detta steg är om möjligt ännu enklare:

Välj "Generate Treatment Programs..." under menyn "Action"

I den dialogruta som följer kan användaren namnge skötselprogramuppsättningen (välj då ett namn som beskriver de aktuella skötselinstruktionerna), ange längden på aktuell planeringshorisont och vilka resultatvariabler som ska tas med i prognoserna. Betänk att ytterligare resultatvariabler både tar plats (i resultatdatabasen) och tid (vid skötselprogramgenereringen) så ta bara med de du avser beakta i analyserna.

Nu kan det, främst beroende på antalet bestånd (eng: treatment units) och antalet skötselprogram (eng: treatment programs) som avses genereras för varje bestånd, vara läge att ta en bensträckare och kanske t.o.m. lunch. Innan du går, kolla bara i "Output"-fönstret så skötselprogramgenereringen startar och verkar funka. En indikation på att någonting blev fel är om bara enstaka program skapas för "vanliga" bestånd - då blir optimeringen skittråkig och sannolikt suboptimal.

Inspektera skötselprogram

När du genom en noggrann inspektion av initialtillståndet kunde förstå förutsättningarna för det aktuella analysområdet gäller i princip samma sak här; inspektera de genererade skötselprogrammen och konstatera att de blev som du ville (enligt dina inställningar/skötselinstruktioner) och studera möjligheterna till optimering. Egentligen kan man se hela planeringsproblemet upplagt framför sig - för visst ser du behovet av ett beslutsstödjande system?

I figur 9 syns t.ex. att man tjänade dryga hundralappen (per hektar, i nuvärde vid aktuell kalkylränta = 2.5%) genom att låta just detta beståndet växa fem år till innan det slutavverkades. �?ndå så sker avverkningen när skogen "bara" är 60 år, är det ok..? Användaren väljer vilka resultatvariabler som ska beaktas via "Select Variables". Tyvärr är det oftast först i detta läge som man inser att man visst var intresserad av t.ex. trädslagsvisa uppgifter, något som man kanske glömde att ta med vid TPG'n. �?nnu tråkigare är det förstås om man upptäcker missen ännu senare, först vid optimeringen (där man t.ex. vill införa en restriktion som säkerställer att det vid varje tidpunkt finns minst 5% löv i det totala, rotstående förrådet - då behövs ju trädslagsvisa uppgifter).

Figur 9

Analysmoment 3: Optimering

Formulera optimeringsmodell

En fullödig och välutvecklad handledning för optimeringsverktyget, ehuru endast tillgänglig på engelska, finner du här.

Föreliggande steg består alltså i att med hjälp av optimering välja ut ett skötselprogram (av de många vi nyss skapade) för varje bestånd.

Under menyn "Optimization" väljs "Open model..."
Välj "ModelBasic.Hops"

Fjolårets optimeringsmodell kan hämtas här. OBS: Bättre är förmodligen att använda och utgå från den med PlanWise-installationen medföljande modellen Max nuvärde med två sorters jämnhetskrav ver 5.Hops. För dig som kan din linjärprogrammering så kanske vissa saker känns bekanta? Man bygger upp sin optimeringsmodell genom att definiera "Sets", "Parameters", "Variables" och "Constraints".

I Heureka finns funktionalitet för att modellera och lösa LP- och MIP-problem. Som modelleringsspråk tillämpas ZIMPL. ZIMPLs User�??s Guide finns här, läs kapitel 4.2 till och med 4.5. Nedan följer sedan ett antal syntax-exempel, vanligt förekommande i en optimeringsmodell i PlanWise.

Kontovariabel som summerar avverkad volym i varje tidsperiod:

FORALL <p> IN periods DO
        SUM <i,j,r> IN treatmentunits * alternatives * rowno :
        volumeHarv[i,j,p,r] * area[i] * x[i,j] == volHarvTot[p] ;

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:

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

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

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

volHarvTot_p = summa avverkad volym under period p

x_ij = 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:

FORALL <p> 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] ;

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.

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.

FORALL <p> 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] ;

"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:

FORALL <p> IN periods DO
areaFinalFelledTot[p] <= 20 ;

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"
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.

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.

Sammanfattningsvis

I viss mån kanske denna kurs blivit lite för lätt, med färdiga och fungerande optimeringsmodeller... I figur 10 syns den med PlanWise medföljande modellen, röd pil markerar målfunktionen; aktiv syntax visar att det rör sig om två mål där man söker högt nuvärde men utan alltför ojämn avverkningsprofil. I egenskapsfönstret kan konstateras att optimeringsmodellens riktning är maximerande. Med så mycket förberett blir din uppgift att försöka förstå jämnhetsrestriktionerna "(max)volharvDecrease" och "(max)volharvIncrease", som de definierats finns en större svaghet och en stor styrka - ser du dessa?

Figur 10

Lös optimeringsproblem

Högerklicka i optimeringsmodell-fönstret och välj "Compile and solve model..."

Beakta utfallet i "Output"-fönstret. Med en bra modell gick allt bra och optimeringsproblemet kunde lösas. Det kan dock krångla, om felmeddelandet "Could not build model" beror det oftast på formuleringen av problemet i optimeringsmodellen. Gå tillbaka och kontrollera variabler och restriktioner, dess definitioner och syntax (ibland kan modellen bli för stor för att kunna byggas - ta då bort parametrar, variabler och restriktioner som inte används). Felmeddelandet "Solution: Infeasible" är lite bättre men givetvis inte bra. Det fanns alltså ingen lösning på föreliggande optimeringsproblem. Gå tillbaka till optimeringsmodellen och uteslut ("Exclude") alla dina restriktioner för att sedan inkludera dem, en efter en, och försök lösa problemet efter varje inkludering. På så sätt kan man hitta åt den restriktion som är alltför restriktiv. Ibland kan man måsta backa ännu längre och generera fler skötselprogram till varje bestånd - att optimeringsproblemet saknar lösning kan mycket väl bero på att det saknas sådana skötselprogram som kan uppfylla en viss restriktion. Gå även in under menyn "Optimization>Settings...", här kan man t.ex. tillåta en längre tid i sökandet efter problemlösning.

Efter att en lösning av optimeringsproblemet erhållits, välj "Save Optimization Results"

Detta så du ska kunna beakta resultatet under fliken "Optimization Results".

Round to integer solution?

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 lång tid.

Att beslutsvariabeln tillåts anta decimaltalsvärden kan i vissa lägen vara önskvärt - ni har ju jobbat med både heltäckande data (där varje bestånd representerat enbart "sig själv") och ett dataset med stickprovsavdelningar där en avdelning har en representativ areal mycket större än sin faktiska och sålunda representerar flera andra avdelningar. Resultatet för en stickprovsavdelning kan då fördelas ut på dess representerade avdelningar i förhållande till värdet på beslutsvariabeln. Men generellt kan man nog säga Heltäckande data = heltalsavrundning.

Numer finns alltså möjligheten att avrunda till heltalslösningar, väljs under "Optimization>Settings..." och innebär att man efter optimering avrundar så att ett bestånd i sin helhet bara kan åtgärdas med en typ av åtgärd i en och samma period. Men det innebär åxå att du kan få olika resultat i "Output"-fönstret jämfört med de under fliken "Optimization Results".

Analysmoment 4: Analysera resultat

Hur du väljer att analysera och presentera resultaten beror på din uppgift. Vilka resultatvariabler som är av intresse att beakta får du välja själv. Under fliken "Optimization Results" finns goda möjligheter att presentera resultat på lämpligt sätt. Tre underflikar finns här:

Details

Här presenteras för samtliga bestånd i aktuellt analysområde det valda ("bästa") skötselprogrammet, via "View Treatment Programs". Du bestämmer vilka variabelvärden som ska beaktas (via "Select Variables") i hur många 5-årsperioder. Möjligheten finns sen att kopiera datamatrisen in i annat medium, t.ex. Excel, och där fortsätta resultatanalysen. Figur 11 visar ett resultat där varje bestånds föreslagna åtgärder, och vid en föreslagen avverkningsåtgärd då den avverkade volymen (i m³sk/ha), presenteras för de tre första 5-årsperioderna.

Figur 11

Tables and Graphs

Här kan användaren skapa egna period- och klassdiagram. Datamatrisen kan även här kopieras in i annan tabell etc. Observera möjligheten att välja typ av punkt-, linje- och olika sorters stapeldiagram. Du kan läsa mer här: Report Builder. Figur 12 visar en s.k. avverkningsprofil, med totalvolymer från gallring respektive slutavverkning, så man snabbt kan kontrollera t.ex. huruvida ställda jämnhetskrav haft genomslag. Borde jämnhetskravet ställts enbart på volymer från slutavverkningar? Och på så sätt lämnat gallringsvolymerna "obundna"? Med en "Period Graph" presenteras förutom diagrammet även de bakomliggande värdena i en datamatris (lämplig att kopiera och klistra in i t.ex. en tabell i Word eller i ett Excelark för att göra ett snyggare diagram).

Figur 12

Map

Gör t.ex. en temakarta för variabeln "Treatments" för att se vilka åtgärder som görs i de olika bestånden i olika perioder. Välj ett resultat, t.ex. "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. "Thinning" och "Final felling" (och ev. andra förekommande avverkningsformr) och ändra färgerna på dessa. Högerklicka igen på "Treatment" och välj "Show in Map". Bläddra mellan planperioderna för att beakta föreslagna avverkningar i respektive 5-årsperiod. Figur 13 visar hur man i kartan kan beakta vilka bestånd som föreslås till vissa åtgärder i en viss period.

Figur 13

Du kan läsa mer om resultatredovisning här: Category:Result Variables