Timo Heister [Thu, 9 Oct 2014 14:17:38 +0000 (10:17 -0400)]
Check in DoFHandler::renumber_dofs() that DoFs are distributed
- This adds several Asserts to check that DoFs are distributed
before calling renumber_dofs() for active or level DoFs.
- Note that we now also require that you call distribute_dofs()
before distribute_mg_dofs().
- Updated documentation.
Since these functions were moved to the header file, we no longer
need to explicitly instantiate them since every .cc file that uses
them will generate an instantiation where necessary.
Vijay Mahadevan [Thu, 9 Oct 2014 16:47:34 +0000 (11:47 -0500)]
Making the next_free_pair_object and next_free_single_object as inline functions.
Also contains a patch from Wolfgang with changes to the instantiation file.
Background: In release mode, GNU-4.8.x (OSX) seem to optimize away the calls when
specializing the template functions and then symbol definitions seem to be different
between debug and optimized modes. This causes undefined linkage for release mode.
Matthias Maier [Wed, 1 Oct 2014 13:08:18 +0000 (15:08 +0200)]
CMake: Remove test DEAL_II_HAVE_CXX11_ICCBOOSTSIGNALSBUG_OK
We cannot sanely test for this regression prior to boost setup. And after
boost setup it is incredibly ugly to do so because DEAL_II_WITH_STDCXX11 is
already processed.
CMake: Only use internal boost header (if available) for regression check
Fix a regression where a test for an icc regression in
check_01_cxx_features.cmake incorrectly used a generic <boost/signals2/...>
include. Such an include file doesn't have to be available at this early
point in the configuration run. User internal boost headers (if available)
instead - otherwise just test nothing.
If we avoid calling GlobalAssemble when copying from an Epetra_FECrsMatrix that uses a
non-local matrix (enabled for Trilinos 11.9 and greater), we do not run into some bad
code in Trilinos causing a segfault. At this point of the code, it is enough if we only
call FillComplete because there should be no communication after all.
CMake: Bugfix: Correctly detect unsupported flags in case of clang
The clang compiler frontend is very conservative in not issuing an error
for unsupported compile flags but that are valid for gcc. Therefore, also
supply "-Werror" for the clang compiler in all 'ENABLE_IF_SUPPORTED' tests.
As pointed out by Praveen C on the mailing list, sadd() of the Trilinos vector did
not work properly when combining ghosted with non-ghosted vectors. The test supposed
to check this used two vectors with the same entries, which did not detect that the
wrong vector was scaled.
Timo Heister [Fri, 19 Sep 2014 13:53:55 +0000 (09:53 -0400)]
Merge pull request #161 from bangerth/private-protected-cleanup
Move declarations in DoFHandler from protected to private.
DoFHandler still had some of its member variables and functions in a protected
section from back when we still had MGDoFHandler derive from it in a meaningful
way. This is now no longer necessary, so remove the protected section and instead
sort things in some sort of natural way into the private section.
Move declarations in DoFHandler from protected to private.
DoFHandler still had some of its member variables and functions in a protected
section from back when we still had MGDoFHandler derive from it in a meaningful
way. This is now no longer necessary, so remove the protected section and instead
sort things in some sort of natural way into the private section.
Timo Heister [Wed, 17 Sep 2014 18:51:08 +0000 (14:51 -0400)]
Merge pull request #152 from bangerth/cleanups
Minor cleanups. Make the FiniteElement::clone() function public, as it is of
general use. Also: Move several member variables from private to protected
as these are generally variables that derived classes are supposed to
initialize; this allows to remove rather random friend declarations for
these derived classes.
Specifically: Make the FiniteElement::clone() function public, as it is of
general use. Also: Move several member variables from private to protected
as these are generally variables that derived classes are supposed to
initialize; this allows to remove rather random friend declarations for
these derived classes.
Updated Documentation. Again, in the Introduction section of the step-20 tutorial a class InverseMatrix appears. Now its changed to use IterativeInverse<..> in all places to match with the code.
Updated documentation for step-20 Introduction section and a typo in the documentation for iterative_inverse.h. Detailed: In the introduction of the step-20 tutorial, Sec. Solving using the Schur complement, the IterativeInverse class is introduced and then in the following code section not used. Now the InverseMatrix is changed to IterativeInverse< .. > to match with the code of the tutorial, as used below.
projects / dealii.git / log