You will need to add this line into all your files in 0 directory:

#includeEtc "caseDicts/setConstraintTypes"

Thanks I will give it a shot

Now I run into issues since the processor BCs are missing which makes sense and I guess the include is supposed to fix that

is that the right way?

no, the include has to be inside the ``boundaryField`` dict

for instance in the motorbike tutorial: https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/incompressible/simpleFoam/motorBike/0.orig/U

And yes you're right: when using the ``-copyZero`` option ``decomposePar`` does not decompose the fields, so it preserves the BC for patches which will be created later by snappy, but it also does not create the processor BCs

Another way is to add an additional BC in your O dir files such as:

"procBoundary.*"
{
  type processor;
}

Perfect it worked 😄 Thank you a lot you saved me tons of time

Hey I have stumbled upon a weird snappyHexMesh behaviour. During the snapping step it shrinkes one of my "outer layers" of my background mesh

https://cdn.discordapp.com/attachments/796072568385568808/1369636120156962877/image.png?ex=681c9489&is=681b4309&hm=289f9f85f6f33fc5c556252c138e110fd02fd6334d25f7d0488e8a35f301ddc1& https://cdn.discordapp.com/attachments/796072568385568808/1369636120555688046/image.png?ex=681c9489&is=681b4309&hm=daece017173ab019880db899880eecc181ad25c754c2b40af5e8c8eb5e66e20d&

Im working on simulating a pipe with something in it so the object inside is snapped, which works quite well, however it uniformly offsets the outer layer in this weird way and I ahve no clue why. Feels like some kind of weird smoothing. Anybody having similar experiences/and idea how to fix this? Version is v2406

One workaround could be adding an stl that represents the pipe, however that feels like an unnecessary step

have you defined the patches during the background mesh creation? or not?

Snappy does not snap without a reason. You are most likely specifying a surface which does not exactly coincide with the cylinder walls of your background mesh.

sometimes when having the external boundaries using the background mesh, snappy can have some extrange behavior. it is not the same but also an example... https://discord.com/channels/397772779870486529/796072568385568808/1033004962541736026

and somewhere when i was doing that case, I had issues that when using default patches on the blockmesh snappy was moving it, but if changed to defined one during the blockmesh then snappy would not change it.... I was looking for the exact message but did not find it right now

So thanks for your tips 😄

the "outside" of the cylinder is a wall that I have specified during background mesh creation

so the only surface there is to snap is an object inside the cylynder with about 1/10 of the diameter located in its center so the outside shouldnt be attrackted to it

I have now added a new stl that coincides with the original outside, that stops the shrinking but results in a "change" in the thicknes of the outer layers, but I can live with that

test the contrary, i mean not definding it. from memory i had issues when it was not defined but i remember clearly that one or the other gave me a headhech so, worth testing.

okay I will try that tomorrow, but how did you then define it afterwards to apply a boundary condition to it?

createPatch

I always define all surfaces for all patches for Snappy. Maybe it does misbehave if not all surfaces are defined 🤔

I couldnt find anything in the docs and also by just trial and error. Is there any way to run mergeMeshes on decomposed parallel cases?

What kind of merging do you need to do? I don't have access to my cases right now but I'm pretty sure this is what I do to merge overset meshes (decomposed on the same number of processors)

I have a mesh section that I create with snappy which is followed by a pure blockMesh section (so I can have a non uniform mesh there). And basically i have to merge them before starting the simulation. They dont overlap, but their boundaries coincide at one location. In terms of running in parallel it feels like it should redistribute the cells after the merging

I'm not sure it redistributes the cells during the merging, but you might give a try to redistributePar afterward