Replies: 8 comments 6 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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]
![image](https://github.com/libMesh/libmesh/assets/52253255/8fa1c389-9fa0-4f92-99a6-3df238408885)
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: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I updated the devel branch, and now the mesh looks good. (*.in configuration file attached) Initial L2-Error is: 6.67143 ---- CODE WHERE IT CRASHES |
Beta Was this translation helpful? Give feedback.
-
Hi Roy I am analyzing this problem in greater depth now. Does libmesh support that? Thank you, |
Beta Was this translation helpful? Give feedback.
-
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
Beta Was this translation helpful? Give feedback.
All reactions