Cannot get two adjacent surface meshes to conform

Hi all – I am using two .stl files from Blender that slice through a 3D objects that include a dam embedded in the surround rock and a water layer.

I then import the .stl files into cubit and attempt to mesh them – and though I can get them to mesh, I cannot get them to conform and the vertices of the adjacent meshes do not line up in many places along the water boundary.

a) importing:

b) imported surfaces before meshing:

c) I then apply “approximate size” 2.5 on both surfaces, set the meshing scheme to “pave”, and then mesh:

Unforunately, the meshes are not conforming along many parts of the boundary – for example:

What can I do about this? I’ve tried playing with imprinting and merging, but that doesn’t seem to help.

Here’s also a copy and paste from the command line:

Hello @TiberiusT,
have you already tried to use the tolerant imprint and setting a greater merge tolerance?

Imprint Tolerant {Body|Volume} <range> [tolerance <value>]
Merge Tolerance <val>

Hello @Norbert_Hofbauer,

I haven’t tried them, but when I do – I get an error saying that the option is not supported for mesh-based geometry:

image

I have attached the stl files, should that help. It contains three files - 1) water, 2) dam and embedding rock, and 3) water and dam/rock combined. rockdamwater.zip (28.6 KB)

As an alternative – would there be a way to slice 3D exodus files instead? In 3D, I am able to sculpt the 3D stl files of the water and dam and create conforming hexahedral meshes. Could cubit then slice these 3D conforming meshes in a way that creates conforming 2D quad meshes? I had expected that just slicing the original model in Blender, importing the 2D slices into cubit, and then trying to create a 2D quad mesh would have been easier – but perhaps it would be easier to use the exodus file?

I played around with my advice to just slice the 3D exodus file created by Cubit in Paraview (instead of slicing the stl in Blender), and then exported the result as another exodus file and imported that to Cubit. After some playing around with booleans and such, I was able to get what seems to be a conforming mesh:

However, when I now proceed to export this as an exodus file, the export works, but it just produces nonsense because it says that it is actually 3D even though it should just be 2D:

And so naturally, if I try to re-import it, it just fails:

Any suggestions on how to fix this? Is it saying it is 3D because the slice is not confined solely to the XY, YZ, XZ planes? However, it does look as though it lies fully within the YZ plane. It also labels them as sheet bodies, so should be 2D, right? I need it to be 2D, as I want to try some modelling in 2D instead of 3D for quicker prototyping.

Since it is just for prototyping, I do not need things to be perfectly accurate - so any simple reprojection or smoothing to fix would be fine provided that everything is qualitatively preserved.

Here’s a save file of the cubit session with the two surface meshes - seemingly conforming now, but apparently 3D even though should be 2D:

Forgot to add the file:

05-first-successful-2D-meshing-dam-water-part3.cub5.zip (1.5 MB)

Well, I may have figured out a workaround. After saving the 2D slice as an 3D exodus file in paraview (having first created from Cubit’s sculpt using 3D Blender stl files), I then tried to import the exodus file into my wave solver program and it threw an error saying that it does not accept higher-order quad meshes:

Using the power of Google for “first order quad cubit”, I found this link:

And it was great that the wave solver program gave me that error message when I tried to import that 2D meshed saved as a 3D exodus, because that lead me to a section of the Cubit documentation specifying:

image

Giving that a go and explicitly saying I want 2D elements (i.e., block 89 element type quad, etc.) solved the issues and I could export the conforming meshes as a 2D exodus and import it into my other program without it complaining about the quads not being first-order.

So maybe this is now solved… I need to run a simulation and verify I do not get any un-necessary free surface reflections at the rock-water interface. So let us see.

Would be great though if someone could chime in on whether it is still possible to do with Blender and stl files… or whether I first need to export 3D stl’s from blender, create a 3D exodus using Cubit’s sculpt, slice the 3D exodus file in paraview, export the slice as an exodus (and not stl), etc.