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.
Matthias Maier [Wed, 26 Nov 2014 23:51:46 +0000 (00:51 +0100)]
Bugfix: adjust rotation for inverted matching
When constraining from face_1 to face_2 we have to use an (orientation,
flip, rotation) bitset that actually gives the relative orientation of
face_2 to face_1 (and not as specified face_1 to face_2).
This worked by accident because the constraining direction face_2 to face_1
is accidentally almost always used in all test cases.
Matthias Maier [Sun, 30 Nov 2014 13:31:46 +0000 (14:31 +0100)]
add another version of the dof_tools_21_b
that also tests for correct behaviour with hanging nodes. This is done by
additionally refining the second cube once. Test that constraining face_1
-> face_2 and the opposite direction face_2 -> face_1 give the exact same
result.
Matthias Maier [Sun, 30 Nov 2014 13:37:02 +0000 (14:37 +0100)]
Also check for reverse matching in bits/dof_tools_21_b
Also check for the inverse matching from face_2 to face_1 in the test
bits/dof_tools_21_b. Both directions must produce the same constraint
matrix except for the ordering of the constraints possibly being swapped.
Matthias Maier [Wed, 26 Nov 2014 22:38:39 +0000 (23:38 +0100)]
Code cleanup and several bugfixes
Refactor the creation of the final (possibly rotated) interpolation matrix
in make_periodicity_constraints into its own function. Add some additional
asserts to catch corner cases.
Return early if nothing to do (fixes dof_tools_21* tests)
projects / dealii.git / log