Here's an integrand that is highly oscillatory for large values of its first
argument:
f[w_, x_] = Sin[w*x]/(x^2);
For small w, NIntegrate automatically selects GaussKronrodRule as usual:
Reap[NIntegrate[f[1, x], {x, 1, 2}, EvaluationMonitor :> Sow[x]]]
For large w, NIntegrate's preprocessor decides the integrand is highly
oscillatory and uses its specialised Clenshaw-Curtis rule for oscillatory
integrands:
Reap[NIntegrate[f[10, x], {x, 1, 2}, EvaluationMonitor :> Sow[x]]]
(One way to tell that the specialised rule was used is to notice that the
endpoints (1. and 2.) were sampled.)
Now consider this example:
Reap[NIntegrate[f[1, x], {x, 1, 2}, Method -> "ClenshawCurtisRule",
EvaluationMonitor :> Sow[x]]]
As expected, NIntegrate's preprocessor does not decide to use the
specialised Clenshaw-Curtis rule (because w is too low to be called "highly
oscillatory"). However, the integration then apparently proceeds using
GaussKronrodRule rather than the requested ClenshawCurtisRule. Why is this?
One way to get around this for particular cases where you know it is going
to happen is to use the option "SymbolicProcessing"->0. But what should we
do if we *do* want symbolic processing, but want ClenshawCurtisRule to be
used (instead of GaussKronrodRule) in those cases to which none of
NIntegrate's specialised rules apply?