Boost is no longer needed in dune-istl.

[release] Merge fix for handling 64 bit IDXTYPEWIDTH in parmetis>3

Tested with gcc-4.9.3 and clang-3.4.  Kinda tricky to make them both happy...

They do.

Well, at least they compile :-)  Don't know yet whether they actually work.

The new modules from the arpack feature branch were
never installed and this would have broken installed dune-istl
modules.

With this commit they now are installed for both CMAke and autotools.

the old code didn't work (at least not with clang). The reason is that constructs like
template<typename... Arg1, typename... Arg2> don't work, as the  compiler doesn't know
where to split the list of arguments. The whole algo_itsteps got reworked to allow for an
easier specialization for MultiTypeBlockMatrix. Now the struct is also parametrized by the
matrix type. By this we can easily add a specialization.

... thus we can always run the multitype examples

we have to preceed the variadic parameter by T1, in order to fix the deduction. The problem is
that (for what ever reason) otherwise the type pack can not be detected properly.

We use the same trick with std::integral_constant as in the MultiTypeBlockVector code.

added tests using the new eigenvalue algorithm class templates to
compute the spectral (i.e. 2-norm) condition number of the system
matrix associated with a 2D Laplace equation discretized using the
classical 5-point finite difference scheme

Check for the ARPACK++ library (needed for the new Dune::ArPackPlusPlus_Algorithms class template)

initial commit of one class template for performing some iterative
eigenvalue algorithms based on power iteration and of one class
template for performing some eigenvalue algorithms provided by the
ARPACK++ library

The code still uses boost::fusion, though.

These methods should be there in analogy to all other ISTL matrices.
Besides, this patch makes the code use them internally, which makes
for a few nice simplifications.

This removes the dependency on boost::fusion.  Using a bit of variadic template
magic makes the code a tiny bit simpler, too.

Note, though, that this change is not backward-compatible.  If you have previously
used

boost::fusion::at_c<i>(v)

to get the i-th entry of the vector v, you now have to change this to

std::get<i>(v)

Alternatively, you can start using operator[], and write

v[std::integral_constant<int,i>()]

We replace constructs like (if T is a MultiTypeBlockVector)

mpl::size<T>::value

by

T::size()

which I find easier to read.  Besides, using size() hides the fact that
boost::fusion is used for the implementation.

This method mimicks the behavior of normal vector access with square brackets like, e.g., v[5] = 1.
The problem is that the return type is different for each value of the argument in the brackets.
Therefore we implement a trick using std::integral_constant.  To access the first entry of
a MultiTypeBlockVector named v write

  MultiTypeBlockVector<A,B,C,D> v;
  std::integral_constant<int,0> _0;
  v[_0] = ...

The name '_0' used here as a static replacement of the integer number zero is arbitrary.
Any other variable name can be used.  If you don't like the separate variable, you can writee

  MultiTypeBlockVector<A,B,C,D> v;
  v[std::integral_constant<int,0>()] = ...

It has to be enabled via the property SKIP_RETURN_CODE.

The class already contains a method 'count', which returns the same value.
However, all our other vector types use 'size' for the vector size, not
'count'.

Additionally, the method is static and DUNE_CONSTEXPR, which is sometimes
helpful.

Both tests mainly test whether all interface methods compile, and whether
the resulting code does not crash (it doesn't).  A large part of the matrix
test has been copied from the file dune/istl/tutorial/example.cc, which
is really much more of a test than an example.

That test for MultiTypeBlockMatrix seems to trigger a valgrind complaint
inside BCRSMatrix.  I'll need to investigate this.

Both test executables are built even if boost fusion is not found.  In that
case, both simply return '77'.  I am aware that this may not be the official
way to handle the boost dependency, but I didn't want to spend to much time
on the corresponding cmake way to skip the test, given that my plan is
to remove the boost dependency anyway.

different versions of ParMetis.

Robert K authored 9 years ago and Markus Blatt committed 9 years ago

Parmetis has the option of using non-standard integral types
for the indices. In this case compilation failed. This is
fixed by using the type even for the graph representation
fed to metis/parmetis.

modification of member data. This is needed in OPM.