Straight-forward tensor-product version of FE_RaviartThomasNodal

[kronbichler]

This PR (based on work by @kkormann and me) aims to define a simple tensor product version of FE_RaviartThomas with nodal polynomials. It avoids some of the orientation issues among the unknowns of the elements as all DoFs are node values and thus set up homogeneously among a face, but obviously it still needs the usual sign flip for some face orientations in 2D/3D. @konsim83 this is the code I was talking about: It still profits from all the work you have done, but on the other hand it can be the basis for later extensions towards efficient tensor product evaluators as described in #9545. It would be great if you can have a look to discuss if the overall concept makes sense (as I am less experienced with Piola-transformed setups).

If we find this useful, @kkormann and I have a similar version for FE_NedelecNodal around. I am not sure how many additional difficulties could arise there compared to the RT case, but since all of a face/edge has the same signs due the nodal polynomials, it might actually be a manageable task.

@agrayver FYI

[konsim83]

All these lines in the test indicate that the conformity tests are successful, so there should be no orientation issue.

[konsim83]

Great work, imho, the concept makes sense and is simpler than the nodal version before. The conformity test indicates that the permutation table with signs is implemented correctly. I have the feeling that together with the tensor product Nedelec version you mentioned this can form a full de Rham complex, i.e., the tensor product Nedelec and RaviartThomas are compatible. Is this correct?

[konsim83]

Also, would it make sense to add a conformity test for 2D since the class is dimension templated? Just to be sure that this is working.

[peterrum]

Looks good to me. Could you elaborate why some of the tests fail. I also think a incompatibility change log entry might be justified, since the location of the support points have changed.

[kronbichler]

The tests fail because I did not yet update the output - as you say, this is an incompatible change and we change the representation of the shape functions. However, I wanted to first check with @konsim83, who is a knowledgeable person on this topic, to whether the overall direction makes sense.

Also, would it make sense to add a conformity test for 2D since the class is dimension templated? Just to be sure that this is working.

That test does exist already, https://github.com/dealii/dealii/blob/master/tests/fe/fe_conformity_dim_2_fe_rt_nodal.cc (it helped me to understand why I need the mapping_kind = mapping_raviart_thomas flag.

[kronbichler]

I now updated the test output. I deleted one test fe/rtdiff because that one implemented a comparison between the FE_RaviartThomas and FE_RaviartThomasNodal and explicitly used the same polynomial space. However, that is no longer the case so we can't make much sense of it.

[kronbichler]

Unfortunately I had to touch two tests with very large line counts, like hp/create_mass_matrix_05 which has 90k lines. This is due to the different form of the polynomials with the update.

[kronbichler]

I now also added a changelog entry.

[kronbichler]

My next step would be to set up the code for a nodal Nedelec element following the same principles. @kkormann and I have the polynomial spaces and basic ingredients ready. Any more comments on this one before we go on?

[peterrum]

I am in favor of merging, since this restructuring is a big step towards processing RT also in MatrixFree. But I am not sure if replacing the old class by a new class is the right approach. I don't mind; but what is the policy in this regard? Maybe someone else can do the actual merging?

[konsim83]

Sorry for the late reply, I like the refactored RT element and it looks well implemented and tested. Would be cool to have.

[drwells]

Though this does cause some slight compatibility issues its a net step forward for fixing all the orientation problems (and matrix-free RT will be nice) so lets merge.

[drwells]

I am in favor of merging, since this restructuring is a big step towards processing RT also in MatrixFree. But I am not sure if replacing the old class by a new class is the right approach. I don't mind; but what is the policy in this regard? Maybe someone else can do the actual merging?

Not being backwards compatible is bad, but - at some point we have to sacrifice it in order to fix bugs. I don't think we have a clear policy but I believe getting the orientation code right is more important than printing the same output.