We have merged this issue. There is follow-up work in issue628 and issue629.

I briefly looked at the code changes that affect the core (i.e., everything that
cannot be disabled) and made a few comments. I'm happy not to look at the rest. :-)

I was asking Martin, since I already talked to you about it. But if you want to
have another look, we could also delay the merge until next week.

Whom are you asking?

Can we merge it, then?

A* + LM-cut on the newest version in the por issue branch compared to A* +
LM-cut on the last version from default shows that the time and number of
expansions have remained the same (see below).

http://ai.cs.unibas.ch/_tmp_files/mwehrle/issue499-v1-issue499-base-issue499-v1-compare.html

(The version f4e72a652f92 which is compared to in msg5131 is much older.)

The sum of expansions until the last jump indeed has increased in most domains.

http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-simple.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-ec.html

I'm confused that the number of expansions is different for the two versions of
LM-cut. Does this include a change of the operator ordering? Can you include the
expansions until last jump in the report to make sure this is not only on the
last f-layer?

Regarding Malte's question in msg5127: A'>=A in all domains, B'>=B in all but a
few domains.

http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-simple.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-ec.html

f4e72a652f92 refers to the old version, 69f9b2915ed9 to the current version. 

The current version is additionally evaluated on the movie and storage domains,
so the overall coverage values need to be interpreted accordingly. For
stubborn-sets-ec, the old version contains the "active operators" flag in the
config-nick, which is included by default in the new version.

This is unrelated to Malte's commment because I wrote this before reading msg5127.

It seems like only the simple stubborn sets method was affected by the changes.
If we want to look into this later, we should start looking there.

I have a question regarding performance.

Let A be coverage of the old version without using POR and B be the coverage of
the old version with POR.

Let A' be the coverage of the current version without using POR and B' be the
coverage of the current version with POR.

If I understand you correctly, B' - A' is lower than B - A. If the reason for
this is that we speeded things up in general, that's fine. Can we make a
plausibility check of this? If this explanation is correct, we should have A' >
A and B' > B. Is this true in general, in all domains, in all but a few domains?

Renaming is done. 

The coverage increase gained by the POR methods is not as high as previously
reported, presumably because the base version of Fast Downward has become more
efficient. Recent refactoring also caused a slight coverage decrease, see below
for experimental results (Jan 10 compared to Jan 20). 

http://ai.cs.unibas.ch/_tmp_files/mwehrle/e10-01-2016-por-integration-report-abs-d.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/e20-01-2016-por-integration-report-abs-d.html

Still this seems ok to be merged now, as we can have a closer look at the
efficiency later on.

I have one general suggestion: I wouldn't call it "por" and
"PartialOrderReductionMethod" etc.

What the interface allows us is to prune successors, and possibly to reorder
them. (We haven't discussed the reordering part yet, but the reordering options
we have in one of our search algorithm could also very well be done here.)

Not all pruning methods are POR. For example, we could move the pruning based on
g bounds into a pruning method (which would have the advantage of being more
nicely composable), or we could do random pruning as in some search algorithms,
or we could perform dominance pruning, which is not partial-order reduction.

So I suggest to use a more general name like "PruningMethod" and directory name
"pruning" to reflect the more general purpose. (This name doesn't capture the
fact that this could also be used for reordering, but I don't have a good
suggestion for that.)

From my point of view this is ok to merge now. Malte, you recently said you
wanted to have a look at the changes in existing classes before we merge.

The changes are on Bitbucket:
https://bitbucket.org/mwehrle/por-integration/pull-requests/1/issue499

The following existing files have changes:
src/search/DownwardFiles.cmake (CMake plugin definition)
src/search/abstract_task.h (the Fact class for issue621)
src/search/options/option_parser.cc (help output)
src/search/search_engines/eager_search.cc
src/search/search_engines/eager_search.h

Considers the integration of two POR techniques for planning which have shown
best performance: simple stubborn sets (corresponding to the FD/forward
ordering) and SSS_expansion_core (which dominates expansion core), including
mutex-based interference.