[PorscheGTIII]

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

[crixman]

That would be an interesting solver to develop, did anyone tried to compile it?

[crixman]

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!

[PorscheGTIII]

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.

[crixman]

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!

[PorscheGTIII]

I sent you a PM with my e-mail. Thank you!

[crixman]

Did you get it? how is it going?

[PorscheGTIII]

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]

One thing I did manage to figure out was why I kept getting the error:

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

[crixman]

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?

[PorscheGTIII]

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:

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:

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]

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

[PorscheGTIII]

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:

/*--------------------------------*- 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;
// }

// ************************************************************************* //

[crixman]

Did you check the difference between AMG and BiCGStab for Up?

[PorscheGTIII]

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]

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.

[crixman]

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

[be_inspired]

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

[crixman]

be_inspired, if you could couple it with pimpleDyMFoam that would be great.
PorscheGTIII, could you send the solver to be_inspired?

[c_dowd]

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.