The doc now correctly describes
* that the overflow area is used during compress and not during assembly
* the meaning of avg and overflowsize
* the numbering dependence of this build mode
* the magic number 4
* the late failure during compress()

Adding a new template perameter before the existing ones is
a non-compatible interface change, because code that explicitly
instantiates the template will fail to compile afterwards.

Putting the new template parameter to the end fixes the issue

According to the Dune style rules, names with trailing underscores are reserved
for class data members.

Since the names of method parameters are not part of the API, they can be changed
without prior warning or deprecation period.

This includes the behaviour of its rows, thus the
CompressedBlockVectorWindow class

These header are no longer used.

modification of member data. This is needed in OPM.

When DUNE_ISTL_WITH_CHECKING is enabled, the BCRSMatrix throws an
exception when trying to access a row that has no columns. This creates
a problem in PDELab when using nested BCRSMatrices (as some people do
for operator splitting in PDELab), where an off-diagonal BCRSMatrix
block might be completely empty (i.e. have a correctly set up structure,
but every row in the off-diagonal BCRSMatrix is empty. If the PDELab
assembler then attempts to set a Dirichlet constraint, it has to access
the row to set all columns in that row to zero, but the check in
operator[] prevents it from doing so.

So this patch just drops that check.

While c++11 allows a trailing comma in enums,
we should avoid this because it provokes
gcc-4.4 warnings.

Jonathan Youett authored 10 years ago and Markus Blatt committed 10 years ago

When assigning a BCRSMatrix to another BCRSMatrix which was setup for
a different size/pattern, it segfaulted and I got the following
Exception:

"InvalidStateException [allocate:.../dune/istl/bcrsmatrix.hh:2108]:
Rows have already been allocated, cannot allocate a second time."

The problem was, that inside the assignment operator the rows (r) were
never deallocated. This commit fixes this and adds a testcase.

Testcase slightly modified by Markus.

- 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.

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.

- Don't do anything if we're in build stage notAllocated
- Reset pointers to nullptr after deallocating
- check whether rows have been allocated before accessing them

[BCRSMatrix] Prevent changing the implicit build mode parameters after matrix construction has started