Blurb::
Specify which finite difference routine is used

Description::
The \c method_source setting specifies the source of the finite
differencing routine that will be used to compute the numerical
gradients:
\li \c dakota (default)
\li \c vendor


\c dakota denotes %Dakota's internal finite differencing
algorithm and \c vendor denotes the finite differencing algorithm
supplied by the iterator package in use (DOT, CONMIN, NPSOL, NL2SOL, NLSSOL,
ROL, and OPT++ each have their own internal finite differencing
routines). The \c dakota routine is the default since it can execute
in parallel and exploit the concurrency in finite difference
evaluations (see Exploiting Parallelism in the Users Manual 
\cite UsersMan).

However, the \c vendor setting can be desirable in some cases since
certain libraries will modify their algorithm when the finite
differencing is performed internally. Since the selection of the \c
dakota routine hides the use of finite differencing from the
optimizers (the optimizers are configured to accept user-supplied
gradients, which some algorithms assume to be of analytic accuracy),
the potential exists for the \c vendor setting to trigger the use of
an algorithm more optimized for the higher expense and/or lower
accuracy of finite-differencing. For example, NPSOL uses gradients in
its line search when in user-supplied gradient mode (since it assumes
they are inexpensive), but uses a value-based line search procedure
when internally finite differencing. The use of a value-based line
search will often reduce total expense in serial operations. However,
in parallel operations, the use of gradients in the NPSOL line search
(user-supplied gradient mode) provides excellent load balancing
without need to resort to speculative optimization approaches. 

In
summary, then, the \c dakota routine is preferred for parallel
optimization, and the \c vendor routine may be preferred for serial
optimization in special cases.

Topics::	
Examples::
Theory::
Faq::
See_Also::	
