Adding nodes to an element side

[rebpoli]

Hi,

I am willing to refine only one side of an element.

Does libmesh support that?
Should I write my own element?

Renato

[roystgnr]

If you refine one side of a Quad4, then you'd expect to get a Quad5? And then if you refined a second side you'd get either a Quad6 or a Quad6ButWithTheRefinedSidesAdjacentNotOpposite? :-) It sounds like you'd end up having to write a lot of your own elements if "create a new element for each asymmetric refinement possibility" is what you want to do.

If you're just trying to study this academically then I'd say the thing to do would be to refine symmetrically (to a Quad8 or Quad9 in this case) but then manually add a constraint equation for each of the sides you don't really want refined, so that you get back to exactly the function space you want.

If you're trying to do this in a production code, then I would leave out the constraint equation. It'll be there automatically if you have an unrefined neighbor, whereas if you don't want either of that side's neighbors unrefined then it's a safe bet that you should want the side refined too, in which case "do nothing special" is the right thing to do.

[rebpoli]

Thanks Roy. Well, I am definitely after the academic validation of an idea. See: I am building my mesh only with TETs. A fracture is represented as a face on the boundary of the domain (a triangle). This is the ONLY place I need higher-order representation (only for displacements, and only at the tip!). Any further refinement is a waste (in 3D, this quickly becomes a big deal). I could imagine a "dynamic element creation" from a function: ::: Elem * my_tet4( Coords, side_on_frac_to_refine ) They'd be a composition of Lagrange polynomials; things would be quite regular and "loopable." I would be able to get, say, 20 additional nodes EXACTLY where I need them. Any chance this could work? Renato Em ter., 9 de abr. de 2024 às 13:43, roystgnr ***@***.***> escreveu:

…

If you refine one side of a Quad4, then you'd expect to get a Quad5? And then if you refined a second side you'd get either a Quad6 or a Quad6ButWithTheRefinedSidesAdjacentNotOpposite? :-) It sounds like you'd end up having to write a lot of your own elements if "create a new element for each asymmetric refinement possibility" is what you want to do. If you're just trying to study this academically then I'd say the thing to do would be to refine symmetrically (to a Quad8 or Quad9 in this case) but then manually add a constraint equation for each of the sides you don't really want refined, so that you get back to exactly the function space you want. If you're trying to do this in a production code, then I would leave out the constraint equation. It'll be there automatically if you have an unrefined neighbor, whereas if you don't want either of that side's neighbors unrefined then it's a safe bet that you should want the side refined too, in which case "do nothing special" is the right thing to do. — Reply to this email directly, view it on GitHub <#3826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER6NUHHGF2OFVKATMDDY4QZFHAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANRSG43TO> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[roystgnr]

With Tets, doing things anisotropically can get a lot simpler - one typical M.O. is to just keep a "flat" mesh with no hierarchy, but refine an edge at a time by splitting each of the tets that share the edge. You still have all Tet4 elements, just e.g. 12 sharing two sub-edges where there used to be 6 sharing a single edge. But that isn't enough if you want anisotropic p refinement.

It's weird to me that you'd want p refinement near a fracture rather than h refinement (generally that's the sort of problem where you get less smoothness and so higher p gives you more ringing instead of higher convergence rates), but if you're right then I think you're back to where "p-refine plus constrain" is your best bet.

Right now libMesh still doesn't support setting up constraint equations automatically on a higher-geometric-order Elem neighboring a lower-geometric-order one, nor do we support p constraints on non-p-hierarchic FE families. But you could get the space you want by building a Tet10 mesh, putting HIERARCHIC variable(s) on it, using p=1 on the domain as a whole, p-refining the elements with sides on the fracture boundary, and adding manual constraints to eliminate the freedom of the DoFs that aren't themselves on the boundary. For every triangle on the boundary you'd end up with an average of 1.5 new unconstrained DoFs (the quadratic DoFs on 3 boundary edges, mostly shared between 2 triangles each) and 3 new constrained DoFs (the ones on non-boundary edges), which is annoying, but would be enough for a proof of concept. You could go up to cubics or higher if you used Tet14 instead of Tet10.

[rebpoli]

Thank you for the reply, Roy. The thing is, 3D poroelastic models quickly grow in size. I am trying to keep the fracture mechanics in the 2D world doing the best possible with the fewest dofsAfter talking to Prof. Hughes, it looks like it is worth a shot - at least to see how it behaves. I think the solution of the p-refinement is worth a try. If I understood correctly, the "plus constraint" part is an optimization, as it should work fine without the constraints. Is gmsh able to generate a mesh of TET10? Renato Em sex., 12 de abr. de 2024 às 12:37, roystgnr ***@***.***> escreveu:

…

With Tets, doing things anisotropically can get a lot simpler - one typical M.O. is to just keep a "flat" mesh with no hierarchy, but refine an edge at a time by splitting each of the tets that share the edge. You still have all Tet4 elements, just e.g. 12 sharing two sub-edges where there used to be 6 sharing a single edge. But that isn't enough if you want anisotropic p refinement. It's weird to me that you'd want p refinement near a fracture rather than h refinement (generally that's the sort of problem where you get less smoothness and so higher p gives you more ringing instead of higher convergence rates), but if you're right then I think you're back to where "p-refine plus constrain" is your best bet. Right now libMesh still doesn't support setting up constraint equations automatically on a higher-geometric-order Elem neighboring a lower-geometric-order one, nor do we support p constraints on non-p-hierarchic FE families. But you could get the space you want by building a Tet10 mesh, putting HIERARCHIC variable(s) on it, using p=1 on the domain as a whole, p-refining the elements with sides on the fracture boundary, and adding manual constraints to eliminate the freedom of the DoFs that aren't themselves on the boundary. For every triangle on the boundary you'd end up with an average of 1.5 new unconstrained DoFs (the quadratic DoFs on 3 boundary edges, mostly shared between 2 triangles each) and 3 new constrained DoFs (the ones on non-boundary edges), which is annoying, but would be enough for a proof of concept. You could go up to cubics or higher if you used Tet14 instead of Tet10. — Reply to this email directly, view it on GitHub <#3826 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER63SLNSVLJHZKCU7S3Y5ALUFAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAOJYG43TK> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[roystgnr]

It will work a little too fine without the constraints - you'll also have some extra accuracy in the normal-to-fracture direction, and if you're trying to see what the impact of just the extra parallel-to-fracture accuracy would have then you'll need the constraints to restrict your space to that.

I don't recall what gmsh can do, but if you have a TET4 mesh just call all_second_order() to turn it into a TET10 mesh.

[rebpoli]

I will try that. I did not understand completely which constraints to add. Let me play with it a little the simple way. If it works, next I'd add the constraints and next-next I'd try to 'adaptively' position the nodes on the face. Or likely choose bigger battles... Thank you very much once again! Renato

…

On Fri, Apr 12, 2024, 17:06 roystgnr ***@***.***> wrote: It will work a little *too* fine without the constraints - you'll also have some extra accuracy in the normal-to-fracture direction, and if you're trying to see what the impact of *just* the extra parallel-to-fracture accuracy would have then you'll need the constraints to restrict your space to that. I don't recall what gmsh can do, but if you have a TET4 mesh just call all_second_order() to turn it into a TET10 mesh. — Reply to this email directly, view it on GitHub <#3826 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVERZ7EPE5HEOB7MQM5WLY5BLFDAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMBQGU3TM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rebpoli]

Hi Roy, Following up on this thread. I started this refinement thing over the fracture elements. What is happening now is that I have around 10 variables and 3 systems in the EquationSystems. The MeshRefinement class does not filter the variables to p-refine. I set all of them to HIERARCHIC, but I am not really sure about the impact of that. The code slows down significantly. Can I get p-refinement for selected variables? Renato Em sex., 12 de abr. de 2024 às 17:41, rebpoli ***@***.***> escreveu:

…

I will try that. I did not understand completely which constraints to add. Let me play with it a little the simple way. If it works, next I'd add the constraints and next-next I'd try to 'adaptively' position the nodes on the face. Or likely choose bigger battles... Thank you very much once again! Renato On Fri, Apr 12, 2024, 17:06 roystgnr ***@***.***> wrote: > It will work a little *too* fine without the constraints - you'll also > have some extra accuracy in the normal-to-fracture direction, and if you're > trying to see what the impact of *just* the extra parallel-to-fracture > accuracy would have then you'll need the constraints to restrict your space > to that. > > I don't recall what gmsh can do, but if you have a TET4 mesh just call > all_second_order() to turn it into a TET10 mesh. > > — > Reply to this email directly, view it on GitHub > < #3826 (reply in thread)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AMOVERZ7EPE5HEOB7MQM5WLY5BLFDAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMBQGU3TM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#3826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVERZGMTPP6IALO6RBJATY5BPLHAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMBQG4ZTA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[roystgnr]

Check out DofMap::should_p_refine()

[rebpoli]

Another issue: in paraview, I get the following message: *#...# Element of topology 'tetra14' with 14 nodes is not supported.* Any workaround for that? Em sáb., 27 de abr. de 2024 às 18:20, rebpoli ***@***.***> escreveu:

…

Hi Roy, Following up on this thread. I started this refinement thing over the fracture elements. What is happening now is that I have around 10 variables and 3 systems in the EquationSystems. The MeshRefinement class does not filter the variables to p-refine. I set all of them to HIERARCHIC, but I am not really sure about the impact of that. The code slows down significantly. Can I get p-refinement for selected variables? Renato Em sex., 12 de abr. de 2024 às 17:41, rebpoli ***@***.***> escreveu: > I will try that. I did not understand completely which constraints to add. > Let me play with it a little the simple way. > > If it works, next I'd add the constraints and next-next I'd try to > 'adaptively' position the nodes on the face. Or likely choose bigger > battles... > > Thank you very much once again! > Renato > > On Fri, Apr 12, 2024, 17:06 roystgnr ***@***.***> wrote: > > > It will work a little *too* fine without the constraints - you'll also > > have some extra accuracy in the normal-to-fracture direction, and if > you're > > trying to see what the impact of *just* the extra parallel-to-fracture > > accuracy would have then you'll need the constraints to restrict your > space > > to that. > > > > I don't recall what gmsh can do, but if you have a TET4 mesh just call > > all_second_order() to turn it into a TET10 mesh. > > > > — > > Reply to this email directly, view it on GitHub > > < > #3826 (reply in thread)>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AMOVERZ7EPE5HEOB7MQM5WLY5BLFDAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMBQGU3TM> > > > . > > You are receiving this because you authored the thread.Message ID: > > ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > < #3826 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AMOVERZGMTPP6IALO6RBJATY5BPLHAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMBQG4ZTA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#3826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMOVER7LACGX6RMHWOLSEW3Y7QXERAVCNFSM6AAAAABF5IAYOWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TENBYGUYDC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[roystgnr]

You could project onto a lower-order mesh for visualization. I don't know if Paraview has any plans to support tetra14 soon.