I deleted the HTML files from the web, so I'm attaching the per-domain results
to this issue for posterity. (I don't think the very large per-problem results
are interesting enough to keep.)

OK, I removed the transition cost field and did a before/after comparison:

per-domain results:
http://www.informatik.uni-freiburg.de/~helmert/exp-issue276-eval-abs-d.html
per-problem results (warning, very large!):
http://www.informatik.uni-freiburg.de/~helmert/exp-issue276-eval-abs-p.html

Summary: In three of the six tested merge-and-shrink configurations (HHH 10K,
HHH 50K and DFP 200K), removing the transition costs increased coverage. In the
other three tested configurations (HHH 1K, HHH 100K, greedy bisim) it didn't
affect coverage. In the configuration I checked most thoroughly (HHH 10K), the
coverage difference was due improvements in four domains, with all other domains
unchanged. The impact on runtime seems to be small but positive. So I'm merging
this change and marking this as resolved.

I looked into this. There's no good reason for AbstractTransition to store a
cost at all, since it's not used for anything and increases the memory usage of
AbstractTransition by 50% (or more depending on alignment). The memory usage for
AbstractTransition is quite important for the overall merge-and-shrink memory usage.

So I'm testing now what happens to M&S performance if we remove the transition
cost field from AbstractTransition.

Alvaro reports:

"In abstraction.cc, Abstraction::compute_init_distances_general_cost() and
compute_goal_distances_general_cost(), to get the cost of a transition
get_adjusted_action_cost(g_operators[i], cost_type) is used instead of just
access to the attribute of AbstractTransition: trans.cost. I don't know if there
is a reason for this, but I think it is more consistent use the stored cost of
the transition."