Done.

For an unrelated reason, I recently implemented a new version of the causal
graph. This change resolves this issue, since the new implementation supports
different kinds of causal graph.

The old implementation is still around ("legacy causal graph") and used in the
places that previously used the causal graph. I've opened an issue to get rid of
it eventually (issue372).

If u doesn't occur in any preconditions or goal (in any given abstraction), it
is irrelevant (for that abstraction), so two states which only differ in u value
will have the same abstract goal distance -- so we don't need to worry about the
value of u.

I am almost convinced. What about states that differ only in the value of u?
Don't we want to distinguish between their values?

I think there is no point in including u in that case. If you consider the
situation before conversion into unary operators (since that itself is an
abstraction), then no operator in the projection to the fork variables has a
precondition on u, so why bother including it?

Every abstract plan in the abstraction without u can be mapped to an abstract
plan of the same cost in the abstraction including u, so there's no point in
making the problem larger.

In such an inverted fork this operator will be decomposed into two operators,
one changing u, and one changing v preconditioned by the effect value of u. 
I think there may be cases when you would like to have u in the inverted fork,
even if there is no goal defined on u.

The way I see it, the best choice between type (A) and (B) for structural
patterns might depend on whether or not you have a goal defined on the given
variable.

For example, in an inverted fork pattern for variable v, if there is a variable
u s.t. u and v are affected by some common operator but u does not have a
precondition in such operators, then there is no point in including u in the
pattern *unless* there's a goal defined in u (in which case it might be either a
good idea or a bad idea, depending on the specifics of the case and the cost
partitioning that is used).

Added Michael, since he had that problem (with structural patterns) a long time 
ago.

There are two "causal graph" variants that are interesting:

 (A) arcs from condition vars to effect vars and arcs between effect vars
 (B) arcs from condition vars to effect vars only

The standard definition is (A). However, our code actually implements (B).

This is actually preferable for some things. For example, for relevance
analysis, definition (B) is better because using it still allows us to do sound
pruning and gives us the possibility of pruning more than with (A). Extreme
examples of that can be found in Trucks-Strips (e.g. task #1).

However, we should *not* use definition (B) and call it "causal graph" without
further qualifications. Maybe call it "dependency graph" instead? Or even
something very descriptive like "condition-effect graph"?

We should go through the code that uses the causal graph and check for each
individual case which of the two definitions should be used. If necessary, we
should provide both graphs in the code (maybe implemented as a single data
structure with annotated edges that can give us both kinds of information).