Compressor Simulation using rhoPimpleDyMFoam

RodriguezFatz · November 11, 2014, 04:39

Hey jetfire, maybe we can speed up this a little. If you want that,
1) post some log output (one time step is enough)
2) how do you decompose?
3) post your current solver settings (fvSolution)

Tobi · November 11, 2014, 04:58

Quote:

Originally Posted by Jetfire

Hi,
Sorry for the late reply , i was not at the work station

for the rhomin/max , with reference to the air properties at atmospheric pressure in the link http://www.engineeringtoolbox.com/ai...ies-d_156.html
I think my rhomin/max should not exceed the limits 0.524/2.793. But looking at the output there are timeSteps deviating from this for example.

Code:

CALCULATED density
rhoEqn max/min : 2.15688 0.182153 . . 
GAMG:  Solving for p, Initial residual = 1.49854e-09, Final residual = 1.49854e-09, No Iterations 0  
ALL CELLS WHICH ARE NOT WITHIN THE DENSITY INTERVAL THAT YOU SET ARE BOUNDED AND THEN:
rho max/min : 2 0.5

Why is this happening ? any idea.

Please notice that in 300.000 rpm your pressure is not 1bar ...
The density changes due to pressure too! Can you check which pressure you will have in between your blades? I dont know which model you are using but the ideal gas rule is:

$p \cdot V = m \cdot R_s \cdot T$

$\rho = \frac{m}{V}$
means its proportional to

$\rho \sim \frac{p}{T}$

p = konst, and T increase --> rho decrease (like your table) and vice versa

p increase and T constant --> rho increase and vice versa

p and T not constant - depend on the ratio

As I expect, your rotor gives a high partial vacuum -> very small densities!
That is the reason (in my opinion) why your density is in that range. Therefor you should decrease your rhoMin to 0.1 or whatever.

vasava · November 11, 2014, 05:02

@Tobi: Thanks for the clarification.

Jetfire · November 11, 2014, 05:24

@Tobi,

Thanks for the tips to speeden up my simulation, I will try implementing them and let you know the results.

Can you message me your email id , i will send my output log file to you. Cannot post it here as it is exceeding max file size.

Tobi · November 11, 2014, 05:29

Quote:

Originally Posted by RodriguezFatz

Hey jetfire, maybe we can speed up this a little. If you want that,
1) post some log output (one time step is enough)
2) how do you decompose?
3) post your current solver settings (fvSolution)

Its sufficient if you post only the last time step with all pimple loops like Philipp told. As you see we both had the same thoughts

Jetfire · November 11, 2014, 05:36

Quote:

Originally Posted by RodriguezFatz

Hey jetfire, maybe we can speed up this a little. If you want that,
1) post some log output (one time step is enough)
2) how do you decompose?
3) post your current solver settings (fvSolution)

1. Please find the output for 2 timeSteps in attachments

2. I am using hierarchical decomposition with 8 cores.

Code:

numberOfSubdomains 8;

method          hierarchical;

hierarchicalCoeffs
{
    n               (2 2 2);
    delta           0.001;
    order           xyz;
}

3. FvSolution

Code:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.3.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver           GAMG;
        smoother         GaussSeidel;
        cacheAgglomeration on;
        agglomerator     faceAreaPair;
        nCellsInCoarsestLevel 100;
        mergeLevels      1;
        tolerance       1e-06;
        relTol          0.01;
    }

    pFinal
    {
        $p;
        relTol          0;
    }

    pcorr
    {
        $p;
        tolerance       1e-2;
        relTol          0;
    }

    "(rho|U|h)"
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-06;
        relTol          0.1;
    }

    "(rho|U|h)Final"
    {
        $U;
        relTol          0;
    }

    "(k|epsilon|omega)"
    {
    solver        PBiCG;
    preconditioner    DILU;
    tolerance    1e-10;
    relTol        0.1;
     }

     "(k|epsilon|omega)Final"
     {
    $k;
    relTol        0;
     }

}

PIMPLE
{
    momentumPredictor   yes;
    transonic           no;
    nOuterCorrectors    100;
    nCorrectors         2;
    nNonOrthogonalCorrectors 1;
    turbOnFinalIterOnly        false;

    rhoMin          rhoMin [ 1 -3 0 0 0 ] 0.1;
    rhoMax          rhoMax [ 1 -3 0 0 0 ] 2.5;

    residualControl
    {
        "(U|k|omega)"
         {
            tolerance 1e-05;
            relTol          0;
                 }

        p
                {
            tolerance 1e-04;
            relTol          0;
                }
    }
}

relaxationFactors
{
    fields
    {
    p    0.3;
    pFinal    1;
    }
    equations
    {
       "(U|h|k|epsilon|omega)"         0.4;
       "(U|h|k|epsilon|omega)Final"      1;
    }
}


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

Tobi · November 11, 2014, 05:40

Quote:

Originally Posted by Jetfire

2. I am using hierarchical decomposition with 8 cores.

Code:

numberOfSubdomains 8;

method          hierarchical;

hierarchicalCoeffs
{
    n               (2 2 2);
    delta           0.001;
    order           xyz;
}

That is not useful.
Please show us the output of your decomposition:

Code:

decomposePar > log

In your case, copy paste your project, decompose it again, store the output and publish it. After that you can remove your copy folder again.

fvSolution:

Code:

tolerance for U|h|rho -> 1e-9;
relTol 0.05;

nCorrectors = 1

residual control p-> 1e-5;

Was mich aber grad etwas stört ist deine Massenerhaltung:

Code:

time step continuity errors : sum local = 4.538409924e-06, global = -4.522927178e-06, cumulative = -0.002405985855

How many time steps did you calculate since now?
Please check your logfile with pyFoam (pyFoamPlotWatcher).

Additionally you can check your meshCourantNo if you insert "checkMeshCourantNo true" into the PIMPLE directory of your fvSolution. I think it is possible to increase your maxCo no to 3.

Jetfire · November 11, 2014, 05:42

I have the output of decomposePar on my terminal , here it is

Code:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  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   : decomposePar
Date   : Nov 10 2014
Time   : 16:45:40
Host   : "EAT-Standalone"
PID    : 8606
Case   : /home/eatin/OpenFOAM/eatin-2.3.0/run/tutorials/TurboCharger/Trial_run2
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



Decomposing mesh region0

Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical

Finished decomposition in 4.13 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes

Processor 0
    Number of cells = 828661
    Number of faces shared with processor 1 = 24114
    Number of faces shared with processor 2 = 10498
    Number of faces shared with processor 4 = 10485
    Number of processor patches = 3
    Number of processor faces = 45097
    Number of boundary faces = 67775

Processor 1
    Number of cells = 828661
    Number of faces shared with processor 0 = 24114
    Number of faces shared with processor 2 = 1298
    Number of faces shared with processor 3 = 6458
    Number of faces shared with processor 4 = 1879
    Number of faces shared with processor 5 = 6472
    Number of processor patches = 5
    Number of processor faces = 40221
    Number of boundary faces = 80623

Processor 2
    Number of cells = 828661
    Number of faces shared with processor 0 = 10498
    Number of faces shared with processor 1 = 1298
    Number of faces shared with processor 3 = 17656
    Number of faces shared with processor 4 = 4197
    Number of faces shared with processor 6 = 12647
    Number of faces shared with processor 7 = 715
    Number of processor patches = 6
    Number of processor faces = 47011
    Number of boundary faces = 62623

Processor 3
    Number of cells = 828661
    Number of faces shared with processor 1 = 6458
    Number of faces shared with processor 2 = 17656
    Number of faces shared with processor 7 = 6219
    Number of processor patches = 3
    Number of processor faces = 30333
    Number of boundary faces = 72641

Processor 4
    Number of cells = 828661
    Number of faces shared with processor 0 = 10485
    Number of faces shared with processor 1 = 1879
    Number of faces shared with processor 2 = 4197
    Number of faces shared with processor 5 = 15088
    Number of faces shared with processor 6 = 13676
    Number of processor patches = 5
    Number of processor faces = 45325
    Number of boundary faces = 81249

Processor 5
    Number of cells = 828661
    Number of faces shared with processor 1 = 6472
    Number of faces shared with processor 4 = 15088
    Number of faces shared with processor 6 = 2022
    Number of faces shared with processor 7 = 6375
    Number of processor patches = 4
    Number of processor faces = 29957
    Number of boundary faces = 78931

Processor 6
    Number of cells = 828661
    Number of faces shared with processor 2 = 12647
    Number of faces shared with processor 4 = 13676
    Number of faces shared with processor 5 = 2022
    Number of faces shared with processor 7 = 16593
    Number of processor patches = 4
    Number of processor faces = 44938
    Number of boundary faces = 70372

Processor 7
    Number of cells = 828661
    Number of faces shared with processor 2 = 715
    Number of faces shared with processor 3 = 6219
    Number of faces shared with processor 5 = 6375
    Number of faces shared with processor 6 = 16593
    Number of processor patches = 4
    Number of processor faces = 29902
    Number of boundary faces = 75444

Number of processor faces = 156392
Max number of cells = 828661 (0% above average 828661)
Max number of processor patches = 6 (41.17647059% above average 4.25)
Max number of faces between processors = 47011 (20.2388869% above average 39098)

Time = 0

Processor 0: field transfer
Processor 1: field transfer
Processor 2: field transfer
Processor 3: field transfer
Processor 4: field transfer
Processor 5: field transfer
Processor 6: field transfer
Processor 7: field transfer

End.

Tobi · November 11, 2014, 05:53

Hi,

Code:

Processor 1
    Number of cells = 828661
    Number of faces shared with processor 0 = 24114
    Number of faces shared with processor 2 = 1298
    Number of faces shared with processor 3 = 6458
    Number of faces shared with processor 4 = 1879
    Number of faces shared with processor 5 = 6472
    Number of processor patches = 5
    Number of processor faces = 40221
    Number of boundary faces = 80623

Processor 2
    Number of cells = 828661
    Number of faces shared with processor 0 = 10498
    Number of faces shared with processor 1 = 1298
    Number of faces shared with processor 3 = 17656
    Number of faces shared with processor 4 = 4197
    Number of faces shared with processor 6 = 12647
    Number of faces shared with processor 7 = 715
    Number of processor patches = 6
    Number of processor faces = 47011
    Number of boundary faces = 62623


Processor 7
    Number of cells = 828661
    Number of faces shared with processor 2 = 715
    Number of faces shared with processor 3 = 6219
    Number of faces shared with processor 5 = 6375
    Number of faces shared with processor 6 = 16593
    Number of processor patches = 4
    Number of processor faces = 29902
    Number of boundary faces = 75444

That is not well decomposed. As you can See its not really weighted. Other strategy would be much better, decompose your case only in x direction (if x is the length of your your pump).

Additionally after decomposing, renumbering!

Jetfire · November 11, 2014, 06:03

@Tobi

Here is my complete domain

http://www.cfd-online.com/Forums/ope...tml#post515511

Since large no. of elements are there in all 3 directions i have given '(2 2 2)' to make it 8 cores. The similar decomposition method is used for Propeller tutorial which is similar to my case. Please see the domain and let me know if i have to change the decomposition approach or change the subdomains.

RodriguezFatz · November 11, 2014, 06:41

Jetfire, did you try to use some other decomposition method? I had a very simple pipe flow and thought it is a clever idea to use "simple" decomposition. It showed low number of shared faces and all that stuff, but for some reason it was slower than just using "scotch" without any additional settings. You can just try some different methods and write down the different execution times. It's worth it for such long simulations to try a bit at the beginning.

Just a general question: Why is every time step converged to insanity? I mean, do you really get different results for these kind of problems with 30 pimple loops compared to - let's say a 3 times smaller time step and PISO solver (thus 1 outer iteration per time step)? Your Courant number is close to "1" anyway, so for stability of PISO just a slightly smaller time step would be needed. All the LES guys use PISO... is this that much different from what you are doing?

Also: Why the first pressure corrector with 60 iterations? For me, this looks like something is going utterly wrong. I think each linear solver should not take more than just a few iterations. Maybe this is again due to your solver, but please can someone elaborate this?

RodriguezFatz · November 11, 2014, 06:48

Another point is: Did you try different settings for the GAMG solver? I did this for a case of mine and found out that playing with "mergeLevels" decreased the simulation time (in my case "2" was the best). Also changing the pre,post,finest sweeps settings changed a lot:

Code:

  "(p|pFinal)"
         {
                solver           GAMG;
                tolerance        1e-12;
                relTol           0.1;

                maxIter          100;

                smoother         GaussSeidel;

                nPreSweeps       1;
                nPostSweeps      1;
                nFinestSweeps    2;

                cacheAgglomeration true;

                nCellsInCoarsestLevel 400;
                agglomerator     faceAreaPair;
                mergeLevels      2;

        }

This was the best for me.

Tobi · November 11, 2014, 07:23

Quote:

Originally Posted by RodriguezFatz

Just a general question: Why is every time step converged to insanity? I mean, do you really get different results for these kind of problems with 30 pimple loops compared to - let's say a 3 times smaller time step and PISO solver (thus 1 outer iteration per time step)? Your Courant number is close to "1" anyway, so for stability of PISO just a slightly smaller time step would be needed. All the LES guys use PISO... is this that much different from what you are doing?

I did not get the point. Co should be increase to 2 during simulation (if it is set in the controlDict), you also can set it to 3 or 4 to get bigger time steps (depend on your relax factors also). But why should he use PISO? It would be much more expensiv and maybe not stable.

Quote:

Also: Why the first pressure corrector with 60 iterations? For me, this looks like something is going utterly wrong. I think each linear solver should not take more than just a few iterations. Maybe this is again due to your solver, but please can someone elaborate this?

I dont know which time step iteration is used but at the beginning in such chases it could be normal. Sometimes I also get 100 iterations for the pressure equation. Depend on the system and I never had rpm 300.000.

If you get 1000 Iterations something is wrong.
In the pressure calculation (my experience) it could occur. But it also could be possible that the BC are wrong for that problem. However, I first should have a look at the calculation procedure in that solver but there is not time for that now.

Quote:

Since large no. of elements are there in all 3 directions i have given '(2 2 2)' to make it 8 cores. The similar decomposition method is used for Propeller tutorial which is similar to my case. Please see the domain and let me know if i have to change the decomposition approach or change the subdomains.

My hints to you:

move your mesh that the long pipe is colinear with the z-axis (transform points)

then use manuelDecomposition

If its to complex try using scotch and have a look to the meshes

@Philipp, here in our institute we get the best results with simple or hierarchical instead of scotch. The gain was round about 13% because scotch decomposed our mesh in a very strange way.

RodriguezFatz · November 11, 2014, 07:29

Quote:

Originally Posted by Tobi

I did not get the point. Co should be increase to 2 during simulation (if it is set in the controlDict), you also can set it to 3 or 4 to get bigger time steps (depend on your relax factors also). But why should he use PISO? It would be much more expensiv and maybe not stable.

Ok, the point was: Even with Co=3 or 4 and like 25 outer iterations I don't see a reason to use PIMPLE. In such cases, one PIMPLE time step would be like 25 PISO time steps, right? So, if you can reduce the time step by a factor of - let's say 8 - to get a Co of 0.5 and use PISO, you still have less computational time to spend. And you have a much finer time resolution.

Or is this just a matter of initialization? Does the number of PIMPLE loops decrease drastically after a few time steps?

Tobi · November 11, 2014, 07:47

Quote:

Originally Posted by RodriguezFatz

Ok, the point was: Even with Co=3 or 4 and like 25 outer iterations I don't see a reason to use PIMPLE. In such cases, one PIMPLE time step would be like 25 PISO time steps, right?

Is there a paper who say that 25 PISO steps = 1 PIMPLE loop (with 25 iterations). In my opinion its not true because you can not compare the algorithms directly.

Quote:

So, if you can reduce the time step by a factor of - let's say 8 - to get a Co of 0.5 and use PISO, you still have less computational time to spend. And you have a much finer time resolution.

You are right, the time resolution would be better. But you have to check what is necessary in your case. So lets say you want simulate 1s and your mesh is big and the system is very stiff you. Therefor you have to set Co to (lets say) 0.3 to be stable. Therefor you will get a dT = 1e-9 which is very bad in that case. Also if there is one cell which makes trouble, this cell would reduce the whole time step, maybe to 1e-11 till it will crash. With relaxation you can handle this better.

well you are right you are more accurate in time

But if you have some problem cells that will reduce the time to 1e-11 its bad.

Quote:

Or is this just a matter of initialization? Does the number of PIMPLE loops decrease drastically after a few time steps?

It is definitiv also an initialization and boundary problem. If the boundary are bad defined or wrong, all algorithm will blow up or crash. The outer iterations will decrease during time steps. Sometimes I have loops like 80 at the beginning and after a few timesteps I get 8 - 10 and my timestep is much bigger than PISO. The computational costs decrease and the linear system is stable due to under-relaxation.

If there would be no advantage of PIMPLE compared to PISO then nobody would use PIMPLE.

RodriguezFatz · November 11, 2014, 07:56

Quote:

Originally Posted by Tobi

If there would be no advantage of PIMPLE compared to PISO then nobody would use PIMPLE.

I got the feeling that he doesn't use the advantage of PIMPLE if he iterates more often than the number of PISO steps he actually needs if he reduces the time step. This is just an educated guess, I never tryed it.

Tobi · November 11, 2014, 08:56

He also can try something like that:

nOuterCorrection 3;
nCorrections 2;

Then the first 2 iterations are relaxed and the last one is without relaxation. But this could give stability problems because its relativ similar to PISO then but with 2 relaxation iterations. I am not sure if this case is working without relaxation. He can also switch to PISO again but then he should use maxCo 0.1 - 0.7 but not 1.

I can not test the case because I do not have it (:

Tobi · November 11, 2014, 10:26

Question: are you using the boundary condition which you attached in this post: http://www.cfd-online.com/Forums/ope...tml#post516087

The reason why I ask is due to the U - file, if it is like that you have an error which could be the reason of the pcorr iteration.

Quote:

Originally Posted by RodriguezFatz

I got the feeling that he doesn't use the advantage of PIMPLE if he iterates more often than the number of PISO steps he actually needs if he reduces the time step. This is just an educated guess, I never tryed it.

That could be possible. I will check if I find some papers about that.

Jetfire · November 11, 2014, 23:06

Hi,

Bad news , Simulation crashed showing the same error as posted earlier after few timeSteps. check the output in attachments

Is this problem related to my thermoPhysicalProperties ? should I change my thermoPhysical settings?

Jetfire · November 11, 2014, 23:12

Quote:

Originally Posted by Tobi

Question: are you using the boundary condition which you attached in this post: http://www.cfd-online.com/Forums/ope...tml#post516087

The reason why I ask is due to the U - file, if it is like that you have an error which could be the reason of the pcorr iteration.

That could be possible. I will check if I find some papers about that.

@Tobi do not refer to those boundary conditions, those were from annular thermal mixer tutorial, I am attaching my final 0 folder for your reference, do let me know if you need any other details.

November 11, 2014, 04:39		#61
RodriguezFatz Senior Member Philipp Join Date: Jun 2011 Location: Germany Posts: 1,297 Rep Power: 26	Hey jetfire, maybe we can speed up this a little. If you want that, 1) post some log output (one time step is enough) 2) how do you decompose? 3) post your current solver settings (fvSolution) Tobi likes this. __________________ The skeleton ran out of shampoo in the shower.

November 11, 2014, 06:41		#71
RodriguezFatz Senior Member Philipp Join Date: Jun 2011 Location: Germany Posts: 1,297 Rep Power: 26	Jetfire, did you try to use some other decomposition method? I had a very simple pipe flow and thought it is a clever idea to use "simple" decomposition. It showed low number of shared faces and all that stuff, but for some reason it was slower than just using "scotch" without any additional settings. You can just try some different methods and write down the different execution times. It's worth it for such long simulations to try a bit at the beginning. Just a general question: Why is every time step converged to insanity? I mean, do you really get different results for these kind of problems with 30 pimple loops compared to - let's say a 3 times smaller time step and PISO solver (thus 1 outer iteration per time step)? Your Courant number is close to "1" anyway, so for stability of PISO just a slightly smaller time step would be needed. All the LES guys use PISO... is this that much different from what you are doing? Also: Why the first pressure corrector with 60 iterations? For me, this looks like something is going utterly wrong. I think each linear solver should not take more than just a few iterations. Maybe this is again due to your solver, but please can someone elaborate this? __________________ The skeleton ran out of shampoo in the shower.

November 11, 2014, 06:48		#72
RodriguezFatz Senior Member Philipp Join Date: Jun 2011 Location: Germany Posts: 1,297 Rep Power: 26	Another point is: Did you try different settings for the GAMG solver? I did this for a case of mine and found out that playing with "mergeLevels" decreased the simulation time (in my case "2" was the best). Also changing the pre,post,finest sweeps settings changed a lot: Code: "(p\|pFinal)" { solver GAMG; tolerance 1e-12; relTol 0.1; maxIter 100; smoother GaussSeidel; nPreSweeps 1; nPostSweeps 1; nFinestSweeps 2; cacheAgglomeration true; nCellsInCoarsestLevel 400; agglomerator faceAreaPair; mergeLevels 2; } This was the best for me. __________________ The skeleton ran out of shampoo in the shower.

November 11, 2014, 08:56		#77
Tobi Super Moderator Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51	He also can try something like that: nOuterCorrection 3; nCorrections 2; Then the first 2 iterations are relaxed and the last one is without relaxation. But this could give stability problems because its relativ similar to PISO then but with 2 relaxation iterations. I am not sure if this case is working without relaxation. He can also switch to PISO again but then he should use maxCo 0.1 - 0.7 but not 1. I can not test the case because I do not have it (: __________________ Keep foaming, Tobias Holzmann

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Study of the EEqn.H in rhoPimpleDyMFoam.	Horacio Aguerre	OpenFOAM Programming & Development	11	August 19, 2022 02:47
Developing a rhoPimpleDyMFoam solver	bvieira	OpenFOAM Programming & Development	20	October 9, 2014 12:12
rhoPimpleDymFoam	jvd.mechanic	OpenFOAM Running, Solving & CFD	0	June 15, 2014 05:20
Divergence in rhoPimpleDyMFoam	bvieira	OpenFOAM Running, Solving & CFD	1	July 19, 2012 02:22

November 11, 2014, 05:02		#63
vasava Senior Member Paritosh Vasava Join Date: Oct 2012 Location: Lappeenranta, Finland Posts: 732 Rep Power: 22	@Tobi: Thanks for the clarification.

November 11, 2014, 05:24		#64
Jetfire Member Abhijit Join Date: Jul 2014 Posts: 75 Rep Power: 11	@Tobi, Thanks for the tips to speeden up my simulation, I will try implementing them and let you know the results. Can you message me your email id , i will send my output log file to you. Cannot post it here as it is exceeding max file size.

November 11, 2014, 06:03		#70
Jetfire Member Abhijit Join Date: Jul 2014 Posts: 75 Rep Power: 11	@Tobi Here is my complete domain http://www.cfd-online.com/Forums/ope...tml#post515511 Since large no. of elements are there in all 3 directions i have given '(2 2 2)' to make it 8 cores. The similar decomposition method is used for Propeller tutorial which is similar to my case. Please see the domain and let me know if i have to change the decomposition approach or change the subdomains.