BreakMeshByBlock not compatible with GMesh files

[Josquin Vandeputte]

Dear moose group,

I am trying to set an interface between two phases of a composite material. The matrix contains spherical inclusions. The mesh was generated with GMesh (attached).

While Moose creates the two blocks well, it struggles to set an interface between them. Indeed, the interface is set only on the spheres that touch the boundaries of the matrix block. We use the BreakMeshByBlock to create the interface between the two phases. It also doesn't works with BreakMeshByBlockGenerator.

If the particles are isolated in the domain, no interface is created at all.

This is the code used (run with --mesh-only):

[Mesh]

 type = FileMesh

 file = test_28_05_in.e

 construct_side_set_from_node_set=true

[]

[MeshModifiers]

 [./interface]

  type = BreakMeshByBlock

 []

[]

these are the interfaces identified:

these are the inclusions identified:

So, as you can see, not all the interface is identified...

Is there a way to identify the rest of the interface ?

Best regards,

Josquin Vandeputte

[Binbin Lin]

 I have the same trouble, I think there is a bug in the BreakMeshByBlockGenerator, since it only identifies particles connected with boundaries.

helps will be appreaciated!

[Ladshaw, Austin]

I have not used the BreakMeshByBlock generator, but you can have Gmsh to create "Physical Groups" for surfaces based on their gmsh surface IDs in the .geo script file (or through the Gmsh GUI). I have done this to create interfaces between blocks in my own meshes and it works fine for me. You can even give your interfaces and surfaces (and volumes/blocks) specific names that MOOSE will identify. 

I have attached an example script and mesh file which I have used to create interior interfaces for your reference. Hope that helps.

Austin 

---

From: moose...@googlegroups.com <moose...@googlegroups.com> on behalf of Binbin Lin <linbi...@gmail.com>
Sent: Tuesday, June 2, 2020 9:37 AM
To: moose-users <moose...@googlegroups.com>
Subject: [EXTERNAL] Re: BreakMeshByBlock not compatible with GMesh files

 

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/1aad496f-9302-42ca-a505-57f5529b1a3d%40googlegroups.com.

[Wen Jiang]

Josquin,

Could you open an issue at Github and attach your input and mesh file? It will be great if you could make a smaller problem to reproduce this error, like a 2D problem with one inclusion in the center. 

You also mentioned that it could be an issue with Gmsh. The easiest way to rule out that possibility is to use MOOSE ConcentricCircleMeshGenerator. It can be used to create a circle inclusion with an outer square. You can test if an interface can be correctly created with that internal generated mesh.. 

Regards,

Wen 

[Alexander Lindsay]

I doubt that there is a “bug” with gmsh but there are things missing in the translation from gmsh to the libmesh mesh relative to exodus. For example boundary “Physical” names/ids never have any sidedness to them in gmsh, eg you cannot use gmsh to create side sets like you can with exodus. We have talked about the following feature in libmesh: if a user uses a specific prefix in a Physical gmsh name then we would be able to construct a side set. We do something similar for lower dimensional blocks right now to help the libmesh gmsh reader distinguish between Physical names that should be boundary ids. 

On Jun 2, 2020, at 7:04 AM, Wen Jiang <jiang...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/85d8bd88-69f6-4da4-90b8-414711376a31%40googlegroups.com.

[Andrea Rovinelli]

Josquin,

I have a possible workaround/check that is going to shed some light on what is happening and may help you run whatever you need.

Create an input file only reading your gmsh meshfile and enabling exodus output. 

This file should look like

[Mesh]

  [./fmg]

    type = FileMeshGenerator

    file = whatever.gmsh

  []

[]

[Outputs]

  exodus = true

[]

Run it with the 

--mesh-only

option. This option only runs mesh-related operations. hte output block will allow to generate an exodus output.

Check the exodus output (usually named _in.e) to see if the domains are correctly assigned to each element (use ParaView or whatever).

If the domains are not assigned properly than Alex is probably right.

After that, create another input file utilizing the _in.e (exodus) as mesh input and add the BreakMeshByBlockGenerator.

run this with the --mesh-only option and see if all interfaces are identified.

If know we might have problem with BreakMeshByBlockGenerator.

Please keep in mind that BreakMeshByBlockGenerator only uses blocks to break the mesh, so if domains are correct interfaces should be correct. Therefore try to avoid creating interfaces or side sets in the gmsh.

Andrea

To unsubscribe from this group and stop receiving emails from it, send an email to moose...@googlegroups.com.