point_value with FEFaceValues

[Yuan Wang]

Dear all,

I would like to ask for some pointers on interpolations between non-matching
grids. And here is the issue I ran into when writing an AMR program for a
space-time HDG method - please see the toy graph attached.

After solving for one time step, I obtain the face solution (blue dots on
purple line, based on an FEFaceQ object) which is imposed as part of the
Dirichlet boundary condition for the next time step. For example, when we look
at the element boundary in yellow and when we need the b. c. value on the
quadrature point green x (both x’s are at the same spatial location), we need
to interpolate the face solution at the green x.

It seemed that point_value function would be the way to go but
VectorTools::point_value(dof_handler, locally_relevant_solution, point_x) was
only able to produce nan‘s.

Here are some lines copied from the source code of the point_value function:

const std::pair<typename DoFHandler<dim, spacedim>::active_cell_iterator, Point<spacedim>> cell_point = GridTools::find_active_cell_around_point(mapping, dof, point); const Quadrature<dim> quadrature( cell_point.first->reference_cell().closest_point(cell_point.second)); FEValues<dim> fe_values(mapping, fe, quadrature, update_values); fe_values.reinit(cell_point.first); std::vector<Vector<Number>> u_value(1, Vector<Number>(fe.n_components())); fe_values.get_function_values(fe_function, u_value);

…and the issue seems to be that FEFaceQ is not supported here. When
modifying the source code to cater for FEFaceQ, an immediate issue is how to
find the dim-1 Point for the single-point quadrature:

const Quadrature<dim-1> quadrature( cell_point.first->reference_cell().closest_point(cell_point.second));

In my case a solution could be get rid of the time component of the output of
closest_point function but I wonder whether there are less hacky ways. Also,
since point_value can be an expensive operation, I was wondering would the
procedure outlined above be considered as economical as it can get in deal.II?

Would really appreciate any comments and/or suggestions!

Best regards,
Yuan

​

[Wolfgang Bangerth]

On 11/28/23 20:08, Yuan Wang wrote:
> After solving for one time step, I obtain the face solution (blue dots on
> purple line, based on an FEFaceQ object) which is imposed as part of the
> Dirichlet boundary condition for the next time step. For example, when we look
> at the element boundary in yellow and when we need the b. c. value on the
> quadrature point green x (both x’s are at the same spatial location), we need
> to interpolate the face solution at the green x.
>
> It seemed that point_value function would be the way to go but
> VectorTools::point_value(dof_handler, locally_relevant_solution, point_x) was
> only able to produce nan‘s.

Yuan:
The fundamental issue is that VectorTools::point_value() assumes that the
point is arbitrary (somewhere, not necessarily on a face) and consequently
uses FEValues. But FEFaceQ of course only lives on the faces of a cell, and
you cannot evaluate it at arbitrary points -- so FEValues only results in the
NaN values you observe.

There is no good solution for this situation in the library at the moment. But
you can probably implement one yourself. Since you know that the point you're
looking for is on a face, you can replicate the kind of thing that
VectorTools::point_value() does in your own code, but using FEFaceValues
instead of FEValues. As you noticed, the key is to get a dim-1 dimensional
quadrature point. Since you know that the face in question is in x-space
(i.e., perpendicular to the time axis), simply throwing away the time
component makes sense to me; you then just have to transform the point you
have into the coordinate system of the face you're considering. I don't see a
much better approach if you really want to have non-matching meshes between
time slabs.

Best
W.

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