We do not divide the adaptive integrator order by two even when we have noises for two reasons:
(i) the adaptivity only works when the integrator is 'deterministic limited'
(ii) if the DE isn't stochastic and has deterministic order, the step strategy is unstable.  In the opposite case where we use the deterministic-order control for a stochastic-order problem, the step strategy is stable.

git-svn-id: https://xmds.svn.sourceforge.net/svnroot/xmds/trunk/xpdeint@2742 a0a4e76c-ba24-0410-a01c-b269113d594b
Better (but far from perfect) OpenMP support.

The trouble with parallelising the general loop operations (with threads) is that any operation could happen in those loops, and some of them aren't parallel-safe.  Using MPI frequently makes these operations safe because each process operates in its own memory space.

I've used the "UNVECTORISABLE" comment that I've previously used for operations which can't be vectorised to mark pieces of code which can't be parallelised in their current form.

The current implementation parallelises most user code loops (dpsi_dt = …) and integration loops and FFTs were already parallelised.  User code loops are only parallelised provided at least one dimension being looped over *isn't* being integrated over. e.g. looping over dimensions 'x' and 'y' and integrating over 'y' will be parallelised, but integrating over both won't be.

What's not parallelised?
* Situations where you integrate over everything.  This is quite common, e.g. calculating the number of particles by integrating over the density.
* The generation of stochastic noises.  But either you're only using noises for initialisation, in which case it's not much of a deal, or you're using dynamic noises in which case you should be using 'mpi-multi-path' anyway.
* In adaptive integrators, looping to calculate the maximum error.
* dx_dt = … code where the code non-locally accesses the integration variable 'x'.

In short, while OpenMP can make parallelisation relatively easy for a given code, doing it in general is not so easy.

git-svn-id: https://xmds.svn.sourceforge.net/svnroot/xmds/trunk/xpdeint@2743 a0a4e76c-ba24-0410-a01c-b269113d594b
Reduce by one the number of FFTs needed to evaluate the EX operator in some cases.

The evaluation of the EX operator uses an additional FFT because it transforms the solution to spectral space to evaluate the EX operator than inverse transforms *both* the solution and the EX operator.  As the solution is never modified, there's no need to do the inverse transform.

The solution I've implemented is to copy the solution vector to the results vector of the EX operator (provided this is safe) and then transform this vector.  As the original vector is never transformed, it doesn't need to be inverse transformed.  This optimisation is only safe in the common, but restricted situation in which only one EX operator is used (e.g. L[u], not Lx[u] and Ly[u]), and the EX operator is applied to all components of the vector.  E.g. if there's u and uDot, then just computing Lxx[u] won't get the optimisation.

Add testcases.

git-svn-id: https://xmds.svn.sourceforge.net/svnroot/xmds/trunk/xpdeint@2744 a0a4e76c-ba24-0410-a01c-b269113d594b
Add missing testcase results file.


git-svn-id: https://xmds.svn.sourceforge.net/svnroot/xmds/trunk/xpdeint@2745 a0a4e76c-ba24-0410-a01c-b269113d594b