Forum Replies Created
-
Posts
-
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.
Thanks for the feedback. Similar to the existing optional argument for the datasheet function in rsyncrosim, perhaps we could add a new withData boolean argument to give the option to only return columns that contain data?
Note that you can also access the External Program feature directly from R (using the rsyncrosim package) or the SyncroSim Console (i.e. using SyncroSim.Console.Exe) through the datasheet named STime_External
Note that the arguments for SyncroSim.Console.exe all use double dashes – the forum seems to have rendered them above as single dashes I’m afraid!
The Python package has not yet been released – I’m afraid it is still a work in progress. We hope to release a beta version of it by summer 2019. The sample python package that you refer to here is not quite ready for prime-time I’m afraid (and so is not yet released as a registered package on http://www.syncrosim.com/packages)
In the meantime it is possible to call SyncroSim from Python using the Console (i.e. command-line) version of SyncroSim. I imagine this is the approach you are already using? The console version of SyncroSim (available for both Windows and Linux) can be invoked with the command SyncroSim.Console.exe. For Windows this can be found in the C:\Program Files\SyncroSim folder by default. The –help argument will always list for you all the possible options. For example the command SyncroSim.Console.exe –help will get you started, while the command SyncroSim.Console.exe –list –help will provide you with help specific to the –list argument.
An Add-on is a SyncroSim Package that extends the functionality of an existing Base Package (like the stsim package). You can also develop your own new Base Package that contains ST-Sim. There are subtle differences between Add-On and Base Packages that probably aren’t important to you at this stage. Either way you would be developing a SyncroSim Package. For any SyncroSim Package you would start by developing a script in R using the rsyncrosim R package to do your spatial regression (as a pre-processing step to running ST-Sim). Once you have the script working you then simply add an XML configuration file to define how this script ties into SyncroSim. Note that you don’t need to develop a Package in order to do your spatial regression – rather you can develop a script in R that first does the spatial regression and then runs ST-Sim and never bother going on to turn this into a Package. We do this kind of thing all the time. Much like in other programming environments (e.g. R) you would only bother developing a Package if you wanted to distribute your script to others in a user-friendly way.
Unfortunately we haven’t had time yet to publish a developer’s guide for SyncroSim – we will be working on this over the coming months. In the meantime you can get an idea of how SyncroSim Packages are developed by looking at the source code for several existing packages at github.com/ApexRMS.
More information on how to work with the supplementary files provided with the paper: Daniel et al 2016. Methods Ecol Evol. State-and-transition simulation models – a framework for forecasting landscape change.
The ST-Sim files associated with this paper can be downloaded from the DRYAD repository at: https://datadryad.org/resource/doi:10.5061/dryad.g58k0/1You will need to use SyncroSim version 1.0.13 in order to open the .ssim file associated with this paper. You can access older versions of SyncroSim by navigating part way down the download page on http://www.apexrms.com
Alternatively, you can download a more recent set of ST-Sim files associated with the paper: Daniel et al 2018. Meth Ecol Evol. Integrating continuous stocks and flows into state-and-transition simulation models of landscape change.
These files contain the same model as in the previous paper (with some additions for carbon dynamics) and will run with the current version of SyncroSim. You can find these files on DRYAD at: https://datadryad.org/resource/doi:10.5061/dryad.6939cEssentially you can use an advanced feature called spatial multipliers to constrain the transition probabilities over space and time in any way you like. In the limit you can generate one multiplier raster for each transition and timestep. This raster then scales (i.e. multiplies) your base transition probabilities up and down over space and time. So the effect of any spatial layer (i.e. roads, rivers, zoning regulations etc.) can be either positive or negative. You can now also generate these multiplier files dynamically (i.e. as you run your simulation) so that they can be responsive to changes in your landscape. All this is pretty advanced work with our software and really is best done with a scripting language to generate the multiplier files. We recommend R as we have an R package to help but you could also other languages like Python. There are some shortcut ways to generate the spatial multipliers directly in ST-Sim without scripting, as was used in the Daniel et al (2016) paper, however the bottom line is you can do pretty much anything you like in terms of modifying transition probabilities if you are willing and able to venture into R.
I just tried it and you are right the Daniel et al (2016) supplementary files aren’t working with the latest version of our software. We’ll try to get a fix for this shortly and post it on the forum.
Note that we have an online course coming up in March that would probably cover a lot of your questions – see http://www.apexrms.com/training. We are actually also updating our videos this week in preparation for another course in February. If you subscribe to our newsfeed on the apexrms.com homepage you’ll get notifications about both the videos and the course.
It looks like you are probably referencing the original scenario with your call Scn = scenario(Prj, “All Models”), rather than the Results Scenario that contains the output associated with this original scenario. Each original scenario can spawn multiple results scenarios – i.e. one for each time you run the original scenario. Only the Results Scenarios contain output.
Try the command scenario(Prj) to see a list all your scenarios, including all the Results Scenarios. From here you can get the ID for the result scenario and then use the command Scn = scenario(Prj, ScnID), where ScnID is the unique ID for the appropriate Results Scenario.
At present the Stratum Name is treated as a key for each Stratum in the Project Definitions. Which means that it is not easy to change the Names once the Definitions are set. We have discussed making it possible to change the values of fields like this programmatically, as you have tried to do, but haven’t yet found the funding to move ahead with that.
In the interim there are 2 ways that you could change your names. The first is to edit them directly on the screen in the user interface. Our user interface handles this because it knows about a hidden primary key in the underlying database table that allows the Name to be changed. Unfortunately this primary key is not yet exposed in rsyncrosim (but we are looking to offer this option in a future release). Of course this would be challenging for 900 values. The other way to do it programmatically would be to update the .ssim SQLite database directly. You can do this in R by connecting to your .ssim file as a SQLite database (using the RSQLite package) and then issuing a SQL command to this database to update the appropriate database table. The names of the tables in the database are the same as the corresponding datasheet names. I recommend using the free SQLiteStudio software to peruse your .ssim file in order to figure out the query. I believe you can also invoke SQL queries directly from within SQLiteStudio. Be sure to backup your library before issuing direct SQL commands however!
Hi Rachel – others here report similar problems on occasion with both RStudio and Visual Studio IDE’s for R – code that runs one day and then not the next. Solution seems to be resetting things somehow. I know in RStudio there is a way to clear all objects from the workspace that might help to reset things. I haven’t used VS so not sure, but I see online there is an option to reset a workspace: https://docs.microsoft.com/en-us/visualstudio/rtvs/r-workspaces-in-visual-studio#saving-and-resetting-a-workspace. Others have worked around the problem by uninstalling and reinstalling the rsyncrosim package (likely as a way to reset things somehow?).
Let me know if any of these work for you. Colin
