Wall on overset mesh causes p-U coupling issues
I want to inject liquid into a 2D gap.
I want to add a wall on an overset mesh, which is supposed to act as a blockage.
Due to the contraction of the thickness of the gap I would assume, that the velocity in the area of the overset mesh with the wall will be increased (due to continuity). However, this is not the case.
I found this issue: #2341
and assumed that this could be some overInterDyMFoam problem with mass conservation. I tested the same flow with overPimpleDyMFoam and the same happens.
Steps to reproduce
I uploaded four case files in a zip file. All four can be run with the one master Allrun script in v2112 (also v2012) in 1-2 minutes on on core.
What is the current bug behaviour?
Here you can see the velocity profile:
First gap is the simulation without the overset mesh (no contraction of thickness) and overPimpleDyMFoam. Second gap is the simulation with the overset mesh (small contraction of thickness) and overPimpleDyMFoam. Third gap is the simulation without the overset mesh (no contraction of thickness) and overInterDyMFoam. Fourth gap is the simulation with the overset mesh (small contraction of thickness) and overInterDyMFoam.
Without an overset mesh, the results look good and reasonable. The moment I merge an overset mesh to the background mesh, the velocity "dissipates" in the area of the overset mesh.
The pressure behaves also incorrectly
without the overset mesh the pressure drop is reasonable. With the overset mesh the pressure drop disappears in the area of the overset mesh.
What is the expected correct behavior?
Increase of velocity in region of contraction.
Relevant logs and/or images
- OpenFOAM version : v2112 (also v2012)
- Operating system : Ubuntu 18.04
- Hardware info : Intel CPU 6 cores (should not matter here)
- Compiler : GCC coming with OpenFOAM
I am not sure. What i noticed is that I have to change the preconditioner between DILU and DIC depending whether I want to run the simulation with or without the overset mesh. In all cases the matrix solver is PBiCGStab though. Maybe this helps? I did try to fix this in the source code, but I am stuck. What I found is that the major impact is coming from pEqn.
In overPimpleDyMFoam the line:
U = cellMask*(HbyA - rAU*gradP);
In overInterDyMFoam the line:
U = cellMask* ( HbyA + rAU*fvc::reconstruct((phig - p_rghEqn.flux())/rAUf) );
The multiplication with cellMask seems to introduce the errors. This might possibly be the source where the error comes out, possibly the cause is in some of the previous steps, where HbyA, rAU or phig are defined. This is where I am stuck.
Is this phenomenon
- my stupidity and ignorance (in this case I am sorry to waste you valuable time)
- a bug
- a feature
- something else
I am happy to support you with any help possibly, I know that you have a lot to do. Tell me, what I can test and I will execute the simulations and test.
Best regards, Jozsef