The TODO isn't really addressed, but previous to #4560, the functions
in question simply did the wrong thing, whereas since #4560, we at
least get an ExcNotImplemented().
The DoF indices for a vertex are stored in an array where we just
collate the indices for each level. There is currently another
array that stors the offset within this array where the DoFs
for a given level start. This array is dynamically allocated,
but it is altogether unnecessary because the offsets are computable:
they are simply the number of the multigrid level times
dofs_per_vertex.
Consequently, get rid of the array and replace it by storing dofs_per_vertex.
We can then easily compute the starting offset wherever necessary, rather than
having to look it up.
The hp DoF renumbering function for the <3,3> case was unnecessarily
convoluted because it tried to look just like the functions that
deal with faces of higher dimensional cells. But we know that in <3,3>,
a hex is a cell, and so there can only be one finite element associated
with the cell. This allows simplifying a fair share of code.
Currently, the code is duplicated between the DoFHandler and the policy
class. This makes no sense, and indeed the policy class code is more
evolved, so let the former call the latter following exposing the
interface in the previous patch.
The existing code in DoFHandler looks like it did not actually support
parallel triangulations (either shared or distributed). This was
probably a bug, and consequently the implementation of the functionality
in the ParallelDistributed policy class now just throws an error.
This relates to the discussion in #4559.
The previous refactoring allows parallelizing renumbering for vertices,
cells, and faces, since these all work on mutually independent data
structures.
The 1d, 2d, and 3d implementations of these functions had most of their code
duplicated. This can be done more elegantly by instead splitting the code into
vertices, cells, and faces. The main function then becomes dimension independent,
as are the functions dealing with vertices and cells, and only the face function
requires dimensional specialization.
Make the DoFHandler a template type of the Sequential policy.
Also adjust all of the places where the class is used.
This change by itself is not useful, but will become useful when also
using the policy class from hp::DoFHandler. Similar changes will at a
later time be made for the ParallelShared and ParallelDistributed
policies.
When distributing MG DoF indices, we accidentally used 'unsigned int'
instead of 'types::global_dof_index'. That's a bug. We didn't notice
this because we never have more than 4B unknowns on one processor,
and the function was only called in the parallel context to enumerate
the DoFs on the *local* portion of the mesh, before indices were
shifted after communication with other processors. Regardless, it's
worth fixing.
We had a function with a funny comment suggesting that a compiler did not
correctly understand the code. But the comment is wrong: when the only
argument to a function that references a 'dim' or 'spacedim' template
argument is of the form
onst typename DoFHandler<dim,spacedim>::level_cell_iterator &
then 'dim' and 'spacedim' are simply not deducible. That's how C++ works.
The function therefore had a dummy argument of type DoFHandler<dim,spacedim>
that isn't used. That's awkward, but works. But we have a way to deal
with the lack of deducibility that's used elsewhere in the library
namely internal::int2type. Use this approach here as well, and remove
the misleading comment.
Do not derive the ParallelShared policy from the Sequential one.
The derivation was slightly contrived, but is not in fact useful any more since
the code has been refactored in ways that allow breaking the derivation and
just calling in ParallelShared what is also called in Sequential. In fact, the
code may have even become a bit shorter that way.
Remove an argument to a function that was no longer used.
Specifically, it allowed to start enumerating DoFs at something other than zero.
There was a time when we allowed that, but that possibility was removed
several years ago.
The corresponding argument to distribute_mg_dofs() was removed a few days ago,
but it was accidently left on distribute_dofs().
The compiler warns about the line
header_ += gzip::magic::id2; // ID2.
deep in BOOST when writing the header for a gzip-compressed block of data. This
is because (i) gzip::magic::id2 is declared as an int, and (ii) has a value
greater than what a *signed char* can store, i.e., greater than 127. Furthermore,
std::string::operator+ takes a 'char', which may or may not be unsigned but
apparently on my system is signed. So we get a warning about overflow.
The only reasonable way to deal with this is to do the casting explicitly.
David Wells [Sat, 24 Jun 2017 14:35:27 +0000 (10:35 -0400)]
Grammar: clarify obtain vs. attain.
Attain and obtain are nearly, but not quite, synonyms: 'attain' implies
achievement or accomplishment while 'obtain' just implies
ownership. This patch fixes our errant usage of 'attain' (one comment
also had a logic error, which I fixed).
projects / dealii.git / log