Unite 2 meshes after import from gmsh

[bengt]

Dear Elmer friends,

I'm trying to unite two separate meshes being imported from gmsh (lower part: volume/material 1, upper part: volume/material 2). The meshes have a common face that perfectly matches (identical coordinates).
I used:
ElmerGrid 2 2 lowerPart upperPart -unite

But I don't get the additional cells, only one original mesh being saved to "lowerPart"
Is it not possible to "glue" the two matching meshes together or is there anything wrong with my command line syntax??

Any suggestions are highly appreciated!!

Have a nice weekend, regards
Bengt

[raback]

Hi Bengt

Try

Code: Select all

ElmerGrid 14 2 msh1.msh
ElmerGrid 14 2 msh2.msh
ElmerGrid 2 2 msh1 -in msh2 -unite -out msh12 -merge 1.0e-8

The last parameter is important so that your mesh will actually share the nodes at the inrerface, if the mesh is conforming. Also non-conforming meshes may be used but then some things should be changed in your FSI case. Also you could try the following, don't know if it works...

Code: Select all

ElmerGrid 14 2 msh1 -in msh2 -unite -out msh12 -merge 1.0e-8

-Peter

[bengt]

Hi Peter,

thanks for your help! The first command works fine, however, the resulting mesh now consists only of one single volume. The fsi interface is lost (1 new volume, 6 new side faces). That's strange because each fsi-patch (of the original meshes) contains 2500 nodes and the -merge option apparently removes 2500, so the merging seems to be correct. Is there another option to keep all boundaries and the two volumes within the new mesh??

Regards
Bengt

[raback]

Hi

The automatic renumbering in ElmerGrid spoils things here since the bodies and boundaries all accupy the same numbers. You could define physical entities with the desired indexes in Gmsh. I think these might be concerved in the unification.

-Peter

[bengt]

Hi Peter,

thanks for your suggestions! I've tried it and nearly all of the gmesh mesh saving options and different gmesh file format / elmer import format options but I only get this one merged mesh. I've attached two mini-meshes, it would be great if you could have a look at them - maybe there's a rather simple trick that I just didn't see.
The meshes cannot be imported directly. They must be opened before in Gmesh and then once saved again in Gmesh format. Seems to be some Gmesh version compatibility issue.

Regards
Bengt

[bengt]

Hi,

solved the problem! Maybe there are features in gmsh that do the same, but the following finally worked for me:
- in gmsh: save each single mesh as .unv without additional options
- in Salome: import the two single meshes, redefine the physical groups (faces, volumes), build compound mesh (unite equally named groups with node merging), export compound mesh as .unv
- ElmerGrid: import .unv with -autoclean, scale from m to µm

Not really the most elegant workflow, however might be of help for someone facing the same problem...now finally back to simulation

Regards, enjoy your weekend
Bengt

[mzenker]

Hi,

I have a similar problem: I want to import a 2D mesh made with gmsh where two adjacent surfaces have different borders with slightly different mesh widths. Is there a way to force the interface to share the nodes?
I attach a test case in case someone wants to have a look.

Thank you,

Matthias

[mzenker]

Problem partly solved: using the SAME mesh width on both sides results in a slight jitter of the nodes when meshed with gmsh. So some nodes are shared, some are not. The -merge [half the mesh width] option in Elmergrid forces all nodes to be shared.
Drawback: this works only if the mesh width is the same for all problematic interfaces, which might not be the case for more complex geometries.
It would be better to have a possibility to directly clean up overlapping lines (2D) resp. surfaces (3D) in the mesher (e.g. gmsh) or in Elmergrid.
Does someone know a (free) mesher which can do this?

Matthias

[raback]

Hi

Due to multiple questions on this problem I just added an example on nonconfirming meshes among the tests that uses the features originally intended for periodic problems. See tests/periodic_nonconforming just added in svn.

-Peter

[mzenker]

Hi Peter,

thank you for this example. This seems to be a good trick for dealing with nonconformal meshes at interfaces.

In the sif file there is a comment saying:

Code: Select all

This test "misuses" periodicity to make computations in a nonconforming mesh
Note that this can work in parallel only if all the nonconforming nodes are in the same partition. Nor should one be optimistic on using direct solvers once the mesh structure has been spoiled by the additional connections.

Do I understand correctly that
1) the mesh is forced to be conformal by the periodic BC applied to surfaces which are in fact adjacent
2) the warning concerning direct solvers applies only to parallel computing, so that there are no restrictions when iterative solvers are used, and/or when parallel computing is not used?

Is there a way to visualize the "spoiled" mesh structure?

Thank you,

Matthias