CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   getting a annoying error when simulating flow over porous media (https://www.cfd-online.com/Forums/openfoam-solving/129992-getting-annoying-error-when-simulating-flow-over-porous-media.html)

hfsf February 17, 2014 23:28

getting a annoying error when simulating flow over porous media
 
Dear all,

Recently I've started the ultimate fight against my serenity: Try to simulate transient flow over porous media on OpenFOAM. When running porousInterFoam in version 2.3.0 i've reached the following error message:

Code:

--> FOAM FATAL ERROR:

    request for volScalarField thermo:mu from objectRegistry region0 failed
    available objects of type volScalarField are

13
(
alpha.water_0
K
alpha.water
rho
p_rgh
nu
gh
nu1
p
rho_0
nu2
alpha.air
mu
)


    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/opencfd/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 198.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam230/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1  Foam::error::abort() in "/opt/openfoam230/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const& Foam::objectRegistry::lookupObject<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >(Foam::word const&) const in "/opt/openfoam230/platforms/linuxGccDPOpt/lib/libinterfaceProperties.so"
#3  Foam::fv::explicitPorositySource::addSup(Foam::fvMatrix<Foam::Vector<double> >&, int) in "/opt/openfoam230/platforms/linuxGccDPOpt/lib/libfvOptions.so"
#4 
 in "/opt/openfoam230/platforms/linuxGccDPOpt/bin/porousInterFoam"
#5 
 in "/opt/openfoam230/platforms/linuxGccDPOpt/bin/porousInterFoam"
#6  __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#7 
 in "/opt/openfoam230/platforms/linuxGccDPOpt/bin/porousInterFoam"
Abortado (imagem do núcleo gravada)

Before I guys say that the 2.3 version is the problem, the exactly same thing happened with me in the 2.2.2 version. The only thing that I could do to solve the issue is removing "thermo::mu" from ALL files in OpenFOAM source (what seems to me ridiculously wrong). I'm I doing something wrong?!

Please, help me!
Thank all of you in advance, and apologize me for the long post.

abacus++ February 27, 2014 12:05

Hello Hanniel.
I obtain exactly the same error with the porousInterFoam solver. I tested several other OpenFOAM version (v.2.2.1, v.2.2.2) but the error persists. What do you use o generate your porous medium? A "porousProperties" file in the "constant" folder or "fvOptions" file in the "system" folder?
The error that we get is that the "thermo:mu" volScalarField is not declared in the 0 folder, but this variable is a part of thermo class and I don't understant why the porousInterFoam solver needed!
I hope someone other than us will read this post and can help us... ;)
Kind regards,
Florent

alexeym February 27, 2014 12:27

Hi,

As the error occurs in explicitPorositySource, you can take a look at its constructor:

Code:

Foam::fv::explicitPorositySource::explicitPorositySource
(
    const word& name,
    const word& modelType,
    const dictionary& dict,
    const fvMesh& mesh
)

    option(name, modelType, dict, mesh),
    porosityPtr_(NULL),
    UName_(coeffs_.lookupOrDefault<word>("UName", "U")),
    rhoName_(coeffs_.lookupOrDefault<word>("rhoName", "rho")),
    muName_(coeffs_.lookupOrDefault<word>("muName", "thermo:mu"))
{
    initialise();
}

As you can see if there's no muName in porosity source coefficients dictionary, it will use thermo:mu.

I guess your source is described like
Code:

    explicitPorositySourceCoeffs
    {
        type            DarcyForchheimer;
        DarcyForchheimerCoeffs
        {
            d  d [0 -2 0 0 0 0 0] (5e7 -1000 -1000);
            f  f [0 -1 0 0 0 0 0] (0 0 0);

            coordinateSystem
            {
                e1  (0.70710678 0.70710678 0);
                e2  (0 0 1);
            }
        }
    }

Try adding 'muName mu;' to explicitPorositySourceCoeffs dictionary so it will be

Code:

    explicitPorositySourceCoeffs
    {
        muName    mu;
        type            DarcyForchheimer;
        DarcyForchheimerCoeffs
        {
            d  d [0 -2 0 0 0 0 0] (5e7 -1000 -1000);
            f  f [0 -1 0 0 0 0 0] (0 0 0);

            coordinateSystem
            {
                e1  (0.70710678 0.70710678 0);
                e2  (0 0 1);
            }
        }
    }


abacus++ February 27, 2014 18:39

Hi Alexei. It works!!! Thank you very mutch, you are the Boss!! ^^

John Degenkolb April 28, 2014 08:51

Hi all,

I've got the same error, but unfortuately, I can’t get rid of it by following the advice of alexeym.
I tried to attach the complete input files.
What I want to do is a two-phase transient simulation of a flow though a porous zone. Basically a simulation of the RTM process (http://compositeswiki.org/what-is-rt...sfer-moulding/)
I think the porousInterFoam solver is the best choice in order to do so (?)

As there is no tutorial available, I used the damBreak tutorial and added a porous zone on top of the obstacle.
I'd like it to look similar to this:
http://www.youtube.com/watch?v=DcDB5mO4CF8

I copied the porosity data from the angledDuctimplicit tutorial. (You may notice at this point: I’m a complete rookie to openFoam, cfd, and C++)
Additionally to alexeym’s advice, I added different versions of the statement “thermo:mu mu”, “muName mu” and so on to different positions in the input files. Without any success.
The terminal message I get is this:

Code:


peter@peter-HP-Compaq-nw8440-RZ646EC-ABD:~/OpenFOAM/peter-2.3.0/run/EigeneVersuche/damBreakPorousRumspieln$ porousInterFoam
/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.3.0                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 2.3.0-f5222ca19ce6
Exec  : porousInterFoam
Date  : Apr 28 2014
Time  : 11:36:41
Host  : "peter-HP-Compaq-nw8440-RZ646EC-ABD"
PID    : 3340
Case  : /home/peter/OpenFOAM/peter-2.3.0/run/EigeneVersuche/damBreakPorousRumspieln
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations
 
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
 
Create mesh for time = 0
 
Reading field p_rgh
 
Reading field U
 
Reading/calculating face flux field phi
 
Reading transportProperties
 
Selecting incompressible transport model Newtonian
Selecting incompressible transport model Newtonian
Selecting turbulence model type laminar
 
Reading g
Calculating field g.h
 
No finite volume options present
 
Creating porosity model list from porosityProperties
 
Porosity region Porosity:
    selecting model: DarcyForchheimer
    creating porous zone: Porosity
 
PIMPLE: Operating solver in PISO mode
 
time step continuity errors : sum local = 0, global = 0, cumulative = 0
DICPCG:  Solving for pcorr, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0, global = 0, cumulative = 0
Courant Number mean: 0 max: 0
 
Starting time loop
 
Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
deltaT = 0.00119048
Time = 0.00119048
 
smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.130021  Min(alpha1) = 0  Max(alpha1) = 1
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.130021  Min(alpha1) = 0  Max(alpha1) = 1
 
 
--> FOAM FATAL ERROR:
 
    request for volScalarField thermo:mu from objectRegistry region0 failed
    available objects of type volScalarField are
 
13
(
alpha.water_0
K
alpha.water
rho
p_rgh
nu
gh
nu1
p
rho_0
nu2
alpha.air
mu
)
 
 
    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/opencfd/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 198.
 
FOAM aborting
 
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const& Foam::objectRegistry::lookupObject<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >(Foam::word const&) const at ??:?
#3  Foam::porosityModels::DarcyForchheimer::correct(Foam::fvMatrix<Foam::Vector<double> >&) const at ??:?
#4  Foam::porosityModel::addResistance(Foam::fvMatrix<Foam::Vector<double> >&) const at ??:?
#5  Foam::porosityModelList::addResistance(Foam::fvMatrix<Foam::Vector<double> >&) const at ??:?
#6 
 at ??:?
#7  __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#8 
 at ??:?
Abgebrochen (Speicherabzug geschrieben)

Thank you very much in advance!

alexeym April 28, 2014 09:29

Hi,

as your porosity is actually porosityModel class and not fvOption, you need to look at src/finiteVolume/cfdTools/general/porosityModel/DarcyForchheimer/DarcyForchheimer.C:

Code:

Foam::porosityModels::DarcyForchheimer::DarcyForchheimer
(
    const word& name,
    const word& modelType,
    const fvMesh& mesh,
    const dictionary& dict,
    const word& cellZoneName
)
:
    porosityModel(name, modelType, mesh, dict, cellZoneName),
    coordSys_(coeffs_, mesh),
    D_("D", dimless/sqr(dimLength), tensor::zero),
    F_("F", dimless/dimLength, tensor::zero),
    rhoName_(coeffs_.lookupOrDefault<word>("rho", "rho")),
    muName_(coeffs_.lookupOrDefault<word>("mu", "thermo:mu")),
    nuName_(coeffs_.lookupOrDefault<word>("nu", "nu"))
...

where coeffs_ is DarcyForchheimerCoeffs dictionary in constant/porosityProperties file.

And so, you need to add to this dictionary

Code:

mu mu;
line (by default, as you can see, it is thermo:mu).

And if we return to the files of angledDuctImplicit tutorial case, your porosityProperties should be something like:
Code:

porosity1
{
    type            DarcyForchheimer;
    active          yes;
    cellZone        porosity;

    DarcyForchheimerCoeffs
    {
        mu mu;

        d  d [0 -2 0 0 0 0 0] (5e7 -1000 -1000);
        f  f [0 -1 0 0 0 0 0] (0 0 0);

        coordinateSystem
        {
            e1  (0.70710678 0.70710678 0);
            e2  (0 0 1);
        }
    }
}


John Degenkolb April 28, 2014 09:57

IT WORKS !!! GREAT !!! :D

Thank you very much for the quick and helpful anser.

Merci beaucoup.

Kind regards, cordialement,

Peter

hfsf April 30, 2014 08:02

Hey guys,

I'm almost giving up. Using OpenFOAM v.2.3, my simulations with the solver interFoam seems to ignore the porous medium. There's no resistance exerted due to the porous medium, however I've declared everything as alexeym suggested, and even could get rid of the "termo::mu" error. The solvers seems to recognize the fvOptions declaration of a porous medium, however no observable effect on the velocity/pressure profile is observed...

Using porousInterFoam the solver seems to recognize the porous media, and the results in U/p shows some evidence of resistance due to the porous media. However, my results are very wrong concerning the mold filling time. Someone experimented similar issue? Using OpenFOAM v.2.1.1 the filling time seems ok, however I need to use the newer version.

Thanks in advance,

Freitas

alexeym April 30, 2014 08:51

Hi,

it's quite obvious but you need to be more specific. How do you add porosity source (i.e. show your dictionaries)? If you attach your case files it'll be even easier.

The only difference between interFoam and porousIterFoam (except creation of porosity zones) is addition of two lines in UEqn.H file:

Code:

    pZones.addResistance(UEqn);
    fvOptions.constrain(UEqn);

In case of explicitPorositySource second line does nothing.

As you compare with 2.1.1 (where fvOption mechanism was not added yet), I guess you're setting up porosity with porosityProperties file, and it's not surprising that interFoam ignores it.

hfsf April 30, 2014 10:00

1 Attachment(s)
Thanks for the quick reply alexeym,

Here are the fies. I'm sending the whole case folder in a zip file.

Using the interFoam solver, the deltaT becomes very small (<1E-6) but before 1s of simulated time, the mold is already filled.

Using porousInterFoam the deltaT is ok, but there's some error in the mold filling time. According to the literature, the filling time for the simulated RTM process is 180s. Using porousInterFoam from v.2.1.1 shows accurate results. Version 2.2.2 shows some divergence (less than 5%) but version 2.3 shows about 30% of error.

CORRECTION: The version 2.2.2 shows the same divergence of the version 2.3, about 30% of error.

I'm also publishing my porousProperties and fvOptions dictionaries as follows.
I would like also to ask you about the coordinateSystem subDict. I've searched all aroud but could not understand its function.

Here is the fvOptions dict:
Code:

porosity1
{
    type            explicitPorositySource;
    active          yes;
    selectionMode  cellZone;
    cellZone        poro;
    porosity        0.7;

    explicitPorositySourceCoeffs
    {
        type            DarcyForchheimer;
        porosity 0.7;
        printCoeffs yes;
        muName  mu;
        DarcyForchheimerCoeffs
        {
            d  d [0 -2 0 0 0 0 0] (2.333e9 2.333e9 2.333e9);
            f  f [0 -1 0 0 0 0 0] (0 0 0);

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

And the porosityProperties dict:

Code:


porosity1
{
    type            DarcyForchheimer;
    mu              mu;
    active          yes;
    cellZone        poro;
    porosity        0.7;

    DarcyForchheimerCoeffs
    {
        d  d [0 -2 0 0 0 0 0] (2.333e9 2.333e9 2.333e9);
        f  f [0 -1 0 0 0 0 0] (0 0 0);

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


Thanks in advance for the attention.

Freitas

alexeym May 1, 2014 10:35

1 Attachment(s)
Hi,

1. Well, it seems that interFoam is really incapable to use fvOptions to add porosity into simulation domain. So the rest will be about porousInterFoam. The reason for very small time step with interFoam is very high velocity inside the domain (as there's no porosity).

2. One of the most common reasons for error in simulations is not fully converged solution. So I've modified your fvSolution to use residualControl instead of fixed number of outer iterations, now it looks like this:

Code:

PIMPLE
{
    momentumPredictor yes;
    nOuterCorrectors 100;
    nCorrectors    2;
    nNonOrthogonalCorrectors 0;

    residualControl
    {
        "(p_rgh|U)"
        {
            tolerance 1e-2;
            relTol 0;
        }
    }
}

maybe you need to play with tolerance in residualControl to get more accurate results (i.e. set it to 1e-4 or 1e-6). With tolerance == 1e-2 solver does 8-11 outer corrector iterations.

3. About coordinateSystem. I guess this functionality is necessary if you have porous block rotated relative to simulation domain. If you look at DarcyForchheimer.C file, you'll find this piece of code there:

Code:

...
    if (coordSys_.R().uniform())
    {
        forAll (cellZoneIDs_, zoneI)
        {
            D_[zoneI].setSize(1, tensor::zero);
            F_[zoneI].setSize(1, tensor::zero);

            D_[zoneI][0].xx() = d.value().x();
            D_[zoneI][0].yy() = d.value().y();
            D_[zoneI][0].zz() = d.value().z();

            D_[zoneI][0] = coordSys_.R().transformTensor(D_[zoneI][0]);
   
            // leading 0.5 is from 1/2*rho
            F_[zoneI][0].xx() = 0.5*f.value().x();
            F_[zoneI][0].yy() = 0.5*f.value().y();
            F_[zoneI][0].zz() = 0.5*f.value().z();

            F_[zoneI][0] = coordSys_.R().transformTensor(F_[zoneI][0]);
        }
       
    }
...

I.e. D and F tensors are transformed to match local coordinate system of porous block. In your case porous block is the whole simulation domain, so e1 is (1 0 0) and e2 is (0 1 0). Though I'm not quite sure about this thing ;)

I've attached case files with modifications I've made to the message.

hfsf May 2, 2014 11:16

Alexeym,

man, you are awesome. However, no change in the results, they keep diverging a lot from the theoretical predictions. Even imposing a tolerance of 1e-8 in the residual control, there are no change in the results :mad: The mold should be completely filled in 180 s (alpha = 1 - the resin - in whole domain).

What I can't understand is that in the version 2.1.1 of the OpenFOAM the solver produces accurate results, with no modifications required. You don't have even to turn on the momentum predictor :(

I don't know what to do anymore.

alexeym May 2, 2014 12:36

Hi,

I've just run the case I've posted in the previous message with 2.3.0, and domain is completely filled with resin at t=180 s (well, maybe except the cell near outlet where value of alpha is 0.458). And if I switch off momentumPredictor simulation runs even faster (2 outer corrector iterations), value of alpha in the cell near outlet is 0.533).

Also I've compared implementations of porousInterFoam/porousZone in 2.1.1 and 2.3.0. Wasn't able to find any difference in physical sense (surely names of classes are different, certain implementation details are different, but equations are the same).

hfsf May 2, 2014 21:50

Alexey, many thanks for all your effort to ellucidate this problem.

Even with the changes proposed by you, the simulation still diverging. After many hours comparing my simulation (already corrected) to yours, still no clue about the error. I've copied all definitions (fvSolution, fvSchemes, etc) to my case, but nothing seems to fix the error.

After a whole day pursuing the error, I've stumbled with the cause of the strange divergence: I let a fvOptions file inside the system/ folder of the simulation. I guess that reading that file, the solver failed to create properly the momentum resistance due to the porous media. It's always the simplest thing that fool our eyes, doesn't? :rolleyes:

Anyways, I thought it may be important to be shared with the forum.
Thanks again.

hfsf May 3, 2014 18:06

Dear All,

Sorry to ressurect the thread.

I would like to thank you for your attention. With your help, I've managed to simulate the mold filling case (initially filled with air, later resin is injected and makes the air goes out). However, by now I need to simulate an additional particle phase, so I've change to the multiphaseEulerFoam solver ( the particle drag is important, so I cannot use the single fluid approach).

The problem is that I set the mold (to help to imagine the problem, lets approximate the mold to a pipe section) filled with air (alpha.air = 1). As no air enters trough the left open section, I've set the velocity of the air phase (U.air) to zeroGradient. How can I set the proper boundary conditions (for alpha and U) for the exit so the air can exit trough the right open section as the resin and particle are injected in the left?

My previous uploaded case has the proper configuration to ensure that air exits the domain as expected. But it was configured to porousInterFoam. When I try to change to multiphaseEulerFoam using the same strategy (defined pressure on the inlet, zero pressure in the inlet, velocity defined tru the pression in the inlet, zeroGradient velocity in the outlet) the air don't exit the domain.

Anybody has any clue about the problem?

Many thanks!

uuivw May 24, 2014 05:09

Quote:

Originally Posted by alexeym (Post 489310)
Hi,

1. Well, it seems that interFoam is really incapable to use fvOptions to add porosity into simulation domain. So the rest will be about porousInterFoam. The reason for very small time step with interFoam is very high velocity inside the domain (as there's no porosity).

2. One of the most common reasons for error in simulations is not fully converged solution. So I've modified your fvSolution to use residualControl instead of fixed number of outer iterations, now it looks like this:

Code:

PIMPLE
{
    momentumPredictor yes;
    nOuterCorrectors 100;
    nCorrectors    2;
    nNonOrthogonalCorrectors 0;

    residualControl
    {
        "(p_rgh|U)"
        {
            tolerance 1e-2;
            relTol 0;
        }
    }
}

maybe you need to play with tolerance in residualControl to get more accurate results (i.e. set it to 1e-4 or 1e-6). With tolerance == 1e-2 solver does 8-11 outer corrector iterations.

3. About coordinateSystem. I guess this functionality is necessary if you have porous block rotated relative to simulation domain. If you look at DarcyForchheimer.C file, you'll find this piece of code there:

Code:

...
    if (coordSys_.R().uniform())
    {
        forAll (cellZoneIDs_, zoneI)
        {
            D_[zoneI].setSize(1, tensor::zero);
            F_[zoneI].setSize(1, tensor::zero);

            D_[zoneI][0].xx() = d.value().x();
            D_[zoneI][0].yy() = d.value().y();
            D_[zoneI][0].zz() = d.value().z();

            D_[zoneI][0] = coordSys_.R().transformTensor(D_[zoneI][0]);
   
            // leading 0.5 is from 1/2*rho
            F_[zoneI][0].xx() = 0.5*f.value().x();
            F_[zoneI][0].yy() = 0.5*f.value().y();
            F_[zoneI][0].zz() = 0.5*f.value().z();

            F_[zoneI][0] = coordSys_.R().transformTensor(F_[zoneI][0]);
        }
       
    }
...

I.e. D and F tensors are transformed to match local coordinate system of porous block. In your case porous block is the whole simulation domain, so e1 is (1 0 0) and e2 is (0 1 0). Though I'm not quite sure about this thing ;)

I've attached case files with modifications I've made to the message.

Why it can't be run blockmesh,what's metter ? I am a Newbie in using openfoam

John Degenkolb May 26, 2014 03:51

Quote:

Why it can't be run blockmesh,what's metter ?
blockmesh is the meshing tool. That means it creates a mesh based on your specifications in the blockMeshDict file. porousInterFoam, interFoam and multiphaseEulerFoam are examples for solvers, which compute your solution.

santoo_cfd June 6, 2014 09:26

Quote:

Originally Posted by alexeym (Post 489310)
Hi,

1. Well, it seems that interFoam is really incapable to use fvOptions to add porosity into simulation domain. So the rest will be about porousInterFoam. The reason for very small time step with interFoam is very high velocity inside the domain (as there's no porosity).

Hi Alexyem,

As you mentioned above, porousInterFoam doesn't honor the porosity value mentioned in the porosityProperties Dict. I have also checked in the src folder that there is no member function that reads the porosity.

I have also checked test case attached by you above by modifying the "porosity" value in porosityProperties. It is does change the results.

Do you have any idea/hint how to modify the solver to take the porosity input.

John Degenkolb June 6, 2014 10:15

Hi Santhosh,

of course, porousInterFoam reads the porosity values you specify in the porousityProperties document in the constant-folder.

The source code file of the porousInterFoam solver includes a file called “createPorousZones.H” (You can find it in …/applications/solvers/multiphase/interFoam/porousInterFoam)

Furthermore, if you take a look at some of the videos of simulations created with this solver, you will find that it is working pretty well:
http://www.youtube.com/results?search_query=porousInterFoam

interFoam obviously doesn’t take any porosity into account. Otherwise, the porousInterFoam solver would be redundant.

Which version of openFoam do you use? Maybe your changes in porosity values were not huge enough.

Best Regards,

Peter

santoo_cfd June 6, 2014 11:20

Hi Peter,

I use OpenFOAM 2.3.0. I know that interFOAM does not need porousity values.
I meant that basic porous media treatment is missing the functionality to read the porosity values.

In the previous version, porosity we supply is used in calculating the temporal derivative of momentum equation. (gamma).

you may look at http://www.cfd-online.com/Forums/ope...-porosity.html for more understanding.

I could not find any video showing difference the results with different porosity values.

You may look at for yourself by downloading the test case attached above and change the value of porosity in constant/porosityProperties. (I have compared the log files with porosity of 0.4 and 0.7)

Hope I am little more clear now.

Regards,
Santhosh


All times are GMT -4. The time now is 02:01.