VectorTools::interpolate_boundary_values doesn't work for DG

[Abbas]

Hello, 

The VectorTools::interpolate_boundary_values function works for interpolating fe_Q<dim> functions but not fe_DGQ<dim> . 
Was this meant to be the case? 
I attached a minimal code that illustrates this.
   

[Daniel Arndt]

Abbas,

Yes, FE_DGQ only defines dofs in the interior of cells. Thus, trying to interpolate the boundary has no effect. You would normally use penalty terms to prescribe boundary values for DG methods.

Best,

Daniel

--
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 the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/0a8d1da6-e564-45de-bc3d-1f5a9d5dfad9n%40googlegroups.com.

[Abbas]

Thank you Daniel. 

I was using penalties before taking this route, because I had artifacts at the boundary faces present at a corner between a Dirichlet and a Neuman BC edge. A problem I didn't have with CG.  My first intuition was to apply BCs strongly to fix this, but I don't think it will even if I were able to interpolate. 

It's cool how dealii is consitent with the maths.

Maybe @Wolfgang would agree that this should have thrown an exception in Debug?

[Wolfgang Bangerth]

> It's cool how dealii is consitent with the maths.
> Maybe @Wolfgang would agree that this should have thrown an exception in Debug?

In principle yes, but I don't know how to write such an assertion given the
generality of the function (for the hp and non-hp case, and when selecting
only a subset of vector components). I will see if I can at least add
assertions for some simple cases.

Best
W.

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

[Abbas]

I would still want to initialise my solution vector to the values which are prescribed at the boundary before solving.   
Context: 
I am solving a nonlinear problem with DG and my BCs are in the weak form. It would be helpful if I start with a solution vector that is closer to the prescribed solution so I won't have to do iterations otherwise would have been unnecessary.

For a purely linear problem, I need to do two non_linear iterations to converge instead of 1. 

If I can't use VectorTools::interpolate_boundary_values what are my options? Does VectorTools::project_boundary_values work in that case? 

[Wolfgang Bangerth]

On 3/8/23 07:49, Abbas wrote:
>
> I am solving a nonlinear problem with DG and my BCs are in the weak form. It
> would be helpful if I start with a solution vector that is closer to the
> prescribed solution so I won't have to do iterations otherwise would have been
> unnecessary.
> For a purely linear problem, I need to do two non_linear iterations to
> converge instead of 1.
> If I can't use VectorTools::interpolate_boundary_values what are my options?
> Does VectorTools::project_boundary_values work in that case?

No, it also needs to know which DoFs are located on the boundary, but for DG
elements no DoFs are logically on the boundary.

I don't see a good solution to your problem that uses what's already in the
library. I imagine that using code similar to what's in
interpolate_boundary_values() but using a different way of finding out which
DoF's support point is physically (though not logically) located on the
boundary, this all could be implemented in 200 lines of code. But there is
nothing simple the obvious already provides you for this case.

[Abbas]

Thank you Prof. Bangerth. 
I am always greatfull for your input.