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).
Timo Heister [Sun, 12 Jul 2015 21:33:09 +0000 (17:33 -0400)]
set cxx14 cmake variable correctly
The with_cxx14 flag was incorrectly set as a variable instead of settings the
cached variable. This would cause some weirdness (cached and non-cached
variables of the same name coexist). Before this patch, "DEAL_II_WITH_CXX14 =
OFF" would be printed twice in the feature section.
Reformatting has destroyed the formatting of this comment and made it
difficult to see what it actually was supposed to mean. That said, I'm
also not entirely clear what exactly the TODO referred to to begin with,
so remove it.
David Wells [Sat, 4 Jul 2015 12:27:51 +0000 (08:27 -0400)]
Fix comments on a code sample.
The comments and code were intercalated in an incorrect manner, where
some comments were uncommented and some code was (incorrectly)
commented. I also fixed a small error in the example code (the dof
handler was not associated a triangulation).
projects / dealii.git / log