lehrfempp
lehrfempp copied to clipboard
Second order writeMatplotlib
I implemented the second order plotting functionality in Matplotlib by fitting a polynomial of degree 2 through the midpoint and the two vertices. Interestingly, the same problems arise as with TikZ:
Otherwise, the plots look fine:
- TriaO1
- TriaO2
- QuadO1
- QuadO2
I suspected that the parametrization breaks down for these cells so I computed the determinants of the Jacobians evaluated at a couple of random points within the cell. The following cells have all-negative determinant values (for the mesh with quads): 2, 3, 6, 7, 10, 11, 14, 15
. @hiptmair do you agree that this is the reason why the curves are incorrect for these cells? This would imply that my TikZ implementation is also correct.
Well, the quadratic parameterization of the edge shape based on three points should be very stable. I will have to look at the internal representation once more, but for a low-degree polynomial any choice of basis should be all right.
I don't exactly know how the mesh refinement is implemented, but aren't the coordinates of the refined mesh computed via the child geometries of the cells? In that case, if the parametrization of a QuadO2
breaks down it yields edges that look weird. For plotting, I only interpolate between three points so it shouldn't go wrong.
@anianruoss Can you please provide me with the exact positions of the nodes that you used to construct the quad in your plots? I'm currently implementing n-th order visualization in Paraview. Then we could compare visually how it looks in paraview..
@craffael you can find the meshes here.
Okay I've visualized the square_quads.msh using ParaView and second order elements:
Then if we refine it once:
As you can see there is not really a difference between the two. And in particular I don't observe the effect which you observe (e.g. close to Node 19). Also if I zoom in in Paraview, I don't see such a behavior.
I also managed to reproduce the negative determinants as you described them. This is not necessarily a bug, but definitely not nice and should be corrected. The problem seems to be that the refinement patterns don't preserve the orientation of the underlying mesh elements. I've created an issue for this #139