Software Development: On Testing and Comparing to Old Versions

One of my major tasks at work has been porting our old Fortran based distribution and mode choice software to Cube Voyager.  During this process, I have been testing and re-testing to ensure that my results from Voyager match the results that came out of Fortran.

The reason I am continually testing to match is because despite being old and having some bugs that I've had to fix, the mode choice process is technically sound.  If I started from scratch, I probably would not have done something nearly as in-depth as this.

One of the other tasks I've done was a new transit model.  Our old transit network, skimming, and loading models were in TranPlan, which is way old and outdated.  While programming the Voyager upgrade, I did settings and parameters to get things in the range of the what was coming out of the old TranPlan model.  This means that when I actually get the new mode choice ready, I should be close to still having a calibrated model (not! and why in a paragraph!).

The experience with the new mode choice and distribution has enabled me to find bugs in the old mode choice and distribution software.  The bugs include:

• Incorrect file reading format


• Failure to reset certain variables to zero causing transit trips to be assigned when there is technically no transit available


• Potentially incorrect script to calculate auto operating cost in park-n-ride and kiss-n-ride situations

That "not!" from above has to do with that very first bullet.  There was an extra field in the read script causing a fixed file format input of:

ZONE    HH1    HH2    HH3    HH4
  10     33    147    301    132

To be read as:

ZONE    HH1    HH2    HH3    HH4
  10   33.1   47.3    1.1     32

This caused transit trips to drop by about 25%.  Re-calibration, here I come!

Tags: cube, voyager, fortran, programming, software, testing

Former DOT Secretary weighs in on Transportation Bill

Reference: National Journal Online -- Insider Interviews -- Bush DOT Chief Discusses Reauthorization.

I agree with the thoughts of increased tolling and more fees other than the gas tax.  I also agree with $1B per year for technology, but it has to be managed right.

I'm also glad that the performance measures are measurable:

• Congestion (we can measure that - it is the percent of a region's network that is operating with a demand greater than its capacity)


• Costs (we can measure that, although we have to watch how we do it, as we don't want to have a system be considered bad if gas prices hit $4/gallon)


• Safety (we DO measure this - it is the number of injuries and deaths on the road)

Travel Demand Modeling 101 Part 1: Terminology

It occurred to me that many people likely do not understand all of the terminology of travel demand models.  Because of this, I felt the need to list many of them here.