Title notify all subscribing evaluators about initial state and transitions
Priority feature Status resolved
Superseder Nosy List florian, guillem, jendrik, malte, manuel, silvan
Assigned To guillem Keywords
Optional summary
This is part of issue727.

We want to allow all evaluators to subscribe to notifications about the initial 
state and state transitions.

Created on 2017-04-28.18:25:45 by manuel, last changed by malte.

This is part of issue727.

We want to allow all evaluators to subscribe to notifications about the initial 
state and state transitions.
msg6832 (view) Author: guillem Date: 2018-03-14.17:37:53
Changes merged.
msg6751 (view) Author: malte Date: 2017-12-13.23:53:38
Looks good to merge.
msg6750 (view) Author: jendrik Date: 2017-12-13.18:53:58
Good idea. I added it to the agenda.
msg6749 (view) Author: florian Date: 2017-12-13.18:44:01
Yes, the memory usage is in kB. The results look good to me. Small changes in
memory usage like the ones in this experiment are normal.

I was surprised to see out-of-memory warnings from slurm in the saticficing
experiment though. It looks like some jobs used close to our slurm limit of 4GB
before they were killed. This should never happen since we set a ulimit of 2GB.
This could be problematic since the memory limit of slurm doesn't always work
and will sometimes not be enforced. The tasks that use over 4GB could then take
away memory from other tasks on the same node. But I guess this issue is not the
right place to discuss this. Jendrik, should we add this to the agenda for the
next meeting?
msg6748 (view) Author: guillem Date: 2017-12-13.15:59:15
I have (finally!) uploaded some experiment results here:

They include configurations for:
* lama-first
* ehc(ff)
* A* + blind heur.
* A* + lm-cut
* seq-opt-bjolp

The only significant differences seem to be in memory usage (which I assume are given in KB).
I don't have a clear intuition of the source of these differences, although they are perhaps small enough to ignore them?
msg6743 (view) Author: guillem Date: 2017-12-07.13:20:21
Thanks Malte, sounds good. I have drafted an experiments setup for this, but 
probably best will be to steal yet 5 more minutes tomorrow to Jendrik/Florian to 
check everything is correct, and then we're good to run the experiments.
msg6702 (view) Author: malte Date: 2017-12-04.13:06:33
I'm done commenting on bitbucket. There are some issues to do with heuristic
caching and path-dependent heuristics that we should discuss (also with Salomé),
but I think we are ready for experiments either way.

I think the experiments should exercise all search algorithms that were changed
and both path-dependent heuristics ("regular" lmcount and synergy lmcount). If
we include lama-first, lama and seq-opt-bjolp, we have coverage of all
heuristics, I think. Choose whatever else makes sense to get coverage of all
search algorithms (e.g. something like EHC with the FF heuristic).
msg6656 (view) Author: jendrik Date: 2017-11-30.15:36:38
I'm happy with the code now :-) If you want, you could already prepare the Lab 
tests until Malte has time to review the code. One configuration that we should 
definitely test is lama-first.
msg6644 (view) Author: jendrik Date: 2017-11-30.11:27:42
I left some comments on bitbucket.
msg6643 (view) Author: guillem Date: 2017-11-30.10:41:45
Sure, I thought the repo was public, should be now.
msg6642 (view) Author: jendrik Date: 2017-11-30.10:13:04
I'll have a look at the code. Could you please give the group access to your 
msg6641 (view) Author: guillem Date: 2017-11-30.10:08:13
Incidentally, I was going to tackle the small issue mentioned in the "TODO" 

namely, that `notify_state_transition` returns a bool which is not used 
anywhere (I confirmed this). Would you rather open a new issue / deal with this 
msg6640 (view) Author: guillem Date: 2017-11-30.10:06:04
I have created a first PR with the changes we discussed in person here:
msg6611 (view) Author: florian Date: 2017-11-27.18:39:09
Added a cross reference to issue727.
msg6311 (view) Author: malte Date: 2017-05-02.11:43:31
My suggested answers to Manuel's questions: we should have a registration
mechanism similar to the current "get_involved_heuristics" method (but with a
new name) that recurses through the open lists and evaluators in order to let
them subscribe to notifications about the initial state and transitions.

This registration mechanism should make sure that the same evaluator is only
asked once whether it wants to register, even if it is reached multiple times.
(The same should be true for open lists, but currently it's not possible to have
an open list be used in multiple contexts.)

All evaluators should be able to subscribe, not just heuristics. In particular,
this mechanism might turn out to be useful for implementing g values and "real g
msg6310 (view) Author: malte Date: 2017-05-02.11:38:11
> If you look into use cases you could also check if we can use an OperatorID,
> OperatorProxy, or just remove the parameter.

Even if we don't currently use the operator parameter, I don't think we should
remove it. There are path-dependent heuristics other than the ones used in our
current codebase (for example in Salomé's LTL code), and it doesn't seem
unreasonable that a path-dependent heuristic should receive information about
operators associated with transitions.
msg6308 (view) Author: florian Date: 2017-05-02.10:21:10
A related thing we should look at is what kind of information the notification
should provide. In issue725 I tried to reduce the number of GlobalOperator* and
notify_state_transition is one of them. It currently takes two GlobalStates and
one GlobalOperator*. But the GlobalOperator* is never used (only forwarded). If
you look into use cases you could also check if we can use an OperatorID,
OperatorProxy, or just remove the parameter.
msg6275 (view) Author: manuel Date: 2017-04-28.18:25:45
A path dependent heuristic can subscribe itself to be notified about initial
state and state transitions that are reached during search.

Currently, FD uses subscriptions and notifications as follows:
- All evaluators can subscribe but only heuristics will be notified.
- All heuristics subscribe themselves but not each heuristic requires a

The current use of subscriptions and notifications raises following questions:
- Should evaluators also be notified?
- If yes, should an evaluator notify its sub-evaluators or should sub-evaluators
be directly notified, independent of the evaluator (e.g. SumEvaluator)?
- Which evaluators/heuristics require notification?

We want to evaluate different use cases (e.g. consider notification under
reopening of states) and look at their requirements. Based on those insights, we
wish to define which evaluators can subscribe, how they subscribe, and how they
are notified about the visited search space (e.g. transitions etc.).
Date User Action Args
2020-07-02 19:51:04maltesetassignedto: gfrances -> guillem
2018-03-14 17:37:53guillemsetstatus: reviewing -> resolved
messages: + msg6832
2017-12-13 23:53:38maltesetmessages: + msg6751
2017-12-13 18:53:58jendriksetmessages: + msg6750
2017-12-13 18:44:01floriansetmessages: + msg6749
2017-12-13 15:59:15guillemsetmessages: + msg6748
2017-12-07 13:20:21guillemsetmessages: + msg6743
2017-12-04 13:06:34maltesetmessages: + msg6702
2017-11-30 15:36:38jendriksetmessages: + msg6656
2017-11-30 11:27:42jendriksetnosy: - gfrances
messages: + msg6644
2017-11-30 10:41:45guillemsetmessages: + msg6643
2017-11-30 10:13:04jendriksetmessages: + msg6642
2017-11-30 10:08:13guillemsetmessages: + msg6641
2017-11-30 10:06:04guillemsetstatus: chatting -> reviewing
nosy: + guillem
messages: + msg6640
2017-11-29 14:00:49jendriksetassignedto: gfrances
title: Subscription and notification of path dependent heuristics. -> notify all subscribing evaluators about initial state and transitions
nosy: + gfrances
summary: This is part of issue727. -> This is part of issue727. We want to allow all evaluators to subscribe to notifications about the initial state and state transitions.
2017-11-27 18:39:09floriansetmessages: + msg6611
summary: This is part of issue727.
2017-11-27 11:15:27jendriksetpriority: meta -> feature
2017-05-02 11:43:31maltesetmessages: + msg6311
2017-05-02 11:38:11maltesetmessages: + msg6310
2017-05-02 11:21:02silvansetnosy: + silvan
2017-05-02 10:21:10floriansetnosy: + florian
messages: + msg6308
2017-04-28 18:25:45manuelcreate