[VdG]

Hi all,

when running splitMeshRegions -cellzones in OF16x, boundaries of type "calculated" are not treated correctly. The values from the original solution are not mapped onto the split solution. I've attached an example based on the angledDuctImplicit tutorial. The original nut file (/10/nut) contains:

outlet
{
type calculated;
value nonuniform List<scalar>
400
(
0.000908662
0.000880609
....
)
;
}

In the split case, this becomes (in /11/outlet/nut):

outlet
{
type calculated;
value uniform 0;
}

A similar problem occurs for boundaries with nutWallFunction, kqRWallFunction etc.

[mattijs]

splitMeshRegions was zeroing out all 'calculated' fvPatch fields since it assumed they were all on inter-region patches. I've pushed a fix to 1.6.x which only zeroes out the inter-region patches it has added. Can you let me know if it does the right thing?

(you will still have 'calculated' instead of nutWallFunction etc. since splitMeshRegions does not know about these boundary conditions. You can add a libs entry to your system/controlDict to force loading the libraries containing these boundary conditions)

Thanks for the nice bug report.

[VdG]

Hi Mattijs,

it works perfectly. Thanks!

[VdG]

Another question: Why would you zero out the values on the inter-region patches? In my case, I need the values on these patches. Is it possible to write the values as a fixedValue, nonuniform BC?

[mattijs]

The faces on these patches originate from internal faces. Hence there are no volFields on them (only possibly surfaceFields). You would have to do interpolation to get values on them. Usually these patches are to be used for coupling to they will have calculated values on them or some simple bc.

In your case maybe you can use mapFields to map a value onto them.

[VdG]

In my case, mapFields doesn't work, since I have insufficient memory. However, for now I can solve the problem by changing calculated to zeroGradient.