[hfsf]

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:

--> 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++]

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]

Hi,

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

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

    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

    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++]

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

[John Degenkolb]

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:

 
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]

Hi,

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

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

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:

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]

IT WORKS !!! GREAT !!!

Thank you very much for the quick and helpful anser.

Merci beaucoup.

Kind regards, cordialement,

Peter

[hfsf]

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]

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:

    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]

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:

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:

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]

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:

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:

...
    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]

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 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]

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]

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?

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

[hfsf]

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]

Originally Posted by alexeym

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:

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:

...
    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]

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]

Originally Posted by alexeym

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]

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]

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