Forum Replies Created
-
Posts
-
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.
With the release this week of rsyncrosim version 1.2.4 on CRAN we now have a basic vignette
This tutorial has now been updated for rsyncrosim version 1.1.9. The exercise assumes you have SyncroSim version 2.2.5 (or higher) installed, along with version 3.2.13 (or higher) of the stsim package.
Thanks for the feedback. It’s on our list now to standardize the datasheet output format across different interfaces.
Note that we don’t recommend writing code against the internal file structure, but rather to always write code to interact with SyncroSim using the command line (or associated wrappers on the command line like the rsyncrosim package for R). The command line represents the official API for SyncroSim and thus we try hard not to break it between releases. As such code written against the API should be supported between versions. The internal file structure however can change at any time.
You should be able to move data in and out of libraries, projects, scenarios, datasheets and datafeeds using only the command line. If you find something you need to do with the file structure that you can’t accomplish using the command line then please let us know. We are always working to improve the command line API.
We are in the process of updating the online documentation for ST-Sim. The new home for ST-Sim documentation is docs.stsim.net. We have already ported over a copy of the old documentation here. For example the current documentation you are looking for is at http://docs.stsim.net/reference/prop_transitions.html
That being said the documentation for Transition Simulation Groups and Transition Multiplier Types is pretty limited at the moment.
Transition Simulation Groups: during a spatial simulation ST-Sim iterates over each transition simulation group to generate “events” for that transition simulation group. Events can be a mosaic of transition types within the transition simulation group that is being generated, therefore you should only combine types within a transition simulation group that you would expect to be part of the same event. Transition Simulation Groups could be useful for combining other types of transitions. For example, you could have different level of severity for insect and disease transitions which could form a mosaic within the same outbreak “event”.
Transition Multiplier Types: these are used to break your Transition Multipliers into different types of multipliers. ST-Sim then combines (i.e. multiplies together) all the multipliers from different types at runtime. For example you might have a multiplier type called “Historic Annual Fire Variability” that represents a multiplier accounting for the annual variability in Fire probabilities observed historically for your landscape. You might then have a second multiplier type called “Fire Future Trend” that represents a trend in the overall increase in your Fire probabilities over time. At runtime ST-Sim will combine these two multipliers to give you a net multiplier for your Fire Transition due to both annual variability and future trend.
