|
[Sponsors] |
Rotor-stator computation with Ggi interface (turbDyMFoam) |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
March 15, 2010, 05:44 |
Rotor-stator computation with Ggi interface (turbDyMFoam)
|
#1 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 15, 2010, 06:01 |
|
#2 |
New Member
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
I have the same pb about segmentation fault (using either icoDynMFoam or turbDynMFoam).
Any ideas ? Thanks, Flo |
|
March 15, 2010, 08:05 |
|
#3 |
Member
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 94
Rep Power: 17 |
Do you have enough memory for the job?
|
|
March 15, 2010, 08:51 |
|
#4 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
Yes only 25% of the memory is used (using top).
|
|
March 15, 2010, 09:07 |
|
#5 |
New Member
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
Yes, I have enough memory.
I also tried to decompose the case and I still have segmentation fault.... |
|
March 15, 2010, 09:18 |
|
#6 |
Member
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 94
Rep Power: 17 |
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 |
|
March 15, 2010, 09:30 |
|
#7 |
New Member
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
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 |
|
March 15, 2010, 09:50 |
|
#8 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 15, 2010, 09:56 |
|
#9 |
Member
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 94
Rep Power: 17 |
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 ); |
|
March 15, 2010, 09:58 |
|
#10 |
Member
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 94
Rep Power: 17 |
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
|
|
March 15, 2010, 10:28 |
|
#11 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 15, 2010, 10:38 |
|
#12 |
Member
Nick Gardiner
Join Date: Apr 2009
Location: Chichester, UK
Posts: 94
Rep Power: 17 |
I'm afraid that it's beyond me too
Sorry |
|
March 15, 2010, 10:44 |
|
#13 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 16, 2010, 04:16 |
|
#14 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 17, 2010, 05:01 |
|
#15 |
New Member
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
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 |
|
March 17, 2010, 06:05 |
|
#16 |
New Member
Stylianos Kyriacou
Join Date: Mar 2010
Location: Cyprus - Athens - Austria - Zurich
Posts: 27
Rep Power: 16 |
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 |
|
March 17, 2010, 06:09 |
|
#17 |
New Member
champet
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
Hi Stelio,
No, I have to modify the cellZones file. Flo |
|
April 4, 2010, 19:57 |
|
#18 |
Member
Jason Eason
Join Date: Jan 2010
Location: Portage, Michigan
Posts: 45
Rep Power: 16 |
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.
__________________
Debian Squeeze - OpenFOAM-2.1.x, Paraview-3.12.0 |
|
May 13, 2010, 14:37 |
Kudos
|
#19 |
Senior Member
|
||
May 25, 2010, 12:42 |
turbdymfoam & GGI
|
#20 |
Member
Aldo Iannetti
Join Date: Feb 2010
Posts: 48
Rep Power: 16 |
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 |
|
Tags |
ggi, segmentation fault, turbdymfoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Wind turbine simulation | Saturn | CFX | 60 | July 17, 2024 06:45 |
GGI (General Grid Interface) Connections | feixiangniao | CFX | 4 | January 14, 2010 20:51 |
RPM in Wind Turbine | Pankaj | CFX | 9 | November 23, 2009 05:05 |
CFX GGI Interface Error (non-overlapping) | surge519 | CFX | 1 | August 3, 2009 19:54 |
Replace periodic by inlet-outlet pair | lego | CFX | 3 | November 5, 2002 21:09 |