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)
The problem here is that class DoFHandler only uses pointers to the
DoF faces and levels objects in the .h file, so we thought that we
don't have to #include the respective header files where these classes
are declared. But we also have a serialization function that uses
them and if you call it, the compiler will complain about undeclared
classes being used.