Incorrect behaviour of overset and cellVolumeWeight

Summary

I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.

1. First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.

2. "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor" I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.

3. Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.

Steps to reproduce

Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.

Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.

Example case

A very crude test case of a check valve closing during reverse flow is attached.

testcase.tgz

What is the current bug behaviour?

I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.

What is the expected correct behavior?

There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.

Relevant logs and/or images

Please see attached case.

Environment information

OpenFOAM version : plus/v1812 Operating system : ubuntu, redhat 6.4 Compiler : gcc

This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.

Possible fixes

blamed file: src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C

In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.

This is a version where all three patches have been applied. cellVolumeWeightCellCellStencil.C

I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.

Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.

## Reattaching the author to the issue ticket: @nicolasedh ##