[Stylianos]

I'm having a problem with at segmentation fault in turbDyMFoam (also tried icoDyMFoam and got a segmentation fault).
I'm attempting an unsteady rotor-stator computation with Ggi interface. I followed all the steps of the mixerGgi tutorial (setSet , setsToZones and everything) but my computation crashes with a segmentation fault.

Here is the message i get.
--------------
Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh mixerGgiFvMesh
void mixerGgiFvMesh::addZonesAndModifiers() : Zones and modifiers already present. Skipping.
Mixer mesh:
origin: (0 0 0)
axis : (0 0 1)
rpm : -1599.98
Reading field p

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches: SP_LOWP/RUNNERGGI
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 0.00907747 average: 0.000142083
Largest master weighting factor correction: 0.00440734 average: 5.53368e-05

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
Reading field rAU if present


Starting time loop

Courant Number mean: 0.000467676 max: 0.375233 velocity magnitude: 2
deltaT = 7.99503e-06
Time = 7.99503e-06

Segmentation fault


Stelios

[flo]

I have the same pb about segmentation fault (using either icoDynMFoam or turbDynMFoam).
Any ideas ?
Thanks,
Flo

[NickG]

Do you have enough memory for the job?

[Stylianos]

Yes only 25% of the memory is used (using top).

[flo]

Yes, I have enough memory.
I also tried to decompose the case and I still have segmentation fault....

[NickG]

The next line should be:-
Initializing the GGI interpolator between master/shadow patches: <names of patches>

so I'd check that they're set up correctly

[flo]

Hi NickG,
the line Initializing the GGI interpolator between master/shadow patches: <names of patches>
is before the segmentation fault.
I got segmentation fault after starting time loop ... Time = 0

[Stylianos]

Hello Nick
I'm also send you the setBatch and boundary files of my case, maybe its a simple mistake there and not in the solver it self.

setBatch:
faceSet SP_LOWP_ZONE new patchToFace SP_LOWP
faceSet RUNNERGGI_ZONE new patchToFace RUNNERGGI
quit

boundary:

12
(

SP_HIGHP
{
type patch;
nFaces 1017;
startFace 17352154;
}

SP_LOWP
{
type ggi;
shadowPatch RUNNERGGI;
bridgeOverlap false;
zone SP_LOWP_ZONE;
nFaces 17350;
startFace 17353171;
}
SP_WALL
{
type wall;
nFaces 143896;
startFace 17370521;
}

STAY
{
type wall;
nFaces 49852;
startFace 17514417;
}
GUIDE
{
type wall;
nFaces 45575;
startFace 17564269;
}

INLET
{
type patch;
nFaces 23520;
startFace 17609844;
}
RU-BLADE
{
type wall;
nFaces 67424;
startFace 17633364;
}

RU-BLADE
{
type wall;
nFaces 67424;
startFace 17633364;
}
RU-HUB
{

type wall;
nFaces 36344;
startFace 17700788;
}
RU-HUBIN
{
type wall;
nFaces 10080;
startFace 17737132;
}
RU-SHROUD
{
type wall;
nFaces 36344;
startFace 17747212;
}
RU-SHROUDIN
{
type wall;
nFaces 10080;
startFace 17783556;
}
RUNNERGGI
{
type ggi;
shadowPatch SP_LOWP;
bridgeOverlap false;
zone RUNNERGGI_ZONE;
nFaces 21952;
startFace 17793636;
}
)

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



Thanks for your time
Stelios

[NickG]

hi flo
I'm just going on what Stylianos wrote but I think it's the same problem if it's coming after e.g.:

Courant Number mean: 0.000467676 max: 0.375233 velocity magnitude: 2
deltaT = 7.99503e-06
Time = 7.99503e-06

Segmentation fault

(you'd have Time = 0)
although I have: Creating ggi check
between deltaT and Time but then it goes on to
Initializing the GGI interpolator between master/shadow patches: InterT/InterR
which I think is where your problem is.

Do you have:
ggiCheck
{
// Type of functionObject
type ggiCheck;

phi phi;

// Where to load it from (if not already in solver)
//functionObjectLibs ("libsampling.so");
}
at the bottom of your controlDict? - before the final );

[NickG]

a quick thing to try is to change bridgeOverlap to true but I'm not sure that this would cause the error you're getting

[Stylianos]

Hi Nick ..

I've tried both (adding the ggiCheck at the end of my controlDict and setting bridgeOverlap to true) bu i still get the same segmentation fault. :/

I gave a fast look in the code and i think that the problem is somewhere near "bool meshChanged = mesh.update();" but i'm not that experienced yet to know how to debug further !

Stelios

[NickG]

I'm afraid that it's beyond me too

Sorry

[Stylianos]

No worries Nick and thanks for your time.
I'll keep digging it and if i find something i'll post it here .

p.s. in the mean time if someone has any ideas please help

[Stylianos]

I think i found what my mistake was. It seems the name of the rotating domain in cellZones is hardcoted in the code as movingCells.

So you just have to go in constant/polymesh/cellZones and rename the whatever name of your rotating domain into movingCells.

Stelios

[flo]

Hi,
I changed the bridgeOverlap to true and it works now. Physically, I have node to node interface so it should be "bridgeOverlap wrong" but now it works...
Thanks,
Flo

[Stylianos]

Hello Flo
I've also have bridgeOverlap set to true in my case and i would like to ask you if yours works without having to hack cellZones. I'm creating a new case now and would like to keep it as clean as possible .

Stelio

[flo]

Hi Stelio,
No, I have to modify the cellZones file.
Flo

[JulytoNovember]

Inside the dynamicMeshDict in the directory src/dynamicFvMesh/dynamicRefineFvMesh on line 29 the dynamicFvMeshLib was commented, uncomment this line and recompile just to be safe, and it may help, it did for me.

[ericnutsch]

Originally Posted by Stylianos

It seems the name of the rotating domain in cellZones is hardcoded in the code as movingCells.

Nice find Stelios. It works

[aldo.iannetti]

hi foamers,
I'm studing a vertical axis wind turbine 2D, I have an internal-rotational zone and an external-static zone and the interfaces have been modelled as GGI.
I have problem using turbDyMFoam and GGI, turning on turbulence model I have floating point error. As mixer GGI tutorial I set U e p boundary conditions on the sliding GGI:
{
type ggi;
value uniform (0 0 0);
}

{
type ggi;
value uniform 0;
}
I'm not sure about that, I have the same doubt for the k-epsilon boundary conditions.
Can you please explane me the correct boundary condition?
thanks
Aldo