Generating 1D lower dimensional block and adding it to 3D filemesh

[Florian-Konrad]

Hi :)
I was wondering if there is a way with the existing MeshGenerators to generate a lower dimensional block from a list of points (x,y,z) that describe a polyline and add this to an existing 3D filemesh. The polyline in my case is also following the edges of the filemesh.
My question is similar to this one #24174
But my filemesh (exodus format) is not coming from GMSH.
If this isnt possible does someone know a way/tool to do this?
Cheers
Florian

[GiudGiud]

Hello

I m not sure we have tried to do this before but on paper it's possible.
Use a FileMeshGenerator to load your mesh
Use a ParsedCurveGenerator to create the 1D line (for example)

then you can either combine (detached meshes) using a CombineMeshGenerator or stitch them (you ll need a nodeset to stitch the polyline to on the multiD mesh)

Guillaume

[Florian-Konrad]

Ah I see! Thanks a lot! ... maybe this did the trick.. need to test if the mesh actually works for my simulation but in paraview it looks good!
Did it like this:

[Mesh]
  [input_mesh]
    type = FileMeshGenerator
    file = ./test_mesh.e
  []
  [wellblock]
    type = PolyLineMeshGenerator
    points = '0.2	0.5	0
    0.2	0.5	0.0777778
    0.2	0.5	0.155556
    0.2	0.5	0.233333
    0.2	0.5	0.311111
    0.2	0.5	0.388889
    0.2	0.5	0.466667
    0.2	0.5	0.544444
    0.2	0.5	0.622222
    0.2	0.5	0.7    
    '
    loop = false
  []
  [wellblockbc]
    type = ExtraNodesetGenerator
    new_boundary = 'well_block_bc'
    coord = '0.2	0.5	0;
    0.2	0.5	0.0777778;
    0.2	0.5	0.155556;
    0.2	0.5	0.233333;
    0.2	0.5	0.311111;
    0.2	0.5	0.388889;
    0.2	0.5	0.466667;
    0.2	0.5	0.544444;
    0.2	0.5	0.622222;
    0.2	0.5	0.7    
    '
    input = wellblock
  []
  [aquiferblockwithwellbc]
    type = ExtraNodesetGenerator
    new_boundary = 'well_bc_aq'
    coord = '0.2	0.5	0;
    0.2	0.5	0.0777778;
    0.2	0.5	0.155556;
    0.2	0.5	0.233333;
    0.2	0.5	0.311111;
    0.2	0.5	0.388889;
    0.2	0.5	0.466667;
    0.2	0.5	0.544444;
    0.2	0.5	0.622222;
    0.2	0.5	0.7    
    '
    input = input_mesh
  []
  [stitch]
    type = StitchedMeshGenerator
    inputs = 'aquiferblockwithwellbc wellblockbc'
    clear_stitched_boundary_ids = true
    stitch_boundaries_pairs = 'well_bc_aq well_block_bc'
  []
[]

[GiudGiud]

looks fine but you are stitiching all 10 nodes of the 1D mesh? So the nodeset and the 1D mesh matched exactly?

If you were just trying to create a block at a sideset location, there's this mesh generator you can use:
https://mooseframework.inl.gov/source/meshgenerators/LowerDBlockFromSidesetGenerator.html

[Florian-Konrad]

Jeah so I got the nodeset by extracting it from my existing mesh. I want to set a 1D mesh on the edges of my existing mesh, so yes they match exactly.
I played around with LowerDBlockFromSidesetGenerator but it didnt work, if I understand correctly it tries to generate a 2D block if I input a 3D mesh. And I wanted to only have the edges.
And the new block should be connected to the 3D mesh along all nodes it shares.
For more context, in a hydraulic simulation (Darcy, porous flow, GOLEM application containing the physics) the 1D block should represent a highly conductive structure (a well) that can exchange fluid flow with the surrounding 3D-mesh-elements. So if I understand it correctly the block needs be connected on all shared nodes.

[Florian-Konrad]

Here you can see the result with a test mesh I used to figure out the workflow and how I can do this later on with a different and more complicted one:

[GiudGiud]

sounds good for the simple mesh. You ll want to make sure you get physical and correct solutions on that one too (not just a working mesh) before moving to something complicated.

I think iterating on "lowerD" could have gotten you from 3D to 2D to 1D. The way you do it works

[Florian-Konrad]

ah interesting, will try all that ! Thanks a lot for the help :)

[Florian-Konrad]

Hey guys!

I have an additional question/situation regarding this stitching process.

Coming from a different filemesh (structured mesh based on an eclipse model using this python tool to convert it to exodus: https://github.com/cpgr/em2ex) I now get an error that says stitching is not possible due to the mesh type.

See attached the error, as well as the Mesh file and the input I use with --mesh-only to test the stitching.

Is it generally true that its not possible to add a lower 1D block to a structured 3D-hex-mesh? Are there any workarounds to this?
I somehow have to add a discrete element following an existing edge to this mesh!

MeshStitching.zip

Cheers
Florian

[Florian-Konrad]

yes as soon as the id values of my blocks are different stitching works! should I open an issue from this?

[GiudGiud]

As you prefer. Please tag me if you do

[Florian-Konrad]

I just discovered a bit more .. seems like my filemesh has one block without any real id ... but moose treats it as id = 0
Changing the non existing id to 0 or a string has no effect. But changing it to >0 integer applies the new id properly so its possible aftwards to change it also to a string with a second RenameBlockGenerator
So this works ... not sure if this is worth an issue since it seems to come from my filemesh.

[Mesh]
  [input_mesh]
    type = FileMeshGenerator
    file = ./MESH.e
  []
  [rename1]
    type = RenameBlockGenerator
    input = input_mesh
    new_block = 3
    old_block = 0
  []
  [rename1_renamed]
    type = RenameBlockGenerator
    input = rename1
    new_block = 'aquifer'
    old_block = 3
  []
[]

[GiudGiud]

This worked:

[Mesh]
  [input_mesh]
    type = FileMeshGenerator
    file = ./MESH.e
  []
  [re]
    type = RenameBlockGenerator
    input = input_mesh
    old_block = '0'
    new_block = 'hhss'
  []
[]

it gave me the following:

 Mesh Subdomains:
  Subdomain 0 (hhss): 350000 elems (HEX8, 350000 active), 367236 active nodes
   Volume: 1.6e+12
   Bounding box minimum: (x,y,z)=(       0,        0,    -4000)
   Bounding box maximum: (x,y,z)=(   20000,    20000,        0)
   Bounding box delta: (x,y,z)=(   20000,    20000,     4000)
  Global mesh volume = 1.6e+12

so I dont think we've narrowed down the issue enough yet.
StitchedMG does not present block id overlap between the two parts. I m not sure we want to change that since it's easy enough to Rename normally?

[Florian-Konrad]

jeah no need to change this!

[Florian-Konrad]

I have a related follow up question!
The element type generated by PolyLineMeshGenerator is EDGE2. In previous meshes i used (generated externally) my well elements (1d lower dimensional block) seem to be of type TRUSS.

Cant find information on these types just that for libmesh TRUSS elements end up being treated like EDGE2:
https://mooseframework.inl.gov/docs/doxygen/libmesh/exodusII__io__helper_8C_source.html

But I'm wondering what the difference is between EDGE2 and TRUSS for my actual simulation? Is it something related to degrees of freedom? Where can I find more info on this?

[GiudGiud]

@jain651 is this something you have worked on as well?

[roystgnr]

In libMesh, an ExodusII TRUSS element is just an EDGE2 with a funny birth name which is read() but then immediately changed and forgotten.

I'm not actually sure whether there's a difference to most other ExodusII codes either; at least https://github.com/sandialabs/seacas/blob/master/packages/seacas/libraries/exodus/include/exodus-element-types.md suggests that TRUSS and BAR (and TRUSS2 and BAR2) are indistinguishable to them.

In older finite element libraries you'll often see a lack of factorization of "finite element family" vs "geometric element" vs "weak form", and AFAIK that's where a lot of these naming distinctions come from. In libMesh and MOOSE you can take e.g. an Edge2 and give it one Lagrange or Hierarchic variable for continuous Galerkin heat conduction or one Hermite variable for conduction or phase field evolution or three Lagrange variables for displacement or multi-species conduction or 6 for displacements and moments or whatever, and it's still an Edge2, but in some other codes the "element type" refers to each unique combination of geometry and discretization (including degree) and physics.

[Florian-Konrad]

ok so if I understand correctly it shouldn't matter for any moose app?
as libmesh is only translating all synonyms to EDGE2 and there is no mechanism that limits anything on EDGE2 elements depending on their "funny birthname".

[roystgnr]

It can't matter to any app reading files only via the standard MOOSE APIs - there's not even any information retained by libMesh or MOOSE classes to tell which original name got translated to EDGE2. MOOSE apps do have direct access to ExodusII functions, so it's not impossible for some app developer to re-open a file themselves with code that executes differently depending on what they find, but surely they wouldn't...

[Florian-Konrad]

perfect thanks for explaining!