Forum Replies Created
-
Posts
-
Original Question: Has anyone noticed that there is variation in year 0 amounts in state classes areas within a stratum? I would expect variation in year 1 of course, but it seems like year 0 should only have the exact value coming in from an initial conditions spreadsheet. Help??
Non-spatial initial conditions for each cell are sampled randomly from the initial distribution specified. So initial conditions will vary randomly for each Monte Carlo iteration. You can initialize precisely (i.e. without sampling) by specifying a value for each cell using the Spatial Initial Conditions.
Age output is built-in to the State Class output – it appears as another column in the base State Class output (both in the UI and through rsyncrosim). If you have age output working properly you’ll see an “Age” entry under the “Dissaggregate By” option for State Classes in the Chart window. Otherwise Age information does not appear for your model.
My guess is that you have perhaps not yet setup your ages in the project’s definitions for you library? See https://docs.stsim.net/reference/prop_ages.html for how to set these up. If you leave the Age Types blank then Ages are not tracked for your model. You may also optionally want to setup Age Groups to bin your ages in order to reduce the volume of your output.
Yes I think what you describe can make sense in certain situations. Normally we might use a variation on the strategy you outline above to determine probabilities for succession transitions where the goal is to have a fixed annual succession probability that effectively leads to (on average) all of the area in a particular state class transitioning out of the state class over the entire age range of the class. Simple math might suggest then that if for example you transition 10% of the cells in a particular state class each year, and the state class has a 10 year age range, that after 10 years on average all of the area in the state class would have transitioned. However the math is a little more complicated than this. For example below is a table of output for 1000 cells starting in a particular state class at timestep 0 with a transition probability of 0.1/timestep:
Timestep Cells_Remaining Cells_Transitioning
0 1000 100
1 900 90
2 810 81
3 729 73
4 656 66
5 590 59
6 531 53
7 478 48
8 430 43
9 387 39
10 350As the table shows, after 10 timesteps of applying a transition probability of 0.1, 35% of the cells will still not have transitioned. If you do the math, to transition 95% of the cells over 10 years you would need a fixed annual transition probability of 0.25!
So the first suggestion is if you do want to balance your transition probabilities across state classes, such that the transition probability on average effectively “clears” each state class over the full age range of a class, using 1/age range as the fixed probability might not be quite right. You’ll need a slightly more complicated formula to get at this.
Secondly, while we do use this approach at times for modeling a process like succession, we don’t normally do this for fire. Wihtout seeing your model, having fire probabilities be a function of the age range seems a bit counterinintuitive. Usually fire probabilities are 1/fire return interval, and while the fire return interval can vary with age, I don’t ever recall varying it with the “age range” (which is more of a modeling construct).
Hope this helps!
Just a quick note to say that our online course for ST-Sim covers all of this in the first 2 exercises. I highly recommend taking the first day (which is free) if you are new to SyncroSim and/or ST-Sim. You can find all of the course materials at https://apexrms.com/training
The simplest way to conduct a sensivitity analysis with a SyncroSim-based model is to script the analysis using either rsyncrosim (for R) or pysyncrosim (for python). In fact this is one of the major benefits of SyncroSim – the ability to quickly and systematically generate and compare many model “scenarios”. Once you get a sensitivity analysis script running in R or Python then you can visualize the results using either your scripting environment or alternatively through the SyncroSim Windows UI.
You can find a short video demonstrating this approach on the Getting Started page for the omniscape SyncroSim package . The second video on this page (i.e. the one called “omniscape & rsyncrosim for reproducibility”) demonstrates a very simple sensitivity analysis using rsyncrosim. The same approach can be used for any SyncroSim model package, including for example the ST-Sim Package you are using.
As with everything in SyncroSim, you can also do all this using an R or Python script (instead of through the UI) using the corresponding rsyncrosim or pysyncrosim packages.
You could to this by defining separate Transition Types that only apply to certain states. For example you could have Transition Types “Firewood Harvest: Late Seral” and “Firewood Harvest: Mid Seral” and set Transition Targets separately for each Type. This would allow you to set different targets for each state class – however the targets for each would be independent of each other. You could also put the two Types in a single Transition Group (say called “Firewood Harvest”) and then set a single target for this group – this would be a more typical way of doing things, as generally people harvesting firewood don’t set targets independently for different seral stages. If the Transition Probabilities for the two Transition Types are the same then the model will distribute this target with equal probability to all cells on the landscape, and thus will harvest firewood from different seral stages in proportion to their relative abundances at any point in time. This is often a very reasonable assumption for many systems. However you can also use these Transition Probabilities to favor one Type over the other – for example, setting the Probability for “Firewood Harvest: Late Seral” to be twice that of “Firewood Harvest: Mid Seral” (in conjunction with setting a Transition Target for the “Firewood Harvest” Transition Group) will have the effect of assigning twice the probability of harvest to Late Seral cells as those that are Mid Seral. The challenge here is deciding on these relative probabilities, as rarely are they known.
A more common way to direct timber harvest across a landscape is to use Transition Attribute Targets. These allow you to express targets in terms of volume (or biomass) of wood harvested, rather than area harvested. With this approach you provide volume curves over age for each seral stage and the model uses these to calculate the harvest. As cells in the Late Seral stage will typically have greater volume than those in the Mid Seral stage, these cells will contribute more to the total harvest. In most forested systems this is much more realistic approach to modeling timber harvest, as a stakeholder harvesting firewood would generally target a certain number of bush cords of wood (i.e. volume), rather than an area each year. Note that this feature is covered (with a timber harvest example) in Exercise 6 of the self-directed online ST-Sim course.
The spatial autocorrelation (i.e. pattern) of your transitions can be controlled in various ways. The simplest way to do this is to use the Transition Size Distribution feature in ST-Sim. Exercise 2 in the free online ST-Sim course covers this topic.
If you establish BpS as a strata in your spatial model (usually the primary strata), then every state on your landscape is uniquely identified by its stratum and state class. Then sharing names of states across strata is not at all a problem (in fact it is a very common thing to do!).
Bottom line is you do not need to have unique state class names across BpS. Just make sure you setup your strata correctly. Exercise 3 in our new self-directed training course covers this if you are able to gain access to it!
One thing that would cause the problem you describe is if you are using an incorrect folder/filename for the library you are trying to reopen. The ssimLibrary() function will either open an existing library (if it exists) or alternatively create a new blank library (if it does not exist). If you get the filename wrong then you will create a new empty library when you first call ssimLibrary(). Every subsequent call to ssimLibrary() will then continue to open this empty library.
You can try this code to test where SyncroSim is looking for your library:
library(rsyncrosim) getwd() # check to see your current working folder addPackage("stsim") # make sure you have the package you wish to use installed # Next line will either open test.ssim (if it exists in the working folder) OR # create a new empty library (if it does not exist) myLibrary = ssimLibrary("test.ssim", package = "stsim") list.files(getwd()) # see the new test.ssim file that was created or openedThe other option for introducing a dynamic link between a cost/distance function of yours and the transition probabilities in ST-Sim is to use the Spatial Transition Multipliers in conjunction with the External Program feature. This would allow you to pause the ST-Sim simulation throughout the simulation and turn control over to a script of your choice (e.g. in R or Python). Your script could then read in the current ST-Sim raster projections for the state of your landscape at the time of the pause, calculate a new Spatial Transition Multiplier raster for the next timestep however you like, and then pass the new Spatial Transition Multiplier raster back to ST-Sim. In this way you are dynamically modifying the transition probabilities across every cell, timestep and Monte Carlo realization as the simulation progresses. The rsyncrosim R package can help you move data back and forth between SyncroSim and an R script. In Python you can make calls to the SyncroSim command line API to do the same. Note that your simulations will take a performance hit for using this feature, as data is passed back and forth between SyncroSim and script by disk.
Below is an example of how you might set this up using the SyncroSim Windows UI for a call to an R script every 5 years in the simulation. Full online documentation for this new feature is coming soon.
You can also get a list of available packages on the SyncroSim Online Package Server using the rsyncrosim::package(install=FALSE)
I think the command line call you want is –import to do the equivalent of the saveDatasheet function in rsyncrosim. See http://docs.syncrosim.com/reference/console_import.html
You can find some basic documentation on the new Merge Dependency feature in our online documentation for SyncroSim. It’s a pretty powerful feature in that it now allows you to split up larger more complex datafeeds into sub-pieces and merge them at runtime. We use it a lot. Best thing is to try it out a bit to get the feel of how it works. Let me know if it isn’t clear and we can add an example.
