Sandbox

Release notes 1.9.8

New features

• A simulation report of what settings have been used when running RegWise or PlanWise TPG-simulation can now be obtained. You do this by right-clicking on a simulation result and choosing Show simulation report.

• You can now define global conditions for a report, i.e. conditions that apply to all variables that are included in the same report. For example, if you want to make a report for treatment units that have a certain site index (or range of site indices), you can add such a condition to the whole report, you do not have to add it to each variable in the report any longer. You can also let the report generator create one report for each forest domain. The only thing you have to do is to mark a check box in the report template.

Enhancements

• In RegWise, treatment units in a given forest domain have been assigned randomly to control categories, if the forest domain has had more than one control category connection. You can now set a fixed seed for the random number generator, to get the same allocation of treatment units to control categories in each simulation. This means that each treatment unit is assigned to the same control category in each run if you use the same seed, and if you use the same forest domain definitions. You can set the seed when you start the simulation, in the same dialog box as where you choose number of planning periods and discount rate. By default, the seed is 0, which means that a random seed will be chosen. But if you set the seed to a value larger than 0, it is considered a fixed seed. Note: Do not confuse this seed with the seeds that can be set since before, in control category Regional Framework. The latter are used for allocating treatments to treatment units, not for allocating treatment units to control categories.

• Forest domains in PlanWise and RegWise can now be copied (right-click on a domain to access the function).
• The forest domain area (i.e. the productive forest areas of the treatment units included in the domain) is now displayed in the properties of a forest domain.

• Forest domains have an internal number that can be used in optimization models. These numbers have until now been accessed in an optimization model (PlanWise only) by adding the forest domain as an optimization parameter, right-clicking that parameter and choosing View definition. The number is now also displayed in parenthesis in the title bar of a forest domain. However, the number only refers to the current forest domain definitions. If you add or remove forest domains, the numbers are not valid for previous simulations that were based on other forest domains. When running an optimization model that uses forest domain numbers in conditions, always check the correct number by checking the forest domain parameter mentioned above for the simulation that the optimization model should be run for.

• In treatment units with more than one plot (such as when you have imported FMPP data), cleanings can be applied to part of a stand. The criteria for cleaning is now based on the state of each plot, not only the average values for the treatment unit. For a cleaning to be applied, a certain proportion of the plots must qualify for cleaning. The same parameter as for thinning is used for this, namely Min Prop. Thinnable Plots in control table Treatment Model. It is possible that we add a specific parameter for cleaning, but for the time being we have solved it this way. The plot-level criteria for cleaning, is that there must be enough stems to clean (by default, at least 500 stems/ha should be cleaned). The height range at the plot level is less restricted than that dictated by parameters Height Range (Min and Max) for cleaning in control table Treatment Model. For the plot the mean height of sapling must be within Height Range Min minus 1 m and Height Range Max plus 2 m. Finally, for the plots that have passed as "candidates" for cleaning, the average mean height of saplings must meet the height range interval criteria in the control table.

• The default values for several control tables parameter have been updated. See Updated default values for control table parameters version 1.9.8. For example, costs for harvesting and forwarding have been increased.

• The minimum diameter for trees transferred from sapling phase to older phase have been decreased to 2 cm, and the ingrowth function is not triggered until the mean age of a plot is at least 50 years. The mean age at which the ingrowth function is activated can be changed in control table Production Model (parameter Mean Age Invoke Ingrowth Function)

• Intermediate optimization files are deleted when closing a PlanWise project.

• Result variables in category SiteData are now available in the Result details view in RegWise and PlanWise.

Bug fixes

• Fertilization was not applied correctly in the tactical treatment program generator. The fertilization scheduler always assumed that a period was five years long, and that two periods corresponded to ten years, which is the time before harvesting that Heureka places a fertilization treatment. This has been fixed so that the period year is used instead to determine how many years have passed.

• Harvest residues were automatically extracted when applying fixed harvest treatment proposals in PlanWise, even if no harvest residues extraction was intended. This affected both growth and net present values. This has been fixed.

• The parameter values in a control table can be reset to their default values by right-clicking on a control table, or on a single parameter item in a control table, and selecting Reset to default. This has not been working correctly for parameters that are set in sub dialogs (i.e. dialogs opened from a control table). This has been fixed.

• In PlanWise tactical TPG, the start year for a time period that follows after the tactical planning horizon has not been set as intended. This is not a true bug, but if you had, for example, five one-year periods in your tactical horizon, then the first five-year period after the last tactical period started in year 5.5 instead of in year 7.5 (this example refers to if period midpoint was used).

• In StandWise, the start of an analysis can be set to the first period midpoint (year 2.5). This is done by choosing "Period Midpoint" in menu Action. However, in previous version this has changed period 0 to refer to year 2.5, which is a different handling compared to RegWise and PlanWise, where period 0 is year 0 and period 1 is year 2.5 when period midpoint is activated. This has been changed so that StandWise is working in the same way as RegWise and PlanWise.

Stepping to first period midpoint in StandWise

.

• When choosing even-aged management for the first generation, conversion has not been possible to another management system (unmanaged or uneven-aged management). This is now possible. Note that this does not work the other way around: When choosing Management System = “Unmanaged” for an existing stand it means that no harvesting will ever take place. If you want to simulate a scenario with no harvesting for a limited time time ahead, and allow harvesting after that time has passed, you can accomplish this in at least two other ways. One way, in PlanWise, is to set Max Number of Thinnings = 0, and choose suitable values for Final Felling Period Min and Max respectively. Another way is to import or enter a management proposal of type None for the treatment unit (or units) and the year to the last year for when no harvesting is allowed. If you choose Management System = "Uneven-aged (CCF)", it also applies to an infinite time horizon, but there is no exact way of simulating a scenario where you convert from uneven-aged management (not to confuse with uneven-aged stand!) to even-aged. Possibly, one could apply an even-aged system with repeated thinnings from above and delay when the first felling period is allowed.

• In previous versions of the optimization modeling tool in PlanWise, It was not possible to combine multiple subexpressions in the same condition if parenthesis were needed to separate them. For example, expressions of the following type were not accepted: ..WHEN (a > b) AND (c > d OR e > f). You had to circumvent this problem by defining additional optimization parameters. In this example, you could have defined a parameter g with the following definition: if (c > d OR e > f) then 1 else 0 end ;. Finally, you could have replaced "(c > d OR e > f)" with g == 1 to get ..WHEN (a > b) AND (g == 1). This has been solved so you can mix "and" and "or"-expressions and separate them with parenthesis directly in a condition.