|
|
(201 intermediate revisions by 2 users not shown) |
Line 1: |
Line 1: |
− | Release notes 1.9.8
| + | {{DISPLAYTITLE:sandbox}} |
| + | |
| + | <syntaxhighlight lang="python" line='line'> |
| + | def quickSort(arr): |
| + | less = [] |
| + | pivotList = [] |
| + | more = [] |
| + | if len(arr) <= 1: |
| + | return arr |
| + | else: |
| + | pass |
| + | </syntaxhighlight> |
| + | |
| <!-- | | <!-- |
− | {{Languages}} | + | {{#ask: |
− | [[Category:Release]] | + | [[Category:Variables]] |
− | [[Release date::2013-06-07]]
| + | | ?VariableUnit = Unit |
| + | | ?VariableDescription = Description |
| + | | mainlabel = Name |
| + | }} |
| --> | | --> |
| | | |
− | ==New features == | + | ==Bug fixed since version 2.8.0== |
− | *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.
| + | <mantis> |
| + | status = resolved, closed |
| + | fixed_in_version = 2.9.3 |
| + | show = id,category, summary, fixed_in_version, updated, resolution |
| + | </mantis> |
| | | |
− | *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.
| + | English [[Image:Feed-icon.png]] |
− | [[File:ReleaseNotes_1_9_8_reportBuilderGlobalConditions.png|none|300px|thumb]] | + | {{#ask:[[Category:Release]] [[newsdate::+]] |
− | | + | |?newsdate= |
− | *In the selection window for treatment units, a '''search function''' has been added do find a treatment unit by entering its id.
| + | |sort=newsdate |
− | | + | |order=desc |
− | *An alternative way of calculating dominant height is available in control table Treatment Model. If you change parameter '''Domainant Height From Trees''' = False, it means that a function will be used that calculates dominant height as a function of mean height (hgv), instead of calculating dominant height from the tree list. However, this function is currently intended only for testing.
| + | |date=newsdate |
− | | + | |format=feed |
− | ==Enhancements ==
| + | |type=rss |
− | * 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 you can set in control category Regional Framework. The latter are used for allocating treatments to treatment units, not for allocating treatment units to control categories.
| + | |searchlabel= RSS |
− | [[File:ReleaseNotes_1_9_8_randomSeed.png|none|thumb|300px]] | + | }} |
− | | + | --> |
− | *'''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.
| |
− | [[File:ReleaseNotes_1_9_8_areaFactorSum.png|none|thumb|500px]] | |
− | | |
− | *Forest domains have an internal number that can be used in optimization models. These numbers have until now only been accessible in an optimization model (PlanWise only) by adding the forest domain as an optimization parameter, right-clicking that parameter and choosing View definition. The '''forest domain 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.
| |
− | [[File:ReleaseNotes_1_9_8_domainNumber.png|none|thumb|300px]]
| |
− | | |
− | *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)
| |
− | [[Image:ReleaseNotes_1_9_8_ingrowthMinMeanAge.png|none|thumb|300px]]
| |
− | | |
− | *When simulating strip roads in first thinnings, the thinning algorithms have not taken into account that the possibility to select what trees to is limited in the strip roads. This has been changed by assuming that a certain proportion of each type tree is cut (by reducing the tree expansion factor, i.e. the number of trees that a sample tree represents) in proportion to the strip road area, when opening strip roads.
| |
− | | |
− | *'''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.
| |
− | | |
− | *'''Dead wood data''' are now available also under tab '''Initial State''', and not only after TPG- or RegWise-simulation (PlanWise and RegWise).
| |
− | | |
− | ==Bug fixes ==
| |
− | *In version 1.9.7 of RegWise, the representive area for a treatment unit was not adjusted correctly when using NFI-data covering several inventories (i.e. several years). This has been fixed.
| |
− | | |
− | *In version 1.9.7, a new height growth correction function was implemented, but a unit error lead to that the effect of using the function was microscopic. This have been fixed, and will typically reduced height growth of non-dominant trees.
| |
− | | |
− | *Thinning algorithm "LOErikson" has not been working as expected, so that for certain conditions the desired thinning form was not obtained. It is now working better but still not perfectly solved, because desired thinning grades are not obtained exactly.
| |
− | | |
− | *Thinning algorithm "Hugin" (not "HuginOld" also had some problems when simulating striproads in thinnings, so that thinning grades became larger than intended. This has been solved.
| |
− | | |
− | *Some bugs have been fixed that occasionally lead to that the scheduling of thinnings failed.
| |
− | | |
− | *'''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.
| |
− | [[File:ReleaseNotes_1_9_8_periodMidpointStandWise.png|none|thumb|300px|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:
| |
− | : <code>..WHEN (a > b) AND (c > d OR e > f)</code>...
| |
− | : 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:
| |
− | : <code>if (c > d OR e > f) then 1 else 0 end ;</code>.
| |
− | : Finally, you could have replaced
| |
− | : <code>(c > d OR e > f)</code>
| |
− | : with
| |
− | : <code>g == 1</code>,
| |
− | : to get
| |
− | : <code>..WHEN (a > b) AND (g == 1)</code>...
| |
− | : This has now been solved so you can mix expressions and separate them with parenthesis directly in a condition.
| |