Support variable order spaces

[rw-anderson]

A gridfunction on a p-refined space does not visualize properly - it appears the enriched elements show up as their original order. How difficult would it be to visualize a variable order space?

[dylan-copeland]

There is some code to deal with this, not in the main MFEM or glvis library, see ProlongToMaxOrder for example in miniapps/gslib/findpts.cpp: https://github.com/mfem/mfem/blob/a96065ed1802ee95e7a33ee749b2ae4a6e4a6de6/miniapps/gslib/findpts.cpp#L46

[tzanio]

Can we add this ☝️ to mfem proper and call it automatically in glvis when needed?

[dylan-copeland]

We thought about it in the recent PR https://github.com/mfem/mfem/pull/2766 which added this code. This "experimental" function is for L2 or H1 spaces. It would need to be generalized for arbitrary spaces, so we would need to think about whether that can be done in general. If there are spaces (e.g. ND, RT) that do not work, we may need to check the type with MFEM_VERIFY to prevent misuse.

[rw-anderson]

Projecting to max order seems like a workaround, but expensive if the space is highly locally enriched. Would rendering each element in its native order be too difficult?

[v-dobrev]

The first issue is that FiniteElementSpace::Save (which is used to send data to GLVis) does not support variable orders yet -- it is probably not too hard to add this. This also needs to be supported in FiniteElementSpace::Load.

With these two methods implemented properly we can try GLVis and see if there are any issues there.

[kmittal2]

Did anyone tried making this work? cc: @rw-anderson @dylan-copeland I need it for another project so figured I would check before I work on it.

[dylan-copeland]

@kmittal2 I am not aware of any work to support this, aside from ProlongToMaxOrder in miniapps/gslib/findpts.cpp, which has always worked for the examples I've seen so far but could be expensive for large enough meshes.