Forum Replies Created
-
Posts
-
As you point out the graphs are sorted automatically in alphabetical order. Unfortunately there is no easy way to reorder them at present. As you suggest you could change the name of the state classes to give the order you would like (e.g. 1-Early, 2-Late, 3-Mid). Another option would be to create a State Attribute with the new names instead, and then graph the state attributes. Either way you would need to setup names that match the alphabetical order in which you would like the graphs to appear.
Adding new options to the graphing in Path is a priority area for us in upcoming releases, as we feel there is definitely room for improvement here. Providing users with control over the order of graphs would be one useful new feature. Thanks for the feedback – Colin.
In Path the "Run" property field corresponds to the Monte Carlo iteration. In Path version 3.0 it only appears on the user interface for one scenario property, and that is the Transition Multipliers property. However if you look in the Path database (as you have done) then you’ll see that the full design for Path accepts a "Run" field for several other properties, with the Initial Conditions property (and its corresponding db table StratumInitialState) being one of these. This is intended for future use, where we eventually plan to allow users to optionally set several properties differently for each Monte Carlo iteration.
If you are setting properties directly through the database you should leave the Run property field blank for all properties except Transition Multipliers. For Transition Multipliers you have the option of leaving it blank or specifying values separately for each Iteration; if you leave it blank then Path will apply your property values to all iterations at runtime.
Hope this helps – Colin.
That sounds like a memory problem, perhaps due to the large number of timesteps and graph variables selected. My suggestion would be to upgrade to version 3 of Path and see if the problem persists. If yes, please let us know. Colin.
We found a bug in the way State Attributes were being handled – this has now been fixed in version 3.0.3, which is now available for download at http://www.apexrms.com/path
The latest version of Path now includes a feature that will automatically upgrade older Path databases to the latest version – this has been in place for several versions now and seems to work well. Version 3 is the first version of Path where we have tried to do the same thing with older versions of Excel files containing model inputs – in other words, from this version forward Path should automatically update older versions of model input spreadsheets. That being said, it is possible that Path will have trouble importing spreadsheets created in versions prior to 2.2 – we haven’t had a chance to test all possible combinations of past versions and model inputs.
If you have trouble importing older Path excel files then I suggest you do the following:
- Create a blank scenario and export a blank copy of the property you wish to import – this will create a blank excel template
- Open your old excel model input file and copy/paste the values into the blank excel template you just created
- Import this new excel file
As for the difficulties you had with importing State Attribute definitions, this sounds like a bug and we will look into issuing a patch to fix it as soon as we can. Sorry for the incovenience.
Colin.
I believe the limit on the total number of structural stages in VDDT is indeed 99, although I would need to double check that with Leonardo when he returns from vacation at the end of the month. A simple test to confirm this would be to enter a structural stage in a dummy VDDT model with a code greater that 99 and see if it complains. Note that you would need to add a state class to your model that uses this code to properly test VDDT.
Path is also limited by any VDDT limits at runtime, although Path no longer asks the user to provide the numeric codes. However they are assigned at runtime based upon the auto-generated "Structural Stage ID" field you see in the Path definitions. So Path is also limited to a maximum of 99 structural stages.
There is a way to track more than 99 "structural stages" in Path, however, using State Attributes. Under Project|Definitions in Path you could set up a state attribute group (say called "My Structural Stage") and then create a state attribute type associated with this group for every structural stage you wish to track. You then assign each state attribute type to a combination of cover type and structural stage. So for example you could have a single structural stage called "Open", but have 2 state attribute types called ""Forest Open" and "Non-Forest Open". The "Forest open" attribute type would be mapped onto any state classes that have cover type of "Forest" and structural stage of "Open", while the "Non-Forest Open" attribute type would be mapped onto any state classes that have cover type of "Non-Forest" and structural stage of "Open". Doing this has essentially doubled the number of possible combinations for the original structural stage "Open". Note that you would need to assign values of 1 to the State Attributes property for your scenarios to make this work.
One caveat here is that the State Attributes property is new to Path and so it is only tracked through the Path database output – in other words you can’t track these new attributes in the old legacy VDDT output files.
Hope this helps – post again if you have more questions. Colin.
That’s a good question. Right now Path assumes each VDDT “model” is a stratum in Path, which is the way most folks have structured their VDDT databases. However a model in VDDT can represent either a different ecological stratum (e.g. BpS), or it can represent a different scenario (e.g. “Current conditions”, “2X current management”). Path assumes the former.
The simplest way to control which models end up in Path is to create a separate VDDT mdb with only the models that you would like to bring across to Path (each as a stratum). You can export one or more models from one VDDT mdb to a new VDDT mdb using VDDT’s File | Export menu item. You can then import this subset of VDDT models into Path.
Alternatively you could import all your models from VDDT into Path, and then use Path’s import/export capabilities to export the full suite of models to Excel. Once in Excel you could delete the models for those strata you did not want and reimport the updated Excel file to create a new Path scenario. You could also use this approach to divide up your models into several Path scenarios.
Hope this helps – let me know if you need further clarification… Colin.
The Access mdb can get large and cause problems if it nears the Access 2GB limit. Have you tried compacting the database? This can help enormously to reduce the database size and needs to be done on a regular basis (we have discussed adding a feature to do this automatically from within Path in the future). You can find this in Access 2007 under the Manage menu (under the Office button) – there’s a similar option under the Tools menu in Access 2003. Let me know if this helps.
A workaround for generating graphs that show % of total landscape area is to setup a scenario where the total area = 100. The area numbers should then represent percentages. Note that you will need to modify the resolution of the run to get the desired number of simulation cells if you reset the total area.
Randy –
Another option is to first try to import your VDDT models into Path using the File | New From VDDT menu option. When you first try to import Path will report any major inconsistencies in your VDDT models. You will need to fix these first in VDDT so that Path can complete the import. Once you’re successful importing the models, Path will generate a short CSV format report listing all of your transition types and groups, sorted by model. This report can be very helpful, as you can open the file in Excel and easily sort through the master list of transition types and groups. You can then use this report to sort out the subtler inconsistencies in your VDDT transition types/groups without having to go into the VDDT Access database.
This approach works well if you have only a few VDDT models, as you can quite easily do all your edits to the VDDT transition types and groups directly in the VDDT user interface. In your case – where you have only 4 models and less than 20 transition types – you might want to consider it if you’re not comfortable working directly in Access.
Whenever a scenario is run through the model Path creates what is called a "results scenario" at the time of the run. By default this new scenario contains copy of all of the original model inputs – Path merges all of the input dependent scenarios into this results scenario, makes the results scenario read-only, and places this "flattened" copy of the model inputs in the database along with the output. This way the results scenario always contains an accurate record of exactly which inputs were used at the time of the model run, even if the user were to subsequently modify one of the original input scenarios after the run.
Of course the downside of this option is that you create copies of every model input each time you do a run, which can take up more processing time (and presumably more time for writing to the database). You can choose to uncheck this option for any of the input scenarios – either the parent scenario your are running, or any of its dependent scenarios. Doing so tells Path not to make a copy of those inputs into the results scenario at runtime, but rather to continue representing this scenario as a dependency at runtime. This can save database space, particularly for scenarios that contain lots of inputs. The downside of this approach is that if you were ever to edit one of your original input scenarios, you would lose your record of exactly which inputs were used to generatae any previous run results.
I imagine you would get better performance if you unchecked this box for your scenarios – which would be acceptable if you don’t ever plan to subsquently edit the original input scenarios after the runs are complete. I’d be interested to hear how much improvement in performance you see over the default option if you’re able to run a short test.
The nomenclature surrounding attributes in Path has changed somewhat from VDDT; the basic concepts are as follows:- There will eventually be 2 types of attributes in Path: state attributes and transition attributes. State attributes are those that are defined as a function of state classes (e.g. habitat suitability index), while transition attributes are defined as a function of both transition types and state classes (e.g. timber volume). State attributes correspond to categorical and numerical attributes in VDDT, while transition attributes correspond to calculated attributes. Only state attributes are currently implemented in Path.
- Attributes are now defined using attribute types and attribute groups. Each attribute type can belong to at most one attribute group; the assignment of an attribute type to a group is optional, allowing for singleton attribute types. VDDT categorical attributes are now setup in Path as a combination of attribute groups and types – e.g. “Structural Stage” might be the group, while “Open” and “Closed” might be the types. A VDDT numerical attribute would be setup as a singleton attribute type in Path (e.g. “Habitat Suitability Index”). See the CEA_Sample.mdb that comes with the install pack for examples of each of these.
- Attribute types and groups are setup once for a Path project as part of the project’s definitions, and can be edited using the new File | Definitions menu. While attributes are the only definitions that can be edited at present, in the future all project definitions (i.e. state classes, transition types, transition groups, strata) will be editable from this same menu.
- Once attributes have been defined as above for the project, each combination of attribute type and state class is then assigned a numeric value using the new State Attribute Value scenario property (found under the Advanced tab); this value is then used as a multiplier on the area in each state class in order to calculate the corresponding value for each attribute. The state attribute values are provided for each scenario, allowing users to vary the way in which attributes are calculated between scenarios. Providing a numeric value of 1 for all state classes will cause the area in each state class to be summed only (i.e. no multiplier effect), thus creating the same result as is possible in VDDT using categorical attributes. See the CEA_Sample.mdb for an example.
- Attribute results now appear automatically in the runtime graphs, and can be aggregated / disaggregated by stratum; in addition there is a new Excel report that allows the attribute results to be exported.
