Some use cases may require to not shrink (one of the) components before merging
them. 
One example is when shrinking by h for non-goal variables. One solution would be
to use 
a strategy that would merge variables only if at least one goal is in (like linear 
strategies that start with a goal variable) and shrink only the merge product.

> With our existing strategies, semantically, it might not make a difference
> when factors are shrunk. I think this might be different with scenarios where
> one removes dead labels/irrelevant factors, which may trigger shrinking
> opportunities on any other factor. So I think the point to discuss here is how
> the user is able to control the main loop of the M&S algorithm. 

A general discussion of how to control the main loop of M&S is something that
makes a bit more sense to me because it can serve a more general need, although
I fear it's quite easy to end up in architecture astronaut territory.

I don't think the tracker is a good place for brainstorming the design of this;
I'd be happier for this discussion to happen somewhere else and move to the
tracker once it's clearer what is being proposed. But if you think we need a
"brainstorm a more general merge-and-shrink heuristic" issue, feel free to open
one. I won't be happy with it because I'd prefer us to be moving in the
direction of fewer open issues rather than more, but my being happy with every
issue is not a formal requirement.

From the previous discussion with Michael, I thought that this wasn't so much
about reproducing the M&S-lite strategy, but about controlling how to shrink. 

With our existing strategies, semantically, it might not make a difference when
factors are shrunk. I think this might be different with scenarios where one
removes dead labels/irrelevant factors, which may trigger shrinking
opportunities on any other factor. So I think the point to discuss here is how
the user is able to control the main loop of the M&S algorithm. 

Currently, the user can specify a global size limit on factors which is enforced
by shrinking *two* factors before being merged if their product would be too
large. Additionally, one can specify a size limit for individual factors that
will be enforced on *both* factors before merging them. What we currently cannot
do is to shrink a *single* factor to a desired size, regardless of the point in
the main loop this could happen. To allow shrinking single factors, a natural
point would be after merging because there we have a new, single factor. In such
a scenario, the user would control the size of individual factors, thus allowing
products to have squared size of the specified limit. 

I think Álvaro also once suggested to have this flexibility regarding when and
with which limit to shrink [adding him to the nosy list]. There might actually
be a discussion related to this in an issue that attempts at integrating some
linear shrink strategies.

[Also adding Jendrik because he wants to be nosy on every issue.]

> Yes, I aware of the existence of that paper, but I do not think it is
> implemented in Fast Downward.

I am sure they implemented it in Fast Downward; I don't think another
implementation of merge-and-shrink in the planning community exists. If you mean
that it's not in the master repository, that's true, but they would probably
provide the code if asked.

I will close this for now because from what I've heard so far I'm not convinced
of the cost/benefit ratio. That doesn't mean it shouldn't be implemented; feel
free to lobby with Silvan if you want to see it implemented. (But please not on
the tracker. Every open tracker issue has a very significant cost for us in
terms of diluted effort, time spent on the discussions, etc.)

More generally, I want to emphasize that we want to remain very selective in
what we add to the repository because without keeping growth in check, things
become unmaintainable for a team of our size and available resources.

Usually these days we follow a policy only to open a feature or wish issue for
new features (as opposed to cleanups, consolidation etc.) if someone has already
made a commitment to implement it and maintain it indefinitely. Without
something like this, the tracker grows without bounds and eventually becomes
impossible to use.

Adding something like the MS-Lite shrinking strategy might be a good idea for
inclusion, but someone with a good track record of maintenance would need to
champion the idea.

It would be nice to eventually have something like a "contrib" fork where it's
easy to add functionality but without the core team having to make a commitment
to keep it in sync and update and maintain it in perpetuity.

Yes, I aware of the existence of that paper, but I do not think it is implemented in 
Fast Downward.
Further, from my earlier discussion with Silvan, it seemed like there were additional 
requests for similar functionality. Silvan, could you maybe comment on that?

> Indeed, I was not clear enough. I would like to implement a very quick and simple
> shrinking strategy, considering abstract states with the same h value to be
equivalent.

That already exists. I think the keyword is "MS-Lite" or something along the
lines; was published quite recently. If you cannot find it, Silvan probably
knows the reference.

> BTW, unless all merge strategies ensure that there are no cases when two
factors with
> no goal variables are merged

Every tree over the variables is a valid merge tree, and many commonly used
merge strategies combine non-goal variables frequently. For example, the ones
based on symmetry do.

If I understand things correctly, it sounds to me like this would be better
implemented as a custom shrink strategy. Is it OK to close this issue then?

Indeed, I was not clear enough. I would like to implement a very quick and simple 
shrinking strategy, considering abstract states with the same h value to be equivalent. 
The problem with such a shrinking strategy is with applying it to factors that don't 
have goal variables.
I agree that an alternative approach is to define when *not* to apply shrinking. 
BTW, unless all merge strategies ensure that there are no cases when two factors with 
no goal variables are merged, you can end up with factors that are not atomic, and 
still don't include any goal variables.

Adding Silvan to the nosy list in case he can comment on this.

I'm not sure I understand the request. Except for when exactly label reduction
happens, which I think can already be configured, there is no meaningful
semantic difference between "shrink after merge" or "shrink before merge". Apart
from the atomic variables, a factor is created by a merge X and lives until it
is consumed by another merge Y. In between it can be shrunk. Whether we call
this a shrink *after X* or a shrink *before Y* makes no semantic difference.

Perhaps it would help if you can explain in more detail which behaviour you
want. I didn't get it in enough detail; from your description it seems that all
you need is a shrink strategy that does nothing if applied on a factor that
corresponds to a single non-goal variable.