CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

interFoam {nOuterCorrections}

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   August 13, 2015, 11:57
Default interFoam {nOuterCorrections}
  #1
Senior Member
 
Saideep
Join Date: Apr 2015
Location: INDIA
Posts: 203
Rep Power: 12
Saideep is on a distinguished road
Hi FOAMERS;

I am using OpenFOAM 2.3.x and using interFOAM solver.

Lately I found an interesting thing for which i am unable to find a solution and would appreciate if anyone can pass me a hint.

I am using a static drop case in 2D, where an air bubble is present within a square domain. (fig1).

I have the following boundary conditions for U, p_rgh and alpha.
U {all sides of the wall fixedValue (0 0 0)}

p_rgh {all sides with zeroGradient}

and alpha {all sides with zeroGradient}.

So, when i use the nOuterCorrector = 1{i.e. solving for PISO} i have a range bound computation for alpha between 0 and 1 and apart from spurious currents everything seems to be fine.

But incase if i increase the nOuterCorrections > 1 {solving for PISO and PIMPLE}, I get alpha values that are above 1 and below 0 which seems quite interesting because if something was wrong it shall not work in the PISO correction too.

Going back to the damBreak case i tried the same and it works over there. So, I am a bit clueless now where is the error in computation coming from.

Any ideas please?

Thanks and best wishes;
Saideep
Attached Images
File Type: jpg fig1.jpg (24.0 KB, 144 views)
Saideep is offline   Reply With Quote

Old   August 14, 2015, 11:01
Default
  #2
Senior Member
 
Saideep
Join Date: Apr 2015
Location: INDIA
Posts: 203
Rep Power: 12
Saideep is on a distinguished road
Hi Guys;

I am to revoke this thread and sorry for that!!
Since a few days i have had a peculiar problem and would like to know if you can help me out.

I am working with OF 2.3.x and using the interFoam solver to study and attempt to reduce the spurious currents considering a simple static drop problem.

I use the following bc's:
U {fixedValue (0 0 0)} on all faces of the domain;
p_rgh {zeroGradient} on all faces of the domain;
alpha.air {zeroGradient} also on all faces of the domain.

So, basically there is nothing like an inflow/ outflow but only simple relaxation of the bubble.

I would like to increase the accuracy of my model by having a value of 3 for "nOuterCorrections".

The alpha value being computed is as follows:

PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 0.0435804, Final residual = 1.49236e-10, No Iterations 4
Phase-1 volume fraction = 0.0399991 Min(alpha1) = -62.1788 Max(alpha1) = 162.964
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.0399991 Min(alpha1) = -59.3845 Max(alpha1) = 147.927
DICPCG: Solving for p_rgh, Initial residual = 0.284426, Final residual = 0.0127196, No Iterations 3
time step continuity errors : sum local = 0.000808737, global = -1.64813e-06, cumulative = -1.70439
DICPCG: Solving for p_rgh, Initial residual = 0.0379612, Final residual = 0.0018768, No Iterations 17
time step continuity errors : sum local = 0.000222015, global = -3.05104e-06, cumulative = -1.70439


But if i use only 1 outercorrection it works perfectly. Also it works good if i reduce the surface tension very low {no idea why this happens, it is after all a constant value}.

If this is the case then the damBreak case also shall not work but that works again. Using all same data from the damBreak and just changing my blockMeshDict and setFieldsDict data will compute wrong alpha as in red.

Could you please let me know where is the error coming from?

Thanks and best wishes;
Saideep

[ Moderator note: post moved from http://www.cfd-online.com/Forums/ope...interfoam.html ]

Last edited by wyldckat; August 20, 2015 at 14:32. Reason: see "Moderator note:"
Saideep is offline   Reply With Quote

Old   August 20, 2015, 14:38
Default
  #3
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Saideep,

Since you asked me to look into this via PM, here's what I can figure out from your posts:
Quote:
Originally Posted by Saideep View Post
So, when i use the nOuterCorrector = 1{i.e. solving for PISO} i have a range bound computation for alpha between 0 and 1 and apart from spurious currents everything seems to be fine.
If you increase the number of corrector iterations, apparently you're simply intensifying the effect the "spurious currents" have got.

Beyond that, you didn't provide the complete configuration for the "fvSolution" file, which would possibly give more important details as to what might be wrong.
In addition, this reminds me of two other cases:
Read those threads and perhaps you'll find something that let's you figure out better what might be happening.


Best regards,
Bruno
__________________
wyldckat is offline   Reply With Quote

Old   August 21, 2015, 13:59
Default
  #4
Senior Member
 
Saideep
Join Date: Apr 2015
Location: INDIA
Posts: 203
Rep Power: 12
Saideep is on a distinguished road
Thanks Bruno;

I will have a look at that!!

Just a question. Yes, you mention the parasite currents get worse but why?
In my view, i am solving a steady state case. Is it because i am advancing over time with larger time steps? Or is there any other reason?

However i can think and also see that effect with the parasitic currents but still alpha shall be bounded right.

My fvSolution data is attached below:

Code:
solvers
{
    "alpha.air.*"
    {
        nAlphaCorr      2;
        nAlphaSubCycles 1;
        cAlpha          1;
        CSK         0.5;
        CPC        0.01;
    MULESCorr       yes;
        nLimiterIter    3;

        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-8;
        relTol          0;
    }

    pcorr
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-5;
        relTol          0;
    }

    p_rgh
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-07;
        relTol          0.05;
    }

    p_rghFinal
    {
        $p_rgh;
        relTol          0;
    }

    U
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-06;
        relTol          0;
    }
}

PIMPLE
{
    momentumPredictor   no;
    nOuterCorrectors    3;
    nCorrectors         3;
    nNonOrthogonalCorrectors 0;
    pRefCell     0;
    pRefValue     0;

residualControl
    {
        U
        {
                tolerance  1e-5;
                relTol      0;
        }
        p
        {
                tolerance  5e-4;
                relTol      0;
        }
     }
}

relaxationFactors
{
    fields
    {
    p_rgh     0.3;
    U    0.3;
    }
    equations
    {
        ".*" 1;
    }
}
--
Thanks a lot Bruno;
Saideep

Last edited by wyldckat; August 21, 2015 at 14:37. Reason: Added [CODE][/CODE] markers
Saideep is offline   Reply With Quote

Old   August 21, 2015, 16:28
Default
  #5
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Saideep,
Quote:
Originally Posted by Saideep View Post
Just a question. Yes, you mention the parasite currents get worse but why?
In my view, i am solving a steady state case. Is it because i am advancing over time with larger time steps? Or is there any other reason?
Technically, using the PIMPLE mode means that you're refining the solution. But if the solution has "garbage in it", i.e. the disturbances in the flow, that means that the problem will possibly only get worse. It might smooth out a bit the values, but for example, if there is a cell with a pressure value that is 10x more than the values on the surrounding cells, either:
  • you get a smoothed out solution, where the value is 5x or 2x larger;
  • or it gets worse, due to the surrounding cells inducing a 50x larger value.
Quote:
Originally Posted by Saideep View Post
My fvSolution data is attached below:

Code:
solvers
{
    "alpha.air.*"
    {
        nAlphaCorr      2;
        nAlphaSubCycles 1;
        cAlpha          1;
        CSK         0.5;
        CPC        0.01;
    MULESCorr       yes;
        nLimiterIter    3;

        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-8;
        relTol          0;
    }

    pcorr
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-5;
        relTol          0;
    }

    p_rgh
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-07;
        relTol          0.05;
    }

    p_rghFinal
    {
        $p_rgh;
        relTol          0;
    }

    U
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        tolerance       1e-06;
        relTol          0;
    }
}

PIMPLE
{
    momentumPredictor   no;
    nOuterCorrectors    3;
    nCorrectors         3;
    nNonOrthogonalCorrectors 0;
    pRefCell     0;
    pRefValue     0;

residualControl
    {
        U
        {
                tolerance  1e-5;
                relTol      0;
        }
        p
        {
                tolerance  5e-4;
                relTol      0;
        }
     }
}

relaxationFactors
{
    fields
    {
    p_rgh     0.3;
    U    0.3;
    }
    equations
    {
        ".*" 1;
    }
}
--
The relaxation factors don't seem to be properly configured. Only the Final iteration should have a relaxation factor of 1.0. Let me see if I can find an example in the tutorials:
Code:
find $FOAM_TUTORIALS -name "fvSolution" -type f | xargs grep "Final"
Mmm... looks like this isn't common in multiphase simulations, but the tutorial "incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_pimpleDyMFoam" has what I was thinking about:
Code:
relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        "(U|k|omega)"   0.7;
        "(U|k|omega)Final" 1.0;
    }
}
As for parasitic flows in multiphase simulations... I know I saw a thread about this sometime ago... there are several actually... for example: http://www.cfd-online.com/Forums/ope...rrent-now.html


As for steady-state simulation:
Quote:
Originally Posted by Saideep View Post
Is it because i am advancing over time with larger time steps?
Wait... seriously? Why did you not mentioned that in your previous posts????

If you want steady-state multiphase flow, you should be using LTSinterFoam!


After re-reading your 2 original posts again... I have my doubts you can do this with any version of interFoam. I suggest you study the
thread I mentioned about parasitic currents and also read this thread: http://www.cfd-online.com/Forums/ope...lat-plate.html

Best regards,
Bruno
__________________
wyldckat is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
InterFoam stops after deltaT goes to 1e14 francesco_b OpenFOAM Running, Solving & CFD 9 July 25, 2020 06:36
interFoam vs. simpleFoam channel flow comparison DanM OpenFOAM Running, Solving & CFD 12 January 31, 2020 15:26
interFoam in parallel gooya_kabir OpenFOAM Running, Solving & CFD 0 December 9, 2013 05:09
Problem of InterFoam with LES SpalartAllmarasIDDES keepfit OpenFOAM 3 August 29, 2013 11:21
Open Channel Flow using InterFoam type solver sxhdhi OpenFOAM Running, Solving & CFD 3 May 5, 2009 21:58


All times are GMT -4. The time now is 13:04.