Open Rickbude opened 4 months ago
I noticed that loading an H1^3 space also causes glvis to crash. To be clear, the header of the solution file contains:
FiniteElementSpace
FiniteElementCollection: H1_2D_P2
VDim: 3
Ordering: 0
The errors are different from the ones reported above (no segfault), so this might be different / unrelated issue. But I thought I'd report anyway. I get various errors, like:
Using GLSL 450
VisualizationSceneVector::VisualizationSceneVector
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server "p$"
after 301 requests (301 known processed) with 0 events remaining.
and
VisualizationSceneVector::VisualizationSceneVector
X Error of failed request: BadCursor (invalid Cursor parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x12dafa50
Serial number of failed request: 310
Current serial number in output stream: 317
Can you post the mesh and the grid function you are trying to load?
Of course. Please find attached 1 mesh and 3 grid functions for that mesh. (1x ND_R2D and 2x H1^3)
Oh, currently you can't visualize 3D vector field on a 2D mesh.
One way to do that will be to make the 2D mesh into a surface mesh embedded in 3D -- see this version.
That worked for me with the first two examples.
Ahh!! And with the changes in MFEM suggested in https://github.com/mfem/mfem/issues/4403, the ND_R2D vector field also loads on this surface mesh.
What would be the "proper" way of generating such a surface mesh from an existing 2D mesh? I found the following to work, but I am not sure if this is the right way to go:
mfem::Mesh surf_mesh(m_mesh);
surf_mesh.SetCurvature(m_element_order,false,3);
surf_mesh.Save("surf-mesh.mesh");
Sorry for not catching this earlier; the error messages generated by glvis did not really indicate that the mesh being 2D was the problem.
By the way: I noted that the visualization of the results on this surface mesh seems a bit restricted compared to equivalent visualizations of 2D vector fields on 2D meshes:
Is this by design?
Yep, SetCurvature
is the right way to make a 2D into a surface mesh. If you have existing 2D mesh files, you can also manually change the VDim
of the nodes to 3 and add a zero at the end of each node coordinate (for the z
component).
By the way: I noted that the visualization of the results on this surface mesh seems a bit restricted compared to equivalent visualizations of 2D vector fields on 2D meshes:
- Pressing 'v' multiple times does not rescale the vector quivers (they just disappear)
- F' cycles only through the magnitude and x/y/z components, not the divergence and curl.
Is this by design?
Good question, @v-dobrev or @najlkin -- do you know?
This is a companion issue to the identically-named issue in MFEM: https://github.com/mfem/mfem/issues/4403
Loading a solution that is expressed in terms of ND_R1D, ND_R2D, RT_R1D and RT_R2D elements gives an error that looks like:
This error is caused by missing code in MFEM (see the linked issue for more information). Adding the missing code resolves things on the MFEM side, but now glvis throws a segmentation fault. This is the trace obtained with gdb: