[Gmsh] High-order visualization for hp-FEM solutions

Marsic, Nicolas marsic at temf.tu-darmstadt.de
Sat Apr 1 12:55:40 CEST 2017


Dear Hadrien,

The current solution to visualize higher-order fields,
is to project it into a Lagrange basis (the one used by gmsh for the 
high-order visu).
A better solution is perhaps to allow the user to enter his own basis 
functions,
defining thus an InterpolationSheme per orientation, as you suggested.
But this is not possible yet...
The 'projection-on-a-Lagrange-basis' solution has the good point that 
only one well defined basis is used,
and it is up to the user to accommodate to the interface...

If you want an example, you can have a look at the small_fem solver:
http://gitlab.onelab.info/gmsh/small_fem
It uses the 'projection-on-a-Lagrange-basis' solution.
The class postprocessing/FEMSolution (FEMSolution.cpp; FEMSolution.h and 
FEMSolutionInclusion.h)
could be a good starting point if you want to get some inspiration :-).
By the way, I think that small_fem uses the same basis functions as 
hp-fem ;-).

Regarding the CG vs DG, the gmsh Lagrange basis function are defined in 
a CG way.
So you will end up with correct solution.
And finally, if you want a high-order vector solution,
you have to project the 3 components of the vector field.

I hope this helps.
Best,
Nicolas.

On 28/03/17 12:15, Beriot, Hadrien wrote:
>
>
> Hello there,
>
>
>
> I have a question regarding the visualization of high-order FEM
> solutions. I would like to use this feature for visualizing highly
> oscillatory solutions arising from high-order p-FEM solutions (for
> instance used in frequency domain electromagnetics and acoustics)?
> There, by contrast to high-order DG, the difficulty I see is that each
> element has a unique edge/face orientation, which results pretty much in
> a different basis definition for each element.
>
>
>
> Considering the tetrahedral element for instance, there are usually 6
> different possible orientations per face, which yields a total of 1296
> different possible basis definitions. In my current understanding, this
> would require defining 6^4=1296 different “$InterpolationScheme”
> entities in the input file for gmsh (for the edges shape functions, a
> workaround can be found by simply multiplying the shape function
> contribution by +1 or -1 depending on the local edge orientation).
>
>
>
> Before I start the actual implementation to make some tests, I would
> like to know whether
>
>
>
> 1.       Has anyone tried the high-order visualization feature for
> viewing 3D p-FEM solutions (integrated Legendre basis)?
>
> 2.       Can the current implementation cope with a very large number of
> interpolation schemes (approx. one per element)? Would it still perform
> correctly on large models?
>
>
>
> Thanks for your help!
>
> Kind regards,
>
>
>
> Hadrien
>
>
>
>
>
>
>
>
>
> _______________________________________________
> gmsh mailing list
> gmsh at onelab.info
> http://onelab.info/mailman/listinfo/gmsh
>


More information about the gmsh mailing list