Forum Replies Created
-
Posts
-
Could you possibly send us the offending mdb? I suggest you remove any results (in Path), open the mdb in Access, compact the database, then zip the mdb before emailing. Also please note the scenario that is giving you the trouble, and any steps required to reproduce the problem. You can email the zip file to info@apexrms.com
Thanks! Colin.
Here are my suggestions:
Daniel, C.J. and L. Frid (in press). Predicting landscape vegetation dynamics using state-and-transition simulation models. In: Kerns, B.K., A. Shlisky, and C.J. Daniel (eds.) 2012. Proceedings of the First Landscape State-and-Transition Simulation Modeling Conference, June 14-16, 2011, Portland, Oregon. Gen. Tech. Rep. PNW-869, Portland, OR: U.S. Department of Agriculture, Forest Service, Pacific Northwest Forest and Range Experiment Station.
Apex Resource Management Solutions Ltd. (2012). Path Landscape Model. Retrieved from http://www.apexrms.com/path
Can you possibly compact, zip and email the VDDT mdb to info@apexrms.com? If it is too large you can upload it to http://ftp.essa.com/incoming
Also please confirm the version of Path that you are using. Thanks, Colin
Hi Steve –
So far we have worked to remove as much of the complexity of working with TELSA as possible with the resources we have had available to-date. And we hope to remove all of the interaction with TELSA in the coming months.However at present you still need to understand certain elements of TELSA in order to use it with Path.
A brief summary of the steps involved to do a spatially-explicit run of Path can be found in the Path online reference guide at http://wiki.pathmodel.com/index.php?title=TELSA_simulation. You’ll see from the steps that you still need to know how to setup and use a portion of the functionality in TELSA – basically the ArcGIS functionality that is used to prepare maps (before a simulation) and then display maps (after a simulation). The rest of the configuration of TELSA is now integrated into Path.
So… no there is not a tutorial yet for how to setup TELSA – and the instructions mentioned above do assume you understand the basics of TELSA. For new TELSA users we generally suggest a bit of one-on-one support with Leonardo Frid (lfrid@essa.com) to get up the TELSA curve. You can also try reading the introductory material in the TELSA manual (that comes with the software download at http://www.essa.com/tools/telsa/), although this material is a bit out -of-date and will not match up exactly with the latest ArcGIS software tools. The material is not difficult, but unfortunately the documentation for TELSA has not kept pace with that of Path more generally.
If you have any thoughts for how best to disseminate this kind of information to our user community, please let us know. Thanks, Colin.
This is a problem with Access that I believe we can fix this quite easily. However it would be best for us to be able to replicate the error ourselves to be sure we’ve then fixed it correctly.
Do you have a database, along with a series of steps you do, that you could share with us so that we can replicate the problem? Would you be able to post it to ESSA’s incoming FTP directory (ftp://ftp.essa.com/incoming/) and let me know when it is uploaded at info@pathmodel.com
Thanks, Colin.
It is a bit trickier to import a VDDT model into an existing Path project than it was in VDDT. The reason is that VDDT allowed you to have different definitions for every model. This made it easier to import and export models, but the tradeoff was that you could end up with a collection of models in a VDDT project with different definitions – which made it difficult to run all of the models together and roll up the results. In Path we only allow one set of definitions for the entire project, so all strata (ie models) need to use the same definitions. This is what allows us to easily run models for several strata together when simulating an entire landscape.
The result is that you must ensure that any new model you are importing into Path – whether it be from VDDT or from Excel – uses the same definitions as exist already in the Path project. Here is how you can do this:
1.First, create a VDDT mdb that contains only the model(s) you would like to import to Path (create a copy of the VDDT mdb, then delete the unwanted models; or use the Export function in VDDT to export the models you are interested in).
2.Import the VDDT model(s) into a new Path project (using File | New From VDDT menu). This will automatically create a new set of definitions in Path corresponding to the VDDT definitions.
3.You then need to edit these new Path definitions so that they match those of your existing Path project. Note that you can open more than one instance of Path at a time, allowing you to display the definitions from the two projects side-by-side.
4.Once the definitions match then you can open both Path projects together (in a single instance of Path) and copy/paste the new model(s) from one mdb to the other. Note that you can only open multiple Path projects at once (in a single instance of Path) if all the projects have matching definitions.
I realize this isn’t perfect. Our plan is eventually to allow users to copy and paste models with different defintions into Path (including models from VDDT) – however this is not a trivial task, as this step requires reconciling the definitions in an intelligent way.
Thanks, Colin.
While riparian zones are often only a very small portion of an entire landscape, often these areas are still critical wildlife habitat and so difficult to ignore. It is for this very reason that the original architects of TELSA decided to represent spatial units using polygons rather than rasters – the tesselation step in TELSA allows one to preserve existing stand boundaries, including those representing sliver-like riparian areas, throughout the simulation process. Other landscape models that "rasterize" a landscape tend to wash out these small but important features.
Because of their importance to most of our users we find that modellers tend to separate riparian areas from neigbouring stands. However these areas can share the same natural vegetation dynamics as upland areas, if this make ecological sense. This would help you avoid creating a new "model" for these areas. What typically differs between riparian and upland areas is the management that is applied – in most landscapes the riparian zones are protected to some degree. By assigning the riparian areas to a different Path stratum, for example, you could then apply different management to the riparian zones. For example in the riparian strata you could set your treatment targets to 0 for management; alternatively you could also use multipliers to turn off all management in these areas.
Hope this helps, Colin.
It turns out this is a bug (for Path version 3.1 and earlier) – it will be fixed in the next release.
The problem is that if the value for the Location field of the Deterministic Transitions ends with zero then the import from Excel fails. As a workaround you can change the value for any Locations that end in zero to something else and the import will work. For example:
1. Highlight the Location column in Excel
2. Find and replace 10 with 25
3. Find and replace 20 with 26
Once the values are imported into Path you can change them back again if you like.Alternatively you can choose to avoid placing any boxes in columns 10 and 20 before you export your Deterministic Transitions.
The Location column records the grid location of each box when displaying the S&T model diagram in Path. The format is similar to that used by Excel – so A1 represents the upperleft grid position of a diagram. Note that you can view the grid used by Path for displaying boxes on the screen by right-clicking on a diagram and selecting "Show Grid".
To ensure your location values are correct before you import from Excel:
- All locations should use valid Excel-like notation for referring to grid cells (e.g. A1, A2, B1, etc..)
- The maximum number of columns for a diagram is currently 26 – so you can’t have a location with a column reference greater than Z
- You cannot have duplicate location values in your spreadsheet for a given stratum – in other words, only one state class can occupy each possible grid cell location for each stratum in your model.
From the error message it sounds like a problem with either 1 or 2 above. If it is #2 then we could look into expanding the number of columns in future releases of Path… however we didn’t ever anticipate anyone would use more than 26! Colin.
Could you possibly send us a copy of the mdb file associated with the model so we can try to reproduce the issue? Also let us know the name of scenario you were trying to open when you had the problem. You can email it to colin.daniel@apexrms.com. Best to zip the mdb and rename the file extension from zip to zzz in order to be sure the file passes through firewalls. Thanks! Colin.
Good question – this is functionality that is currently missing from Path but which we should hopefully be able to include in a future release.
In the meantime there is a round-about way to do this in Path right now:
- In Path use File|New From VDDT to create a new Path project (i.e. database) from an existing VDDT database. This will import all of the models from a single VDDT database into a new Path database. It will also import all of the definitions from the existing VDDT database. If you only want to import a subset of the models in your VDDT database, then first use the the File | Export | Project command in VDDT to create a new VDDT database that contains the subset of models you wish to bring over to Path.
- Now let’s suppose a little later you would like to import some additional VDDT models into this existing Path project. The trick is to create a second, new Path project (ie. database) by repeating step #1 above for the new set of VDDT models. With 2 separate Path projects created, you can now copy models from one Path project to the other. To do this open both databases together in the Path Project Explorer, then copy and paste models from one Path project to the other.
The one limitation here is that all of the VDDT models that you bring into a single Path project must all have identical definitions. In fact Path will currently only allow you to open two Path projects simultaneously if they both have identical definitions. As you may be aware, VDDT allows you to have different definitions for each model in a single database. This provides the flexilibility to have many different models within a single database. In Path we changed things so that all of the models in one "project" (i.e. database) must use a single set of definitions. This constraint was imposed to ensure that multiple models could be run together to represent a single landscape. We hope to be able to relax this constraint somewhat in future versions of Path.
Thanks for the feedback – let me know if you have any further questions/comments. Colin.
What I think you are referring to is the option in Access 2007 called "Compact on Close" which will automatically compact your database whenever you close it – however you must open then close the mdb using Access itself; the option does not apply when other applications (such as Path) open and close your database.
Unfortunately whenever you manipulate an Access database it seems to grow exponentially in size – the same is true when Path reads and writes to the database. At present the only solution is to periodically open your Path mdb file in Access, select Manage from the Office button, then select Compact and Repair. This will typically reduce the size of the mdb considerably.
If your mdb file is still large you can consider deleting some of the run results. It is also easy to copy scenarios from one database to another, and to have multiple databases open at once, so another option is to move some scenarios to a second copy of the mdb.
Hope this helps, Colin.
Just thought I would clarify a bit further. There are always ages and time-since-transitions present for all probabilistic transitions in both Path and VDDT. As Randy points out, the toggle on the Probabilistic Transition screen simply shows/hides these columns in the display – the underlying values for these columns are still present and used by the model even when not displayed. Note, however, that when a new transition is created, the default values for ages and time-since-transitions are set in such a way that they have no effect on the model predictions – for example the minimum time-since-transition value is always set to 0 by default. The result of this is that if you don’t ever use (or display) the age and time-since-transition columns, the model will still run as though these features were not turned on.
Hope this helps – Colin.
Good question. Given the high profile of climate change these days we get asked about this regularly. Such transitions are commonly used to represent shifts over time in species ranges.
At present the architecture of VDDT does not allow for transitions between "models", where each model is used to represent a biophysical setting (BpS). Because Path still uses VDDT as its simulation engine, it, too, is constrained by the limits of VDDT. However we are hoping to begin work on a new simulation engine for Path in the fall of 2011 that would allow use to overcome this limit and make it very easy to represent transitions between Path strata.
That being said there are some users that are already modelling these kind of effects in Path and VDDT. They do this by manually combining all of their biophysical setting models into a single "mega model", which then allows them to create transitions between BpS within the mega model. Combining models in Path is quite a bit simpler than in VDDT thanks to its cut/copy/paste features. However once you create a mega-model, you can’t easily go back to the individual models ever again. And of course the mega-model can become very large and difficult to work with. This is why we are hoping to tackle this question properly in Path in the near future.
Colin.
