[boffin5]

Hi,


As the title implies, I'm an openfoam rookie setting up my first multiregion case. Given that, I have run into questions that I'm sure are trivial for the experienced OF users.


My case is a simulation of a car radiator in a simple fairing, with the radiator modelled as a porous zone. This far, I have a mesh with 2 regions, fluid and solid, so everything is ready to go. My plan is to run it in 2 steps: Step 1 is to simply run it as a simple porous media case. Step 2 is to add heat to the radiator, turning it into a heat transfer case. btw, I noticed that in the constant folder, there are now fluid and solid folders. I assume that the BCs go into the fluid folder. Correct?


So I'm in the process of trying/failing/editing/trying again. Firstly, I have been using simpleFoam as the solver. But immediately, there are failure messages implying that T needs to be present in the BC files. This implies that chtMultiRegionFoam should be the solver.


But wait, if that is true, then I'm already into Step 2. Questions: Is simpleFoam not applicable to multiregion cases? Should I just abandon Step 1, and and treat it like a heat transfer case with an ambient temperature radiator, and then increase T for Step 2? I'm just hoping for information that will keep me clear of blind alleys, and point me in the right direction.


Thanks, boffin5

[Yann]

Hi Alan,

You cannot solve a multiregion case with simpleFOAM. AFAIK, the only solver able to deal with multiregion cases is chtMultiRegionFoam. So you cannot complete step 1.

Step 1 with simpleFoam is basically what you have done before: a classic simpleFoam case with a porous zone do model the radiatior.

About multiregion cases, you have a folder for each region in 0, constant and system directories. Each region needs its own setup in all of these directories.

Have a look at the heatExchanger tutorial, it seems to be similar to what you are trying to achieve.

Have fun,
Yann

[boffin5]

Hello,
Well, I got some ways in sorting out my *first* chtMultiRegion case, but finally ran into the proverbial brick wall. This is a simple case involving a car radiator with a simple fairing. It has 2 regions, one for fluid (the air), and one for solid (a porous zone representing the radiator).


The run feedback that I couldn't understand is as follows:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create fluid mesh for region fluid for time = 0

Create solid mesh for region solid for time = 0

*** Reading fluid mesh thermophysical properties for region fluid

    Adding to thermoFluid

Selecting thermodynamics package 
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          hPolynomial;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}

    Adding to rhoFluid

    Adding to UFluid

    Adding to phiFluid

    Adding to gFluid

    Adding to hRefFluid

    Adding to pRefFluid

    Adding to ghFluid

    Adding to ghfFluid

    Adding to turbulenceFluid

Selecting turbulence model type laminar
Selecting laminar stress model Stokes
    Adding to thermophysicalTransport

Selecting thermophysical transport type laminar
Selecting default laminar thermophysical transport model Fourier
    Adding to reactionFluid

Combustion model not active: combustionProperties not found
Selecting combustion model none
    Adding to radiationFluid

Selecting radiationModel none
    Adding to KFluid

    Adding to dpdtFluid

    Adding to fieldsFluid

    Adding MRF

No MRF models present

    Adding fvOptions

Creating finite volume options from "constant/fvOptions"

Selecting finite volume options model type constantHeatTransfer
    Source: airToporous
Selecting finite volume options model type interRegionExplicitPorositySource
    Source: porosityBlockage
- selecting inter region mapping
Creating mesh-to-mesh addressing for fluid and solid regions using cellVolumeWeight
    Overlap volume: 1.05692e-09
*** Reading solid mesh thermophysical properties for region solid

    Adding to thermos

Selecting thermodynamics package 
{
    type            heSolidThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          ePolynomial;
    equationOfState rhoConst;
    specie          specie;
    energy          sensibleInternalEnergy;
}

    Adding to radiations

Radiation model not active: radiationProperties not found
Selecting radiationModel none
    Adding fvOptions

Creating finite volume options from "constant/fvOptions"

Selecting finite volume options model type constantHeatTransfer
    Source: solid_to_fluid
- selecting inter region mapping
Creating mesh-to-mesh addressing for solid and fluid regions using cellVolumeWeight
    Overlap volume: 2.32512e-08

PIMPLE: Region fluid
PIMPLE: No convergence criteria found


PIMPLE: Region solid
PIMPLE: No convergence criteria found


PIMPLE: Operating solver in steady-state mode with 1 outer corrector
PIMPLE: Operating solver in SIMPLE mode


Region: fluid Courant Number mean: 79.7349 max: 6625.92
Region: solid Diffusion Number mean: 0.00710092 max: 0.844007
--> FOAM Warning : 
    From function bool Foam::functionObjectList::read()
    in file db/functionObjects/functionObjectList/functionObjectList.C at line 871
    Caught FatalError 
--> FOAM FATAL ERROR: 

    request for objectRegistry region0 from objectRegistry radiator-case4 failed
    available objects of type objectRegistry are

2
(
fluid
solid
)


    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-8/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211.

--> FOAM Warning : 
    From function void Foam::timeControl::read(const Foam::dictionary&)
    in file db/functionObjects/timeControl/timeControl.C at line 89
    Reading "/home/boffin5/cfdaero/radiator-case4/system/controlDict/functions/forceCoeffs1" from line 55 to line 64
    Using deprecated 'outputControl'
    Please use 'writeControl' with 'writeInterval'
--> FOAM Warning : 
    From function bool Foam::functionObjectList::read()
    in file db/functionObjects/functionObjectList/functionObjectList.C at line 871
    Caught FatalError 
--> FOAM FATAL ERROR: 

    request for objectRegistry region0 from objectRegistry radiator-case4 failed
    available objects of type objectRegistry are

2
(
fluid
solid
)


    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-8/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211.

--> FOAM Warning : 
    From function bool Foam::functionObjectList::read()
    in file db/functionObjects/functionObjectList/functionObjectList.C at line 871
    Caught FatalError 
--> FOAM FATAL ERROR: 

    request for objectRegistry region0 from objectRegistry radiator-case4 failed
    available objects of type objectRegistry are

2
(
fluid
solid
)


    From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::objectRegistry]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-8/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211.

Region: fluid Courant Number mean: 79.7349 max: 6625.92
Region: solid Diffusion Number mean: 0.00710092 max: 0.844007
Time = 1


Solving for fluid region fluid
Porosity region porosityBlockage:
    selecting model: DarcyForchheimer
    creating porous zone: porosityBlockage:porous
DILUPBiCGStab:  Solving for Ux, Initial residual = 1, Final residual = 0.0298795, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 1, Final residual = 0.00604549, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 1, Final residual = 0.00734271, No Iterations 1

After FATAL ERROR it says "region0", but I can't relate that to anything in the case setup files, so I don't know where to go from here.


If I'm fortunate enough to get help resolving this, I have another general question: My porous zone represents the radiator, but in the thermophysicalproperties for that region I used properties for water, since that's mostly what it's made of. So it's a solid porouse zone made of water. Sounds weird, but analytically it should work? Actually, after fine tuning, I would try to come up with an amalgam of water, aluminum and glycol by averaging the properties. Is that a reasonable approach?


I have attached a zip file that contains my case setup, and a powerpoint file showing the case structure, along with an image file showing the appearance of my contraption. Please let me know if I have bungled the creation of the zip file.


Much appreciation if any help comes my way!

[Bloerb]

The error message is from your function objects. You need to add a line like region fluid; to each function object you use. It is looking for region0 but your case has no default region. You do not have a constant/polyMesh you are solving for. Only constant/fluid/polyMesh and constant/solid/polyMesh. Function objects by default use the default region. Hence the need for specifying which region the function object should be applied on.


And yes choosing water as the value is correct. You basically have two fluid flow simulations, whose flow will not impact each other. You are only transferring heat by the constantHeatTransfer function object. To add the influence of the solid you are adding porosity. And both of these are done on a per region basis. Another approach would be fully resolving everything and to use 3 regions. air, water and the solid.

[boffin5]

Thanks Bloerb,


However, I'm not sure how to apply your suggestions to my specific case. That said, I did find what I think are mistakes in my fvOptions files. After running splitMeshRegions, included in the output are these lines:


7 fluid_to_solid
8 solid_to_fluid


So I used that verbage to replace lines in my fvOptions files. Previously I had airToporous, which was an artifact from a heat exchanger tutorial:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

//#include "fvMesh.H"

//airToporous
fluid_to_solid
{
type constantHeatTransfer;

interpolationMethod cellVolumeWeight;
nbrRegionName porous;
master false;

nbrModel porousToair;
fields (h);
semiImplicit no;
}

porosityBlockage
{
type interRegionExplicitPorositySource;

interRegionExplicitPorositySourceCoeffs
{
interpolationMethod cellVolumeWeight;
//nbrRegionName porous;
nbrRegionName solid;

type DarcyForchheimer;

d (-1000 -1000 1e4);
f (0 0 0);

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


I made those changes to the fvOptions files in the constant/fluid and the constant/solid folders.


Alas, it didn't help! When I try to run the case, I still get the 'can't find region0' message in the output.


Is it possible for you to provide an example of how to specify the region in my case files?

[Bloerb]

It stems from the function objects not your fvOptions file. Those are the parts included in the controlDict under functions. You need to add a region line to each of those.

    forceCoeffs1
    {
        type        forceCoeffs;
        region     fluid; (or name of your region)
        functionObjectLibs ( "libforces.so" );
        outputControl   outputTime;
        writeFields true;

        patches     (body);
        pName       p;
        UName       U;
        rhoName     rhoInf;      // Indicates incompressible
        log         true;
        rho         rhoInf;
        rhoInf      1;           // Redundant for incompressible
        liftDir     (0 0 1);
        dragDir     (1 0 0);
        CofR        (3.5 0 0);   // Axle midpoint on ground
        pitchAxis   (0 0 1);
        magUInf     10;
        lRef        4;           // Wheelbase length
        Aref        1;           // Estimated
        porosity    on;

        binData
        {
            nBin        20;          // output data into 20 bins
            direction   (1 0 0);     // bin direction
            cumulative  yes;
        }
    }

and the same for the other ones you include. Which you have put in different files like fieldAverage inside your system folder. It tries to execute the force function object but does not know which region to use. Since there is no default region, but only subregions. Hence you need to add two function objects if you want to have them in both regions.


Running splitMeshRegions on your file won't work. You need to have those overlap. Typically you are using two regions connected by one boundary. And hence this wall is coupled between the two regions using a coupling boundary condition. splitMeshRegions creates this coupling type automatically (mappedWall and names the boundary automatically as well fluid_to_solid). You however chose a coupling which is not done by the wall boundary condition. Rather you are trying to couple them via coupling a certain cellZone (inside part of your mesh). Hence you need two meshes, which overlap in the coupling region, since you want to couple them.
The part of your radiator is not fully modelled, you are only adding porosity there. Hence you need a mesh in that region for BOTH parts.



You need to think of this as two seperate fluid simulations. You have the air flow (through your radiator) as one region. To make sure the flow through it is correct you are using a porosity (since you can't fully resolve all the walls in there). And in the second region (your coolant) , you need to do the same, add a porosity to model the pressure loss in the pipes you can't resolve. You afterwards couple both regions by this fvOption:

nameOfTheModel
{
    type            constantHeatTransfer;

    interpolationMethod cellVolumeWeight;
    nbrRegionName       fluid;
    master                    true;

    nbrModel        nameOfTheModelInTheOtherRegion;
    fields          (h);
    semiImplicit    no;
}

This exchanges the heat by looking at the other region (nbrRegionName) for another fvOption and adds heat in the cells at the same place in space.


The best way to test your simulation is to run it without any coupling. I.e remove or rename the fvOption files. If you simulation runs, and you are not getting any errors, you should atleast get the flow solution in both cases. Afterwards add porosity and heat transfer one by one.

[boffin5]

Hi Bloerb,


First, I would like to thank you for taking the time to look at my case and providing detailed response. However, as an OF rookie, I'm not sure how to act on your replies, relative to my case. Regarding the mesh and regions, I have attached 2 images that outline the status of the mesh after the execution of snappyhexmesh, splitmeshregions and toposet. It may or may not be that it is acceptable according to your description. Also attached is a zip fle of my case folders.


Regarding your recommendation about the controlDict functions, I tried including a region name for each of the functions as follows:

forceCoeffs1
    {
        type        forceCoeffs;

        functionObjectLibs ( "libforces.so" );
        region          fluid;
        outputControl   outputTime;
        writeFields true;

        //patches     (body);
        patches     (bod);

I assumed that the region 'fluid' was appropriate since it seems likely that calculated forces are based on the fluid flowfield. But I also tried to include both regions as 'region fluid|solid' but that just gave a syntax error. In any event, after the changes, I still got the 'request for objectRegistry region0 from objectRegistry failed' message.


Then I decided to save that problem for a later day, and commented out the entire function section, and there was no failure message - not for that problem, anyway.


Following your advice to bypass the fvOptions files by renaming them, resulted in a longer system attempt to run, but it terminated with this message:

 Energy -> temperature conversion failed to converge:
          iter          Test           e/h          Cv/p          Tnew
             0       284.847       67640.6       1010.56      -451.391
             1      -451.391       -631761       422.474      -556.982
             2      -556.982       -663131        132.37      -656.996
             3      -656.996       -659721      -233.575      -585.715
.
.
.

 FOAM FATAL ERROR Maximum number of iterations exceeded; 100om objectRegistry radiator-case failed.  Available objects of type objectRegistry are {
fluid
solid }

Please bear with me on my ignorance, but as a beginner I am totally unsure of how to proceed. If you have any more insights to provide, I would sincerely appreciate it.


Alan w

[boffin5]

Finally, I think I have the case files set up properly for my car radiator multiRegion case, but the solution doesn't converge. There are 2 regions, fluid and solid. The radiator is represented by the porous solid region. When I run splitMeshRegions, it shows the regions, and the interface patches, which are fluid_to_solid, and solid_to_fluid. When I run topoSet, it creates a cellZone called porousZone, which represents the radiator. Also in the BCs is something called bod, which is a simple fairing that I added around the radiator for realism. There are images in the setup in my previous posts, which show the domains and the interface patches.


My first question is to ask if I have correctly created the boundary conditions. Sometimes the porousZone applies, and sometimes the interface patches. For example, here is the BC for fluid T here in which the interface zone applies; it is similar to several of the other BCs:

internalField   uniform 294;

boundaryField
{
    "rightSide|leftSide|upperWall"
    {
        type            zeroGradient;
    }
    
    ground
    {
        type            zeroGradient;
    }
    
    inlet
    {
        type            fixedValue;
        value           uniform 294;
    }
    
    outlet
    {
        type            inletOutlet;
        inletValue      uniform 294;
        value           uniform 294;
    }
    
    bod
    {
        type            zeroGradient;
    }
    
    /*porousZone
    {
        type            zeroGradient;
    }*/
    
    fluid_to_solid
    {
        //type            zeroGradient;
        type            compressible::turbulentTemperatureCoupledBaffleMixed;
        value           $internalField;
        //kappa           kappa;
        Tnbr            T;
    }

}

Here is the BC for fluid k, in which the porousZone applies:

internalField   uniform 0.375;

boundaryField
{
    "rightSide|leftSide|upperWall"
    {
        type            zeroGradient;
    }
    
    ground
    {
        type            kqRWallFunction;
        value           $internalField;
    }
    
    inlet
    {
        type            fixedValue;
        value           $internalField;
    }
    
    outlet
    {
        type            zeroGradient;
    }
    
    bod
    {
        type            kqRWallFunction;
        value           $internalField;
    }
   
   porousZone
    {
        type            kqRWallFunction;
        value           $internalField;
    }
    
}

When I run chtMultiRegionFoam, it takes a few minutes to set up files, but then fails to converge. Here is the last part of the error output:

Energy -> temperature conversion failed to converge:
          iter          Test           e/h          Cv/p          Tnew
             0       292.871       80398.6       1011.57      -472.806
             1      -472.806       -640447       370.726      -617.628
             2      -617.628       -665426      -77.8299      -248.753
             .    .    .    .    .    .    .    .    .    .    .    .    .    .    .    .

            99      -207.431       -467941        812.62      -485.784
           100      -485.784       -645222       337.695      -630.629
           101      -630.629       -664198      -127.509       -395.84


--> FOAM FATAL ERROR: 
Maximum number of iterations exceeded: 100

I'm not sure why the max number of iterations was reached, or why the simulation aborted. There is also a problem with registries regarding region0 in the controlDict functions, but for now I have commented all of that out.


I am hoping for help in understanding why the case failed. The zip file for my case is attached. My run sequence is:

blockMesh
surfaceFeatures
snappyHexMesh -overwrite
splitMeshRegions -cellZones -overwrite
topoSet
chtMultiRegionFoam

Thank you Bloerb, Yann and others for your help thus far, and bear with me, I'll get there in the end!

[boffin5]

Here is the complete output error message from running chtMultiRegionFoam. I know it's important, but was having trouble uploading it.

[Bloerb]

A few remarks.
Your paraview screenshot show that you have these 3 regions.

1. internalMesh
2. fluid/internalMesh
3. solid/internalMesh

Hence paraview shows you the non split mesh as well. rename your constant/polyMesh folder to polyMesh.orig or delete it. This often is confusing in postProcessing. Although not an error for anything. For the functionObjects you can't name them seperated by a | like in fvSolution (sadly). You need to do this:

forcesFluidDomain
{
        type        forceCoeffs;
        region     fluid;
.....
}
forcesSolidDomain
{
        type        forceCoeffs;
        region     solid;
.....
}

Aside from that it looks good. Your solver just crashes due to bad settings.
This looks good

//your fluid region:

 fluidTosolid
{
    type            constantHeatTransfer;

    interpolationMethod cellVolumeWeight;
    nbrRegionName   solid;
    master          false;
    nbrModel        solidTofluid;
    fields             (h);
    semiImplicit    no;
}

//your solid region:
solidTofluid
{
    type            constantHeatTransfer;
    interpolationMethod cellVolumeWeight;
    nbrRegionName       fluid;
    master          true;
    nbrModel        fluidTosolid;
    fields          (h);
    semiImplicit    no;
}

HOWEVER your error message states:
Source solidTofluid defined for field h but never used
Thats because your thermophysicalProperties is set to solve for sensibleInternalEnergy (e) not (h). Your fluid side uses sensibleEnthalpy hence that works. Simply switch h to e or change the solution method to sensibleEnthalpy for your solid.


I do HOWEVER suspect that your regionProperties is wrong:

regions
(
    fluid       (fluid)
    solid       (solid)
);

likely needs to be

regions
(
    fluid       (fluid solid)
    solid       ()
);

Because yo do not really have a solid region. But rather the air flowing through the radiator and the water flowing through it. Hence changing both to fluid regions seems logical. Hence maybe rename solid to water. The solid inbetween air and water you are not resolving. You are adding its's effect by the second fvOption as porosityBlockage. And because you are not resolving each single wall of the radiator you need to use the volume method ie those two fvOptions (solidTofluid and fluidTosolid listed above). Hence the need for a heat transfer coefficient. When coupling regions via boundary conditions this is not needed.
As the solver tells you:

Creating mesh-to-mesh addressing for solid and fluid regions using cellVolumeWeight
Overlap volume: 2.32512e-08

Hence you meshes for air and water need to overlap. Because in the overlapping regions you are transfering energy from one region to the next. Therefore I do not quite understand why you are also coupling those regions via a boundary condition:

    solid_to_fluid
    {
        //type            zeroGradient;
        type            compressible::turbulentTemperatureCoupledBaffleMixed;
        value           $internalField;
        //kappa           kappa;
        Tnbr            T;
    }

You need to create two meshes. One for the air flow including the radiator. And one with only the radiator. Hence no splitMeshRegions at all. Just run snappyHexMesh twice with different settings. Once for the air region. Once for the solid region, with different stl files if necessary. Or snappyHexMesh -region fluid with all settings inside system/fluid/snappyHexMesh etc.

[boffin5]

Bloerb,


Your response is really helpful, and I will get to work incorporating all of your suggestions. But you said, I need the heat transfer coefficient. This is logical, but where does it go? fvOptions covers the porosity definition, but I don't recall seeing the heat transfer coefficient in the tutorials.


Alan w

[boffin5]

Actually, would the heat transfer coefficient not be covered by the thermoPhysicalProperties?

[Yann]

Hi Alan,

the field "h" in your fvOptions stands for "enthalpy", while "e" stands for "internal energy", as Bloerb already mentioned:

Originally Posted by Bloerb

HOWEVER your error message states:

Source solidTofluid defined for field h but never used
Thats because your thermophysicalProperties is set to solve for sensibleInternalEnergy (e) not (h). Your fluid side uses sensibleEnthalpy hence that works. Simply switch h to e or change the solution method to sensibleEnthalpy for your solid.

You just have to update your solid thermoPhysicalProperties from "sensibleInternalEnergy" to "sensibleEnthalpy". You will probably have to adjust your fvSolution and FvSchemes to replace "e" with "h".

I think the energy form mix up is probably related to the fact you have been playing around with tutorials cases from the ESI-OpenCFD branch (uses sensibleEnthalpy in chtMultiRegion tutorials) while using the OpenFOAM foundation branch (which uses sensibleInternalEnergy).

I think Bloerb covered the case strategy pretty well. The heatExchanger tutorial seems to be doing exactly what you are trying to achieve: https://github.com/OpenFOAM/OpenFOAM.../heatExchanger

Cheers,
Yann

[boffin5]

There were 2 hurdles to jump in my car radiator multiregion case: 1. to create an overlapping mesh, and 2. solve the region0 problem in controlDict functions. This case has a radiator (the porous heated solid), a surrounding fairing to provide a basis for force and moment analysis, and the domain (here called fluid). I have attached an image showing the case.



It was a big relief to accomplish the creation an overset mesh, something that Bloerb said I needed to do. The result is a mesh for the radiator itself, located in constant/solid, and a mesh for the domain with the fairing carved out, located in constant/fluid. And, when running chtMultiRegionFoam, it churns for a long time (a good thing), and converges on a solution. The steps to effect this are shown in the attached run file.


It even creates a postProcessing folder based on my controlDict functions. However, I don't trust the data, because during the running of the case, I get this message:


--> FOAM FATAL ERROR:

request for objectRegistry region0 from objectRegistry radiator-case5 failed
available objects of type objectRegistry are

2
(
fluid
solid
)


The attached runlog file shows the complete output from running the case. I have tried all sorts of ways to define regions in the controlDict functions, but this problem is still plaguing me. Attached is my current controlDict file, with all its flaws.



Another problem remaining regards the need to see streamlines. In previous cases, I have a system/streamLines file, and in paraView I access a constant/sets folder to open VTK data which provides for creating streamlines in the view.


But, with this multiregion case, there is no 'sets' folder created. So how can I create streamlines? I know that there is a streamline function within paraView, but I find that the one in native OpenFOAM is much better. I just need to get it to work for this simulation.


Also attached is a zip file of my complete case files.


Once again, I am hoping for help in resolving these last 2 issues; if I can get a handle on them, my last great struggle in my self-study course in OpenFOAM will be complete!

[Yann]

Hi Alan,

Originally Posted by boffin5

It was a big relief to accomplish the creation an overset mesh, something that Bloerb said I needed to do.

I would not use this term here. Overset is a different technique involved in a specific set of solvers and it is not currently implemented in the OpenFOAM foundation branch. This is not what you are doing here, so better not mix up the names.

For you function object problem, the issue remains the same as before. You need to specify in which region you are applying the function, since each region has a different mesh and is solved separately in chtMultiRegionFoam.

    FieldsMinMaxFluid                // monitor
    {
        type  fieldMinMax;
        functionObjectLibs      ("libfieldFunctionObjects.so");
        enabled                 true;
        mode                    component;
        writeControl            timeStep;
        writeInterval           5;  // output every 5 time steps, change as needed
        log                     true;
        fields                  (p U k);  // list of any fields you want to monitor
        region                    fluid;
    }

    FieldsMinMaxSolid              // monitor
    {
        type  fieldMinMax;
        functionObjectLibs      ("libfieldFunctionObjects.so");
        enabled                 true;
        mode                    component;
        writeControl            timeStep;
        writeInterval           5;  // output every 5 time steps, change as needed
        log                     true;
        fields                  (p U k);  // list of any fields you want to monitor
        region                    solid;
    }

You need to do this on every function object you use, including streamLines, cuttingPlane and forceCoeffs which are defined in separate files and then included in your controlDict thanks to the #include function.


Cheers,
Yann

[boffin5]

Thanks again, Yann!

I'll try those changes to the controlDict functions straight away. I suppose that for most/all of the functions, the region would be fluid. Or I might try it this way:

region (fluid solid)
I thought I saw some reference to that method.
Any ideas regarding my question about streamlines? The native OpenFOAM streamline function worked for me in the simpleCar case, but it doesn't work so far, in the multiregion case, since the constant/sets folder that was created in the former case, doesn't appear in the latter. I think I will post that question as a new thread.
Alan w

[Yann]

Hi Alan,

You can define only one region for each function. region (fluid solid) will not work.

I'm not sure to understand your problem with streamlines. If you define a region in your streamline definition file (e.g. region fluid;) it works just fine. The vtk files are created in postProcessing/sets/streamLines/fluid/

Cheers,
Yann

[boffin5]

Thanks Yann,


Acting on your comments, I carpet bombed my systems files with 'region fluid', and the 'region0 in registry' problem is solved! I am getting very close, and have my corkscrew at the ready, but then I saw this verbage in the run output:


--> FOAM Warning :
From function virtual void Foam::functionObjects::forces::calcForcesMoment()
in file forces/forces.C at line 838
Porosity effects requested, but no porosity models found in the database


In order to have an overlapping (thanks for the clarification re 'overset'), I ran blockMesh, then SHM to create a mesh of the radiator. Then I ran blockMesh again, with a different SHM to carve out the radiator fairing, giving me two different meshes, and hence regions.


in paraView, the regions appear as the image 'regions' below. 'Fluid' and 'solid' are clearly shown. The porositiy is defined in constant/fluid/fvOptions:

fluidTosolid
{
    type            constantHeatTransfer;

    interpolationMethod cellVolumeWeight;
    nbrRegionName   solid;
    master          false;

    nbrModel        solidTofluid;
    fields          (h);
    semiImplicit    no;
}
porosityBlockage
{
    type            interRegionExplicitPorositySource;

    interRegionExplicitPorositySourceCoeffs
    {
        interpolationMethod cellVolumeWeight;
        nbrRegionName   solid;

        type            DarcyForchheimer;
        
        // D 100;  // Very little blockage
        // D 200;  // Some blockage but steady flow
        // D 500;  // Slight waviness in the far wake
        // D 1000; // Fully shedding behavio

        d   (120 1e9 1e9);
        f   (120 1e9 1e9);

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

And in constant/solid/fvOptions:

solidTofluid
{
    type            constantHeatTransfer;

    interpolationMethod cellVolumeWeight;
    nbrRegionName       fluid;
    master          true;

    nbrModel        fluidTosolid;
    fields          (h);
    semiImplicit    no;
}

What is the reason for the 'no porosity models found' message?


Actually, I thought I might try another way to create the two regions. First run blockMesh, and SHM to subract out the radiator fairing. This creates the fluid domain as in the 'domain' image below. Then, run topoSet to create the radiator porousZone. When I do this, it creates a cellZoneSet. But how do I convert this into a mesh which comprises the other region?


So close, and yet so far ..

[boffin5]

Regarding the 2nd question on how to create the other mesh using topoSet, I was able to do it. So now I have one mesh for the domain with the fairing carved out, and another with just the solid radiator. Will this run without giving the "no porosity models found in the database?" I am running it now, so will find out. If the problem is still there, I am hopeful for some comments as to how to fix it.

[boffin5]

My attempt to create overlapping meshes with topoSet failed. But, I returned to the version where I had a run message saying, "no porosity models found." In this one, I create two meshes by running blockMesh twice. I found an error in my controlDict functions where under 'body' I had a line referring to 'porosity' and the solver got confused. By commenting that line out, the problem was solved, and my long journey is complete!!


Now, I want to create a script to run the case in parallel. Firstly, I am a complete novice at writing scripts. But something fundamental is going haywire. Don't laugh, but here is my script:

blockMesh
surfaceFeatures

decomposePar -copyZero -force

mpirun -np 2 snappyHexMesh -overwrite -parallel     # creates mesh for radiator

cd constant
cp -r polyMesh ./solid

cd ..
blockMesh

mpirun -np 2 snappyHexMesh -dict system/snappyHexMeshDict.2 -overwrite -parallel    #  carves out bod from domain

cd constant
cp -r polyMesh ./fluid

rm -r polyMesh
cd ..

mpirun -np 2 potentialFoam -noFunctionObjects -parallel

checkMesh -region solid | tee checkMesh-solid.log
checkMesh -region fluid | tee checkMesh-fluid.log

mpirun -np 2 chtMultiRegionFoam -parallel | tee run.log

reconstructParMesh -constant
reconstructPar -latestTime

Whereas the same sequence of commands worked in the serial mode, it failed miserably in parallel. And it became evident that in the places where I made reference to directory locations, like 'cd ..' and 'mpirun -np 2 snappyHexMesh -dict system/snappyHexMeshDict.2', directory locations were ignored.


I even tried entering the commands one line at a time, but when I got to 'mpirun -np 2 snappyHexMesh -dict system/snappyHexMeshDict.2 -overwrite -parallel', it ignored the location after 'dict' and ran the wrong SHMDict. Somehow in commands following 'mpirun' and containing a directory reference, that reference is ignored.


Now, I don't mind entering commands one by one, but in this case, I am unable to run my case in parallel mode, which will be problematic in the future when my case deals with bigger stl files.


What is going on? I'm hoping for help in understanding and resolving this.