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.
Include mpi.h in base/config.h to avoid Intel compile error
On my system with Intel compiler, I used to get the following error:
In file included from /lrz/sys/intel/mpi_41_3_048/intel64/include/mpi.h(1279),
from [...]/deal.II/include/deal.II/base/mpi.h(23),
from [...]/deal.II/include/deal.II/base/utilities.h(21),
from [...]/deal.II/include/deal.II/base/index_set.h(20),
from [...]/deal.II/include/deal.II/lac/vector.h(24),
from [...]/deal.II/source/numerics/data_out_faces.cc(18):
/lrz/sys/intel/mpi_41_3_048/intel64/include/mpicxx.h(99): error: #error directive: "SEEK_CUR is #defined but must not be for the C++ binding of MPI. Include mpi.h before stdio.h"
#error "SEEK_CUR is #defined but must not be for the C++ binding of MPI. Include mpi.h before stdio.h"
^
This is Intel compiler 15.0 with Intel MPI. The solution to this problem is to include mpi.h early enough, which for us means to include it in base/config.h before we include types.h.
Timo Heister [Mon, 24 Nov 2014 13:04:03 +0000 (08:04 -0500)]
Fix mathjax on website broken due to https
The dealii.org webserver now tries to serve https sites. This breaks mathjax because of:
Mixed Content: The page at 'https://www.dealii.org/developer/doxygen/deal.II/step_31.html' was loaded over HTTPS, but requested an insecure resource 'http://cdn.mathjax.org/mathjax/latest/MathJax.js'. This request has been blocked;
We have a number of tests that use p4est output functionality, but the
format p4est writes in has changed in recent p4est versions. Delete the
lines that differ in normalize.pl and adjust stored test output files
accordingly.
A new way to initialize an FEEvaluation object (fast tensor product evaluation routines) has been introduced.
It takes the same arguments as the initialization method of FEValues, namely a Mapping, a FiniteElement, a
one-dimensional Quadrature<1> object, and update flags. This enables using FEEvaluation on the fly just as
FEValues. Since FEEvaluation treats objects of one base element only, this class can select which components
to read.
The concept is explained in the documentation of the FEEvaluation class and an example for the Laplace matrix
is given. However, it also works for the Stokes operator as shown by the test program assemble_matrix_02.
Improved comparison operators for TriaAccessorBase
The previous commit was a bit too aggressive because it is still useful to catch the case when comparing iterators to two different triangulations (leading to infinite loops).
Therefore, I now merely extended the assertion to not trigger when one of the two objects is default constructed, i.e., does contain a null pointer to tria. The comparison then does not need tria == a.tria because invalid iterators use invalid cell and level index, too (leading to !=).
Allow comparison == and != of TriaAccessorBase with different tria
It is well-defined to check for equality and inequality of TriaAccessorBase (cell_iterator types) that belong to different triangulations. Those are simply unequal. This is necessary e.g. for comparing with a default constructed cell_iterator variable. Of course, operator < is still undefined.
projects / dealii.git / log