Add a mutex to IndexSet and use it to make IndexSet::do_compress() thread-safe.
IndexSet has a number of 'mutable' member variables. The only function that modifies them is
'do_compress', which is called by 'compress', which is in turn called by all of the
'const' member functions. To make all of these 'const' member functions thread-safe, we
need to use a mutex in 'do_compress'. This patch does this.
I have verified that no other 'const' function actually modifies any of the 'mutable'
member variables, so only guarding 'do_compress' by the mutex is sufficient.
Predictably some minor errors were only spotted after a merge! The
biggest point is ensuring that definitions of static members of the
Elasticity::StandardTensors class don't get inlined in their description
as "Initial values".
Standard transformations, and kinematics and tensors for elasticity.
This commit adds a set of functions to perform various push forward /
pull back operations that regularly feature in finite deformation
mechanics. It also adds some standard tensor definitions for elasticity,
as well as functions that compute kinematic quantities typically used in
finite strain elasticity.
Right now, one can only create such an object pointing to a specific
array. It is not possible to default construct it, and consequently
you can't put them into collections, for example.
David Wells [Wed, 7 Dec 2016 15:01:57 +0000 (10:01 -0500)]
Cache end_active() when assigning hp dofs.
This fixes a performance bug where distributing dofs on some grids would take an
amount of time quadratic in the number of dofs when it should be linear.
In #3333, I added virtual functions to DataPostprocessor with the same name as the existing
functions. This leads to issues where we get a warning in every derived class that only
overloads one of these functions, because that hides the other function. This is, well,
suboptimal.
This patch is therefore a redo of my earlier attempt in which I continue to deprecate
the old functions, but the new functions have a different name. I think they also
have a better name (for a discussion of the naming, see
https://github.com/geodynamics/aspect/issues/1284 ). The different names avoid the
problem of getting the warning and should therefore lead to less discontent. They
also avoid the need to try to work around the warnings using 'using' declarations, like
in #3528.
Move DataOutInterface::write_pvd/visit_record() to namespace DataOutBase.
These functions did not depend on the state of the DataOutInterface object and could therefore
be made 'static'. On the other hand, we have traditionally kept such functions in namespace
DataOutBase. Move them there, and deprecate the old versions of these functions.
David Wells [Sat, 3 Dec 2016 22:24:28 +0000 (17:24 -0500)]
Make VectorSpaceVector's destructor virtual.
Since the classes inheriting from VectorSpaceVector all implement their own
memory management strategies, the destructor of the base class should always be
virtual.
Currently, if a TimerOutput section takes a very small fraction of the overall
time, we happily output in the last column that it took 6.5e-4%. This is not
only visually awkward compared to all of the other numbers that are not using
the e-04 notation, but also pretty pointless: nobody cares whether something took
that small a fraction of the overall time, and if they happen to do anyway: the
absolute amount of time is printed in the previous column.
Consequently, show everything that takes less than 0.1% of time as 0%.
Added warning for unsuccessful case in GridTools::collect_periodic_faces
A note and assert has been added to provide a warning for the case where
collect_periodic_faces doesn't find any matched faces. This may happen
if there is no colouring on the coarsest level mesh (i.e. grid
refinement before boundary id definition) or where they've accidentally
called the function with the wrong boundary id's (or direction?).
Incomprehensively, the function looped over all faces of a cell, and then
all vertices of the face. This visited each vertex exactly 'dim' times.
This can be done easier.
While there, also fix a number of issues where we confuse 'unsigned int'
with 'types::global_dof_index'. This doesn't matter here because the
function only works in sequential settings anyway, but we should be
consistent.
Finally, instead of setting vertex locations from each adjacent cell, only
do it once by keeping track when we touch the vertex the first time.
This patch revises commit 9386b1e30c in #3639. There, I tried to avoid instantiating types
that have a template signature of the kind <3,spacedim> if spacedim is less than three,
since that leads to invalid types. I did so by using <3,max(3,spacedim)>, which works
because we can only get to these places if dim==3, and consequently spacedim>=3, but the
compiler may not always recognize that if spacedim<3, then we must be in dead code.
This patch goes the other way around, which I find conceptually clearer: in code where we
have
if (dim == 3)
{
typename Triangulation<3,spacedim>::cell_iterator cell = ...;
we clearly only got into the 'if' block because dim==3. Consequently, we might as well
have written
if (dim == 3)
{
typename Triangulation<dim,spacedim>::cell_iterator cell = ...;
to the same effect. On the plus side, however, whenever dim<3 (i.e. in cases where
this is dead code anyway), we still do not instantiate invalid types.
This patch therefore undoes the changes made in #3639 and replaces them with the second
option above. There are a number of places where we then have to replace calls to
GeometryInfo<3>::...
by
GeometryInfo<dim>::...
as well as one place where we have to do a cast from
RefinementCase<3>
to
RefinementCase<dim>
or the other way around; the latter is the identity cast if we do get into this block.
Since we only get into this piece of code if dim==3, there is nothing wrong with
this: if dim==3, then spacedim>=3. On the other hand, the compiler will still
instantiate Triangulation<3,spacedim> even if dim==spacedim==1.
This patch works around this by replacing the type by
Triangulation<3,max(3,spacedim)>
which for all of the cases in question leads to the exact same type, but
avoids instantiating invalid types.