Matthias Maier [Tue, 6 Jan 2015 19:21:59 +0000 (20:21 +0100)]
CMake: Build up library name directly
The LOCATION property is deprecated starting with CMake 3.0. Further it
leads to an astonishing bug if used in CMake 3.1 [1]. Thus, we have to
build up the library name by hand.
Matthias Maier [Fri, 2 Jan 2015 11:43:21 +0000 (12:43 +0100)]
CMake: Also handle subminor version number
CMake now correctly queries the DEAL_II_PACKAGE_VERSION string for a
subminor version replacing "pre" and "rc?" by "0". The subminor version
number is also exported in the project configuration and the config.h
header file.
Timo Heister [Fri, 26 Dec 2014 10:27:59 +0000 (05:27 -0500)]
better @ref handling
Correctly handle @ref in the wrapcomments.py script. We need to keep the
description in quotes in one line and move everything else to the next line
except immediate punctuation.
Documentation: Remove all references to external resources
We already link to this external resources on the homepage - there is no
point in doing it here (nobody will find it and it has the bad tendency of
being out of date).
Well, we already have a detailed doxygen file about indentation. So it is
better to add the three relevant lines about astyle there and remove this
additional documentation page completely
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.
projects / dealii.git / log