Forum Replies Created
-
Posts
-
One last comment in addition to my previous post. VDDT has an internal flag in the database that allows the user to turn aging off after a transition occurs. By default this option is turned off, however if this were turned on and a probabilistic transition occurred every time step then aging would not occur and neither would probabilistic transitions from this state.
In this situation a probabilistic transition will occur to a cell every time-step. Whether a deterministic transition occurs will depend on what the probabilistic transitions that occur do to the state and/or age of the simulation cell. If the probabilistic transitions move the cell to another state then deterministic transitions from a state that has Probabilities > 1 will not occur. If the probabilistic transitions set the age back so that the cell can’t age to reach it’s end age then deterministic transitions will not occur.
If probabilistic transitions occur but do not set the age back then deterministic transitions can still occur. The cell will continue to age and eventually reach it’s end age and undergo a deterministic transition.
While it is true that outputs of VDDT and Path can exhibit Weibull distributed return intervals for transitions, neither model actually uses a Weibull distribution in it’s algorithm. For all the cells of the same class at any one time step there are two possible outcomes — undergoing a transition or not. The resulting probability distribution for the number of transitioning pixels of that class at any one time step is the binomial distribution. This process is analogous to tossing a coin and describing the number of heads vs. tails or tossing a dice and describing the number of times out of a fixed number of tosses that you get a specific outcome like rolling a 6.
If the probability of a transition is constant as a function of age or time since a previous transition then the return interval (or time since the last transition) follows the exponential distribution. The exponential distribution is a special case of the Weibull distribution. If the probability of a transition changes with the age of a cell or time since a previous transition, then return intervals for transitions exhibited in the model outputs will follow the Weibull distribution. The model does not sample from a binomial, Weibull or exponential distribution; rather the models exhibit these kinds of distributions in their outputs as a mathematical consequence of the simple binomial (yes/no) process used in the algorithm.
If a user would like to influence the kind of distribution followed by return intervals in the model then they need to modify the probabilities of transitions and how they change or stay constant over time. In this sense the state and transition model is quite transparent in terms of assumptions which only consist of the state classes defined by the user, the transitions between state classes and the probabilities assigned to those transitions.
There is a more detailed description of this in Appendix B of the VDDT user guide http://essa.com/wp-content/uploads/2010/09/VDDT-60-User-Guide.pdf
Please let me know if any of this requires further clarification.
Colin is correct in saying that the maximum number of Structural Stages that can be handled by VDDT is 99 and codes are limited to 2 digits. Because Path currently uses VDDT as the simulation engine Path is also limited to a maximum number of 99 structural stages.
At the moment Path does not import this setting from VDDT although this issue has been identified as a potential enhancement. There is currently no property for which a user can specify the randomization range for initial TST (Time Since Transition). In the meantime Path initializes the TST to a random number between zero and the maximum value (by stratum) used for the “Min TST” field in the Probabilistic Transition property.
Hi Randy,
I think that your idea of setting up the dummy transitions in VDDT for TELSA is a good one for a couple of reasons:
1. It is good to have a clear record of all of your model assumptions in one place and the VDDT UI is a much easier to interpret and review a model’s states and transitions with than the TELSA UI.
2. It is easy in VDDT to turn off certain transitions using Run | Settings | Options | Disable some transitions
3. You will only need to move these transitions into TELSA once, as opposed to having to reimport your pathways from VDDT once you have done some work in TELSA.Hope that helps.
Leonardo
In assigning initial conditions (Run | Settings | Initial Conditions), the user is given the option of selecting an age range for each record by selecting the Ages checkbox. The default age range is the same as the age range that spans the class as defined in the Deterministic Transitions. For each cell beggining in the class, VDDT then assigns an age randomly from a uniform distribution spanning the age range defined in the Initial Conditions screen. It is very likeley that the way that ages are initialized will influence the final conditions, particularly if run times are short.
Your idea of using final age conditions to initialize ages for a new run makes sense. One question that you will need to resolve is: how long is it appropriate to run your VDDT models before extracting the age distribution? If your models represent current conditions which have only been present for 100 years, you may want to start with reference conditions then run your current conditions model from this starting point for 100 years to get the age distribution for your current conditions.
To increase the number of transition groups allowed follow these steps:
1. Open the VDDT database you are working with using MS Access and open the Global Settings Table
2. Change the field MaxGrp to the number of transition groups you would like to be able to use (the maximum number is 255).
3. Open the Project table and change the number of characters in the field DisableProbabilisticTransitions to equal the number of transition groups you would like to work with by adding the required number of capital F’s to the end of the string. For example, if you want to work with 50 transition groups you would need to add 20 F’s to the string (30 default + 20 = 50). This change must be made for every Project record in the table.Note that Path automatically configures the VDDT database to handle the required number of transition groups at runtime.
It is forseeable that as users get more and more output into their DB that they will approach the 2GB limit of Access. Some possible solutions to this problem are:
1. Under Advanced | VDDT Settings | Output select to print output for only some, not all time steps.
2. Use MS Access to Compact and Repair your database.
3. Create multiple databases for completing your simulations. Note that multiple databases can be opened at the same time in Path and scenario properties can be copied between them.Can you make sure that you have checked the first two boxes in the summary output group of your VDDT Output property? The summary output files are what gets imported to the Path database to generate graphs and reports so these boxes need to be selected if you want to view results from Path.
If you are still having trouble after trying this give me a shout and we can try to resolve with a GoTo Meeting.
Hi Randy,
If you want to import your VDDT models to TELSA you will need to have standardized codes for all your definitions. The easiest way to do this is to let Path generate the unique codes for you and then preserve the intermediate VDDT database after you do a run. This database will have unique codes for all of the definitions.
To generate a VDDT database with unique codes do the following:
1. Import your VDDT database into Path with the use VDDT definition codes checkbox deselected.
2. Once you are ready to run your models in Path set the VDDT Output property for the scenario you are running to Retain intermediate VDDT files. This can be done in the Advanced tab of the scenario properties under VDDT Settings, VDDT Output. The folder where the VDDT output is saved is set under File | Preferences.
3. After you run the model navigate to your VDDT output directory and there will be a VDDT database there. All definitions will have the unique codes generated by Path. The default name for the automatically generated database will be VDDT_Scenario-(ScenarioID).mdb for example: VDDT_Scenario-51.mdb
4. You can then export your VDDT projects from this database to TELSA using the “Export for TELSA” feature in VDDT.Leonardo
This will occur if the scenario that you ran had a VDDT Output property defined but had the save output to the database checkbox deselected. In this case no output is saved to the database so it is not possible for Path to generate graphs of results.
The VDDT Output property can be found in the Advanced properties tab of the scenario properties under VDDT Settings in the property tree.
You will need to select this checkbox and rerun your scenario to be able to graph results.
This is most easily acomplished in the VDDT Database using MS Access. However, you need to be very cautious so as not to Break your models. Making a Backup copy first is definately a good idea. If you are not comfortable working with Access you might want to get help from someone who is or do the change using the VDDT UI which is safer but more labor intensive.
Making the Change Using MS Access:
1. Create a query to determine what distinct groups are used across all your models in the VDDT databse you are planning to import into Path. You can do this by using the following SQL in a new query:
SELECT ProbabilisticTransitionGroup.Name
FROM ProbabilisticTransitionGroup
GROUP BY ProbabilisticTransitionGroup.Name;
This query will identify all of the distinct transition group names that are currently being used in your database. Looking at this list decide which names are supposed to represtn the same group and for these decide what is a common group name you would like to use.2. Edit the group names in the ProbabilisticTransitionGroup Table. Open the table and sort ascending by Name. Change the names of the groups that you identified in step 1 to the standardized name. Be careful about not creating any duplicate groups with identical names for the same Project ID. Do not add or remove any records, only edit the Name of existing ones. Do not edit any of the other fields.
3. When importing into Path you will probably still need to uncheck the Use VDDT Definition Codes on Import checkbox because your definitioin codes will probably be out of synch. It is very difficult to standardize these acropss multiple VDDT models and you can definately break your database by messing with the definition codes.
Making the Changes using the VDDT UI:
You can edit Transition Group Names using the File | Properties | Definitions screen (Transition Group Tab). Unfortunately using this method you can only work one VDDT project at a time so it will be labor intensive.
This is currently not possible in Path 2.0, although it is on the list of planned enhancements. To acomplish this at the moment you need to export the Summary Reports and post process the data.
