This is a simplified test of FESystems whose base elements are again FESystems.
The test helped me debug a couple of issues, and might be of help again
at a later time. It is a simpler version of fe/shapes_system.
Reshuffle the argument list of FE::fill_fe_*_values().
This brings the argument list in line with the changes made to Mapping in #1204.
In essence, it is all about sorting the list in a halfway reasonable order. No
functional changes.
The patch changes all of the derived finite element classes as well. In some cases
it changes the name of arguments to match a uniform style.
We had a number of places of the form
for (...tight loop...)
if (constant condition)
data update;
The compiler almost certainly can hoist the condition out of the loop,
but why make it this complicated for the compiler. I also find the code
easier to read because the loop is really only over a counting index
and does not carry any particular meaning at a level higher than the
if-statement.
Replace update_once/each by requires_update_flags() in FiniteElement.
The purpose of this patch is to align the finite element classes with the way the
mapping classes have already been converted. Specifically, there is no need for
any of the users of finite element classes to actually know whether a FE implementation
wants to treat a particular flags as update_once or update_each. This is an internal
decision. Rather, all we need to know is what flags they need overall. This is now
communicated by the new FiniteElement::requires_update_flags() function.
The update_once() and update_each() functions have been retained -- for now -- as
internal functions individual elements can implement, but they are no longer virtual.
At least in cases where we know that the output vector of one function
has the same type as the result type of the current one, we can avoid
allocating a temporary vector.
Timo Heister [Thu, 5 Nov 2015 14:02:50 +0000 (09:02 -0500)]
fix tests
- use std_cxx11::bind instead of std::bind
- require Trilinos if we use it
- fe/bdm_*: do not set matrix entries <1e-14 to zero (different on
different machines) and always print 0 entries
- use check_solver_within_range where needed
David Wells [Mon, 19 Oct 2015 02:48:08 +0000 (22:48 -0400)]
Use VectorType, not InVector, as a template type.
Some functions use a template for the input and output types, but other
functions use InVector. This commit switches the second kind to use VectorType,
which is more consistent with the usage of both VectorType and InVector.
Remove the first_cell/is_first_cell/current_update_flags() mechanism from FiniteElement.
What this patch does is address the issue that
`FiniteElement::get_data()` (as was previously the case with Mappings
as well) sets a flag in the returned `InternalData` object that
indicates that we are visiting a cell for the first time. `FEValues`
later sets this flag back once we're done with the first cell.
The way this is used is that the various finite element
implementations query `current_update_flags` in
`FE::fill_fe_*_values()`, which equals `update_each|update_once` if we
are on the first cell, and `update_each` on later cells. That means
that on the first cell we update fields in the output object that we
need to initialize only once, e.g., the values of shape functions on
quadrature points, but we won't do this again on later cells.
I don't particularly like this approach. It is opaque and took even me
a long time to reconstruct when I saw it (see #1305 for a
discussion). My preference is to do things we only need to do once in
`FE::get_data()`, and do things we need to do every time in
`FE::fill_fe_*_values()`. This kind of change was already implemented
for mappings in the patches references from #1305, and the current
pull request goes into the same direction.
The current PR only does one half of the necessary changes in order to
keep the patch reasonably self contained and readable. In particular,
what it really does is simply *always* do everything, by storing
`update_once|update_each` in `FE::InternalDataBase::update_each`. In
other words, it is the equivalent to telling finite element
implementations that we are always on the first cell. This requires
more work than in the previous state, although copying shape values
every time is arguably of small expense compared to transforming
gradients.
I will of course fix this up in upcoming patches. It requires
significant shuffling around. I'll open an issue in a minute
discussing the details. I'd simply like to propose this here already
as an incremental step forward, without making patch review too
onerous. The patch is mostly mechanical once you understand what it
does.
Matthias Maier [Sun, 1 Nov 2015 23:17:24 +0000 (17:17 -0600)]
CMake: Bugfix: Also use DEAL_II_INCLUDE_DIRS for bundled boost
This fixes a compilation issue with a zlib library not in a default
location in combination with bundled boost. Many thanks to Lukas Korous for
pointing this out.
Matthias Maier [Thu, 29 Oct 2015 03:47:29 +0000 (22:47 -0500)]
Bugfix: Provide missing operator+ and operator- variants
Unfortunately, it is not possible any more to exploit an implicit
conversion from SymmetricTensor to Tensor due to the heavily templated
operator variants for Tensor.
Thus, provide mixed operator types. (And clean up symmetric_tensor.h
later).
Break dependency of MappingQ from MappingQGeneric.
As discussed in #1732, MappingQ doesn't have the is-a property with
regard to MappingQGeneric. Nor does it have it with regard to its previous
base class, MappingQ1, and this was already fixed previously (#1429). Rather, what
it should be is a has-a relationship with regard to both the MappingQGeneric
(used on cells on the boundary) and MappingQ1 (used for interior cells).
This patch implements this. The part of the patch for MappingQ itself is
relatively straightforward: have it store pointers to both Q1 and Qp
mappings, and where it currently dispatches to the base class
MappingQGeneric, just dispatch to the Qp object instead. We can
then break the inheritance from MappingQ
to MappingQGeneric, at the cost of reimplementing a couple of
trivial functions of the Mapping interface that were previously
provided by the MappingQGeneric class.
The bigger problems appear in the MappingQEulerian and
MappingC1 classes which previously overloaded functions
declared in MappingQGeneric and that are now no longer
available to the MappingQGeneric object we now keep a
pointer to, rather than have as base class. This is
worked around by having both MappingQEulerian and
MappingC1 declare their own internal classes derived
from MappingQGeneric that provide the now missing
functions.
Alistair Bentley [Tue, 27 Oct 2015 15:14:07 +0000 (11:14 -0400)]
Implemented BDM_grad_grad in 3D
* Added second derivative terms to polynomials_bdm class in 3D
* Added tests and output to verify 2nd derivatives are returning
proper values
* I carefully checked the output file to confirm the correct output
is being produced
projects / dealii.git / log