Forum Replies Created
February 21, 2023 at 5:27 pm in reply to: Sensitivity Analyses #21728
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.
September 18, 2022 at 12:51 am in reply to: ST-Sim Library with an external program example #21208
- This reply was modified 3 weeks, 6 days ago by Colin Daniel.
- This reply was modified 3 weeks, 6 days ago by Colin Daniel. Reason: Fix links
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.October 13, 2021 at 12:03 am in reply to: specifying transition targets by state class #20673
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.
October 4, 2021 at 10:15 pm in reply to: Speckling- how to avoid #20646
- This reply was modified 1 year, 5 months ago by Colin Daniel.
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.July 1, 2021 at 3:34 pm in reply to: running multiple strata spatially when they have the same state names #20493
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!April 23, 2021 at 11:43 pm in reply to: Rsyncrosim inability to access scenarios #20408
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 openedJanuary 21, 2021 at 4:40 pm in reply to: Incorporating Cost-Distance Raster #20211
The 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.December 29, 2020 at 3:36 pm in reply to: No base packages installed when running rsyncrosim for the first time #20186
You can also get a list of available packages on the SyncroSim Online Package Server using the rsyncrosim::package(install=FALSE)August 7, 2020 at 9:15 pm in reply to: Has the Python package been released? #19989
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
June 11, 2020 at 10:38 pm in reply to: documentation for new Merge Dependency feature #19926
- This reply was modified 2 years, 7 months ago by Colin Daniel.
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.June 11, 2020 at 10:32 pm in reply to: Sample R code for getting started with rsyncrosim #19925
With the release this week of rsyncrosim version 1.2.4 on CRAN we now have a basic vignetteFebruary 28, 2020 at 2:36 pm in reply to: Sample R code for getting started with rsyncrosim #19777
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.
February 28, 2020 at 2:28 pm in reply to: How to find out full path to spatial inputs? #19776
- This reply was modified 3 years ago by Colin Daniel.
Thanks for the feedback. It’s on our list now to standardize the datasheet output format across different interfaces.February 27, 2020 at 4:36 pm in reply to: How to find out full path to spatial inputs? #19774
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.January 24, 2020 at 1:48 pm in reply to: Where is the manual? #19705
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.