Evaluation Queue

The EvaluatorControl manages the evaluations. It has a queue of EvalQueuePoints which are points that need to be evaluated. The points are generated by SearchMethods, PollMethods, or other Steps derived from IterationUtils. The EvaluatorControl also handles the Evaluator(s).

The queue is implemented by a vector.

Points may be ordered before evaluation. This is useful for opportunistic evaluation, more so when there is little CPU available (few threads for OpenMP).

There are multiple sorting criteria: DIR_LAST_SUCCESS, LEXICOGRAPHICAL, RANDOM, SURROGATE; others like QUAD_MODEL should be added. See parameter EVAL_QUEUE_SORT. The default is DIR_LAST_SUCCESS.

The way the EvaluatorControl is implemented, the points at the end of the vector are evaluated first - they have the greatest priority.

Points are taken by threads for evaluation. As soon as a thread is done evaluating a point, it is free, and it pops the next point in the queue.

When a point is evaluated, updates are done:

• If opportunism is used, a FULL_SUCCESS will stop evaluations. Evaluations that are already in progress will continue, but no new evaluation will be started.
• Eval of the point is saved to the cache.
• The stats to be displayed are updated.
• Some members of EvaluatorControl, like the counter for the number of evaluations, are updated.

When evaluations are done because all points in the queue are evaluated, or because of opportunism, a single thread (the main thread) exits from the EvaluatorControl's run method. The other threads keep looping inside the run methods while waiting for new points to evaluate.

In the case of PSD-Mads, there is more than one main thread. Each subproblem has its own main thread. Additional threads, used solely for evaluations, are called secondary threads.