Matthias Maier [Fri, 19 Dec 2014 11:33:45 +0000 (12:33 +0100)]
Test umfpack/umfpack_04: Avoid printing exact number of iterations
This commit introduces a new macro for tests to test an iterative solve to
convergence within a given number of iteration steps. Due to roundoff
errors the exact number doesn't have to be stable...
We assume that the pointers to a Trilinos sparse matrix remain valid when a matrix
is copied from another one or added and the two matrices share the same sparsity pattern.
This is used in step-32. However, the fix introduced in 8d64256 could not ensure this
(while fixing a few other cases). The check if the two sparsity patterns point to the same
memory is not good (we can have the same sparsity pattern memory but different addresses).
Therefore, the add and copy_from methods need to be more careful to not set up a new
matrix structure when this is not necessary. In particular, the two methods now check
whether the column indices are the same in any case but without requiring calling
methods that change the memory layout.
Commit 1d327fd1dcd34023a3d5bb2c0ee7524593d44015 moved a function from the .cc
file into the .h file and made it inline. Subtly, it also snuck in a small
change in the code: it changed
if (!something)
{
...
}
if (something)
into
if (!something)
{
...
}
else
The problem is that the first code block in rare circumstances changed the
value of the variable something. It is remarkable that this only triggered
in a single test in the testsuite -- an indication that the testsuite is
after all reasonably good at finding even obscure problems, but also an
indication that the anisotropic refinement stuff is not particularly well
tested.
Matthias Maier [Wed, 17 Dec 2014 00:58:28 +0000 (01:58 +0100)]
try to get the arpack test a bit more stable
Well, it turns out that depending on arpack version and CPU the result for
the first 5 eigenvalues differs. Try to make this a bit more stable by
computing 8 eigenvalues and only print the first 5.
Change the code so that checking whether a function parser object
has already been created now happens at the place where we use
the object, rather than as an early exit in the init_muparser()
function. I find that this makes the code easier to read.
This also allows us to remove the creation of a parser object on the
thread where the object is actually created. In many (most) cases,
we will simply create the parser later on anyway, but not necessarily.
This is for the same problem as reported by Krishna Garikipati
on the mailing list this week. He verified that this used to fail
and works now, so I would like to add it to the testsuite to make
sure we don't regress in this functionality.
Matthias Maier [Thu, 11 Dec 2014 19:49:34 +0000 (20:49 +0100)]
CMake: Correctly detect -Wno-... support for gcc
gcc does not emit a warning if an unknown -Wno-... flag is specified on the
command line, thus the ENABLE_IF_SUPPORTED macro unconditionally enabled
-Wno-... flags for gcc. Unfortunately, gcc _does_ emit a warning for the
unrecognized compiler option if another warning is emitted in the same
compilation unit. This is now fixed by always querying for the non-negated
version, i.e. -Wfoo instead of -Wno-foo.
Apparently, the initialization of a std::shared_ptr with NULL is not
allowed with the Intel compiler. It is also not necessary (that's what
the default constructor does anyway), so just remove the line.
The current implementation of SymmetricTensor<rank,dim,Number>::unrolled_to_component_indices
and its inverse function was only implemented for rank=2 and looked essentially like this:
Assert (rank == 2, ExcNotImplemented());
Assert (i < n_independent_components, ExcIndexRange(i, 0, n_independent_components));
switch (dim)
{
case 1:
return TableIndices<2>(0,0);
...
Such code cannot be generalized to rank=4 (in fact, it doesn't even compile
for rank=4) because we would have to return objects of different types
in any switch on rank. The only way around this is to use dispatch to
different functions that do the work for a particular rank.
This patch does the first part of this: set up the dispatch. Later patches
may in fact implement this function and its inverse for other ranks than 2.
Patch by Lukas Korous: Work around a compiler problem in Microsoft Visual Studio by disabling a safety check (for just this compiler) that should never trigger.
Patch by Lukas Korous: Remove the explicit instantiation of a function since this creates problems for Microsoft Visual Studio. The instantiation is not strictly needed since the function, internal::MatrixFreeFunctions::ShapeInfo<T>::reinit() is defined in a file that is always included.
projects / dealii.git / log