Cube Voyager Speed Clinic
There are several issues with long travel demand model run times. Â Deep down, these are supposed to be planning tools, and taking too long for results can reduce the practicality of using a travel demand model in decision making.
In Cube Voyager, I’ve been finding more ways to cut runtimes down as much as possible, and below is the list with some of the rationale.
Keep JLoops at a Minimum
The Matrix program runs in an implied ILOOP.  This being the case, anything in the script runs many times (as many as the zones you have).  Using a JLOOP in a 2,000 zone model means that there are  4,000,000 calculations to be done for each COMP statement.  What happens if you have 3 COMP statements?  You go from 4,000,000 to 12,000,000 calculations.  This is even worse if the calculations include a lookup function, which are generally slow.
Keep Files Small – Only Write What You Have To
This is a no-brainer. Â The more that Cube (or anything, for that matter) has to write to disk, the longer the runtime.
Replace RECI with DBI wherever possible
DBI can be clustered (look for a post on that in the coming weeks). Â While I’m not sure if there is any difference on one core, being able to use Cluster is the trump card.
Use Cluster Dynamically and Wherever Possible
Standardize the Cluster ID in your code, but set the process list to a catalog key as with below:
DISTRIBUTEINTRASTEP CLUSTERID=Cluster PROCESSLIST=2-{CORES}
Using Cluster to your advantage is critical to having a fast model.
Tags: cube, four step model, speed, tdm, tour-based-modeling, trip-based-modeling, voyager
