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 <jwpeter...@gmail.com<mailto:jwpeter...@gmail.com>> wrote: On Wed, Aug 28, 2019 at 11:20 AM Lee, Jae Ho <jaeho...@live.unc.edu<mailto:jaeho...@live.unc.edu>> 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 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
