Fixes flyspray https://dune-project.org/flyspray/index.php?do=details&task_id=1393
(not stopping if there is no convergence).
In addition each residual is only printed once now.

Some cmake specific dirs have been deleted in commit c66db537
but not removed from configure.ac resulting the build process to fail for the autotools.

Previously, the macros were installed to $(datadir)/cmake/. As we have
some macros in DUNE that might also be in other packages
this may cause conflicts in package managers. With this patch we install
them to $(datadir)/dune/cmake to resolve this issue. Together with the
last patch this will resolve problems  outlined in flyspray
task 813
https://dune-project.org/flyspray/index.php?do=details&task_id=813
I apologize for givin the wrong task number in the previous patch.

Previously, the macros were installed to $(datadir)/aclocal. As we have
some macros in DUNE that are also installed for some Linux distributions
this caused conflicts in package managers. With this patch we install
them to $(datadir)/dune/aclocal to resolve this issue outlined in flyspray
task 1409
https://dune-project.org/flyspray/index.php?do=details&task_id=1409

Previously, dependencies were not correctly searched for as
required packages. This patch fixes this.

For generating the config.h file we use the HAVE_* variables instead
of the CMake ones *_FOUND, Unfortunately, we sometines to not set
HAVE_* to the value of the *_FOUND vriable but to its name. Usually
we only query whether these variable are set at all. While
this often (except for psurface) does not pose a problem, it is semantically
wrong. Therfore this patch fixes this.

Kudos to Ansgar for pointing to this problem.

Arne Morten Kvarving authored 11 years ago and Markus Blatt committed 11 years ago

After adding UMFPack support, the printed log message was "Using DIRECTSOLVER"
which irritated users. With this path the actual direct solver will be
printed.

- Use std::copy instead of homegrown copy loop
- Avoid custom counting logic for consistency check

[Release][BCRSMatrix] Delay allocation of contiguous data array until after the pattern has been created

Due to the way BCRSMatrix construction works, you cannot write data to
the matrix before the pattern is finalized, except in the new implicit
build mode. This fact makes it possible to reduce the memory
requirements when building the pattern using an intermediate data
structure: That temporary data structure will usually be of about the
same size as the number of nonzero matrix entries. Thus by delaying the
allocation of the actual data array in the BCRSMatrix until after the user has
built up the pattern information inside the matrix and has had a chance
to deallocate the temporary data, we never need substantially more
memory than required for the matrix in any case, which avoids the
current memory spike during pattern construction.

That value indicates the amount of allocated memory, changing it tripped
a problem when copy-assigning matrices for me.

The full krylov basis is copied in the call of the method update(),
working with a reference to the krylov basis reduced the peak amount of allocated memory
by a factor of about 1.7 and improves the runtime by 4%.

Steffen: Also constified all applicable function arguments as suggested
         by Christian.

Closes FS#1378

[documentation,release] Make the UMFPack class appear in the doxygen even when not configured with UMFPack

The user should see from the documentation that he/she could use UMFPack,
provided the missing external dependency is installed.

Add missing underscore in PTHREAD_CFLAGS.
Add missing returns in solver functions.

- don't try to copy an incomplete matrix when passing it to rowWiseBuild
- test copy assignment in addition to copy construction
- make sure preallocated matrix can hold all inserted data

Previously, the tests supposed to fail would not have been
detected with -DNDEBUG. With this patch we use cerr to report problems
and return a nonzero error code on completion.

Previously there seemed to be a copy and paste mistake and bcrsimplicitebuiltest
used the same source file as bcrsbuildtest. This patch fixes this.

After the recent changes to BCRSMatrix, row and column sizes are now only
set by allocate() because several places assume a correlation between
the set number and rows and the allocation state. Thus the copy
constructor and the assignment operator don't directly copy those values
over, but initialize them to 0. The correct values are then set by
allocate. The row-wise build mode is a special case that requires
iterating over the source matrix rows before allocating memory.
Unfortunately, the copy constructor tried to use the (0-initialized) row
count of itself as iteration bound instead of the source matrix's one.

Fixed by doing the same thing as the assignment operator: Just use the
number from the source matrix.

Fixes FS #1394.

This reverts commit 5d8e6db1.

While the patch above fixes the issue in FS #1394, it creates an
inconsistency between the way the copy constructor and the assignment
operator work.

Reverted before applying a more consistent fix.

Due to the latest changes the number of rows was not copied correctly
in all cases.This patch introduces the old behaviour.
Should fix FS #1394.

This more easily triggers FS #1394