Forum Replies Created
-
Posts
-
Hi Kori,
This sounds like a bug that we should fix in the next release which should be coming out next week. Can you send me a copy of the ssim library with instructions on reproducing the problem?
Thanks,
Leonardo
Hi Josh,
At the moment we don’t have a full scenario import option for ST-Sim. The changes to the architecture between Path and ST-Sim were substantial and this is one of the features that has not been replicated in the new platform.
However, you can have multiple Libraries (databases) open in ST-Sim and use the copy/paste options for projects and scenarios to move data between lirbraries in this way.
Regards,
Leonardo
Hi Randy,
The upcoming release of ST-Sim (2.3.1). Will support a number of commandline utilities for running the model including running iterations and spatial regions for the same scenario in parallel. These commandline utilities can be run on Linux with Mono ( http://www.mono-project.com/Main_Page) installed. Once the software is released we will create some documentation around running the commandline utilities. However, it will still not be possible to run the full UI version of ST-Sim in Linux as at the moment Mono does not provide full support for windows forms.
Regards,
Leonardo
Hi Randy,
This is a good question that has not been asked in the forum. At the moment there is no autmoated way of migrating from TELSA to ST-Sim but is has been done by researchers at NCSU. There are two possible approaches that you could use:
If they still have the pathways in VDDT format, they can go through the tutorial for going from VDDT to Path to ST-Sim (see http://www.apexrms.com/content/importing-vddt-projects-st-sim and http://www.apexrms.com/downloads/syncrosim/Path-To-ST-Sim-Tutorial.pdf). Then reconfigure the spatially explicit settings in the model.
If you have knowledge of the TELSA database and SQL then you can design queries that export the data to a suitable format that can be imported to ST-Sim using the excel import templates for each model property.
In either case you will also need to create raster based spatial model inputs rather than vector based ones.
I would be happy to help with specifics if you or your colleagues want to give me a call.
Regards,
Leonardo
Hi Miles,
There is no utility in ST-Sim for importing MCM files. Path Version 4.2 has an Import MCM utility. You could import into Path first and then use the excel import export feature in both Path and ST-Sim to transfer the data across. This woudl be a similar process to what is done for bringing models from Path to ST-Sim. See:
http://www.apexrms.com/content/importing-vddt-projects-st-sim
and
Click to access Path-To-ST-Sim-Tutorial.pdf
Let me know if you would like to discuss options for porting the MCM import utility to ST-Sim.
Regards,
Leonardo
Hi Alison,
Great question. In the current release of ST-Sim (V2.1.0) there would not be faster runtimes for model A. However, we are about to release a new version that handles ‘no data’ cells much more efficiently and in this coming version model A will run significantly faster and use less memory. If you would like a pre-release Beta version please let me know.
Regards,
Leonardo
Hi Miles,
Spatial multipliers work for both primary and secondary transition groups.
Note that at the moment, area targets, slope multipliers, direction multipliers and adjacency multipliers in spatial runs only work for primary transition groups.
Regards,
Leonardo
Hi Randy,
You can get Path 4.2.2 from http://www.apexrms.com/download/6080/
The password for the zip file is the same as for ST-Sim.
The state class import can be tricky. As specified in the tutorial, note that the ”Name” field in the template you are importing into ST-Sim should be set with a formula to:
=B2&":"&C2
If you are still having trouble, let me know and we could look it over with a GoTo.
Cheers,
Leonardo
The probability of a fire crossing a fuelbreak will depend on a number of factors inluding:
- The configuration of the fuel break and how it relates to the surrounding cells and their probabilities for fire
- The ultimate length of the fire perimeter that abuts against the fuel break, a longer perimeter means that there are more opportunities for crossing
- Whether you are using direction and or slope multipliers and the relation of the fuel break to the fire source with respect to these.
In the example you give, assuming the fire is a single pixel in size and it is trying to grow by a single pixel only, that all cells surrounding that pixel are equal aside from the fuel break, and that three/eight fuel break cells are adjacent to the source cell, the probability of the fire crossing the fuel break will be:
[the sum over fuel break neighbors (relative probability/relative distance from source)]
divided by
[the sum over all neighbors (relative probability/relative distance from source)]
where the relative probability for 3 fuel break cells is 0.1 and 1 for 5 other cells, relative distance is 1 for horizontal/vertical neighbors and the square root of 2 for diagonal neighbors. In this case the probability of a fuel break cell burning is 0.05186.
Hi Miles,
The main reason why you would observe different fire types occuring to the same cell in the same timestep is if those fire types are in different primary transition groups. These primary transition groups define the set of transitions that will be simulated as a unit within the model. Transitions belonging to the same primary group can be part of the same transition event and can’t occur more than once to an individual cell in a timestep. My guess is that in your project definitions for transitions you have currently either assigned a different primary group for the three different kinds of fire, or you have not defined primary groups at all, in which case all transition groups are considered primary. If it is important for you that the different fire types belong to different primary groups, you could prevent multiple occurences in one timestep by setting a minimum TST since fire for each of these fire types. Finally, if multiple fires occur to a pixel within a timestep, all types will be recorded in the cummulative area burned.
Let me know if this answers your questions.
Regards,
Leonardo
Hi Alison,
Strangely, I have not been able to reproduce the problem with the library that you sent me using ST-Sim V2.1.0 32 or 64 bit. I have sent the updated version back to you. Please let me know if you encounter this problem again.
Thanks,
Leonardo
Hi Kori,
You are correct that you must first import from VDDT to Path and then to ST-Sim. Going from VDDT to Path for an entire database is very straight forward (File | New Project from VDDT) so no tutorial is required for this step. Let me know if you need any clarification on this.
Regards,
Leonardo
A bug in version 1.5.0 can occasionally result in this crash. This is more likely for very large landscapes. The bug will be fixed in the next release. If you are experiencing this problem we recomend you go back to version 1.4 or upgrade to the next version when it becomes available. We anticipate having a new release available by the end of Nov. 2013.
Hi Miles,
Please post your library (ssim file) and acompanying folder with the same name to ftp and I will have a look.
Thanks,
Leonardo
Hi Brian,
This is a known bug in version 1.4 of ST-Sim associated with prioritizing large patche edges for transitions when area targets are used. The crash is incosistent and does not always occur; but it does often. It will be fixed in the upcoming version (1.5) of ST-Sim. We hope to get a release out by early November.
Regards,
Leonardo
