gmsh with 1D lower dimensional elements into a 3D mesh

[mcacace]

Dear all,
we have been trying to import a gmsh mesh consiting of 3D and 1D elements, but it does seem that the reading capability of the FileMeshGenerator in Moose does not support this type of combination (all is fine if the LD elements have a dim=dim_3d-1).
Attached the input *.geo file to reproduce the issue.
On a side node, we tried to play a bit around by merging and extracting block ids (below our Mesh block), but despite being able to generate the correct IDs for the 1D elements, while running a simulation with that geometry all internal connectivities are lost and the 1D elements does not have any influence on the overall behaviour.
Any help/hint would be highly appreciated.
Thanks,
Mauro

[Mesh]
  [add_inj]
    type = PolyLineMeshGenerator
    points = '2.5e3 5e3 -0.2e3
    2.5e3 5e3 -0.4e3
    2.5e3 5e3 -0.6e3
    2.5e3 5e3 -0.8e3
    2.5e3 5e3 -1.0e3
    2.5e3 5e3 -1.1e3
    2.5e3 5e3 -1.2e3
    2.5e3 5e3 -1.3e3
    2.5e3 5e3 -1.4e3'
    loop = false
  []
  [add_pro]
    type = PolyLineMeshGenerator
    points = '7.5e3 5e3 -0.2e3
    7.5e3 5e3 -0.4e3
    7.5e3 5e3 -0.6e3
    7.5e3 5e3 -0.8e3
    7.5e3 5e3 -1.0e3
    7.5e3 5e3 -1.1e3
    7.5e3 5e3 -1.2e3
    7.5e3 5e3 -1.3e3
    7.5e3 5e3 -1.4e3'
    loop = false
  []
  [input]
    type = FileMeshGenerator
    file = 'mesh/fiel.msh'
  []
  [merge]
    type = MeshCollectionGenerator
    inputs = 'input add_inj add_pro'
  []
  [extract_inj]
    type = SubdomainBoundingBoxGenerator
    input = merge
    block_id = 1
    block_name = 'injector'
    top_right = '2.49e3 4.99e3 -0.19e3'
    bottom_left = '2.51e3 5.01e3 -1.41e3'
  []
  [extract_pro]
    type = SubdomainBoundingBoxGenerator
    input = extract_inj
    block_id = 2
    block_name = 'producer'
    top_right = '7.49e3 4.99e3 -0.19e3'
    bottom_left = '7.51e3 5.01e3 -1.41e3'
  []
[] 

fiel.zip

[GiudGiud]

Hello

The MeshCollectionGenerator is explicit that it's not merging meshes, just appending. So the internal connectivities are indeed not working.

The StitchedMeshGenerator is the only one that merges them.
https://mooseframework.inl.gov/source/meshgenerators/StitchedMeshGenerator.html

However, I've never dealt with 3D & 1D elements in the same simulation in MOOSE. By lowerD we usually mean 2D for a 3D mesh. What physics are you going to use? Did you write your own kernels to deal with 1D?

Guillaume

[mcacace]

Dear @GiudGiud,
thanks a lot for your reply. Indeed, I thought the same (about the MeshCollectionGenerator vs StichedMeshGenerator). However, to be able to stitch the meshes I would need to define a boundary and this breaks down for 3D and 1D (cannot find a common boundary to stitch them). I also see that lowerD means (max_dim-1), but ... We routinely run simulations (based on an in-house developed mesher) with 1D-2D-3D FEMs (there is an example on the gallery page). And, yes, we use our own developed kernel for the simulations.
This said, would you suggest us to write our own import routine?
Thanks

[GiudGiud]

I think adding support for importing gmsh 1-2-3D mixed-dimensional meshes would be awesome.
@jwpeterson will know if it's needed or if there's something we can do right now.

[mcacace]

Excellent! Let me know.
Mauro

[jwpeterson]

If I recall correctly, the difficulty with Gmsh meshes is that they can use lower-dimensional elements to specify boundary conditions, in which case those elements should not be added to the mesh. We added some support for this which is related to the lower_dimensional_blocks variable declared in GmshIO::read_mesh():

  // Keep track of lower-dimensional blocks which are not BCs, but
  // actually blocks of lower-dimensional elements.
  std::set<subdomain_id_type> lower_dimensional_blocks;

The internal convention that we created is that if the string "lower_dimensional_block" appears in the file, i.e.

              // The lines in the PhysicalNames section should look like the following:
              // 2 1 "frac" lower_dimensional_block
              // 2 3 "top"
              // 2 4 "bottom"
              // 3 2 "volume"

then we will treat that block of elements as actual elements and not boundary conditions. I can't recall if there are any issues with having all three dimensions present in the same mesh or not, it's possible that it already works provided that you use the "lower_dimensional_block" string like above.

[mcacace]

@jwpeterson thanks! Almost right, if I added the lines as suggested I can retrieve the 1D elements though not exactly in the right manner
see below (the right way would be to have only the two vertical line elements). Will try to have a look deeper at that.