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

pUCoupledFoam with Multiple Reference Frames (MRF)

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   June 25, 2014, 20:40
Default pUCoupledFoam with Multiple Reference Frames (MRF)
  #1
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
Greetings All!

I'm very excited about the latest release of foam-3.1. I see that the long awaited coupled / block matrix solver has been added to the library. However, it doesn't look like there's a compiled version with multiple reference frame (MRF) capability.

My question is, would it be just as simple as taking the MRF lines of code from MRFSimpleFoam and plugging it into the pUCoupledFoam, merging the dependencies between the two solvers, and compiling the new solver (say MRFpUCoupledFoam)?

Also, if you were to include the unsteady capabilities from, say, pimpleDyMFoam into the code, would the end result be similar to CFX's steady-state solver with pseudo-timescale or FLUENT's Coupled Pseudo-Transient method, where the chosen pseudo time-step acts as a relaxation factor?

Just wanted to bounce the idea around before I try to compile something silly. lol
raj kumar saini likes this.
PorscheGTIII is offline   Reply With Quote

Old   November 14, 2014, 05:21
Default
  #2
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
That would be an interesting solver to develop, did anyone tried to compile it?
crixman is offline   Reply With Quote

Old   November 18, 2014, 05:37
Default
  #3
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
I compiled the solver, it is incredibly slow but converges with very few iterations compared to MRFSimpleFoam,
If anyone is interested in testing it let me know!
crixman is offline   Reply With Quote

Old   November 18, 2014, 17:36
Default
  #4
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
Can I give it a try? I had compiled a version shortly after my first post, and I had some problems with convergence with the problem I was studying compared to the results I got from MRFSimpleFoam. If I remember correctly, I couldn't get the multigrid solver to work correctly either.
PorscheGTIII is offline   Reply With Quote

Old   November 19, 2014, 04:45
Default
  #5
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
Sure send me an email I will send it to you - then please let me know how it goes and if you think it should be improved!
crixman is offline   Reply With Quote

Old   November 19, 2014, 09:58
Default
  #6
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
I sent you a PM with my e-mail. Thank you!
PorscheGTIII is offline   Reply With Quote

Old   November 20, 2014, 13:09
Default
  #7
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
Did you get it? how is it going?
crixman is offline   Reply With Quote

Old   November 20, 2014, 16:23
Default
  #8
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
I got it, thank you! Running through my first test case. It may take a few days to run the simulation and check the results out and compare with MRFSimpleFoam
PorscheGTIII is offline   Reply With Quote

Old   November 20, 2014, 19:05
Default
  #9
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
One thing I did manage to figure out was why I kept getting the error:

Quote:
[1] --> FOAM FATAL ERROR:
[1] fineInterface must be of processor type and either processorBlockLduInterfaceField<Type> or processorFvPatchField<Type>
[1]
[1]
[1] From function processorBlockGAMGInterfaceField<Type> Constructor
[1] in file lnInclude/processorBlockGAMGInterfaceField.C at line 61.
[1]
After a quick Google search I found the following ticket for this very problem:

http://sourceforge.net/p/openfoam-ex...ndrelease/248/

From the explanation given there, when the code was update to rid it's dependence of the finiteVolume library the error occurred. Fortunately, the ticket has proposed a solution in a text file "bugFixProcessorBlockAMG.patch." If you make the changes and recompile the source, the Block AMG solver will work in parallel. I tested it on the example backwardFacingStepTurbulent tutorial for pUCoupledFoam. However, I'm having difficulty getting it to work with my test case for this MRFpUCoupledFoam solver. I immediately get a floating point error. I'll try playing around with it as well, but the BiCGStab solver seems to be stable and solving this test case.
PorscheGTIII is offline   Reply With Quote

Old   November 21, 2014, 05:50
Default
  #10
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
Allright interesting, in fact I did not use the AMG solver as it wasn't working properly, so now I know why!

What case are you simulating? Could it be a boundary condition problem?

Let me know how the test goes and would you send me the updated code when you got it to work?
crixman is offline   Reply With Quote

Old   December 3, 2014, 09:48
Default
  #11
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
I have completed one tests of this new MRFpUCoupledFoam solver. The computation was carried out on a small, propeller-type hydrokinetic turbine similar to what's pictured below:



The mesh is a tetrahedral mesh generated with ANSYS meshing, with a conformal mesh between the turbine domain and the river/channel domain. The "Free Surface" was modeled as a non-deformable slip wall. A rotating reference frame was used in the turbine domain and the absolute reference frame in the river/channel domain. More information about the boundary conditions and the problem setup can be found in my recent publication: http://www.sciencedirect.com/science...60148114007472 (doi:10.1016/j.renene.2014.11.032). Note that that the unit studied in that manuscript is different then the one presented in this post. The units in the manuscript also used a structured hexahedral mesh.

I did a result comparison between MRFpUCoupledFoam and MRFSimpleFoam. Both simulations used the same mesh and boundary conditions and schemes. Both simulation were calculated on the same PC and decomposed with the same number of processes. They were both ran for 1000 iterations. The solvers were different. Pictured below are the residual plots for the MRFpUCoupledFoam solver:





Pictured below are the residual plots for the MRFSimpleFoam solver:





For the same number of iterations, the coupled solver had lower residuals; however, it took longer for the coupled solver to obey continuity than the MRFSimpleFoam solver. This may just be due to the different solvers used in the fvSolution file.

The execution time for the MRFpUCoupledFoam solver was 22660.96 s and 11660.8 s for the MRFSimpleFoam solver.

The forces on the turbine blades for the MRFpUCoupledFoam solver were predicted to be:

Code:
forces output:
    forces(pressure, viscous)((-0.35897795 0.063049842 -168.78056) (-0.0084648028 -0.0011228238 -1.1589041))
    moment(pressure, viscous)((-0.10147754 0.049363351 6.1399811) (0.00013767574 0.00035465256 -0.37919792))
And for the MRFSimpleFoam solver:
Code:
forces output:
    forces(pressure, viscous)((-0.150706 0.102579 -168.551) (-0.00871071 -0.00162742 -1.157))
    moment(pressure, viscous)((-0.0502227 0.0337058 6.11785) (8.06596e-05 0.000381771 -0.378728))
Conclusion: So far so good! I want to try the problem out next on my published results, which also uses a GGI interface between reference frames.
crixman likes this.
PorscheGTIII is offline   Reply With Quote

Old   December 3, 2014, 10:03
Default
  #12
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
Very good! Results are very close, we just need to find out how to speed up the solver then!
Any ideas about what can cause those oscillations in Up[1] and Up[3] ?
crixman is offline   Reply With Quote

Old   December 3, 2014, 11:02
Default
  #13
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
Yes, I'm pretty sure it's because of the relTol I set on the Up solver. When I had that set to 0, I think I didn't see those oscillations. I set the relTol to 0.001 to speed up the computation time. Here's the fvSolution file I used:

Code:
/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | foam-extend: Open Source CFD                    |
|  \\    /   O peration     | Version:     3.1                                |
|   \\  /    A nd           | Web:         http://www.extend-project.de       |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
     Up
     {
         solver BiCGStab;
         preconditioner Cholesky;

         tolerance 1e-09;
         relTol  0.001;

         minIter 1;
         maxIter 500;
     }
/*
    Up
    {
        solver          AMG;
        cycle           F-cycle;
        coarseningType  AAMG;
        norm            componentNorm;
        normComponent   0;

        nPreSweeps      0;
        nPostSweeps     3;
    nFinestSweeps    30;
        groupSize       2;
        minCoarseEqns   4;
        nMaxLevels      100;
        scale           on;
        smoother        ILU;

        minIter         0;
        maxIter         100;
        tolerance       1e-18;
        relTol          0.001;
    }
*/
    // Segregated
    p
    {
        solver          GAMG;
        tolerance       1e-18;
        relTol          0.001;
        smoother        GaussSeidel;
        nPreSweeps      1;
        nPostSweeps     3;
        nFinestSweeps   30;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 240;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    U
    {
        solver          GAMG;
        tolerance       1e-18;
        relTol          0.01;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     3;
        nFinestSweeps   30;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 240;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    k
    {
        solver          GAMG;
        tolerance       1e-18;
        relTol          0.01;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     3;
        nFinestSweeps   30;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 240;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    omega
    {
        solver          GAMG;
        tolerance       1e-18;
        relTol          0.01;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     3;
        nFinestSweeps   30;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 240;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }
}

blockSolver
{
}

relaxationFactors
{
    U               0.75;
    p            0.75
    k               0.8;
    omega           0.8;
}

SIMPLE
{
    nNonOrthogonalCorrectors 20;
}

// SIMPLE
// relaxationFactors
// {
//     p               0.3;
//     U               0.7;
//     k               0.7;
//     epsilon         0.7;
// }

// ************************************************************************* //
PorscheGTIII is offline   Reply With Quote

Old   December 3, 2014, 16:21
Default
  #14
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
Did you check the difference between AMG and BiCGStab for Up?
crixman is offline   Reply With Quote

Old   December 3, 2014, 16:55
Default
  #15
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
This is funny. Right after you posted I checked the AMG solver and it started working for this problem! I'd much rather use the multigrid method. I'll play around with the solver settings to see what's up
PorscheGTIII is offline   Reply With Quote

Old   December 4, 2014, 10:41
Default
  #16
New Member
 
Chris
Join Date: Jan 2012
Posts: 17
Rep Power: 14
PorscheGTIII is on a distinguished road
Just tried to use the MRFpUCoupledFoam solver on my problem with ggi interfaces. For some reason, it looks like information isn't being passed between interface zones. Running this with MRFSimpleFoam works fine.

PorscheGTIII is offline   Reply With Quote

Old   December 5, 2014, 11:47
Default
  #17
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
I am getting a similar problem with pimpleDyMFoam + GGI, not sure how to solve it.
I'll see if I can solve it then I'll help you
crixman is offline   Reply With Quote

Old   September 14, 2015, 06:46
Default
  #18
Senior Member
 
M. Montero
Join Date: Mar 2009
Location: Madrid
Posts: 155
Rep Power: 17
be_inspired is on a distinguished road
How complex is to include pU coupling into an reference solver?
I want to check pUCoupling over pimpleDyMFoam.
Could you share MRFpUCoupledFoam to check it?

Best Regards
be_inspired is offline   Reply With Quote

Old   September 14, 2015, 08:53
Default
  #19
Member
 
crixman's Avatar
 
Christian
Join Date: Apr 2014
Posts: 74
Rep Power: 12
crixman is on a distinguished road
be_inspired, if you could couple it with pimpleDyMFoam that would be great.
PorscheGTIII, could you send the solver to be_inspired?
crixman is offline   Reply With Quote

Old   March 9, 2016, 02:56
Default
  #20
Member
 
Cameron
Join Date: Jul 2012
Posts: 33
Rep Power: 14
c_dowd is on a distinguished road
Did any of you have any luck with the AMG solver for this case? I've just compiled an SRF version of pUcoupledfoam which works for the tutorial cases, but keeps diverging on my problem.
c_dowd is offline   Reply With Quote

Reply

Tags
block matrix, coupled solver, mrfsimplefoam, mrfzones, pucoupledfoam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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
Second Derivative Zero - Boundary Condition fu-ki-pa OpenFOAM 11 March 27, 2021 04:28
OpenFOAM 1.6-ext git installation on Ubuntu 11.10 x64 Attesz OpenFOAM Installation 45 January 13, 2012 12:38
Error with Wmake skabilan OpenFOAM Installation 3 July 28, 2009 00:35
OpenFOAM on MinGW crosscompiler hosted on Linux allenzhao OpenFOAM Installation 127 January 30, 2009 19:08
G95 + CGNS Bruno Main CFD Forum 1 January 30, 2007 00:34


All times are GMT -4. The time now is 12:45.