Implemented computation of shape function 3rd derivatives in real cell, except in FE_PolyTensor

Merge pull request #1546 from tamiko/fix_testsuite

Testesuite: Bugfix: Fix configuration for with_64bit_indices

Testesuite: Bugfix: Fix configuration for with_64bit_indices

Merge pull request #1545 from tamiko/fix_cxx11_thread_check

CMake: Bugfix: Export -pthread when trying to link

CMake: Bugfix: Export -pthread when trying to link

It turns out that clang is a bit more picky and wants to have -pthread
on the command line.

Merge pull request #1517 from tamiko/complexify

Tensor<rank,dim,Number> - major cleanup

Bugfix: Use generic initializer in Tensor::norm()

Do not use Tensor<..>(bool) contstructor in headers and testsuite

Cosmetic change: Attach operator to conversion type

Tensor, Point: Remove constructor taking a boolean argument

This boolean has no effect any more. Simply remove it.

Cosmetic change: Use member initializer list

Bugfix: Put tensor_base.h back in place.

Bugfix: Remove an unnecessary second pass for value initialization

Bugfix: Avoid C++11 only syntax

Workaround for a bug in gcc-4.8 wrt to operator* and mixed std::complex types

Bugfix: Dissallow access to an object of type Tensor<rank,0,Number>

Well, there is no sane way of accessing such an object. Unfortunately, the
"degeneration" operator[](void) is not part of the C++ language...

So, dissallow any access to the value but allow creation and comparison of
this object...

Remove unnecessary specializations and a confusing comment

Obsolete tensor_base.h, refactor everything to tensor.h

Bugfix: Avoid temporaries

Bugfix: Only run this test in C++11 mode

Bugfix: Remove ambiguity.

With the rest of Tensor<0,dim,Number>'s interface this operator= is
redundant.

Bugfix: Do not use C++11 features

Bugfix: Add more typetraits to ProductType for non C++11

Bugfix: Allow creation and handling of Tensor<rank, dim ==0>

Such objects only store a zero (which doesn't make much sense to work with
them). But for certain situations in the library we need to be able to
create such objects.

Bugfix: Remove superfluous operator<< and fix ambiguity

Bugfix: Tensor<rank,dim>: Always store a tensor type internally

Bugfixes: Update wrong descriptions, fix typos

Bugfix: Update Point<dim,Number> documentation, fix norm, norm_square

Both are supposed to return a real valued scalar product. Update
documentation and implementation accordingly.

Bugfix: Avoid C++11 features

Do not use template default arguments for function templates.
Also provide fully templated interface for scalar multiplication with
point, too.

Bugfix: Promote VectorizedArray<Number> to a scalar type

Now, every operation concerning Tensors are guarded with the EnableIfScalar
type trait. Consequently, a VectorizedArray has also to be made a scalar
type.

run astyle

add a news/changes.h entry

Minor Bugfixes on Point<dim>

- use numbers::NumberTraits<Number>::abs_square to compute the squared
  euclidian norm

- allow scaling with arbitrary, compatible number type

- implement some functions directly to be independent of the Tensor<>
  implementation

Restructure declarations in tensor_base.h and tensor.h

Move everything that isn't necessary from tensor_base.h to tensor.h

Eliminate specialization for Tensor<1,dim>

This is more or less an exact code copy of Tensor<rank_,dim>.

tensor_base.h now contains the full definition of Tensor<rank_,dim>. All
external functions operating on tensors that are not strictly needed reside
in tensor.h.

Tensor<rank, dim>: Finish interface cleanup

Testsuite: Add a test for mixed type operations

Tensor<1, dim>: Finish interface cleanup

Tensor<0,dim>: Use cast instead of friend declaration to access value

Tensor<0,dim>: Also provide operators for scalar multiplication

Tensor<k,dim>: Remove superfluous operator* variants

It is completely sufficient to provide 1 ("one") templated variant.

I guess, over time more and more variants were added. This increased the
grade of ambiguity for the compiler to chose the one intended
implementation.

Tensor<0,dim,Number>: Implement mixed (tensor) operations

This allows arbitrary arithmetic operations of mixed value_type operands
such as real and complex valued tensors.

Bugfix: Fix type ambiguity for two calls to std::min

Merge pull request #1515 from tcclevenger/write_svg

Add SparsityPattern::write_svg

Merge pull request #1544 from maieneuro/remove_compute_2nd

removed compute_2nd as hessians are analytically computed

removed compute_2nd as hessians are analytically computed

Add SparsityPattern::print_svg

Merge pull request #1541 from tjhei/enable_muelu_tests

enable muelu tests with newer Trilinos

enable muelu tests with newer Trilinos

Merge pull request #1516 from tjhei/new_inst_file_splitting

rework fe_values.cc inst splitting

address comments

- rename files

Merge pull request #1534 from drwells/refactor-q1-mapping-with-exceptions

Use exceptions to mark Q1 transform failures.

Merge pull request #1536 from tamiko/fix_cxx11_thread_detection

CMake: Avoid running CXX11 Thread support test

Merge pull request #1539 from tamiko/gold

Use gold instead of the traditional linker if possible.

Use exceptions to mark Q1 transform failures.

The previous implementation returned magical numbers in some instances.

CMake: Refactor check for -fuse-ld=gold into check_01_compiler_features.cmake

Use gold instead of the traditional linker if possible.

Merge pull request #1522 from bangerth/further-FEValues-cleanups-32

Make MappingQ1::InternalData more generic

Reapply a patch that would otherwise have been lost in a rebase.

Store the correct polynomial degree in MappingQGeneric.

Currently, MappingQ derives from MappingQ1 which passes 1 down as polynomial degree.
This worked 'by accident' because the polynomial degree is only used by MappingQGeneric
in get_data() and friends, which are overloaded by MappingQ. However, the correct
place to store the polynomial degree is clearly in MappingQGeneric.

Remove MappingQ copy constructor.

It is apparently not needed.

Simplify code.

Some more preparatory work for separating MappingQ/Q1.

Some documentation updates.

Also make the Q1::InternalData object in MappingQ a pointer since that
will fit better into the structure we will need later on.

Refactor MappingQ/Q1 into a common base class.

This patch separates out the common functionality for generic polynomial
mappings into a base class. It contains most of what used to be in MappingQ1
but really was not specific to p=1 mappings.

Make MappingQ::InternalData protected.

Remove a whole bunch of code.

None of this is needed any more now that the InternalData
class has been largely separated.

Move the computation of the Mapping values into initialize().

Rather than having to do it yourself right after initialize(), let initialize()
call the function that does that. This greatly simplifies a good deal of code,
and also leads to better parallelization.

Move the code that initializes the Mapping{Q,Q1}::InternalData into that structure.

This allows us to get rid of the two implementations of compute_shapes(). It also
significantly simplifies the logic which of the two functions actually need to
be called, since the InternalData object actually knows that itself.

Get rid of the awkward dispatch mechanism in MappingQ*::compute_shapes().

In particular, remove the manual dispatch to either the Q1 or Qp functions.

Attempt to disentangle MappingQ1 and MappingQ.

Store the polynomial degree in MappingQ1::InternalData, rather than
which kind of mapping created it.

Merge pull request #1533 from drwells/tria-iterator-greater-than

Add operator< to TriaRawIterator.

Documentation: Increase minimal compiler versions to reflect reality

CMake: Avoid running CXX11 Thread support test

We have had multiple problems with running this test so far. The latests is
pull request #1524, the attempted fix opens another problem #1535.

Given the fact that the test tries to detect a problem with gcc-4.5, just
check for successful compilation.

Add operator< to TriaRawIterator.

This just switches the arguments to operator>.

Merge pull request #1532 from QiaoLei-88/step15Eqn

correct equation in intro of step-15

correct equation in intro of step-15

Merge pull request #1530 from asartori86/fix_multiple_parameter_loop

fix multiple parameter loop tests

new .inst splitting insolution_transfer.cc

fix multiple parameter loop tests

add changelog

move error_estimator code into templates.h

split compilation units

Implement .inst splitting in make_instantiations

Merge pull request #1377 from maieneuro/analytical_hessian_for_fe_poly_tensor

Analytical hessian for fe poly tensor

changed shape hessians in FE_PolyTensor to use analytical instead of numerical differentiation

Merge pull request #1520 from asartori86/prm_preprocess

Allow to use "\" in the file of parameters

allows continuation lines in ParameterHandler

Merge pull request #1524 from Rombur/cxx11_thread_bug

Workaround a bug with Ubuntu 14.04

Merge pull request #1525 from tjhei/sparsity_pattern_docs

update SparsityPattern documentation

update documentation

Workaround a bug with Ubuntu 14.04

Merge pull request #1521 from kronbichler/master

Attempt to fix non-C++11 code path

Attempt to fix non-C++11 code path

Merge pull request #1518 from tamiko/fix_openmp_simd_configuration

CMake: Fix openmp-simd configuration

add news/changes.h entry

CMake: Fix openmp-simd configuration

This enables openmp simd for Clang version 3.6 or newer (and the
corresponding version for XCode). Further, it unconditionally disables
the openmp check for any older clang version - checking for openmp support
with the flag only is unreliable

Merge pull request #1424 from davydden/fe_nothing_dominate

let make_hp_hanging_node_constraints() search for a common space in FECollection

fixed compiler warning in dof_tools_constraints

test make_hanging_node_constraints() with hp-ref and neither_element_dominates

simplified Grid generation in hp_constraints_neither_dominate_01

Also fixed indentation.