
[Sponsors] 
[swak4Foam] swak4foam 0.4.2, groovyBC parallel diverging, openfoam extend 4.0 

LinkBack  Thread Tools  Search this Thread  Display Modes 
November 22, 2020, 13:41 
swak4foam 0.4.2, groovyBC parallel diverging, openfoam extend 4.0

#1 
New Member
Artem
Join Date: Apr 2014
Posts: 29
Rep Power: 10 
Dear all,
I am using openfoamextend 4.0 and swakfoam 0.4.2. Recently, I faced a problem with the parallel using of the groovyBC feature. I have the following boundary condition for the scalar value (electrical potential): Code:
MENISCUS { type groovyBC; gradientExpression "normal()&(U^B0)"; fractionExpression "0"; value uniform 0; } Code:
Courant Number mean: 0 max: 0.323067 velocity magnitude: 0.637633 Time = 0.0005 PIMPLE: iteration 1 BiCGStab: Solving for Ux, Initial residual = 1, Final residual = 1.14672e12, No Iterations 2 BiCGStab: Solving for Uy, Initial residual = 1, Final residual = 3.16692e12, No Iterations 2 BiCGStab: Solving for Uz, Initial residual = 1, Final residual = 1.33198e12, No Iterations 2 GAMG: Solving for p, Initial residual = 1, Final residual = 0.00978763, No Iterations 370 time step continuity errors : sum local = 6.24569e08, global = 9.6658e09, cumulative = 9.6658e09 GAMG: Solving for p, Initial residual = 0.0240702, Final residual = 9.83996e07, No Iterations 244 time step continuity errors : sum local = 1.4049e09, global = 3.13278e10, cumulative = 9.97908e09 bounding k, min: 1.27743 max: 1.04867 average: 5.39138e05 swak4Foam: Allocating new repository for sampledGlobalVariables GAMG: Solving for PotE, Initial residual = 1, Final residual = 8.72425e07, No Iterations 119 ExecutionTime = 106.58 s ClockTime = 106 s Code:
Courant Number mean: 0 max: 0.323067 velocity magnitude: 0.637633 Time = 0.0005 PIMPLE: iteration 1 BiCGStab: Solving for Ux, Initial residual = 1, Final residual = 1.9242e08, No Iterations 2 BiCGStab: Solving for Uy, Initial residual = 1, Final residual = 2.27917e08, No Iterations 2 BiCGStab: Solving for Uz, Initial residual = 1, Final residual = 2.98058e08, No Iterations 2 GAMG: Solving for p, Initial residual = 1, Final residual = 0.00964027, No Iterations 352 time step continuity errors : sum local = 6.15166e08, global = 1.67908e08, cumulative = 1.67908e08 GAMG: Solving for p, Initial residual = 0.024065, Final residual = 9.83998e07, No Iterations 228 time step continuity errors : sum local = 1.40527e09, global = 5.68618e10, cumulative = 1.73594e08 bounding k, min: 1.27755 max: 1.04845 average: 5.3917e05 [0] swak4Foam: Allocating new repository for sampledGlobalVariables [1] swak4Foam: Allocating new repository for sampledGlobalVariables [2] swak4Foam: Allocating new repository for sampledGlobalVariables [3] swak4Foam: Allocating new repository for sampledGlobalVariables GAMG: Solving for PotE, Initial residual = 1, Final residual = 344.02, No Iterations 1000 ExecutionTime = 111.69 s ClockTime = 112 s 1. The simulation works without groovyBC in both parallel/single mode. 2. The simulation works with groovyBC in a single mode. 3. The simulation doesn't work with groovyBC in a parallel mode. Did anybody encounter the same problem? Thank you very much in advance. Regards, Artem 

November 22, 2020, 21:09 

#2  
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 50 
Quote:
Usually groovyBC works in parallel without problems and that expression should be unproblematic because it is purely local. I know it is not good manners to try to shift the blame but could you check 2 things:
__________________
Note: I don't use "Friend"feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request 

November 23, 2020, 05:51 

#3  
New Member
Artem
Join Date: Apr 2014
Posts: 29
Rep Power: 10 
Quote:
Thank you for your answer and for your hints. I checked the other solvers and it seems that BiCGStab and PCG indeed work with groovyBC in a parallel mode, though they are much slower than GAMG (now it takes 1500 iteration in order to achieve tolerance e7). Regarding decomposition  I use a simple method and 4 processors. Code:
numberOfSubdomains 4; method simple; simpleCoeffs { n (1 1 4); delta 0.001; } May I ask you if it is possible to use GAMG with groovyBC in a parallel mode? This will be approx. twice faster for my simulation. I tried to change a smoother and nCellsInCoarsestLevel in GAMG settings but it did not change anything, as expected. Code:
solver GAMG; tolerance 1e06; relTol 0.0; smoother GaussSeidel; cacheAgglomeration true; nCellsInCoarsestLevel 500; agglomerator faceAreaPair; mergeLevels 1; Artem 

November 23, 2020, 09:40 

#4  
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 50 
Quote:
I'm afraid the problem is not groovyBC. It is the (physical) boundary condition in combination with AMG: I'm pretty sure that if you coded the same boundary condition in C++ it will fail in a similar way The problem is probably the way AMG works: it lumps together cells to get a coarser mesh. Solves on that and uses the solution as a starting point for the finer mesh. That works fine if inside the cell groups values don't change to fast (but for instance if the cell group has some kind of boundary layer then then this is broken). With parallel cases things become worse because the algorithm can only grop cells from one processors and therefore can't collect cells that it would have collected before Sorry. But that is where my wisdom ends. Maybe somebody with more knowledge about GAMG can help you (also: how old are your OFsources? Maybe that problem was already addressed in foamextend 4.1)
__________________
Note: I don't use "Friend"feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request 

November 24, 2020, 09:42 

#5  
New Member
Artem
Join Date: Apr 2014
Posts: 29
Rep Power: 10 
Quote:
It seems that there is definitely a problem below groovyBC, I tested different things and found that setReference works strange after the decomposition in foam extend 4.0, that in turn also contributes to divergence. Anyway, I did a workaround  I just added into my solver a piece of code for updating the necessary boundary condition as it could be done in the same manner by groovyBC. So fat this fix works, even with GAMG solver. Here is the code for those who can have the same problem, just replace "MENISCUS" with your patch name and change the PotE and my expressions for your boundary variable and expression: Code:
//This file describes dynamic boundary conditions //Find a patch for the dynamic boundary condition label patchID = mesh.boundaryMesh().findPatchID("MENISCUS"); if(patchID == 1) { FatalError << "Slip patch not found!" << exit(FatalError); } //Define the class off the boundary condition fixedGradientFvPatchScalarField& PotEpatch = refCast<fixedGradientFvPatchScalarField> ( PotE.boundaryField()[patchID] ); //Calculate the patch normal const vectorField nf = PotEpatch.patch().nf(); //Calculate the boundary condition forAll(PotEpatch, faceI) { vector UB = U.boundaryField()[patchID][faceI] ^ B0.boundaryField()[patchID][faceI]; PotEpatch.gradient()[faceI] = UB & nf[faceI]; } Regards, Artem 

Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
[swak4Foam] undefined symbols in .so libraries when compiling swak4foam 0.4.2 on foam extend 4.1  mAlletto  OpenFOAM Community Contributions  3  August 29, 2018 07:02 
OpenFOAM 4.0 Released  CFDFoundation  OpenFOAM Announcements from OpenFOAM Foundation  2  October 6, 2017 06:40 
OpenFOAM Training JanJul 2017, Virtual, London, Houston, Berlin  CFDFoundation  OpenFOAM Announcements from Other Sources  0  January 4, 2017 07:15 
OpenFOAM Training, London, Chicago, Munich, Houston 20162017  cfd.direct  OpenFOAM Announcements from Other Sources  0  September 14, 2016 04:19 
Superlinear speedup in OpenFOAM 13  msrinath80  OpenFOAM Running, Solving & CFD  18  March 3, 2015 06:36 