[bigphil]

Hi Hojatollah,

I suggest you try the case in solids4Foam; maybe whatever the issue is, it has been fixed.

Kind regards,
Philip

[Hgholami]

I also check the geometry with solids4Foam and the issue still exist. It seen the problem is from Ggi class.
the geometry is work correctly with cyclic condition but it can't run with cyclicGgi.

Originally Posted by bigphil

Hi Hojatollah,

I suggest you try the case in solids4Foam; maybe whatever the issue is, it has been fixed.

Kind regards,
Philip

[bigphil]

Can you attach a small simple example case showing the problem?

Philip

[Hgholami]

Dear Philip
the attachment is a simple case for foam-extend4.0 and solids4Foam solver.

http://uupload.ir/view/i0vb_simplecyclicggicase.zip/ fileSize:4.1 Mb
or
https://gofile.io/?c=XNJhb1
or
https://filebin.net/vstxf2bco1ts6xbd...zip?t=ag494xny

Originally Posted by bigphil

Can you attach a small simple example case showing the problem?

Philip

[bigphil]

Hi,

In the case, you did not define the top and bottom patches as cyclicGgi in the polyMesh/boundary file (as described earlier in this post) e.g.

top
{
    type            cyclicGgi;
    nFaces          200;
    startFace       27345;
    shadowPatch     bottom;
    zone            topZone;
    bridgeOverlap   false;
    rotationAxis    (0 0 1);
    rotationAngle   0;
    separationOffset (0 -0.05 0);
}

bottom
{
    type            cyclicGgi;
    nFaces          200;
    startFace       27545;
    shadowPatch     top;
    zone            bottomZone;
    bridgeOverlap   false;
    rotationAxis    (0 0 1);
    rotationAngle   0;
    separationOffset (0 0.05 0);
}

Once this is defined, the solver seems to run.

Philip

[Hgholami]

Hi ,
In zip file, I modified polyMesh/boundary file by hand (without ./Allrun) as bellow:

7
(
inlet
{
type patch;
nFaces 50;
startFace 27295;
}

top
{
type cyclicGgi;
nFaces 200;
startFace 27345;
shadowPatch bottom;
zone topZone;
bridgeOverlap off; //or false
rotationAxis (0 0 1);
rotationAngle 0;
separationOffset (0 -0.05 0);

}

bottom
{
type cyclicGgi;
nFaces 200;
startFace 27545;
shadowPatch top;
zone bottomZone;
bridgeOverlap off; //or false
rotationAxis (0 0 1);
rotationAngle 0;
separationOffset (0 0.05 0);
}
...

It seen same as your code, but my problem is

...
Time = 0.001, iteration: 1
Modes before clean-up : 0, modes after clean-up : 0
Current fsi under-relaxation factor: 0.05
Creating accumulated fluid interface displacement
Maximal accumulated displacement of interface points: 0
GAMG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 1
GAMG: Solving for cellMotionUy, Initial residual = 0, Final residual = 0, No Iterations 1
GAMG: Solving for cellMotionUx, Initial residual = 0, Final residual = 0, No Iterations 1
GAMG: Solving for cellMotionUy, Initial residual = 0, Final residual = 0, No Iterations 1


--> FOAM FATAL ERROR:
Attempting to create reconFaceCellCentres on a shadow

From function void ggiPolyPatch::calcReconFaceCellCentres() const
in file meshes/polyMesh/polyPatches/constraint/ggi/ggiPolyPatch.C at line 303.

FOAM aborting

Aborted (core dumped)

I don;t understand, where is problem? Is it work in your PC?

Originally Posted by bigphil

Hi,

In the case, you did not define the top and bottom patches as cyclicGgi in the polyMesh/boundary file (as described earlier in this post) e.g.

top
{
    type            cyclicGgi;
    nFaces          200;
    startFace       27345;
    shadowPatch     bottom;
    zone            topZone;
    bridgeOverlap   false;
    rotationAxis    (0 0 1);
    rotationAngle   0;
    separationOffset (0 -0.05 0);
}

bottom
{
    type            cyclicGgi;
    nFaces          200;
    startFace       27545;
    shadowPatch     top;
    zone            bottomZone;
    bridgeOverlap   false;
    rotationAxis    (0 0 1);
    rotationAngle   0;
    separationOffset (0 0.05 0);
}

Once this is defined, the solver seems to run.

Philip

[bigphil]

OK, I didn't realise I should not use the Allrun script.

When I run it on my computer, it continues to run and does not give an error.

From examining the solution in the written time-steps, the inlet velocity condition does not seem correct (unlelated to cyclicGgi) so I then changed it to fixedValue with (3 0 0) and then the p and U fields looked reasonable.

I was using the development branch of solids4Foam (commit: 9b06f42) but I think the master should be almost the same, and foam-extend-4.0 (commit: 246a172c9).

Philip

[Hgholami]

As you noted, I realize that the case study running continues in your computer without error. I checked the Turek&Hron benchmark with cyclicGgi in my PC and it work good. But for the case study, it take error in both fsiFoam and solids4Foam solvers.

I uses last solids4Foam in bitBucket. and the foam-extend-4.0 from https://github.com/Unofficial-Extend...oam-extend-4.0.
I think the problem comes from foam-extend's ggi but still confuse why in my PC. Can you give me your foam-extend-4.0 (commit: 246a172c9) for downloading and testing it?

Originally Posted by bigphil

OK, I didn't realise I should not use the Allrun script.

When I run it on my computer, it continues to run and does not give an error.

From examining the solution in the written time-steps, the inlet velocity condition does not seem correct (unlelated to cyclicGgi) so I then changed it to fixedValue with (3 0 0) and then the p and U fields looked reasonable.

I was using the development branch of solids4Foam (commit: 9b06f42) but I think the master should be almost the same, and foam-extend-4.0 (commit: 246a172c9).

Philip

[bigphil]

I was able to reproduce your error by using a more recent commit of foam-extend-4.0.

The foam-extend-4.0 commit that does not give an error (though I have not checked if the results are correct) is:
246a172c9d9ecdbfc8f18b8224467de7f2b7606e

A more recent foam-extend-4.0 commit that gives the error is: 10298020aac73b7f4b194c0369669c07325eb438

By using "git diff" to compare the commits (git diff 246a172c9d9ecdbfc8f18b8224467de7f2b7606e.. 10298020aac73b7f4b194c0369669c07325eb438 -- $FOAM_SRC), I can see that some code has changed in the GGI classes.

So I suggest one/both of the following:

• Run your code in debug mode and through a debugger and find where the error is coming from i.e. what class; hopefully, this will tell where the problem is and how to fix it
• Check that the older commit above works for you and compare the code between the two commits above and see if you can find what the problem is

Philip

[Hgholami]

Dear Philip
Thanks for your reply.
I do your recommends. First I use debugSwitches for ggiInterpolation, ggi, cyclicggi, but It can't help me to recognize problem base. The attachment is log of it.
Second, I change src folder of my current foam-extend4.0 with src folder of commit 246a172c9d9ecdbfc8f18b8224467de7f2b7606e. But another error occur as:

Selecting physicsModel fluidSolidInteraction

Selecting fluidSolidInterface method IQNILS

Selecting fluidModel icoFluid
Selecting dynamicFvMesh dynamicMotionSolverFvMesh
ggiPolyPatch::calcRemoteZoneAddressing() const for patch top
Initializing the GGI interpolator between master/shadow patches: top/bottom

From function void ggiPolyPatch::calcPatchToPatch() const
in file meshes/polyMesh/polyPatches/constraint/ggi/ggiPolyPatch.C at line 211
Calculating patch to patch interpolation for patchtop


--> FOAM FATAL ERROR:
Addressing already calculated

From function void GGIInterpolation<MasterPatch, SlavePatch>::calcAddressing() const
in file /home/itp/foam/foam-extend-4.0/src/foam/lnInclude/GGIInterpolationWeights.C at line 104.

FOAM aborting

Aborted (core dumped)

This error also occur for Turek & Hron benchmark.

[hand90]

Hi everyone

This is probably going to be a very silly question but how do I define the faceZones?

I have imported a mesh of a 3D blade passage from ICEM with defined patches: Inlet, Outlet, Side1 (empty), Side2 (empty), SYM1 and SYM2.
Now I was able to run the simulation in a different OF version using cyclicAMI. However I am trying to use foam-extend 4.0 where I only have cyclicGgi available.

When the mesh is imported I have the following folders in polyMesh: boundary, cellZones, faces, faceZones, neighbour, owner, points,pointZones. Within the folder faceZones I do have 4 different zones, however they belong to different volume parts in the mesh and the periodic boundaries (SYM1 and SYM2) stretch through all zones.

Does anyone have a suggestion?

[bigphil]

You can use setSet and setsToZones.

Note: you may want to remove the old zones first i.e. rm -rf constant/polyMesh/faceZones.

Then use setSet and setsToZones:

$> setSet

readline>faceSet SYM1 new patchToFace SYM1
readline>faceSet SYM2 new patchToFace SYM2
readline>quit

$> setsToZones -noFlipMap

Philip

[hand90]

Dear Philip

This worked a perfectly. Thank you so much for that quick answer!
I applied that to two simulation setups I have (different mesh). In one it worked without an error and in the other simulation I got the following error:

Found uncovered faces for GGI interface SYM1/SYM2 while the bridgeOverlap option is not set in the boundary file.
This is an unrecoverable error. Aborting.

But by changing bridgeOverlap to "True" it was solved.
I am not fully sure why there seems to be uncovered faces as the simulation did run before hand with cyclicAMI.

Many thanks again

[bigphil]

The uncovered faces error says that your two cyclic patches do not fully overlap (to some built-in tolerance), possibly this could be due to an incorrectly prescribed transformation in the "boundary" file. Either way, it is a good idea to check the solution fields on both patches when you run your case to see if they are consistent.

[Hgholami]

Dear foamer
In previous problem, I checked a lot of commits, that not work correctly. In another try, I use DebugSwitches in controlDict

DebugSwitches
{
cyclicGgi 2;
ggi 2;
}

and write some Info in calcReconFaceCellCentres class.
The results show that, the solver selects correctly master patch as "top" and shadow patch as "bottom" and start running.
But after calculating pointMotionU, the calcReconFaceCellCentres class again called and after selecting top patch, go to selecting bottom patch. As the bottom patch isn't master, so the -->

FOAM FATAL ERROR:
Attempting to create reconFaceCellCentres on a shadow

occurs. As my test, it seen this problem usually appears in problem with more than a interface (should note: In fsiFoam, multiInterface merged as single Interface).
As the pointMotionU can't has boundary as cyclicGgi, so it defined as fixedValue; and If we use any others solver without calculating dynamic Motion is work correctly. So, it seen error comes from pointMotion. But how?