[volker1]

Hi everybody,

I am going to solve a transient fluid problem where a compressible flow will pass two porous regions in series, connected by a narrow channel. I already found out that multiple regions are no standard capability of OF solvers and adding this capability will probably be much work. On the other hand the fvOptions feature available for chtMultiRegionFoam allows to add porosity using explicitPorositySource to add Darcy-Forchheimer coefficients. I tried it out extracting an fvOptions file from a tutorial and I got a flow field as well as an impact of porosity that look already reasonable. Later also heat transfer to the wall is to be implemented. So I think chtMultiRegionFoam seems a good basis for my problem (am I right here?).

For some time now I am stuck with the problem how to specify two (slightly) different porosity regions. If I just divide my flow region into two neighbouring regions, the two flow regions will be solved separately and I get a completely different flow field (as neighbouring flow regions are obviously not connected automatically).

So my question is can I
(1) specify sub-regions for the fluid region or
(2) merge two fluid regions before the calculation without merging all properties data, too, or
(3) solve this by connecting the neighbouring fluid regions by something like “calculated boundary conditions” (I did not manage to realise the nearby idea successfully to set the fluid1_to_fluid2 boundary fields to “type calculated” so far) or
(4) ... other ideas ...?

A hint to a promising proceeding would be fine.

Regards, Volker

[volker1]

Hi everybody,
in case someone should have the same problem or just is curious how this proceeded. This is what I found so far (for version 2.3.1).

0. Each region is always calculated as a unit, one after another, clear from a look at the solver loops. This is a formal reason (that certainly makes sense), but e.g. there is no need for a region to be a geometrical unit (cyclic boundary conditions seem a simple way to connect distant mesh parts to a single region but this does of course not necessarily make sense ...).
For my case this means I should use a single fluid region, so I try to introduce something like “sub-regions”. The below proceeding will merge several cellZones “subset1_of_region_name”, “subset2_of_region_name”, … into a single cellZone (and region in this case) named “region_name”.


1. with the command “topoSet” one has to specify a cellSet with “region_name”. The ~case/system/topoSetDict file could look like that:

actions
 (
   {   
         name    region_name;
         type    cellZoneSet;
         action  new;
         source  zoneToCell;
         sourceInfo
           {
             name  subset1_of_region_name;  // name of one cellSet (seems no matter which one) that is part of the generated region
           }
   }
 )

2. now the command “splitMeshRegions -cellZonesFileOnly cellZones_korr” provides the opportunity to generate a region containing different cellZones.
This file I named “cellZones_korr” bases on the original ~case/constant/polyMesh/cellZones file. This original file is e.g. available after running blockMesh if the cell zones are specified as block names in the ~case/constant/polyMesh/blockMeshDict file. The original file is still required and therefore must not just be simply overwritten. Instead, in the “cellZones_korr” file, one collects all the cell labels from the subset zones that should represent one region under the name of the region “region_name”. The original “subsetX_of_region_name” cellZone names have to be removed in this file, otherwise they will appear as regions again.


As a result, at the region level there seems no difference to the case where all subzones had been defined as a single region from the beginning on. The specification, calculation and output in the subzones are still done in the “region_name” subdirectories.
What is new, however, the subzones are now available and separately accessible in paraView if "include zones” is set. This also implies that the cell labes of the subzones are accessible in the original ~case/constant/polyMesh/cellZones file. This certainly is helpful with regard to modifications of properties on the subzones level, e.g. by introducing fields for lookup.

Regards, Volker

[derekm]

Can you post a test case with all the scripts for building it? That way I can be clear what it is you have done

thanks

derek

[volker1]

Hi derek,

I simplified and stripped my case to the mesh and region creation for clarity.

The Readme file proposes two sequences of commands so one can see what happens with and without the manipuilation.

This example even seems to work without the topoSet command, but chtMultiRegionFoam did not operate properly without it.



Edit:
As the final step to solve my problem of two subzones with slightly different porosity inside the same region I had to place an fvOptions file in the $case/system/region_name directory with the content:

porosity1
{
    type            explicitPorositySource;
    active          true;
    selectionMode   cellZone;
    cellZone        subset1_of_region_name;  

    explicitPorositySourceCoeffs
    {
        type            DarcyForchheimer;

        DarcyForchheimerCoeffs
        {
            d   d [0 -2 0 0 0 0 0] (7e2 7e2 7e2);
            f   f [0 -1 0 0 0 0 0] (0 0 0);

// this seems required for OF231:

            coordinateSystem
            {
                type    cartesian;
                origin  (0 0 0);
                coordinateRotation
                {
                    type    axesRotation;
                    e1      (0 1 0);
                    e2      (0 0 1);
                }
            }
         }
    }
} 

porosity2
{
    type            explicitPorositySource;
    active          true;
    selectionMode   cellZone;
    cellZone        subset2_of_region_name;  

    explicitPorositySourceCoeffs
    {
        type            DarcyForchheimer;

        DarcyForchheimerCoeffs
        {
            d   d [0 -2 0 0 0 0 0] (5e2 5e2 5e2);
            f   f [0 -1 0 0 0 0 0] (0 0 0);

// this seems required for OF231:

            coordinateSystem
            {
                type    cartesian;
                origin  (0 0 0);
                coordinateRotation
                {
                    type    axesRotation;
                    e1      (0 1 0);
                    e2      (0 0 1);
                }
            }
         }
    }
}

That's it!

Hope it is useful.

Regards, Volker