How to use FE_FaceQ with update_gradients.

[Lars Corbijn]

Hello,

I am trying to implement and HDG like method from [1], but without the elimination process described in step 51. Thereby creating a block matrix.

To implement this I use as finite element a system of FE_DGQ + FE_FaceQ. On the face I need to compute integrals between the functions from the trace space (i.e., from FE_FaceQ) and the normal times gradient of the functions inside the element (i.e., from FE_DGQ). Therefore, I pass update_gradients to FE_FaceValues, but this runs into the exception that the gradients are not implemented for FE_FaceQ. Note that the lack of gradients of FE_FaceQ is no problem, as its gradients are not need and (I expect) not well defined, but I do need the gradients of FE_DGQ.

Is there a way around this without eliminating the degrees of freedom for the elements (like in step 51)?

Regards,

Lars Corbijn

[1] https://epubs.siam.org/doi/abs/10.1137/090775464

[Wolfgang Bangerth]

Lars,

> I am trying to implement and HDG like method from [1], but without the
> elimination process described in step 51. Thereby creating a block matrix.
>
> To implement this I use as finite element a system of FE_DGQ + FE_FaceQ.
> On the face I need to compute integrals between the functions from the
> trace space (i.e., from FE_FaceQ) and the normal times gradient of the
> functions inside the element (i.e., from FE_DGQ). Therefore, I pass
> update_gradients to FE_FaceValues, but this runs into the exception that
> the gradients are not implemented for FE_FaceQ. Note that the lack of
> gradients of FE_FaceQ is no problem, as its gradients are not need and
> (I expect) not well defined, but I do need the gradients of FE_DGQ.

I see the problem. I *think* that the right approach would probably be
to remove the assertion in the fill_fe_values function of FE_FaceQ that
you see, and instead fill the fields that should be filled with the
gradients with some kind of numbers::signaling_nan() -- in other words,
make sure that it's allowed to call the function with update_gradient,
but also ensure that you're poisoning the returned values with values
that will trigger a floating point exception once anyone tries to use
them. (It is conceivable that these memory locations are already pre-set
to have these signaling nans in them.)

Do you want to give this a try and see whether you can come up with a patch?

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Lars Corbijn]

Wolfgang,

Thank you for the detailed information. That sounds like a good solution to the problem given the current situation.

Now that I have a working checkout (but waiting for a recompile), I will see if I can find some spare time to program the solution.

Lars

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/jsO66NpqKVg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/4b250c0d-b2a8-b0e5-19d7-aa31736aeac0%40colostate.edu.

[Wolfgang Bangerth]

On 8/26/19 1:09 PM, Lars Corbijn wrote:
>
> Thank you for the detailed information. That sounds like a good solution
> to the problem given the current situation.
>
> Now that I have a working checkout (but waiting for a recompile), I will
> see if I can find some spare time to program the solution.

Great! Feel free to open an issue on the deal.II github account that
describes the problem, and then we can have discussions there if you
have questions on how to address the problem. We can also reference that
issue from all pull requests that address (parts of) it.