Timo Heister [Wed, 1 Feb 2017 14:59:44 +0000 (09:59 -0500)]
update step-57
- always assemble rhs when assembling matrix (so we get correct boundary
values from the ConstraintMatrix)
- this fixes having 0 iterations in the first Newton iteration
- restructure assemble* functions to make this more clear
- reorder some comments
- redo results section (neater tables)
David Wells [Sun, 22 Jan 2017 17:04:16 +0000 (12:04 -0500)]
Move the matrix-free project copy operation up the call stack.
The matrix-free projection solves the linear system with a specific vector type
and then copies the result into the given one. This commit moves that copy
operation into a separate function so that the actual matrix free function no
longer depends on the type of the input vector. Put another way: we no longer
have to instantiate the matrix free projections for all possible vector types.
Before moving the copy operation:
File name Memory, MB Time, s
source/numerics/vector_tools_project.cc 2774 76
source/numerics/vector_tools_project_inst2.cc 2829 81
source/numerics/vector_tools_project_inst3.cc 2823 86
After:
File name Memory, MB Time, s
source/numerics/vector_tools_project.cc 1855 47
source/numerics/vector_tools_project_inst2.cc 1995 51
source/numerics/vector_tools_project_inst3.cc 2183 55
David Wells [Sun, 22 Jan 2017 05:41:09 +0000 (00:41 -0500)]
Give the codim > 0 VectorTools::project functions their own file.
Since these functions don't go into the MatrixFree code we can split them off
with a very small amount of overhead for the additional parallelization. This
lowers the required memory for the last projection instantiation by about a
gigabyte.
Before:
File name Memory, MB Time, s
source/numerics/vector_tools_project.cc 2775 79
source/numerics/vector_tools_project_inst2.cc 2882 92
source/numerics/vector_tools_project_inst3.cc 3948 102
After:
File name Memory, MB Time, s
source/numerics/vector_tools_project_codim.cc 1843 28
source/numerics/vector_tools_project.cc 2774 76
source/numerics/vector_tools_project_inst2.cc 2829 81
source/numerics/vector_tools_project_inst3.cc 2823 86
David Wells [Sun, 22 Jan 2017 00:49:53 +0000 (19:49 -0500)]
Give the hp version of VectorTools::project its own file.
This new file takes about 17 seconds to compile and improves the performance of
the non-hp (i.e., the matrix free) projections a little bit.
before splitting out the hp files:
File name Memory, MB Time, s
source/numerics/vector_tools_project.cc 2860 81
source/numerics/vector_tools_project_inst2.cc 2970 100
source/numerics/vector_tools_project_inst3.cc 3956 114
After:
File name Memory, MB Time, s
source/numerics/vector_tools_project.cc 2775 79
source/numerics/vector_tools_project_inst2.cc 2882 92
source/numerics/vector_tools_project_inst3.cc 3948 102
These numbers come from setting the C++ compiler as a shell script containing
Timo Heister [Wed, 18 Jan 2017 22:56:52 +0000 (17:56 -0500)]
disable MGTransferPrebuilt without Trilinos
Do not allow MGTransferPrebuilt to work with distributed::Vector if we
don't have Trilinos. This used to compile and crash at runtime because
we wrongly created serial matrices.
This also fixes the tests/multigrid/transfer_prebuilt_04 error message:
An error occurred in line <361> of file
</mnt/data/testsuite/dealii/source/lac/dynamic_sparsity_pattern.cc> in
function
bool
dealii::DynamicSparsityPattern::exists(dealii::DynamicSparsityPattern::size_type,
dealii::DynamicSparsityPattern::size_type) const
The violated condition was:
rowset.size()==0 || rowset.is_element(i)
Extensions for Trilinos support in LinearOperators.
Trilinos sparse matrices and preconditions can now we wrapped as
LinearOperators, and can be used (nearly) as naturally as the deal.II
linear algebra classes could. This means that they can be used as a
transpose_operator(), inverse_operator() and within the
schur_complement().
The core support for block operations is also there, but has not been
thoroughly tested.
Make Trilinos Solver classes compatible with LinearOperators.
This patch adds some core functionality to the Trilinos Solver that is
later necessary for them to be compatible with LinearOperators.
Specifically, this is two additional solve() functions that accept
Trilinos EpetraOperators as the input Matrix (with one accomodating
wrapped Trilinos preconditioners, and the other another EpetraOperator
as a preconditioner.).
David Wells [Sun, 15 Jan 2017 23:08:07 +0000 (18:08 -0500)]
Make Tensors trivially copyable.
The implicitly defined copy constructors and assignment operators are no
different from the ones implemented prior to this patch, so we can clean things
up a bit by just using the defaults here.
This has the nice effect of making the class "trivially copyable", which means
compilers may optimize things by using memcpy to copy things instead of the copy
constructor.