DoFHandler: Support virtual degrees of freedom

[tamiko]

@kronbichler @luca-heltai @peterrum This is what I have in mind.

You can find a modified step-40 in the build directory that I used to test whether this works - and yes, so far no problems.

The changes required are surprisingly minimal. In essence we only need to:

• shift the global enumeration of the local range
• make the virtual dof range available in some form

I looked into some alternatives (including playing this index game in the Partitioner). But I think adding support for this in the DoFHandler is the most elegant solution.

The interface here is a quick 30 minute hack testing the core functionality.
We should probably design something much more elegant. (including an interface to create multigrid structures.)

But I wanted to share this here early on. Because it works surprisingly well.

[kronbichler]

I think the code is indeed very nice. One of the pros is that it is actually the DoFHandler's task to organize degrees of freedom, irrespective of where they come from.

One of the topics I already mentioned in our discussion board is the question about ghosting. This is of course up to the user code to decide whether and to which extent the virtual DoFs should be accessible outside of the owner process. So it is not the business of the DoFHandler but the partitioner and parallel vectors, in order to ensure efficient communication routines.

[luca-heltai]

Sorry, I'm late to the party. I like this option, but I think we still need to add support for non-local dofs. In this particular example, I see that you are essentially replicating the "dofs_offset" concept we had some time ago (done in a much better way, I must admit!) and that was removed since it was not very well tested.
This won't work with basis functions associated to these dofs on some cells, in my understanding, right? You have to handle them manually all-together.
I think we still need this, and I'm in favour of this PR.

[luca-heltai]

Do I understand correctly that these should be interpreted as the total number of virtual dofs? In your example, you are making all of them locally owned by all processors. This does not sound right to me, i.e., in the example above, if you run on n processors you should end up with a matrix that has n on the diagonal on the virtual dofs block. Sorry. I just saw that you have two different implementations, where the argument is interpreted differently based on the type of triangulation.

[tamiko]

@luca-heltai Yes right now I only explored what this parameter should mean for serial and parallel::distributed (and not for the others). We'll have to discuss how the interface should look like anyway.

I really don't like this additional argument for distribute_dofs and I think it should either be a part of the finite element or a different method/interface.