Marking this as resolved.

I've split the remaining work into five separate issues:

 * issue120: implement LAMA-style action cost support
 * issue121: Reuse of heuristic values between different iterations of RWA*
 * issue122: merge emil-new branch
 * issue123: proper h_add and FF(h_add) heuristic implementations
 * issue124: use first/any achiever info in landmark costs

Of these, issue120, issue121 and issue123 have been marked as requirements for
version 1.0; the others have not.

I've used my best guess on what interests you to define the nosy lists for these
issues; of course feel free to edit.

Thanks! For better reference, I'll open two different issues for the two things
and close this one.

Going through the comments for this one, I found a few things (mostly minor, but
better not to forget them):

* LAMA has more fine-grained LM construction options (e.g. for reasonable orders
and disjunctive landmarks). I'll turn this into a more general issue of merging
features from the emil-new branch (which has these options as well as
conjunctive LMs and implementation efficiency improvements).

* LAMA also has a proper FF(h_a) implementation. IIRC, we have that as part of
the LAMA/FF synergy thing, but not in our plain FF heuristic.

* Erez mentions a change to the LAMA heuristic where an LM cost would depend on
whether it's achieved first or required again. If it's not implemented yet, it
definitely should at least be implemented as an option.

I think the only things that are missing are what Malte listed:

* the way that action costs are handled in LAMA (the +1 thing)
* reuse of heuristic values between different iteraions of RWA*

I can take care of them (the heuristic cache might be a bit problematic, but 
we'll see when we get there)

Yes, if you want this to be handled soonish we'll have to reassign it
to someone else. Sorry, but I'm flat out with thesis writing.

Erez, can you confirm or deny that the other features mentioned in the messages
below have been ported (the various LM generation methods etc.)? Would be good
to have a complete list of open ends, which we might then split up into separate
issues.

Nominating this for 1.0 -- we really should have something that can at least
roughly replicate LAMA's behaviour in our codebase, or else everybody will have
to keep using two codebases for a long time.

Silvia, I know you're not in a position to work on this in the near future.
Shall we reassign this to someone else?

Erez, what is still missing in the current version of the code to reproduce
LAMA's behaviour, at least for the most part?

Two things I can think of:

 * the way that action costs are handled in LAMA (the +1 thing)
 * reuse of heuristic values between different iteraions of RWA*

Anything else?

I would go with LAMA's FF(h_a) implementation. If we feel like it, we can
investigate other alternatives later.

LAMA also uses a more exact implementation of the FF heuristic than Fast
Downward, i.e. not the "poor man's h_add" exploration (see note at top of
ff_heuristic.cc in trunk).

Do we want to make both implementations of that exploration available (e.g.
configurable by option) within the ff heuristic class?

Sounds good -- but if we do that, let's do it after we've integrated things and
compared runtime. Otherwise it'll be hard to find out if we messed anything up
speed-wise.

I had an idea about landmark costs for LAMA - when a landmark has not been reached 
,use the cost of the cheapest first achiever as the cost of the landmark. If a 
landmark is needed again, use the cost of the cheapest possible achiever.

I will merge the rest of things in landmarks.

Action costs is also something that is in lama-trunk but not in lama-integration.

That issue of costs also plays into lama-experimental, as the latter is various
different ways of handling action costs. I don't actually think we need to merge
the lama-experimental stuff.

Synergy between FF and LAMA is indeed not implemented, so we'll have to think of
how we can do that. I think it will be time-critical.

Erez has merged everything that was in lama-integration as of r3309 into the
trunk. We still need to merge:

 * whatever is in "landmarks", but not in lama-integration@3309.
 * whatever is in lama-trunk, but not in lama-integration (such as the
   weighted A*, I think)
 * whatever is in lama-experimental and should be kept.

For the weighted A*, we need to coordinate. Silvia, is there anything else in
LAMA-trunk that we should merge?

Also, the synergy between FF heuristic and LAMA heuristic is currently not
implemented. (We think.)

Decision:
 * start from lama-integration, add some things from landmarks
 * don't integrate Jörg's stuff
 * options can be put back in again later, for now take landmarks_graph.cc/h
   implementation from LAMA

Some parts of the landmarks branch (not to be confused with the lama branch)
that are missing from LAMA should be integrated, namely:

 * Zhu & Givan's landmark generation method
   => landmarks_graph_zhu_givan.cc/h
 * Hoffmann et al.'s landmark generation method
   => landmarks_graph_old.cc/h
 * exhaustive facts landmark generation (testing all facts for RPG
   landmark-ness)
   => landmarks_graph_rpg_exhaust.cc/h

There are also some options that control various aspects of landmarks that we
may or may not want to integrate (switching disjunctive landmarks on/off;
switching reasonable orders on/off)
  => planner.cc/h
  => landmarks_graph.cc/h

Finally, there is the LM-local search procedure of Hoffmann et al., which we
currently do *not* intend to migrate
  => local_landmarks_search.cc/h