Re: [Libmesh-users] QTrap for TRI3SUBDIVISION

[Lee, J. H. <jae...@li...>]

I am having some trouble getting a stack trace, but I will continue to look more into what may the issue here. Another question — is there a function already available that support projecting solution from a system that uses subdivision onto a system that uses lagrange elements and vice versa?

On Aug 28, 2019, at 12:29 PM, John Peterson <jwp...@gm...<mailto:jwp...@gm...>> wrote:



On Wed, Aug 28, 2019 at 11:20 AM Lee, Jae Ho <jae...@li...<mailto:jae...@li...>> wrote:
John —

I just added TRI3SUBDIVISION to quadrature_trap_2D.C as a case, and I think it’s working now. I am still debugging things one step at a time, and one place that I got a complaint from is fe_lagrange.C — I may be confusing myself right now, but I think it’s complaining because TRI3SUBDIVISION is listed under FIRST order along with TRI3, but I think TRI3SUBDIVISION should be FOURTH order. I think I am confused because TRI3SUBDIVISION is listed in fe_lagrange.C.

Hmm... I guess somehow your code is calling lagrange_n_dofs_at_node() or lagrange_n_dofs(). That does seem wrong to me, unless somehow a LAGRANGE FE was created/reinit'd on a TRI3SUBDIVISION Elem. It might be helpful if you could give us a stack trace for the case where your code hits that line in fe_lagrange.C. Maybe we are building a Lagrange FE internally to the library for some reason...

Thanks for your report about the QTrap thing working, I will make a PR for that shortly.

--
John