Ggi help please
 

I want to simulate a co-axial rotor system, I've modified the MRFSimpleFoam case, with the implementation of the ggi, but I don't understand the what will represent the insideSlider. I created a cylinder around each rotor to represent the outSlider. Also, with MRFSimpleFoam will I have to use the dynamicMechDict to control the angular velocity, because of the use of ggi, or would I have to use the MRFZones file for the purpose.
Thank you in advance. Jason

If you mention about mixerGgi tutorial case, insideSlider is a ggi patch at outside of the Rotor. And you should not define dynamicMeshDict for MRFSimpleFoam. You need MRFZones only. If you use turbDyMFoam, you need to define dynamicMeshDict.

Ohbuchi, Thank you for your reply, should I not include the outsideSlider, or should I define the insideSlider and outsideSlider as the same entity?

You should define outsideSlider too.
For use of GGI, you should define a pair of GGI patches,
one is rotor-side, other is stator-side.

Sorry, I have another question I've created 4 blocks, using 16 points to create, a ring around my mesh, which is the in/outsideSlider, but somehow the results are unusual. I've arc the blocks also, arc a b (x y z), the ring won't closed, somehow the x or z value is the circumference, instead on the points in which the line arcs through. Any thoughts on what is wrong or what I'm doing wrong?
[IMG]file:///E:/arc.png[/IMG]Edit: I've done may round meshes before so I know my syntax is correct, when I erase the arc functions my image forms a square/diamond as expected.
http://www.cfd-online.com/Forums/att...1&d=1268527542

It seems like a problem on usage of blockMesh utility.
Please refer ti OpenFOAM UsersGuide Chapter 5.3.

I found my problem and it was in the blockMeshDict file, Thank You Ohbuchi, you were corrct sorry for flooding the forum.

Edit: Have completed my case file, MRFSimpleFoam with ggi implementation, I found all step setting cells and faces, I've included eveything in the pertinent files and folders, and deleted the dynamicMeshDict. Following instructions from http://openfoamwiki.net, setBatch and decomposePar, when I run decomposePar or the simulation itself I get this error

Attempt to cast type patch to type lduInterface
From function refCast<To>(From&)
in file /OPENFOAM/.../src/OpenFOAM/lnInclude/typeInfo.H at line 106

Any help would me appreciated. Thank You. Jason

I solved this problem by addressing the boundary file in the constant directory, and changed the type from patch to ggi, and had to add the shadowPatch and bridgeOverLap and zone.

When I try to run my simulation I get a segmentation fault. So I removed the functions at the end of the ControlDict, the website info was located in the optional category, the simulation then ran, but the mesh didn't rotate at all. Also my boundary file clears the zone and shadowPatch and the bridgeOverlap always changes to off. Any thoughts? Anyone?

If you still use MRFSimpleFoam, mesh never rotate. MRFSimpleFoam is a steady state solver using multireference frame ( Frozen Rotor ). This Frozen Rotor method simulate flow field using computational mesh relative position between rotor and stator region is fixed, and taking into account centrifugal force and Coriolis force in impeller region only.
If you want to rotate actually, you should use turbDyMFoam.

I thought that the ggi could rotate any mesh, I know that MRFSimpleFoam doesn't rotate, but shouldn't adding the ggi make it rotate, I need a multizone case thats why I chose MRFSimpleFoam. Is it possible to have multi-moving meshes with anything other than MRFSImpleFoam?

GGI stands for general grid interface, so this doesn't directly concerned with sliding mesh.
This is quite useful for define interface between patches with discontinuous face mesh.

You suggested turbDyMFoam but I don't see a case in the directory, I'm not skilled enough to create the files in the system folder, is there another case in which the system folder can transfer without any modifications? Can turbDyMFoam run a co-axial rotor system, which intels one rotor above the other turning in opposite directions?

I suppose mixerGgiFvMesh support only one rotating zone. If you want to handle two rotating zone, you should modify it.

My mesh checks is ok my cellzones are set to movingCells, the boundary file ggi is set, my simulation ends with a floating point exception. The interations max out no matter of high I raise them(5000). DecomposePar shows no errors. Any ideas why this may be happening?