Issue #1228 ( https://issues.fast-downward.org/issue1228 ) introduced alternative precondition choice functions for LM-Cut.

There are a few implementation choices that may have an impact on performance and are worth checking experimentally:

* Check whether using dynamic programming for has_no_zero_cost_achiever improves performance:
https://github.com/aibasel/downward/blob/6230635ccff53e1df38ead53b057a2a0e9160275/src/search/heuristics/lm_cut_landmarks.cc#L237

* Check whether the tie-braking options should be exposed to the user. Instead, we could always enable the best-performing configuration by default or automatically select an option based on the best initial heuristic value.

* Check whether the order in which the tie-breaking rules are applied affects performance:
https://github.com/aibasel/downward/blob/6230635ccff53e1df38ead53b057a2a0e9160275/src/search/heuristics/lm_cut_landmarks.cc#L254
We testested this for the workshop paper. The current implementation uses the best-performing variant from those experiments. But, it makes sense to double-check.

I like the idea of computing the initial heuristic value of both, to have an estimate which one would preform better for the rest of the search.
However, unless there is a guarantee that the dominance for the initial heuristic value implies a dominance for all heuristic values, I would allow the user to set the option by hand.
I could imagine a parameter 'tie-break-strategy' with the option 'none', 'border_detection', 'goal_zone_detection' and 'auto', that does the comparison of the initial heuristic values.