This compilation of frequently asked questions is still under construction. It will get updated on an irregular basis, depending on the time I have available and the ideas that emerge from my support activities. This document has last been changed on December 22, 1997 .

- 1. Fixed Demand Equilibrium Assignment
- 1.1.
*Can EMME/2 also perform shortest path assignments?* - 1.2.
*What is meant by ``iterations'' in the auto assignment?* - 1.3.
*What do the the different gap stopping criteria mean?* - 1.4.
*Do I have to specify a relative gap stopping criterion?* - 1.5.
*Can EMME/2 also perform stochastic assignments?* - 1.6.
*Auto time matrix does not exactly match the network times - why?* - 1.7.
*Can EMME/2 do auto assignments which are not based on a one-hour period?*

- 1.1.
- 2. Variable Demand Assignment
- 3. Multiclass Assignment
- 4. Additional Options Assignment
- 5. Other Questions Regarding the Auto Assignment

Yes. This is done simply by using fixed times in the volume-delay and turn penalty functions (i.e. times not dependent on auto volumes) and by specifying zero for the maximum number of iterations. This results in an all-or-nothing shortest path assignment.

The auto assignment in EMME/2 uses the Frank-Wolfe algorithm to find the equilibrium network volumes and times by successive linear approximation. This is an iterative process in which, at each iteration, a new set of paths is computed (shortest paths based on the times that correspond to the current volumes) and mixed into the current solution with a weight (the so-called ``optimal step length'') which is optimal with respect to satisfying the equilibrium conditions.

As at each iteration exactly one path is generated for each O-D pair (not necessarily a different path, though), the number of iterations limits the number of paths used for a single O-D pair. E.g. an assignment that stopped after iteration 10, uses at most 11 different paths (iteration 0!) for one O-D pair.

There are two gap stopping criteria: the relative gap (fixed demand only) and the normalized gap (fixed and variable demand). The term ``gap'' (or also ``absolute gap'' to distinguish it from the relative and the normalized gap) refers to the maximum difference of the current solution from the equilibrium solution in terms of a (rather abstract) mathematical objective function. However, there is also a very intuitive interpretation of the absolute gap: It is simply the difference of the total vehicle hours computed with the current network volumes and times minus the total vehicle hours computed using the current shortest paths. As equilibrium is approached, this gap gets smaller, and at equilibrium it must be zero, since only minimum time paths are used.

The relative gap is the ratio between absolute gap and the current value
of the objective function, in percent. As the objective function is
a theoretical construct, the meaning of the relative gap is not easily
understandable (other than ``smaller is better'', of course), nor easily
transferable from one application to another. Note that the value
of the objective function increases as the trips get longer; so
for any given application the relative gap can always be made arbitrarily
small without changing the assignment, by simply adding a constant time
to all connector links. (But of course, this does **not** improve
the closure of the assignment!)

The normalized gap is the absolute gap divided by the number of trips. I prefer this stopping criterion, since it has a direct and easily understandable interpretation of how near the current solution is to the true equilibrium conditions: it corresponds to the average difference (over all trips) between the current mean trip times (weighted average over all used paths) and the minimum trip times. A normalized gap stopping criterion of 0.5 minutes e.g. implies that the assignment stops when the time difference between currently assigned and minimum path times is less than 30 seconds on the average.

No. In fact, if you do not use the relative gap stopping criterion, you can specify a value of -1 for it in module 5.11. This will cause the assignment to skip completely the computation of the objective function value, which is not really necessary for the assignment, but only needed to compute the relative gap. Depending on the complexity of the volume-delay function and the type of system used, this can save up to 10% of the total assignment CPU time!

Directly: No. But there is the macro
`stochas.mac`

available which implements a stochastic equilibrium or fixed
cost assignment. This macro allows for user definable random perturbations
on the link times (and is also a nice example on how to code pseudo random
number generators in EMME/2).

The auto time matrix corresponds to the times of the shortest paths generated during the last iteration of the auto assignment, whereas the network times (link and turn times) correspond to the final volumes of the assignment. Thus, the time matrix ``lags behind'' one iteration compared to the network times. As equilibrium is approached, this difference gets smaller and smaller, so that for assignments with a reasonable convergence this difference is negligible. (Note that this only holds for the fixed demand assignment, for the variable demand assignment, the time matrix is computed in the final ``half''-iteration and therefore always reflects the network times that correspond to the final volumes.)

If the demand used for the assignment is not based on one hour, it is by far the easiest solution to normalize it to one nominal hour within the period and then use the hourly demand matrices for the assignment to obtain the usual hourly traffic volumes.

If for some reason it is not desireable to use a one hour assignment period, it is important to note the following:

- The volume delay functions and turn penalty functions must not be based on the usual hourly capacities, but to capacities which correspond to the assignment period.
- The volumes produced by the auto assignment are not hourly volumes, but correspond to the volumes during the entire assignment period.
- Any fixed additional volumes used as precharge on links and/or turns must also be based on the chosen assignment period.
- Special attention is necessary when using the transit vehicles as part of the precharge volumes. In this case, the auto equivalence factors must be scaled by the assignment period in order to obtain the correct precharge values.

The auto demand functions only allows the six matrix parameters
`mat1`, `mat2`, ...,`mat5` and `mat6`.
This should be enough for most applications, if the following points
are observed:

- Check your demand functions for constant sub-expressions (i.e.
sub-expressions not involving
`upqau`) and replace them by a single pre-evaluated matrix. This not only saves matrix parameters, it also speeds up the assignment, since this way the sub-expressions are evaluated only once instead repeating the same computations over and over at every iteration. - If different demand functions access different matrices, these matrices can be grouped and overlaid, so that a single matrix contains for the O-D pairs of one function class a different parameter than for another function class.
- If the demand function uses several parameters with a limited value
range, these can be packed (up to 6 significant digits per packed matrix)
and unpacked ``on the fly'' in the demand function expression.
Since only two digits are used in the function index matrix, additional
information can be packed into the upper 4 digits, and then unpacked
from the parameter
`index`.

In the previous releases of EMME/2, this had to be done
using the additional options to compute, one class at a time,
the class specific volumes. Starting with Release 8, class
specific volumes can be saved directly into link and turn extra
attributes. This is done with the new option

` 5= generalized cost multiclass assignment with class specific volumes`

when specifying the type of single class / multiclass assignment. Note
that even if the option says ``*general cost*'' you can still get
a time-only based assignment by simply not specifying any fixed costs for
the classes.

As the additional options assignment is strictly a path following mechanism
it should never influence or alter the results of the main auto assignment.
If it does anyway, this is a sign that something went wrong!
In most cases, such differences are due to volume delay and/or turn
penalty functions which use the `volad`

/`pvolad`

parameter.
During an additional options assignment the additional volumes are used
to store the results. Thus, they cannot be used as parameters in the
functions. If they are used anyway, zeroes values are substituted for the
keywords `volad`

and `pvolad`

during function evaluation. If
you do need preloading in your model, recode your functions to access
user data items directly instead of `volad`

/`pvolad`

.

Yes, it can and it has been used for this purpose. The basic idea is rather
simple, as you only need to replace the normal volume delay and turn penalty
functions *s(v)* by the corresponding marginal cost functions
*m(v)=s(v)+v*s'(v)*.
This part is well known from theory and in general does not cause any problems.

By using these marginal cost functions you do get the system optimum volumes, but watch out when it comes to all other assignment results, such as impedances, auto times and speeds! These are not what you expect, since they are not what you expect, rather they represent marginal costs that do not correspond to the real costs. In order to obtain the corresponding real link and turn costs, the system optimum volumes have to be used as preloads in a dummy assignment with zero demand using the normal cost functions. If an average impedance matrix is needed for the system optimum, this can be constructed by repeating the system optimum assignment using the additional options with the real link and turn times from the dummy assignment.

When comparing average system optimum impedances with user optimum impedances, note that it is very important to have a good convergence of the equilibrium assignment. The user optimum impedance matrix approaches the optimum from below, whereas the system optimum approaches the optimum from above. Thus, if you get to the paradox situation that the system optimum is ``worse'' than the user optimum, you probably need to do more iterations on your assignments.

*Note that this is an ideal problem to implement in a
portable macro. I hope to be able to do this eventually. In case
someone has already developed such a macro, I would be very interested
to know.*

The macro
`demadj.mac`

can be used for this purpose. It is an implementation of the gradient
method for adjusting O-D matrices, which is described in detail in
my paper
*``A Gradient Approach for the O-D
Matrix Adjustment Problem''*.

Last changed on Mon Dec 22 11:36:14 MET 1997