Deprecate DoFHandler initialization interface.

[marcfehling]

Split from #11133 and only addresses the deprecation of the DoFHandler initialization.

Part of #11102 and #10333.

This PR simplifies the initialization interface for the DoFHandler class by keeping the most common way of initialization (DoFHandler(tria) and distribute_dofs(fe)) and deprecating the remaining.

[kronbichler]

/rebuild

[peterrum]

Let's get some more feedback before merging this one!

[tjhei]

deprecation of the DoFHandler initialization.

Do you want to summarize what the motivation behind this deprecation is? It doesn't seem to be a terrible feature to have...

[marcfehling]

My idea behind this deprecation is to remove ambiguity by providing a clear interface. I wanted to separate the initialization process from the actual enumeration of degrees of freedom.

After merging DoFHandler and hp::DoFHandler, we allow setting active fe indices after the initialization of the DoFHandler object. When distributing dofs, we check if the provided finite element collection fits.

When I worked on the parallelization of the hp elements, I introduced the set_fe functions to make sure that active fe indices are valid with the attached collection of elements. Retrospectively, I would not have introduced them and would like to get rid of them.

I do not like about the initialize function that it actually performs two tasks at once: registering a triangulation and enumerating degrees of freedom. I would be okay with leaving a function initialize(triangulation).

---

Apart from that, the initialize function basically destroys the DoFHandler object and recreates all internal data structures from scratch. To make sure that no reminiscene to the old triangulation is left, I would rather advise users to destroy the whole DoFHandler object and recreate it freshly with the new triangulation in mind. That is the main reason why I want to get rid of the basic DoFHandler() constructor and the initialize functions.

As we are using DoFHandler(Triangulation) and distribute_dofs throughout all examples (with the exception of step-69), I would like to limit the interface to only these two functions.

[bangerth]

I'm for this simplification of the interface. It makes it easier to reason about the state the object is in (e.g., it always has an associated Triangulation object). It also only removes/deprecates functions that are not in wide use.

The only reason, I believe, to have the DoFHandler() constructor and associated initialize(Triangulation) function was so that one can store DoFHandler objects in collections that require default initialization. But the fact that we never seem to do that in the tutorials is a good indication that that's not a common use case, and there is also always the possibility to use a collection of pointers instead.

So I'm in favor.

@tjhei What do you say? I think you were the lone voice of question here.

[peterrum]

The only reason, I believe, to have the DoFHandler() constructor and associated initialize(Triangulation) function was so that one can store DoFHandler objects in collections that require default initialization.

This comment reminds me that I am using it like this. I have a MGLevelObject<DoFHandler<MatrixType::dim>> dof_handlers; with each DoFHandler initialized with a different triangulation.

[tjhei]

I do not like about the initialize function that it actually performs two tasks at once: registering a triangulation and enumerating degrees of freedom. I would be okay with leaving a function initialize(triangulation).

This is a good point. More intuitive would have been a reinit(Triangulation) that only does the first part.

What do you say? I think you were the lone voice of question here.

I am not opposed to this change but wanted to understand the motivation. Every deprecation/removal has downstream effort for at least some users so that has to be considered.

Peter makes a good point though: usage of DoFHandler in containers becomes more difficult without initialize or reinit. Peter, is there a way to still achieve what you are doing? Can we add a way to emplace an object into MGLevelObject? Or would a new reinit option be a good choice?

[peterrum]

Peter makes a good point though: usage of DoFHandler in containers becomes more difficult without initialize or reinit. Peter, is there a way to still achieve what you are doing? Can we add a way to emplace an object into MGLevelObject? Or would a new reinit option be a good choice?

I can always use a smart pointer (although it is my last choice). My personal use case should be not a problem. However, this will involve with replacing a couple of . with -> in my code and potentially in many user codes (where the type of Triangulation is determined by some input parameters - sorry for seeing this issue so late).

I think

Or would a new reinit option be a good choice?

would be a good idea. What do others think? reinit functions is not my favorite style (since I would prefer that as many internal fields are cost as possible) but this is common in the library.

[marcfehling]

I didn't think of default construction in containers either. I would be okay with leaving the DoFHandler() and introducing a reinit(Triangulation) function.

[marcfehling]

I've provided a patch for the default constructor and a reinit() function. I will squash or drop this commit depending on the general opinion :)

[peterrum]

Looks good. Thanks! But I am a bit confused why the constructor that takes a triangulation does not call the reinit function?

[kronbichler]

Looks good to me!

[marcfehling]

Looks good. Thanks! But I am a bit confused why the constructor that takes a triangulation does not call the reinit function?

For some reason I felt like not altering the initializer list in the non-default constructor. It makes sense to use the reinit function here!

[tjhei]

I am happy with this change.

[marcfehling]

Thank you for your feedback!

I will squash the commits so we can finally get this merged!

[peterrum]

@marcfehling I have replaced the Do not merged label with Reviewed and ready to merge label. Thanks for the efforts!