---

CB Planner Retrospective and Suggestions

---

It seems useful to retain a high-level description of the CBPlanner, which was used by PLASMA (and therefore IDEA) as its planner until September 2004 when CBPlanner was replaced by MIDWAY.

The basic structure of CBPlanner module was:

• It provided overall search control but did very little other than the highest level search algorithm for a chronological backtrack.

• A DecisionManager was used to manage the set of Open and Closed Decisions and to service the requirements of decision assignment and retraction. It managed the stack of closed decisions and transitions from open to closed.

• The OpenDecisionManager was responsible for retrieving the next open decision for the search. This involved the application of filters to determine the scope of flaws to work on and the heuristic selection over the set of open decisions for getting the next one. The items appearing below are filter conditions used to exclude candidate flaws from becoming open decisions. These filter conditions are:

HORIZON_CONDITION - excludes all tokens and their variables if they do not have at least one of their timepoints necessarily inside the horizon.

TEMPORAL_VARIABLE_CONDITION - excludes any variable that is a token temporal variable - start, end, duration

DYNAMIC_INFINITE_REAL_CONDITION - excludes any variable with infinite choices or dynamic domains

NO_BRANCH_CONDITION - excludes a given variable on a given predicate unless it is a singleton. Latter part was a recent extension for IDEA.

ATTRIBUTE_CONDITION (IDEA_CODE)- excludes token activation or merging decisions as well as variable decisions on all tokens which are listed to be ignored based on the Timeline Name and composing object.

VARIABLE_HAS_TOKEN_CONDITION - excludes decisions on variables that might be globals, or variables defined locally within rules, or defined on a class. Only permits decisions on Token Variables. (IDEA_CODE)

• Most of the work done in the Planner mode was spent managing the set of open decisions. The OpenDecisionManager buffered notifications from the plan database and constraint engine. These messages were processed to add and remove decisions.

• Processing occured "lazily" based on demands from the planner (via the decision manager). Most of the complexity was in buffer management.

• There is a HSTS extension to CBPlanner that provided additional heuristic support primarily. IDEA-DEV further customized the search to employ different strategies.

• Numbers printed for Objects (and their subclasses such as timelines), Tokens, Variables, and Constraints are unique integers over all entities in a plan database. These numbers are very useful for tracking the activity in a log file.

• Suggestions for debugging purposes:

• Enabling the plan database messages using :PlanDatabase will show all the activity on the database and is very useful for tracking what is happening on a decision.

• Enabling the constraint engine messages using :ConstraintEngine is useful for figuring out why you got an inconsistency, but it produces a lot of data. It will tell you the before and after state for every constraint fired.

• Enabling DecisionManager messages using :DecisionManager and :OpenDecisionManager is useful to see the steps in decision making, the choices, and what was filtered out.

• One final recommendation: When I write models or try to get a search working, I use PlanWorks all the time. The log files are useful up to a point, but often a visual inspection of the partial plan is required. In particular, this is true for looking at the timelines, and looking at the subgoal tree. In the latter, you will be able to observe in place the rule that fired to generate subgoals.

---

---

Contact information © IDEA