[Arnoldinho]

Hi all,

I have a 'little' problem with (what I guess) numerical errors in my simulations. In order to save computational time I'm right now trying to set up a nested domain, i.e. a small "cut-out" part of a global, large domain is modeled as an own domain using pre-calculated boundary conditions from the large one.

In the first step, the flow (e.g. water waves, plus structure) is solved in the large domain. At the boundary locations of the small domain, values of U, pd, k, omega and nut are stored using sample tool (plane). These values are then used as boundary values for the small domain (four side walls plus top), by a direct mapping of face values within a modified interFoam solver every time step. The points/cells in the small domain are exactly the same as in the area within the large one, so no spatial interpolation is undertaken.

Coming to the problem:
The boundary mapping and time-interpolation itself works fine, the calculation within the small domain does not. Looking at attached pictures one can see the boundary values for Umag (left) and the internalMesh for Umag (middle) at the same time step, as well as for Ux (right, different time). Obviously, something goes really wrong here. There is a strange "cross pattern": Values have opposite signs and very large values in neighboring cells e.g. in the outlet cell corners. So I guess either my settings are not correct, or the way boundary values are modified is not correct. The latter is done within the modified interFoam solver in the time loop right before the UEqn (and afterwards pEqn) is solved.
Furthermore, residuals for k and omega never fall below 0.01. Dicts for fvscheme and fvsolution are attached.

Any hints on whats wrong are highly appreciated!

Arne

[Arnoldinho]

Hi again,

cane someone at least say if the above described procedure, i.e. having a domain and giving fixed (but time-varying) boundary values for all four sides plus the top patch of the domain is generally possible, or if I walked right into one of the numerous numerical/mathematical traps?
I further investigated this and got similar, faulty results even for simple test cases with uniform velocity inflow.

Thanks,
Arne

[ngj]

Hi Arne

I have two possible explanations, which depends slightly on the details, and you will be able to check the correctness using a laminar solution:

1. If you are using U from the large to the small domain: In that case you are using a velocity field, which does not conserve mass! On collocated grids as in OpenFoam, mass conservation is enforced through the face fluxes, so if you prescribe a boundary value all the way around for U, then mass conservation fails.

2. If you are using face fluxes between the two grids: In that case you might have forgotten to take the direction of the normal vectors into account, i.e. you are not conserving mass.

Furthermore, if you are also pre-scribing values for the pressure on the boundaries, then you have an extremely stiff system, hence I would suggest pressure dirichlet when the flux is outward and neumann when inward. Virsa virsa for the velocities.

Hope it helps

/ Niels

[Arnoldinho]

Hi Niels,

thanks for your suggestions. In facts its number 1 right now. I also had the mass conservation problem in mind and therefore tried zeroGradient at the outlet, which gave slightly better results. The main problem seems to be the boundary condition at the top, which is somewhere "in the middle" of the large domain, more specific in the water region only.
So I think I will shift my top boundary up again and think of making the system less stiff.

Thanks,
Arne