On the use of higher order or 'special' elements

[rebpoli]

Hi

I need to increase interpolation accuracy around the tip of a crack. The best idea that comes to mind is to have a special higher order element in that position.

I am currently using TET10 elements - does libmesh support higher order elems?
Can I use them together with TET14?
If not, does it make sense to design my own element?

Thanks,
Renato

[roystgnr]

If you're using a Lagrange FE basis, you can't really get higher-order than TET10 in libMesh. TET14 adds a few "bubble functions", but doesn't include all of P^3.

If you use the HIERARCHIC FE basis, though, a TET14 should let you use cubic and higher bases - it stores more degrees of freedom on the edge and face nodes as the polynomial degree p goes higher. You can even refine p adaptively, to just get the higher order near the crack tip.

IIRC, though, h refinement is generally more productive near the tip of a crack. Your stress/strain there aren't going to be as smooth as elsewhere in your domain, and to get the full order of convergence from high p bases you need the true solution to be smooth enough for it.

Selfishly, I'd love to see you try both. Adaptive p refinement on Tets is relatively new for us and I don't think we have as much coverage of it as we should yet.

[rebpoli]

Hi Roy, Thanks for the reply. I just started my PhD at UT - Austin, so I will be around for a while testing stuff. :-) Getting accurate estimates around crack tips is one of my main interests. The thing is I have to compute integrals over the crack boundaries. Simple stuff: I need to pair the crack faces, then measure the crack aperture and assign cohesive forces. All I need actually is a data structure holding a list of pair-of-pairs: [ [elem,side]+ <=> [elem,side]- ] Looks doable in a refined mesh? Especially P-refinement - wouldn't that demand the use of higher order elements in the _whole_ mesh? In h-refinement, the problem would be confined to where it belongs... Is this understanding correct? Renato Em dom., 10 de mar. de 2024 às 22:31, roystgnr ***@***.***> escreveu:

…

If you're using a Lagrange FE basis, you can't really get higher-order than TET10 in libMesh. TET14 adds a few "bubble functions", but doesn't include all of P^3. If you use the HIERARCHIC FE basis, though, a TET14 should let you use cubic and higher bases - it stores more degrees of freedom on the edge and face nodes as the polynomial degree p goes higher. You can even refine p adaptively, to just get the higher order near the crack tip. IIRC, though, h refinement is generally more productive near the tip of a crack. Your stress/strain there aren't going to be as smooth as elsewhere in your domain, and to get the full order of convergence from high p bases you need the true solution to be smooth enough for it. Selfishly, I'd love to see you try both. Adaptive p refinement on Tets is relatively new for us and I don't think we have as much coverage of it as we should yet. — Reply to this email directly, view it on GitHub <#3794 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER4VV4TYGNUU4NK34ELYXUXQZAVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONBQGEZTO> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[roystgnr]

When we do mesh h-refinement, by default we renumber elements (in case we have gaps from coarsening that could be usefully closed up), so you don't want your data structure to ID elements by id(). We don't change Elem pointers, but we do delete pointers if any coarsening is done, so you can only ID elements by pointer if you never coarsen or if you're careful to remove coarsened-away elements from your structure in a way that doesn't dereference dangling pointers.

P-refinement demands the use of "complete-order" (e.g. TET14) elements in any part of the mesh that you might want to p-refine to a sufficient degree (e.g. a TET4 will support p<2, TET10 p<3, TET14 arbitrary p). We just recently added support for meshes with mixed Elem order in the same manifold (so a TET4 can be a neighbor of a TET14), but it was intended for meshes in intermediate stages of modification so if you want to solve on such a mesh you'll be the first.

But p-refinement doesn't demand the use of higher-order FE anywhere you have a higher order element. You can have a TET14 mesh and put a p=1 basis on it; in that case the extra 10 nodes just get used for mapping functions but not for shape functions and so not for unknown solution coefficients.

[rebpoli]

Nice. If I understood correctly, it seems that P-Refinement is the easiest way to go, for now. Do you have a simple example I can look at? The simplest workflow I can imagine: 1) get the mesh to TET14 ; 2) choose some elements to p-refine ; 3) make sure it is solvable in a mixed set of "p". Renato Em qua., 13 de mar. de 2024 às 10:35, roystgnr ***@***.***> escreveu:

…

When we do mesh h-refinement, by default we renumber elements (in case we have gaps from coarsening that could be usefully closed up), so you don't want your data structure to ID elements by id(). We don't change Elem pointers, but we *do* delete pointers if any coarsening is done, so you can only ID elements by pointer if you never coarsen or if you're careful to remove coarsened-away elements from your structure in a way that doesn't dereference dangling pointers. P-refinement demands the use of "complete-order" (e.g. TET14) elements in any part of the mesh that you might want to p-refine to a sufficient degree (e.g. a TET4 will support p<2, TET10 p<3, TET14 arbitrary p). We just recently added support for meshes with mixed Elem order in the same manifold (so a TET4 can be a neighbor of a TET14), but it was intended for meshes in intermediate stages of modification so if you want to solve on such a mesh you'll be the first. But p-refinement doesn't demand the use of higher-order FE anywhere you have a higher order element. You can have a TET14 mesh and put a p=1 basis on it; in that case the extra 10 nodes just get used for mapping functions but not for shape functions and so not for unknown solution coefficients. — Reply to this email directly, view it on GitHub <#3794 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER73LZR45Z4RUZ3SPFTYYBW55AVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONZVGEYTA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[roystgnr]

Check out adaptivity example 3?

[rebpoli]

Will do. Thank you.

…

On Thu, Mar 14, 2024, 18:06 roystgnr ***@***.***> wrote: Check out adaptivity example 3? — Reply to this email directly, view it on GitHub <#3794 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVERZHXTZLOF5PB7MX34DYYIUPLAVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOOJSGU4TS> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rebpoli]

Hi, I am studying adaptivity_ex3 in-depth, trying to vary parameters. It seems I'll need the "mesh->all_complete_order" function to get higher-order p refinement. However, when I set "complete=true" in the input file, the mesh becomes inconsistent, and the solver breaks. Is that a bug? Or am I using an invalid set of input parameters? [image: image.png]  Em qui., 14 de mar. de 2024 às 18:16, rebpoli ***@***.***> escreveu:

…

Will do. Thank you. On Thu, Mar 14, 2024, 18:06 roystgnr ***@***.***> wrote: > Check out adaptivity example 3? > > — > Reply to this email directly, view it on GitHub > < #3794 (reply in thread)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AMOVERZHXTZLOF5PB7MX34DYYIUPLAVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOOJSGU4TS> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#3794 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER6TVA72KKFOFAZTALLYYIVTZAVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DOOJSGY2TE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[roystgnr]

When I set complete=true and run the whole make check suite of test cases there, I do see an issue after a couple solve steps when running with prisms. I'm checking that out now. Beyond that, I don't know what other parameters you're using so I can't say if there are other bugs too.

[roystgnr]

I've got a fix for one bug, in #3810, but I'm not yet sure how to replicate your twisted mesh; post all of the input file changes you've made?

[rebpoli]

Here you go...

The trigger is this combination (it seems):

approx_order = 3
complete = true
dimension = 3
extrusion = true

adaptivity_ex3.in.txt

[roystgnr]

I can't seem to replicate the problem, either with those variables added or with your .in file. That's definitely the .in file that is giving you failed solves and trashed output? Are you running with the patch in #3810 (and in devel, now)?

If the answers are "yes" and "yes", would you post the .e file that looks so screwed up?

I also tried just changing from tensor to simplex (so we'd actually get a meaningfully-different-from-second-order "complete" PRISM21 instead of HEX27), but I'm still seeing successfully completed solves and looks-fine-in-Paraview visualization.

[rebpoli]

In fact, the answers are "yes" (the exact .in file), and "no" (not in devel). Let me get libmesh into devel branch and try again. Renato Em qua., 20 de mar. de 2024 às 10:03, roystgnr ***@***.***> escreveu:

…

I can't seem to replicate the problem, either with those variables added or with your .in file. That's definitely the .in file that is giving you failed solves and trashed output? Are you running with the patch in #3810 <#3810> (and in devel, now)? If the answers are "yes" and "yes", would you post the .e file that looks so screwed up? I also tried just changing from tensor to simplex (so we'd actually get a meaningfully-different-from-second-order "complete" PRISM21 instead of HEX27), but I'm still seeing successfully completed solves and looks-fine-in-Paraview visualization. — Reply to this email directly, view it on GitHub <#3794 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER4MBAXSKJAEGSTVA43YZGQMNAVCNFSM6AAAAABEGJFCOGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DQNJUGM3DE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rebpoli]

I updated the devel branch, and now the mesh looks good.
I still get a crash after the refined iteration (p-refinement).
It looks like a valid setup - any idea of what might be wrong?

(*.in configuration file attached)
adaptivity_ex3-240320.in.txt

---

Initial L2-Error is: 6.67143
Initial H1-Error is: 7.68181
Beginning Solve 0
System has: 64 degrees of freedom.
Linear solver converged at step: 21, final residual: 3.76874e-15
L2-Error is: 0.267678
H1-Error is: 1.19193
Mean discontinuity error = 2.22061e-15
Refining the mesh...
*** Warning, This code is untested, experimental, or likely to see future API changes: ../src/mesh/nemesis_io_helper.C, line 80, compiled Mar 20 2024 at 23:08:46 ***
Beginning Solve 1
System has: 165 degrees of freedom.
Linear solver converged at step: 27, final residual: 9.84268e-13
L2-Error is: 0.26745
H1-Error is: 1.1953
Mean discontinuity error = 2.28134e-15
Refining the mesh...
Beginning Solve 2
System has: 336 degrees of freedom.
Linear solver converged at step: 0, final residual: inf
libMesh terminating:
NaN solve result
Stack frames: 6
0: libMesh::print_trace(std::ostream&)
1: libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*, std::ostream&)
2: main
3: /usr/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7d8941060d90]
4: __libc_start_main
5: _start
[0] /lm23_hdd/chimas4d/demos/TEST/p-adaptive/main.cpp, line 362, compiled Mar 20 2024 at 22:13:19

---- CODE WHERE IT CRASHES
356 // Compute the error.
357 exact_sol.compute_error("Laplace", "u");
358
359 // The error should at least be sane, but it isn't if the solver
360 // failed badly enough
361 if (libmesh_isnan(exact_sol.l2_error("Laplace", "u"))) <<<<<<====
362 libmesh_error_msg("NaN solve result");
363

[rebpoli]

Hi Roy

I am analyzing this problem in greater depth now.
One approach to representing the fracture tip geometry would be to refine only one side of the element, in opposition to the H and P approaches. This approach would be similar to hanging nodes (e.g., fig 3.11.4 in Hughes's book).

Does libmesh support that?

Thank you,
Renato