parallel::distributed::SolutionTransfer for FE_FaceQ element

67 views
Skip to first unread message

Yu Leng

unread,
Jul 12, 2020, 7:06:43 PM7/12/20
to deal.II User Group
Hello all,

I am encountered with this error while using adaptive mesh refinement in parallel. 

virtual const FullMatrix<double> &dealii::FiniteElement<2, 2>::get_prolongation_matrix(const unsigned int, const RefinementCase<dim> &) const
The violated condition was:
    prolongation[refinement_case - 1][child].n() == this->dofs_per_cell
Additional information:
    You are trying to access the matrices that describe how to embed a finite element function on one cell into the finite element space on one of its children (i.e., the 'embedding' or 'prolongation' matrices). However, the current finite element can either not define this sort of operation, or it has not yet been implemented.


A little background of my problem. 

Deal ii version: 9.1.1

I am using Weak Galerkin FE so the FESystem is (FE_DGQ<dim>(degree), 1, FE_FaceQ<dim>(degree), 1).

After mesh is refined, I need to interpolate solution from old to new mesh using parallel::distributed::SolutionTransfer and this is where this error pops out. I believe there is some conflict using solutiontransfer with the FE_FaceQ element. 

Does anyone know how to solve this? 


Thanks,
Yu

Wolfgang Bangerth

unread,
Jul 13, 2020, 3:08:41 PM7/13/20
to dea...@googlegroups.com
On 7/12/20 5:06 PM, Yu Leng wrote:
>
> I am encountered with this error while using adaptive mesh refinement in
> parallel.
>
> virtual const FullMatrix<double> &dealii::FiniteElement<2,
> 2>::get_prolongation_matrix(const unsigned int, const RefinementCase<dim> &) const
> The violated condition was:
>     prolongation[refinement_case - 1][child].n() == this->dofs_per_cell
> Additional information:
>   You are trying to access the matrices that describe how to embed a finite
> element function on one cell into the finite element space on one of its
> children (i.e., the 'embedding' or 'prolongation' matrices). However, the
> current finite element can either not define this sort of operation, or it has
> not yet been implemented.

Yu -- could you try to come up with a minimal example that demonstrates the
error? It doesn't have to do anything useful -- just set up the FE, a
DoFHandler, call SolutionTransfer. This way, it would be much simpler for us
to reproduce the error.

Best
W.

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

Yu Leng

unread,
Jul 13, 2020, 4:21:39 PM7/13/20
to deal.II User Group
Wolfgang,

Thanks for your quick response. I added a function ( local_refine(),  line 959 - 1010 ) to step-61, please see the example in the attachment.

I have this error in serial as well. The error comes from SolutionTransfer.interpolate().


Thanks,
Yu 
step-61.cc

Luca Heltai

unread,
Jul 13, 2020, 4:39:47 PM7/13/20
to dea...@googlegroups.com
Dear Yu,

It is unclear what it means to transfer a solution for FE_FaceQ. On refined cells, the central part of the skeleton cannot be transferred from the outer skeleton (I.e., a refined grid is not a subspace Of the coarse grid), so technically we cannot transfer solutions for FE spaces defined only on faces. You should construct the solution transfer by hand, if you really need that. 

Luca

Il giorno 13 lug 2020, alle ore 22:21, Yu Leng <yulen...@gmail.com> ha scritto:


--
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/4a80b18b-a555-4049-9f05-58a2182c0a3do%40googlegroups.com.
<step-61.cc>

Yu Leng

unread,
Jul 13, 2020, 4:48:44 PM7/13/20
to deal.II User Group
Hi, Luca, 

Thanks for your explanation. 

What I really need is the solution in the interior (FE_DGQ). 

I am trying to separate (FE_DGQ, FE_FaceQ) into (FE_DGQ, FE_Nothing) and (FE_Nothing, FE_FaceQ)  and hope in this way I can only transfer solution on FE_DGQ. But I have no luck yet.

On the other hand, can you recommend any reference on how to transfer the solution by hand. 


Thanks,
Yu
Dear Yu,

To unsubscribe from this group and stop receiving emails from it, send an email to dea...@googlegroups.com.

Wolfgang Bangerth

unread,
Jul 15, 2020, 11:37:19 PM7/15/20
to dea...@googlegroups.com
On 7/13/20 2:48 PM, Yu Leng wrote:
>
> What I really need is the solution in the interior (FE_DGQ).
>
> I am trying to separate (FE_DGQ, FE_FaceQ) into (FE_DGQ, FE_Nothing) and
> (FE_Nothing, FE_FaceQ)  and hope in this way I can only transfer solution on
> FE_DGQ. But I have no luck yet.

What specifically happens?


> On the other hand, can you recommend any reference on how to transfer the
> solution by hand.

You should be able to define a DoFHandler that *only* has the FE_DGQ, copy the
solution into a vector associated with that DoFHandler, and transfer that from
one mesh to another. Then reverse the process once you're on the other mesh.

Yu Leng

unread,
Jul 16, 2020, 12:09:06 AM7/16/20
to deal.II User Group


On Wednesday, July 15, 2020 at 11:37:19 PM UTC-4, Wolfgang Bangerth wrote:
On 7/13/20 2:48 PM, Yu Leng wrote:
>
> What I really need is the solution in the interior (FE_DGQ).
>
> I am trying to separate (FE_DGQ, FE_FaceQ) into (FE_DGQ, FE_Nothing) and
> (FE_Nothing, FE_FaceQ)  and hope in this way I can only transfer solution on
> FE_DGQ. But I have no luck yet.

What specifically happens?


This ended up working.  I realized using blockvectors and a separate dofhandler is a better way. 

Thanks for all the help. 
Reply all
Reply to author
Forward
0 new messages