Timo Heister [Wed, 5 Nov 2014 15:41:11 +0000 (10:41 -0500)]
Merge pull request #221 from kronbichler/master
Fix a compiler warning with gcc-4.9.
gcc-4.9 seems to be able to see that accessing R[1] in 1D is out of bound
for spacedim == 1 but it can omit the warning if accessed inside a switch
statement. Fix this warning (even though we won't use SphericalManifold
for spacedim == 1).
gcc-4.9 seems to be able to see that accessing p[1] in 1D is out of bound
for spacedim == 1 but it can omit the warning if accessed inside a switch
statement. Fix this warning (even though we won't use SphericalManifold
for spacedim == 1).
Combined add and inner product for vectors: add_and_dot
- Implemented a new method add_and_dot for all vector classes (deal.II's vectors,
block vectors, PETSc, Trilinos vectors)
- Specialized function for deal.II vector that does add_and_dot in one sweep over
the data by a new AddAndDot struct that is passed to the accumulate function. This
also extends the other structs for inner products and norms by one (unused) argument.
- New tests for this feature.
- Added new do_vectorized operation to all accumulation operations that uses the
operations of VectorizedArray<double/float> for the sums. This helps to reduce the
operations and thus increase performance when memory transfer is not the limit.
This functionality is called in the regular part of the accumulate function which
now sits in its own method 'accumulate_regular' (length divisible by 32). This
functionality can unfortunately not be realized by the OPENMP_SIMD pragma recently
introduced because that leads to non-reproducible results when the vector memory
starts at different memory locations. VectorizedArray is only supported on some
platforms and thus this functionality may not be available everywhere. However, good
code will be generated unconditionally (except on old machines from around 2004-2008
where unaligned reads also from aligned memory are slow, but those are not relevant
any more).
- To implemented vectorized pow operations, I also added a std::pow function for
VectorizedArray.
- The memory for parallel::distributed::Vector is now allocated to 64 byte boundaries
just as is the memory of Vector<Number>.
This patch uses signals to determine whether a current iterate
satisfies the convergence criterion. Currently, the only slot that
is connected to a signal is the SolverControl::check() function,
but users will be able to connect different slots there as well,
closely monitoring the convergence process.
Timo Heister [Thu, 23 Oct 2014 11:05:03 +0000 (07:05 -0400)]
Merge pull request #206 from bangerth/remove-faulty-test
The test verifies that it doesn't matter whether we first call
DoFHandler::distribute_dofs() and then DoFHandler::distribute_mg_dofs(),
or the other way around. But we have recently changed the behavior
to require exactly this order, so part of the test is no longer of interest.
The test verifies that it doesn't matter whether we first call
DoFHandler::distribute_dofs() and then DoFHandler::distribute_mg_dofs(),
or the other way around. But we have recently changed the behavior
to require exactly this order, so this part of the test is no longer of interest.
Timo Heister [Wed, 22 Oct 2014 20:30:45 +0000 (16:30 -0400)]
Merge pull request #207 from bangerth/fix-test
We have recently allowed that one can set a vector to zero, even if it has
ghost elements. But this test verified that we throw an exception in this
case. Remove this one test.
We have recently allowed that one can set a vector to zero, even if it has
ghost elements. But this test verified that we throw an exception in this
case. Remove this one test.
Guido Kanschat [Fri, 17 Oct 2014 08:54:07 +0000 (10:54 +0200)]
Merge pull request #202 from kronbichler/master
Improved AVX-512 vectorization code path. The original version of the AVX-512 vectorization (DEAL_II_VECTORIZATION_LEVEL = 3) was not properly tested. When I did some tests with gcc, it turned out that I had to fix a few issues. Now it compiles fine and the generated assembler code looks good, but there is no hardware out to test it yet.
The original version of the AVX-512 vectorization (DEAL_II_VECTORIZATION_LEVEL = 3) was not properly tested. When I did some tests with gcc, it turned out that I had to fix a few issues. Now it compiles fine and the generated assembler code looks good, but there is no hardware out to test it yet.
I also improved some code comments.
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.
projects / dealii.git / log