1d elements dev

[termi-official]

I work coupled 1D-3D problems so for me it is sometimes helpful to visualize the solutions side by side while MFEM is computing the solution to track down issues.

The draft is not very clean yet and might come with some level of memory corruption (could not test everything in detail yet). This is basically my late try on fixing #68 .

To test the PR I currently just utilize two very simple meshes which I feed into MFEM example 0.

3D mesh

MFEM mesh v1.0

dimension
1

elements
5
1 1 0 1
1 1 1 2
1 1 2 3
1 1 2 4
2 1 4 5

boundary
3
1 0 0
2 0 3
3 0 5

vertices
6
3
  0    0 -1.0
1.0    0    0
2.0    0    0
3.0  1.0    0
3.0 -1.0    0
4.0 -1.0  1.0

3D vector test field

FiniteElementSpace
FiniteElementCollection: H1_1D_P2
VDim: 3
Ordering: 0

0
2.029082637937203
2.25675394962394
0
2.128376974811976
0
1.264541318968602
2.267918293780571
1.378376974811971
2.442565462217959
1.314188487405989
0.6947706594843015
2.179750465858888
1.880065462217956
2.412159705920951
1.783782731108984
1.709311978452903
2.293586121702257
0.7516884874059858
2.347971218514969
0.719594243702995
0
2.029082637937203
2.25675394962394
0
2.128376974811976
0
1.264541318968602
2.267918293780571
1.378376974811971
-1.442565462217959
1.314188487405989
0.6947706594843015
2.179750465858888
1.880065462217956
2.41211241205920951
1.783782731108984
1.709311978452903
-2.293586121702257
0.7516884874059858
0.347971218514969
0.719594243702995
0
2.029082637937203
2.25675394962394
0
2.128376974811976
0
1.264541318968602
2.267918293780571
1.378376974811971
2.442565462217959
-1.314188487405989
0.6947706594843015
-2.179750465858888
2.179750465858888
1.880065462217956
-2.412159705920951
1.783782731108984
2.293586121702257
-0.7516884874059858
2.347971218514969
0.719594243702995

2D mesh

MFEM mesh v1.0

dimension
1

elements
5
1 1 0 1
1 1 1 2
1 1 2 3
1 1 2 4
2 1 4 5

boundary
3
1 0 0
2 0 3
3 0 5

vertices
6
2
  0    0 
1.0    0 
2.0    0 
3.0  1.0 
3.0 -1.0 
4.0 -1.0 

2d vector test field

FiniteElementSpace
FiniteElementCollection: H1_1D_P1
VDim: 2
Ordering: 0

-0.84018773
-0.39438292
-0.78309923
-0.79844004
-0.91164738
-0.19755137
-0.33522275
-0.7682296
-0.27777472
-0.55396998
-0.47739705
-0.6288709

scalar test field

0
2.029082637937203
2.25675394962394
0
2.128376974811976
0
1.264541318968602
2.267918293780571
1.378376974811971
2.442565462217959
1.314188487405989

GlVis output (left 2D, right 3D)

TODOs

• [x] Visualizing the grid without solution
• [x] Visualizing element attributes
• [ ] Visualizing boundary attributes (possible future work)
• [ ] Visualizing the element endpoints correctly (possible future work)
• [x] Visualizing high order solutions
• [x] Vector valued problems
• [ ] Merge master after #232 gets merged
• [ ] Add keys to control line width for solution interactively
• [ ] Add tests

[tzanio]

This looks really cool @termi-official. If you clean it up we will be interested in merging it. -Tzanio

[termi-official]

Okay this is more problematic than anticipated. I am currently working on modifying the mesh to support mixed dimensional elements (while also making at least 1d branching meshes possible, because they are required from time to time in mechanics and electrophysiology).

One major issue I ran into is that the elements keep disconnecting (I assume because for branched meshes the connectivity tables are broken) - this is "fixed" by simply providing different visualization modes for now.

Some features are missing in 1d vis which I probably cannot address by myself. I am aware that the following does not work (see above for bullet points).

[termi-official]

Turns out many of the issues I encountered has been fixed with recent MFEM patches and the ongoing restructuring of the GLVis codebase. Scalar field visualization is basically working now. Some minor things remain to be resolved for scalar fields.

However, vector-valued fields are still open, which are important in some areas of mechanics.

[termi-official]

Okay 3d vector visualization is also okayish now.

The visualization is not very pretty, because modifying the renderer to include dynamic line thickness information seems a big out of scope for now. I also noticed a crazy amount of code duplication between scalar and vector field visualizer classes. Maybe a good future PR is to merge the duplicate code (and hence features).

[termi-official]

Bump @tzanio @publixsubfan . I think https://github.com/GLVis/glvis/pull/232 is not being worked on anymore? Can we merge this PR then and leave the open TODOs for a follow up PR which addresses line rendering?

[tzanio]

Can we merge this PR then and leave the open TODOs for a follow up PR which addresses line rendering?

Yes, lets do that. Sorry for the long delay @termi-official !

[termi-official]

Absolutely no problem! :) I will merge master and fi the remaining errors tomorrow.

[termi-official]

Sure, we can think about adding some of the 1D network mesh stuff to MFEM, but we might need to think a bit how to do this one properly. My heart simulation framework is heavy patchwork (subclasses of mesh to patch the connectivity tables) to work around the assumption that we have the scenario of more than 2 element sharing a face. I do not have a good solution to make this properly work for now, because this assumption seems to be quite deeply rooted into the MFEM core. Happy to discuss further.

Edit: I should note that the "solution" for the visualization in the PR description is hand-constructed and not part of any simulation. I can make a PR into the data repository for smoke tests.

[tzanio]

Thanks for making the changes, @termi-official !