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 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:
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''.