/*!

\page essay04  CB Planner Retrospective and Suggestions

<hr>


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:

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

\li  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.

\li  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)

\li  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. 

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

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

\li 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.

\li  Suggestions for debugging purposes:

\li    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.

\li    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.

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

\li  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.

<hr>

*/
