.. _method-coliny_pattern_search-stochastic:

""""""""""
stochastic
""""""""""


Generate trial points in random order


.. toctree::
   :hidden:
   :maxdepth: 1



**Specification**

- *Alias:* None

- *Arguments:* None


**Description**


Traditional pattern search methods search with a fixed pattern of
search directions to try to find improvements to the current iterate.
The SCOLIB pattern search methods generalize this simple algorithmic
strategy to enable control of how the search pattern is adapted, as
well as how each search pattern is evaluated.  The ``stochastic`` and
``synchronization`` specifications denote how the the trial points are
evaluated.  The ``stochastic`` specification indicates that the trial
points are considered in a random order.  For parallel pattern search,
``synchronization`` dictates whether the evaluations are scheduled
using a ``blocking`` scheduler or a ``nonblocking`` scheduler (i.e.,
:ref:`Model<Model>`::synchronize "Model::synchronize()" or
:ref:`Model<Model>`::synchronize_nowait "Model::synchronize_nowait()",
respectively).  In the ``blocking`` case, all points in the pattern are
evaluated (in parallel), and if the best of these trial points is an
improving point, then it becomes the next iterate.  These runs are
reproducible, assuming use of the same seed in the ``stochastic`` case.
In the ``nonblocking`` case, all points in the pattern may not be
evaluated, since the first improving point found becomes the next
iterate.  Since the algorithm steps will be subject to parallel timing
variabilities, these runs will not generally be repeatable.  The
``synchronization`` specification has similar connotations for sequential
pattern search.  If ``blocking`` is specified, then each sequential
iteration terminates after all trial points have been considered, and
if ``nonblocking`` is specified, then each sequential iteration
terminates after the first improving trial point is evaluated.  In
this release, both ``blocking`` and ``nonblocking`` specifications
result in blocking behavior (except in the case where
``exporatory_moves`` below is set to ``adaptive_pattern``).  Nonblocking
behavior will be re-enabled after some underlying technical issues
have been resolved.