Simplified version

The simplified version assumes that all activities operate near their typical duration.  In this case (see here), one can approximate the marginal utility of activity duration (i.e. the marginal utility if the sum of all activities is extended by that amount of time) by beta_perf .

Now let us consider the typical changes (of the Vickrey scenario).  Note that in the Vickrey scenario, the meaning of the marginal utility of arriving earlier means the marginal contribution assuming that the travel time remains the same.  We will assume that activities are ended by the endtime attribute, not by the duration attribute.

Travel takes longer (by amount deltaTtime)

In this situation, the activity that follows the trip is cut short by deltaTtime.  We thus have the following (linearized) modifications of the utility:

• Travel takes longer by deltaTtime; the utility change is beta_travel * deltaTtime .  Note that beta_travel typically is negative.
• The following activity is shortened by deltaTtime; the (linearized) utility change is - beta_perf * deltaTtime .  beta_perf is typically positive, so the contribution is negative.

Overall: The (linearized) utility change caused by longer travel is

( - beta_perf + beta_travel ) * deltaTtime

Traveller increases arriving early (by amount deltaEtime)

In that situation, the traveller will "do nothing" between the arrival and the opening time of the activity.  That is, the amount of time that the traveller is doing nothing is now increased by deltaEtime.  Consistent with the meaning of the Vickrey parameter "marginal utility of arriving early", we assume that the travel time is the same compared to the later arrival. This means that the preceeding activity was cut shorter by deltaTtime.  We thus have the following (linearized) modifications of the utility:

• The preceeding activity is shortened by deltaTtime; the (linearized) utility change is - beta_perf * deltaEtime .  beta_perf is typically positive, so the contribution is negative.

There are no other contributions, since the time between the arrival and the opening time prodices neither positive nor negative utility contributions.  Overall: The (linearized) utility change caused by arriving early is

( - beta_perf ) * deltaEtime

Traveller increases arriving late (by amount deltaLtime)

In this situation, we have the following (linearized) modifications of the utility:

• The preceeding activity is extended by deltaLtime; the (linearized) utility change is beta_perf * deltaLtime .  beta_perf is typically positive, so the contribution is positive.
• The following activity is shortened by deltaLtime; the (linearized) utility change is - beta_perf * deltaLtime .  beta_perf is typically positive, so the contribution is negative (and exactly cancels the previous contribution).
• Arriving late is increased by deltaLtime; the (exact) utility change is beta_late * deltaLtime .  beta_late is typically negative, so the contribution is negative.

Overall: The (linearized) utility change caused by increasing the amount of arriving late is

beta_late * deltaLtime

Overall

Overall, calibration of the Charypar-Nagel scoring function is best done as follows:

• Run a survey and estimate logit models that include penalties for travelling (by mode), schedule delay early, and schedule delay late.
• The marginal utility of schedule delay early from the logit model, multiplied by minus one, results in the MATSim beta_perf.  Since the marginal utility of schedule delay early is typically negative, beta_perf is thus typically positive.  This is the marginal opportunity cost of time.  A useful interpretation is that this is the difference between "leisure" and "doing nothing".
• The marginal utility of travelling from the logit model, plus beta_perf, results in the MATSim beta_trav (by mode).  That is, the MATSim beta_trav is an additional utility offset when compared to doing nothing.  Since driving can well be seen as more positive than doing nothing (e.g. because of making phone calls, listening to music, enjoying to drive), the MATSim beta_trav can well be positive.
  (Note that this has still nothing to do with "positive values of travel time", e.g. by Susan Handy.  Those positive values imply that the additional utility offset over-compensates the marginal opportunity cost of time.  In other words, "time spent driving home" is (to an extent) seen more positive than "being at home".)
• The marginal utility of being late from the logit model results in the MATSim beta_late.
• Note that you also need reasonable values for opening time, latest arrival time, and closing time, in order to achieve that the schedule delay cost mechanics works in MATSim.  This is quite clear if you think about it; nevertheless, it has been forgotten uncountable times (in particular in studies that start from trips, not from full daily plans).

Without schedule delay

If you intend to run MATSim without time adaptation (TimeAllocationMutator), these things are not that critical.  In that situation, you just need to make sure that - beta_perf + beta_trav matches your marginal utility of travel time differences.  An easy way in our view is:

• Set beta_car to zero (i.e. assume that driving is as good or bad as doing nothing).
• Set beta_perf to the estimated marginal utility of travel time savings (make sure you get the sign right; beta_perf should be positive).
• Set (say) beta_pt to your estimated marginal utility of travel time savings (should be positive) minus the MATSim beta_perf.  The result may be positive (implying that spending time using the mode is better than doing nothing) or negative (implying that spending time using the mode is worse than doing nothing).

Note that even without time adaptation, beta_late may still have an influence if you have set the latest arrival times for some activities.

Full version

"Full version" would imply that we could calibrate the MATSim parameters also for situations where the actual activity durations are far from their "typical" values.  This could happen for two reaons:

• There are too many activities that need to be squeezed into a day.  A possible interpretation would be that beta_perf corresponds to the marginal utility of additional leisure time on, say, sundays, but the weekday activites cannot be shifted to sundays.
• There are too many activities that need to be squeezed into certain time periods, say between day care opening and closing, or into typical business hours.

Both of these interpretations make sense (in my view) and should be investigated for MATSim.  Presumably, there is already general research; it would then be necessary to bring that research and the MATSim formulation together.

As explained here, the MATSim scoring function has, under some circumstances (actual durations near "typical" durations"), some similarity to the Vickrey scenario.

The "typical" parameters of the Vickrey scenario are beta_early=-6, beta_travel=-12, and beta_late=-18.

For MATSim, as explained here, this translates into beta_perf=6, beta_travel=-6, and beta_late=-18.  These are the parameters that were, for a lack of estimated parameters, introduced into (the precursor of) MATSim approximately in 2006.

These parameters are multiplied with the beta_brain parameter, which can be seen as a separately configurable logit scale parameter.  A useful setting for this parameter was determined via systematic tests concerning the stability of the iterations, see here.

As a next step, an infrastructure to compare MATSim simulations with real world traffic counts was set up.  Only after that infrastructure was there, an attempt to calibrate the MATSim parameters from a survey was made.  This is documented here, unfortunately in German.  Two results were

• The estimated parameters all have the same order of magnitude as the MATSim default parameters (the "Vickrey" parameters).
• The results with respect to traffic counts were not considerably different from before.

The so-called "Charypar-Nagel scoring function" is used in many MATSim studies.  It is called that way because there is an ancient paper where this scoring function was introduced.

It uses a logarithmic utility of time for activities: U = beta * t_x * ln(x/t_0) .  I sometimes call t_x the "typical duration".

The first derivative of U is beta at the typical duration:

• dU/dx = beta * t_x / x

• dU/dx(x=t_x) = beta

Interpretation: marginal utility of duration at "typical duration" is indep of activity type. (*)

The second derivative of U at the typical duration is

• d^2U/dx^2 = - beta * t_x / x^2

• d^2U/dx^2(x=t_x) = - beta / t_x

An important consequence of this is that there is no separate free parameter to calibrate the curvature (= 2nd derivative) at the typical duration: beta needs to be the same across all activities, and t_x is given by (*).

A second consequence is that t_0 is largely irrelevant.  It shifts the function up and down, i.e. it determines how much you lose if you drop an activity completely.

In the original paper (and in most of MATSim), t_0 is set to t_x * exp(-10h/t_x) .  This has the (intended) consequence that all activities have the same utility contribution at their typical duration:

U = beta * t_x * ln( x / t_x / exp(-10h/t_x) ) = beta * t_x * [ ln( x/t_x ) + 10h/t_x ]

which is, at x=t_x:    = beta * t_x * [ 0 + 10h/t_x ] = beta * 10h .  With our usual beta = 6Eu/h, this results in 60Eu per activity.

The slope at U=0, i.e. at x=t_0, is

(beta * t_x / t_x) * exp( 10h/t_x) = beta * exp( 10h/t_x )

which decreases with increasing t_x.  This means that activities with larger typical duration are easier to drop completely.

In the end, this makes sense: Since the additional score of any activity is the same, the score per time is smallest for activities with long typical durations.  Therefore, it makes sense to drop them first. 

But practically, this is probably not desired behavior, since it would first drop the home activity from a daily plan.

Overall, therefore: In my opinion, the current utility function does not work for activity dropping.

An alternative, never tested since activity dropping was never tested with this utl fct, would to to recognize that U'(t_0) = beta * t_x / t_0 , i.e. increasing slope with decreasing t_0.  That is, high priority activities should have t_0 such that t_x/t_0 is large (large slope = hard to drop).  Activities of the same priority should have t_0 such that t_x/t_0 is the same between those activities.  Overall, something like

weight \propto t_x/t_0

or

t_0 \propto t_x/weight

where large weight implies a large importance of the activity.

This was, as said, never tried, since activity dropping was never systematically tried.  It also does not fix the problem, discussed later, that different activities might have different resistance against making them shorter; since this is U'', this is  -beta/t_x with the above utl fct: activities are shortened proportional to their typical duration.

To make matters worse, there is currently the convention that negative values of U are set to zero.  This is done since we need useable values for negative durations (since they may happen at the "stitching together" of the last to the first activity of a day), and if we give those a "very negative" score, then the utl at t=0 cannot be even smaller than this.

This has, however, the unfortunate consequence that the "drift direction" of the adaptive algorithm, once an activity duration has gone below t_0, goes to zero duration.

Outlook: What would we want for our next generation utl function?  Some wishes from my perspective:

• Curvature at typical duration can be calibrated
• Slope at U=0 can be calibrated
• Utl function extends in meaningful way to negative durations (this would fix the arbitrary handling that we currently employ)

In my view, a polynomial of second degree would be worth trying. As usual, there are several ways to set this up.  One way is to expand around the typical duration:

U(t_x + eps) = U(t_x) + eps * U'(t_x) + eps^2 * U''(t_x)/2

or

U(x) = U(t_x) + (x-t_x) * U'(t_x) + (x-t_x)^2 * U''(t_x)/2

with t_x = typical duration, U'(t_x) = beta = marg utl at typ dur, U''(t_x) = curvature at typ dur ("priority"), and U(t_x) = "base value of act" (which could be something like beta*t_x ).

Another way (having the parabola going through (0,0)) would be

U(x) = - a x ( x - c ) = - a x^2 + a c x

U'(x) = - 2 a x + a c

prio = U'(x=0) = a c , i.e. c = prio/a .

beta = U'(x=t_x) = - 2 a t_x + prio, i.e. a = (prio - beta)/2t_x

There is other work (e.g. by Joh) that should be looked at.