Rotor-stator computation with Ggi interface (turbDyMFoam)
 

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

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

Do you have enough memory for the job?

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

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

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

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

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

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 );

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

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

I'm afraid that it's beyond me too

Sorry

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 :)

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

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

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

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

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.

Kudos
 

Nice find Stelios. It works :)

turbdymfoam & GGI
 

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

Hello Aldo,

Me too! Sounds like we are at about the same stage of testing as well.


So does your ggi model work without the turbulence model?
I have gotten a k-e turbulence model to work with the ggi. Once I know more specifically where your hung up I can help.

Im in the process of testing the ggi interface with the turbulence model and so far so good.


Ive signed an NDA on the VAWT design, but I would certainly like to correspond on our solving methods; ericnutsch@gmail.com

Hi Aldo

I don't bother to specify a value for any of the /0/ files - just: type ggi;

The important part is specifying correct values for k and epsilon (or omega)

My understanding is that you set the internalField as:

for k:

1.5(magUI)^2 where magU is the magnitude of the velocity
I is the turbulence intensity

for epsilon:

(Cmu^0.75)(k^1.5)/L where Cmu =0.09 (see /constant/RASProperties)
k is worked out through previous
L is the characteristic length that you'd use for the Reynolds number

for omega if you need it later:

(Cmu^-0.25)(k^0.5)/L

Good luck! Let us know if it works

Nick

GGI for HAWT
 

Hi all,

i'm simulating the propeller of an HAWT using GGI / turbDyMFoam, and i'm quite surprised that the wake of my blades is almost unexisting (e.g. no wing-tip structures) for a lambda of around 7 (lambda = Vwingtip / Vinf)...

Could you please briefly share your experience on GGI for simulating WT?
- Which turbulence model are you using?
- Which BC on the rotating elements?
- Which lambda?
- Which level of initial / inlet turbulence?
- Are you satisfied of your results?

Thank you for your answers!!
Antoine

You are a bit ahead of me. I am currently modelling in 2D with a k-epsilon model. I have yet to confirm its performance with wind tunnel testing, but I will keep everyone posted.

You may want to test that the turbulence values are passing the interface at all, or if there is a time delay. This will give you an idea of where the issue lies...

For 3D i believe you will want to use a LES turbulence model, but i have not tested any with the ggi.

Ok, thanks for keeping posting, it's really interesting.

On my side, i want first to success using RAS approach, before i go to LES. Moreover it's actually not yet possible to use GGI in comibnation with LES, is it?

Any other experience to share, concerning 3D RAS simulations of WT with GGI and turbDyMFoam?

does turboDyMFoam work in OF-1.6
 

Hi Foamers,
Does turboDyMFoam work in OF-1.6?

Hi Shyam - I'm afraid not.

Dear Stelios

After I renamed it into movingCells and ran the simulation, I found that the stator is rotating as well. Then I compared the 3d case with 2d case for a very simple rotating block case, i found after I convert the fluent mesh to the OpenFOAM conpatable, the cellZones (should only include the cells from rotator only) include all the cells from both stator and rotor, which causes such problem.

Have you experienced this before? Will it be due to the meshing problem? I used the icemcfd.

I have upload the case at http://www.megaupload.com/?d=2IIU3UVC

Really appreciate if you can have a look at it.

I am not sure whether it is the meshing problem or not. Now I can make the stator to be stationary by re-initialise the /constant/polyMesh/cellZones with the followings:

##########

FoamFile
{
version 2.0;
format ascii;
class regIOobject;
location "constant/polyMesh";
object cellZones;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

0
(
)
//************************************************** ********************//

##########

Then, the cellZones will be re-written with the celld from rotor part.

Cheers