Project Setup Data
Outline
The project level data defines specific aspects of your project that will further direct or constrain your Domain Model configuration. While the Domain Model provides a general framework for how your model will operate, the Project level setup data sets specific bounds and limits that are specific for the Network (i.e. Project) that you are currently working on.
Some Project level data is provided in addition to the Domain Model configuration, while other Project level data will override the Domain Model data. Project Level data elements you need to define are as follows:
- Budget Constraints (you can give each constraint set a different tag).
- (Optional) Treatment Rates to override default rates in Domain Model.
- (Optional) Lookup Tables to override default lookups in Domain Model.
For Cassandra Desktop, your Project Level data is defined in a Project Setup file, which is an Excel file with a specific format. You point Cassandra to this file location when you define your Work Bench.
Each of these setup data elements are discussed in more details below.
Budget Constraint Definition
Budgets need to be defined in your Project Setup file (Excel file with specific format) on sheets prefixed with ‘budget_’.
The Budget definition data on these sheets are used to define the budget constraints for all model periods. The figure below shows an example of a Budget Definition table for the Desktop version of Juno Cassandra. In this example, we have a categorised budget in which there are three budget categories, namely ‘Rehab’, ‘Resurfacing’ and ‘Maintenance’. These three budget category names need to match exactly (case-sensitive) the names of the budget categories you used in your Treatments Definition Data.
Once you have prepared your Budget Data in a table as shown below, you can import the data into Cassandra and store it under your project. When you store a Budget Definition, you need to provide a tag to identify the specific definition. Such a tag is a short code that allows you to quickly identify different budget definitions (e.g. ‘low budget’ or ‘high budget’ or ‘unconstrained’).
Your Budget Definition data should have a category that matches each one of the Budget Categories you used in your Treatments Definition Data, otherwise an error will be thrown at run-time to inform you of this discrepancy. That is, UNLESS YOU WANT TO USE A MONOLITHIC BUDGET (see note below) you can have more categories in your Budget Definition than there are Budget Categories in your Treatments Definitions data, but not the other way round.
Your budget definition data should also have a row that matches at least as many periods as there are in your model run. Thus, if you want to run a model over 35 years, you should have a row in your budget definition that matches each period between 1 and 35. You can have more rows/periods in your budget definitions file than there are modelling periods, but not the other way around.
Required Columns
The columns required for your Budget definitions data are self-explanatory if you consider the example above. The only mandatory column is the column named ‘period’ which denotes the modelling period. As explained above, the other columns in your budget definition table should match the values of Budget Categories in your Treatments Definition Data.
Monolithic Budget
If you do not want a categorised budget, you simply need to specify a single name for the Budget Category for each treatment in your Treatments Definition Data. For example, you can specify a dummy category name ‘monolithic’ or ‘all_treatments’ for your budget category for all treatments. Then, in your budget definition, you need to specify only one column apart from the ‘period’ column, and this column name should then match the dummy budget category you used in your Treatments Definitions Data (case-sensitive).
If you want to use a Monolithic Budget, you cannot have more than one column apart from the ‘period’ column. That is, your Budget Definition data should have only two columns. This requirement is needed for JCass to determine whether a monolithic budget is being used or not. If we can pre-determine that you are using a monolithic budget, some operations during optimisation can be optimised. No pun intended!
Project Level Treatment Rates
Project level Treatment Rates provide you with the option to override the default unit rates for the treatments defined in your Treatments Definition Data. You can define different sets of Project Level Treatment Rates in your Project Setup file on sheets prefixed with ‘rates_’.
At run time, Cassandra will first load the treatment rates defined for the Domain Model, and then it will override the treatment rates using the Project level unit rates for any treatment name that matches a treatment found in the Domain Model. This means that, if you have treatment names in your Project level unit rates that do not match names defined in your Domain Model’s treatments definition data, those treatment rates will be ignored because Cassandra does not know which treatment they apply to. A warning will be shown at run-time to inform you if your Project level treatment rates contain treatment names that are not in the Domain Model.
Any treatments with unit rates defined in your Domain Model’s treatments definition data that do not have matching names in the Project level treatment rates will be used ‘as-is’, meaning the default unit rates will apply.
The figure below shows the format for the import/upload template for Project level treatment rates:
Project Level Lookups
Project level Lookup Data provide you with the option to override the default Lookup Data defined in the Domain Model. Typically, your Domain Model Lookup data will contain thresholds, constants and calibration coefficients that provide control over aspects of your Domain Model.
These Lookup values are unlikely to apply to all Networks/Projects you encounter, and for this reason, Project level Lookups provide you with the option to override the default values in your domain model for a specific Project situation.
You can define different sets of Project Level Lookups in your Project Setup file on a sheet named ‘lookups’.
At run time, Cassandra will first load the Domain Model Lookups, and then override the lookup sets using the Project level Lookups for any lookup set name in the Project level Lookups that matches a name in the Domain Model Lookups. If your Project level Lookups contain set names that are not found in the Domain Model lookups, those sets in your Project level Lookups will be ignored and will have no effect on your model execution.
The import/upload template for Project level Lookups is identical to that of the Domain Model Lookup template, which is shown below:
