CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

GGI in OpenFOAM

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   May 3, 2009, 14:03
Default further data
  #21
New Member
 
Mikko Auvinen
Join Date: Mar 2009
Location: Helsinki, Finland
Posts: 8
Rep Power: 8
auvinen is on a distinguished road
Hello Hrvoje,

I am using the movingWallVelocity BC. Let me provide some hard ascii data to be more specific.

When I stopped the GGI run, with the previous dev version, U and phi demonstrated the following:

U

impellerWall
{
type movingWallVelocity;
value nonuniform List<vector>
18488
(
(4.9647339 -5.2771553 -0.0018872856)
(4.7601108 -5.3303373 -0.0020557974)
(4.5670492 -5.3605736 -0.0019166547)
(4.3854936 -5.3684121 -0.0014655788)
(4.2141501 -5.3542863 -0.00090790046)
(4.0513943 -5.3195429 -0.00031373207)
(3.8939149 -5.2681244 0.00025266462)

...


phi
impellerWall
{
type calculated;
value nonuniform List<scalar>
18488
(
-1.6940659e-21
-1.6940659e-21
1.6940659e-21
0
0
0
0
...


So, we have strange non-zero z-velocities (comparatively small however) on the impeller wall, but the mass flux across it is practically zero. Up until now I had no severe problems - except at the very beginning - but then I went ahead and updated the dev version to the current one and the same results, after a very small time step, depict this:

U
impellerWall
{
type movingWallVelocity;
value nonuniform List<vector>
18488
(
(4.9682308 -5.2911397 -2.0632922e-05)
(4.762548 -5.346407 -2.2850246e-05)
(4.5680695 -5.3785635 -1.9691256e-05)
(4.3844853 -5.388396 -1.4211187e-05)
(4.2105156 -5.3759217 -8.5769172e-06)
(4.0448415 -5.3421346 -2.9240217e-06)
(3.8852911 -5.2907393 2.8557031e-06)
...


phi
impellerWall
{
type calculated;
value nonuniform List<scalar>
18488
(
-3.432816e-12
-2.0036404e-11
6.8836892e-11
5.7797203e-11
1.764198e-10
-2.6405148e-11
7.8682583e-11
-1.7541699e-10
...



The velocity values are now little different and the z-components still non-zero (still comparatively small, but a little scrolling revealed values upto 0.012). The problem is the mass flux values, which can no longer be labeled as 'practically zero'. Little scrolling revealed values upto 1.0e-7 which lie in the same ball park with the internal face values. Within this same time step the pressure had gone wild and so far I've been unable to tame it with my trials. This is where I need a second opinion.

Yours,
- mikko
auvinen is offline   Reply With Quote

Old   May 4, 2009, 05:14
Default
  #22
Member
 
Hai Yu
Join Date: Mar 2009
Location: OvgU, Magdeburg
Posts: 65
Rep Power: 8
yuhai is on a distinguished road
Hallo, foamer,
Can anybody confirm me that turbDyMFoam working on GGI is fully paralleled? I mean whether the movingCells zone can be cut through.
And in which code module is this machenism located? I would just look it through to get a deep feeling.

Regards.

Hai

Last edited by yuhai; May 4, 2009 at 07:03.
yuhai is offline   Reply With Quote

Old   May 14, 2009, 10:23
Default Skype failed...
  #23
Senior Member
 
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 397
Rep Power: 12
marupio is on a distinguished road
Did anyone record the conference call? My skype bandwidth was too low to hear anything useful.
marupio is offline   Reply With Quote

Old   June 15, 2009, 05:25
Default Example/Tutorial
  #24
New Member
 
Pal Schmitt
Join Date: Mar 2009
Posts: 28
Rep Power: 8
waterboy is on a distinguished road
Dear Foamers,
Is there any example/tutorial case working with the current 1.5-dev version? My old cases don't run anymore and I missed the skype presentation...
Any help much appreciated,
Pal
waterboy is offline   Reply With Quote

Old   August 11, 2009, 10:36
Default
  #25
New Member
 
Pablo Grazziotin
Join Date: Mar 2009
Posts: 6
Rep Power: 8
pablocg is on a distinguished road
Hello all,

I missed this tutorial conference, can anyone please point me to some tutorial or examples of how to set GGI run on OF?

Thanks,
-Pablo
pablocg is offline   Reply With Quote

Old   August 11, 2009, 11:03
Default
  #26
Senior Member
 
John Deas
Join Date: Mar 2009
Posts: 160
Rep Power: 8
johndeas is on a distinguished road
Some pdf were mentionned. Is it possibly to gain access to them ?
johndeas is offline   Reply With Quote

Old   August 12, 2009, 04:48
Default
  #27
Member
 
olivier Petit
Join Date: Mar 2009
Location: Göteborg, Sweden
Posts: 67
Rep Power: 8
olivier is on a distinguished road
Hello,

If you want a working case with the GGI and some hints on how to set up a case with a GGI, you can go to the OpenFOAM Wiki, to the turbomachinery wiki page, there is a tutorial on how to set up a case with a GGI in it. To go there, just follow the following link, http://openfoamwiki.net/index.php/Si...vaned_diffuser.

And the tutorials are available on the svn. Just follow the steps written on the wiki page.

Good luck.
olivier is offline   Reply With Quote

Old   November 25, 2009, 13:39
Default Moving part of GGI-mesh cutting a boundary
  #28
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Hello,

allow me to bother you with a question. Before I pose it, please see the attached image

ForumBildGGI.jpg.
red = static part of the GGI-mesh, blue = moving part of the GGI-mesh, black = boundaryPatch ("wheel"), gray = boundaryPatch ("road").

As you can see the moving part of the mesh is cutting the boundaryPatch ("road").

Can the present GGI implementation (svn-revision 1503 of /src) treat this behavior correctly? (Simulation is run with turbDyMFoam [svn-revision 1197])

Last edited by lord_kossity; November 25, 2009 at 13:40. Reason: font
lord_kossity is offline   Reply With Quote

Old   November 25, 2009, 14:26
Default
  #29
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,763
Rep Power: 21
hjasak will become famous soon enough
Yes, it will work, but I am not sure if this is what you want. Do you want to impose a boundary condition on the exposed part of the rotating mesh below the road or you simply don't care what happens there?

Hrv
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   November 25, 2009, 15:47
Default
  #30
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Quote:
Originally Posted by hjasak View Post
Yes, it will work, but I am not sure if this is what you want.
What I actually want is to quantitatively compare (especially Cl, besides Cd) an MRF approach and a GGI approach for automotive simulations with turning wheels and moving floor.

Quote:
Originally Posted by hjasak View Post
Do you want to impose a boundary condition on the exposed part of the rotating mesh below the road or you simply don't care what happens there?
On the first shot I did not care about the boundary condidtion on the exposed rotating part but ran into difficulties.

Do you have any recommendation on how to treat this kind of simulations in a proper way?
lord_kossity is offline   Reply With Quote

Old   November 25, 2009, 19:27
Default
  #31
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,763
Rep Power: 21
hjasak will become famous soon enough
We are getting too close to answering support questions on an open forum: I would need to understand much better what you are trying to do and what kind of results you expect to see.

Sorry, we should really deal with this directly - I am sure you understand.

Hrv
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Old   November 26, 2009, 05:55
Default
  #32
Member
 
lord_kossity's Avatar
 
Andreas Dietz
Join Date: Mar 2009
Location: Munich
Posts: 79
Rep Power: 8
lord_kossity is on a distinguished road
Quote:
Originally Posted by hjasak View Post
I would need to understand much better what you are trying to do and what kind of results you expect to see.
The goal is to use the GGI approach for automotive simulations with turning wheels and moving floor. Therefore I already ran a siumulation with MRF approach (MRFSimpleFoam) and now wanted to run the same car with GGI approach and compare coefficients. [I know MRFSimpleFoam is steady-state and turbDyMFoam not, but I wanted to give it a try.]

Quote:
Originally Posted by hjasak View Post
Sorry, we should really deal with this directly - I am sure you understand.
Sure
lord_kossity is offline   Reply With Quote

Old   February 17, 2010, 11:21
Default
  #33
Senior Member
 
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 10
braennstroem is on a distinguished road
Hello,

I am trying to use ggi for a noncomformal interface without any motion as an alternative to stitchMesh. I created the two meshes with snappyHexMesh and merged them with mergeMeshes. I set the typ the interfacing boundaries to ggi type with:
GGI_OUT_BLOCK_maxX_1
{
type ggi;
// type patch;
nFaces 6108;
startFace 10116664;
shadowPatch GGI_IN_BLOCK_minX;
zone GGI_OUT_BLOCK_maxX_1_Zone;
bridgeOverlap true;
}

GGI_IN_BLOCK_minX
{
// type patch;
type ggi;
nFaces 5626;
startFace 10991895;
shadowPatch GGI_OUT_BLOCK_maxX_1;
zone GGI_IN_BLOCK_minX_Zone;
bridgeOverlap true;
}

Unfortunately, I get this error, when running with simpleFoam:
--> FOAM Warning :
From function GGIInterpolation<MasterPatch, SlavePatch>::calcAddressing()
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 412
polygonIntersection is returning a zero surface area between
Master face: 6092 and Neighbour face: 1197 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 533
Uncovered faces found. On master: 23 on slave: 0
Largest slave weighting factor correction : 0.9994067 average: 0.001887828
Largest master weighting factor correction: 0.9991873 average: 0.00420317

Floating point exception



Somehow, the 'intersection area = 0' is a bit strange to me...
Does anyone have a suggestion, what I am doing wrong!? Both patches should have the the same size (but might vary slightly due to snappyHexMesh).

Regards!
Fabian
braennstroem is offline   Reply With Quote

Old   February 17, 2010, 18:27
Default
  #34
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Fabian,

it should work but setup is little tricky. Did you create faceZones from patches? Do you run in parallel? If yes did you ensure correct parallelisation (globalFaceZones)? Do the Zones match? Did you check this in Paraview?
Btw. Running it in parallel is quite slow for parallel cases. Are you happy with stitchMesh? I have lots of problems with it.

Regards BastiL
bastil is offline   Reply With Quote

Old   February 19, 2010, 13:15
Default
  #35
flo
New Member
 
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 8
flo is on a distinguished road
Hello,
based on the ercoftac pump tutorial, I am trying to set a turbine computation but I have few difficulties.
- I would like to simulate only one runner channel (instead of the full 360°), how should I set the GGI parameters (is there any "pitch angle" to specify ?).
I guess that I have 2 cyclicGGI bondary condition, a wall for the blade, what about the interface rotor/stator ?
Here are my BC:
10
(
SP_HIGHP
{
type patch;
nFaces 1017;
startFace 10749226;
}
SP_LOWP // this is the interface stator side (360°)
{
type ggi;
nFaces 17350;
startFace 10750243;
shadowPatch INTERFACEGGI;
bridgeOverlap false;
zone SP_LOWP_ZONE;
}
SP_WALL
{
type wall;
nFaces 143896;
startFace 10767593;
}
STAY
{
type wall;
nFaces 49852;
startFace 10911489;
}
GUIDE
{
type wall;
nFaces 45575;
startFace 10961341;
}
BLADE
{
type wall;
nFaces 24016;
startFace 11006916;
}
INTERFACEGGI // this is the rotor/stator interface - rotor side (51°)
{
type ggi;
nFaces 3136;
startFace 11030932;
shadowPatch SP_LOWP;
bridgeOverlap false;
zone INTERFACEGGI_ZONE;
}
PERIODSIDE1
{
type cyclicGgi;
nFaces 5488;
startFace 11034068;
shadowPatch PERIODSIDE2;
zone PERIODSIDE1_ZONE;
bridgeOverlap false;
rotationAxis (0 0 1);
rotationAngle 51.42857143;
separationOffset (0 0 0);
}
PERIODSIDE2
{
type cyclicGgi;
nFaces 5488;
startFace 11039556;
shadowPatch PERIODSIDE1;
zone PERIODSIDE1_ZONE;
bridgeOverlap false;
rotationAxis (0 0 1);
rotationAngle -51.42857143;
separationOffset (0 0 0);
}
INLET
{
type patch;
nFaces 3360;
startFace 11045044;
}
)

- Secondly, I think I don't totally understand the difference between MRFSimpleFoam and simpleTurboMRFFoam. The first one is frozen-rotor and is the second one what CFX call "stage" ?

Is there any tutorial using simpleTurboMRFFoam or turbDyMFoam ?

Thanks a lot !
Flo
flo is offline   Reply With Quote

Old   February 26, 2010, 15:47
Default
  #36
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
Hello Fabian,

Check your mesh for concave faces on the GGI patches.

The cutting algorithm being used by the actual GGI implementation cannot handle concave faces on the GGI patches.

snappyHexMesh is known to generate mesh with concave faces.

You can check your mesh for the presence of concave faces using checkMesh. But watch out, checkMesh concave angle threshold is 10 degree, so all concave angles from 10 degree and less will not be reported.

You can change this default setting in your main controlDict by changing the tolerance parameter primitiveMeshFaceAngleThreshold.

Martin


Quote:
Originally Posted by braennstroem View Post
Hello,

I am trying to use ggi for a noncomformal interface without any motion as an alternative to stitchMesh. I created the two meshes with snappyHexMesh and merged them with mergeMeshes. I set the typ the interfacing boundaries to ggi type with:
GGI_OUT_BLOCK_maxX_1
{
type ggi;
// type patch;
nFaces 6108;
startFace 10116664;
shadowPatch GGI_IN_BLOCK_minX;
zone GGI_OUT_BLOCK_maxX_1_Zone;
bridgeOverlap true;
}

GGI_IN_BLOCK_minX
{
// type patch;
type ggi;
nFaces 5626;
startFace 10991895;
shadowPatch GGI_OUT_BLOCK_maxX_1;
zone GGI_IN_BLOCK_minX_Zone;
bridgeOverlap true;
}

Unfortunately, I get this error, when running with simpleFoam:
--> FOAM Warning :
From function GGIInterpolation<MasterPatch, SlavePatch>::calcAddressing()
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 412
polygonIntersection is returning a zero surface area between
Master face: 6092 and Neighbour face: 1197 intersection area = 0
Please check the two quick-check algorithms for GGIInterpolation. Something is missing.

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /opt/OpenFOAM/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 533
Uncovered faces found. On master: 23 on slave: 0
Largest slave weighting factor correction : 0.9994067 average: 0.001887828
Largest master weighting factor correction: 0.9991873 average: 0.00420317

Floating point exception



Somehow, the 'intersection area = 0' is a bit strange to me...
Does anyone have a suggestion, what I am doing wrong!? Both patches should have the the same size (but might vary slightly due to snappyHexMesh).

Regards!
Fabian
mbeaudoin is offline   Reply With Quote

Old   March 1, 2010, 06:34
Default
  #37
Member
 
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 93
Rep Power: 8
NickG is on a distinguished road
Hi Learned Ones

I have a similar problem that works/rotates with icoDyMFoam but gives a floating point error after the first step with turbDyMFoam. I'm using the movingWallVelocity boundary condition in the U file for the blade which I assume is also necessary for the icoDyMFoam to work.

The GGI is working for the icoDyMFoam case so I don't think it's a mesh interface problem.

I've tried reducing the time and changing the number of p correctors enough that I don't get any changes with further iterations but am clueless as to what to try next.

Any suggestions would be gratefully received

Thanks

Nick
NickG is offline   Reply With Quote

Old   March 1, 2010, 06:41
Default
  #38
Member
 
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 93
Rep Power: 8
NickG is on a distinguished road
This is the output

Initializing the GGI interpolator between master/shadow patches: InterT/InterR
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.85271e-05 average: 2.77807e-06
Largest master weighting factor correction: 4.47993e-05 average: 7.11812e-07

BiCGStab: Solving for Ux, Initial residual = 1, Final residual = 2.71511e-08, No Iterations 7
BiCGStab: Solving for Uy, Initial residual = 1, Final residual = 4.66166e-08, No Iterations 8
BiCGStab: Solving for Uz, Initial residual = 1, Final residual = 4.14282e-09, No Iterations 6
BiCGStab: Solving for p, Initial residual = 1, Final residual = 9.96992e-08, No Iterations 267
BiCGStab: Solving for p, Initial residual = 0.705496, Final residual = 9.4242e-08, No Iterations 211
BiCGStab: Solving for p, Initial residual = 0.0302484, Final residual = 3.65547e-08, No Iterations 199
time step continuity errors : sum local = 9.62158e-14, global = 2.47271e-15, cumulative = 2.47271e-15
BiCGStab: Solving for p, Initial residual = 0.046603, Final residual = 5.78336e-08, No Iterations 206
BiCGStab: Solving for p, Initial residual = 0.00832937, Final residual = 4.69163e-08, No Iterations 147
BiCGStab: Solving for p, Initial residual = 0.000697974, Final residual = 9.73038e-08, No Iterations 78
time step continuity errors : sum local = 2.45325e-13, global = 5.62079e-14, cumulative = 5.86806e-14
BiCGStab: Solving for p, Initial residual = 0.00268834, Final residual = 6.2455e-08, No Iterations 178
BiCGStab: Solving for p, Initial residual = 0.000414399, Final residual = 4.79598e-08, No Iterations 125
BiCGStab: Solving for p, Initial residual = 3.51465e-05, Final residual = 9.8068e-08, No Iterations 34
time step continuity errors : sum local = 2.47464e-13, global = -1.67022e-13, cumulative = -1.08342e-13
BiCGStab: Solving for p, Initial residual = 0.000847403, Final residual = 2.87118e-08, No Iterations 154
BiCGStab: Solving for p, Initial residual = 0.000142032, Final residual = 9.4255e-08, No Iterations 127
BiCGStab: Solving for p, Initial residual = 1.09702e-05, Final residual = 9.90043e-08, No Iterations 20
time step continuity errors : sum local = 2.4977e-13, global = 1.42343e-13, cumulative = 3.40009e-14
Floating point exception


Thanks again
NickG is offline   Reply With Quote

Old   March 1, 2010, 08:12
Default
  #39
Senior Member
 
Pavan
Join Date: May 2009
Location: Melbourne
Posts: 101
Rep Power: 8
rieuk is on a distinguished road
Hey Nick, could you upload your case file so we could have a look at what you're trying to simulate?
rieuk is offline   Reply With Quote

Old   March 1, 2010, 09:03
Default
  #40
Member
 
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 93
Rep Power: 8
NickG is on a distinguished road
Hi James

These are the case files less the mesh which was too big to upload with this lot. If you need it just say. I've got about three iterations running now before a floating point error again.

Thanks Nick
Attached Files
File Type: gz Merge2.tar.gz (4.3 KB, 45 views)
NickG is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Superlinear speedup in OpenFOAM 13 msrinath80 OpenFOAM Running, Solving & CFD 18 March 3, 2015 06:36
64bitrhel5 OF installation instructions mirko OpenFOAM Installation 2 August 12, 2008 18:07
Adventure of fisrst openfoam installation on Ubuntu 710 jussi OpenFOAM Installation 0 April 24, 2008 14:25
OpenFOAM Debian packaging current status problems and TODOs oseen OpenFOAM Installation 9 August 26, 2007 13:50
OpenFOAM Training and Workshop Zagreb 2628Jan2006 hjasak OpenFOAM 1 February 2, 2006 22:07


All times are GMT -4. The time now is 08:50.