There are a couple of places where we call a get_data() function
that returns a pointer to a base class when we know that the actual
data type is a pointer to derived class. We need to cast right back
to the derived class.
This can be avoided by using covariant return types where the get_data()
function returns a pointer to derived right away.
Make the CellSimilarity argument const also in Mapping.
Logically, these arguments are intended to be input arguments, so make them
const. Also, don't make them a reference as they are simply integral values.
That said, the original intention of having a reference was so that
mappings can indicate situations where cell similarity has to be
disregarded. Consequently, let the fill_fe_values() functions return a
cell similarity value that will then simply be assigned to the same
variable again.
Specifically, don't modify an input argument of the function but instead use the
old value and just modify the conditions in which it is used. This makes it clearer
when certain actions have to be performed.
Rewrite the FE_DGPNonparametric::fill_fe_*_values() functions.
Specifically, make sure that the FiniteElement::InternalDataBase object they receive is
really used specifically only for read-only purposes. This requires that we allocate some
memory in the fill_fe_*_values() functions for scratch arrays, but on the upside, we can
get rid of the FE_DGPNonparametric::InternalData class.
In the constructor of FESystem, we clone the base elements, which requires
constructing new finite element objects -- an expensive task. This patch
does this in parallel for the base elements.
Timo Heister [Sat, 18 Jul 2015 16:24:04 +0000 (12:24 -0400)]
Avoid Intel 15 bug in SymmetricTensor
This should fix broken behavior in deal.II/fe_values_view_{23|24|25} with
Intel 15.0.3, where the compiler sometimes forgets to initialize the static
fields.
Workaround: fix compilation with icc and linear_operator
Disables the sfinae lookup in the has_vmult_add helper class for faulty
icc. Intel's compiler up version 15.0.3 run into an sfinae bug otherwise.
For affected compiler versions, has_vmult_add will always report "false"
for icc which will result in a slight performance penalty due to
unnecessary temporary storage.
My understanding is that when FEValues calls the mapping, the mapping puts
its results into the FEValuesData base class of the FEValues object. Then,
FEValues calls FiniteElement::fill_fe_values which uses the mapping data
and its InternalData object to compute shape function information and again
put it into the FEValuesData base class of the FEValues object.
In the case of FESystem, this is a bit more complicated: Here, we don't want
the base elements to put their stuff into the FEValuesData base object
because the results of *all* base elements will go there (and because,
consequently, array sizes don't match, etc). Thus, FESystem::fill_fe_values
creates an array of scratch FEValuesData objects, passes these to the
base elements that fill them, and the copies back the data from the scratch
objects to its own base element. To make this work, FESystem has to also first
copy everything that's in its own FEValuesData base object to each of the scratch
objects.
This is where the bug lies: Currently, only one of the elements that the mapping
has computed is copied; we need to be consistent and do this with all
mapping related arrays in FEValuesData.
clang outputs '(nil)' when printing a null pointer, rather than '0'. This is not a bad
idea I suppose, but it is incompatible with other compilers. Change the test to just always
do it.
Bugfix: Do not test for inclusion of config.h in header tests
It turns out that sometimes [1] the testsuite picks up revision.h (and
config.h) as well.
revision.h does not include config.h and the test subsequently fails with
the DEAL_II_NAMESPACE_* not being found. Disable this check for the
revision.h test.
[1] For an in-source build and if an installed deal.II is tested.
Timo Heister [Tue, 14 Jul 2015 13:11:53 +0000 (09:11 -0400)]
disable cxx14 if cxx11 fails
Finally disable cxx14 if cxx11 detection failed for whatever reason.
Before we could end up in a situation with CXX14=TRUE and CXX11=FALSE
even if nothing was specified during configure time. Running cmake a
second time would then bail out.
We passed a data element around and stored it in a local class, but
ended up not using it after all. This is likely a leftover from a
previous iteration in the code. In any case, removing the member
variable turns out to compile and test fine, so we don't need to
pass this data to the constructor either.
Timo Heister [Sun, 12 Jul 2015 21:40:00 +0000 (17:40 -0400)]
BOOST no cxx11 warnings
Stop BOOST from trying to use variadic templates when we compile without cxx11
support. This only happens rarely (at least with mingw gcc 5 on windows).
projects / dealii.git / log