[DaveR]

Hi all, wondering if you can help me with a problem that has been plaguing my simulations for weeks now!!

I have no problem setting up and running my simulations in parallel, however trying to mesh in parallel persistently throws the following error message:

--> FOAM FATAL ERROR:
face 2 area does not match neighbour by ___ % -- possible face ordering problem
[...]
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file. Rerun with processor debug flag set for more information.

This is persistent every single time on every simulation I try to run. I always end up resorting to running sHM in serial however this is significantly inhibiting my work flow when i'm trying to optimise meshes.

I have tried decomposing snappy using hierarchical and the method of switching between scotch/ptscotch, neither seem to work.

I've noticed it suggests to increase the match tolerance if i'm sure the mesh is correct - however as I'm relatively new to OpenFOAM i don't really know how to tell if it is correct, nor how to adjust the matchTolerance. However I do know the mesh runs absolutely fine in serial.

In my current case I'm not trying to run anything particularly fancy - just a 2D turbine validation using a dynamic mesh (sHM in 3D, 1 cell span in Z-direction from the blockMesh followed by extrudeMesh). I haven't edited the source code or anything complex like I've found to be the problem for others on the forum.


Can anyone help me? I'm relatively new to OpenFOAM and this is considerably complicating my learning!

Best Regards,

Dave

[Antimony]

Hi,

It looks like you have cyclic patches in your case. A simple solution (though I am not sure if it would cause any problems) would be to change the patch type to patch before running snappyHexMesh.

You can later change it back to cyclic, either by using changeDictionary or by createPatch.

Cheers,
Antimony

[DaveR]

Hi Antimony, thanks for your response!

I didn't know I could do that for dynamic meshing - I'll give that a try and see if I have any luck!

However, I seem to get this problem with sHM regardless of the type of case i'm setting up (i.e. static, dynamic etc.) so think perhaps the problem is more fundamental to my understanding of how to use/process snappyHexMesh?

Cheers,

Dave

[Antimony]

Hi,

Typically the face matching error, as far as I have seen, usually are with the cyclic patch, which can be circumvented by the way I mentioned.

Cheers,
Antimony

[DaveR]

Hi Antimony,

took the cyclic cell zone out of the sHM dictionary and worked a treat, however has run me into another problem

Within the cyclic boundary I had named "movingCylinder" I had .stl geometry of three turbine blades. Now that sHM sees this as a patch, the .stl geometry doesn't generate.

Is there a way around this?

Many thanks again for your help

Dave

[Antimony]

Hi,

Hard to suggest without seeing your geometry and knowing perhaps pictorially what you want to do....

Cheers,
Antimony

[DaveR]

Hi Antimony,

I managed to solve the problem this morning with your help. I think I had made too many iterative adjustments trying to fix the problem such that I had introduced new ones.

Taking a couple of steps back and working carefully through my dictionaries I am now able to successfully run multiple parallel runs.

Thanks again for your help!!

Cheers,

Dave

[DaveR]

Hi Antimony/All,

Unfortunately it would seem I am still having issues with this case. I thought I had been able to sort it when I made modifications to another case that seemingly worked, however this one is still a no go.


Perhaps I can attach you my case to see if there is anything glaringly obvious that may be missing?

It is attached at the following link.
https://drive.google.com/open?id=0B3...mloVU5MYVZNejg

I have also attached an Allrun.pre (mesh) and Allrun (solution) script to demonstrate my generalized approach to the problem.


Any help you are able to offer is greatly appreciated!

Best regards,

Dave

[DaveR]

Sorry to bump this but I still can't figure this out!

I took all of the cyclic boundaries etc. out of the equation - essentially i'm now trying to mesh the flow across a stationary turbine.

However, I still get the face ordering issue! Therefore would I be right in saying this isn't a cyclic AMI issue? Research would suggest this to be an issue with the boundaries between the decomposed processors. As per the error code

--> FOAM FATAL ERROR:
face 0 does ot match neighbour by 0.0131312% -- possible face ordering problem.
patchrocBoundary17to19 my area:2.06695e-06 neighbour area:2.06668e-06 matching tolerance:1.73554e-10
Mesh face:33114 vertices:4(0.0768854 -0.0437495 -0.005) (0.0760748 -0.0439212 -0.005) (0.0760776 -0.0439184 -0.0025) (0.0768851 -0.0437497 -0.0025))
If you care certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file. Rerun with processor debug flag set for more information.

In an attempt to resolve this, between the decompose and sHM commands I adjusted the match tolerance through:

sed 's/0.0001/0.05/g' processor*/constant/polymesh/boundary -i

However this hasn't made the simulation any better.

Is anyone able to explain the error to me, or shed any light on resolving the issue?

I've re-attached my most recent case for any considerations

https://drive.google.com/drive/folde...jg?usp=sharing


Many thanks for your help and best regards,

Dave