[wllmk1]

Hello.

Today I got my element model converted with ideasUnvToFoam. I defined patches with autoPatch and after that I combined patches with createPatchDict.. Everything went real smooth with no errors. setSet and setsToZones commands worked fine too.

When executing icoDyMFoam 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 : 60
Reading transportProperties

Reading field p

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches: rotoright/rotorleft
Evaluation of GGI weighting factors:

From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
in file /build/buildd/openfoam-dev-1.5-1726/OpenFOAM-1.5-dev/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 534
Uncovered faces found. On master: 5108 on slave: 5238
Largest slave weighting factor correction : 0 average: 0
Largest master weighting factor correction: 0 average: 0



Found uncovered faces for GGI interface rotoright/rotorleft while the bridgeOverlap option is not set in the boundary file.
This is an unrecoverable error. Aborting.

From function void ggiPolyPatch::calcPatchToPatch() const
in file meshes/polyMesh/polyPatches/constraint/ggi/ggiPolyPatch.C at line 129.

FOAM aborting

Aborted (core dumped)

--------------------------------------

rotoright and rotorleft are cyclicGgi patches. Have I understood right that this patch must be set for planes defining the "slice" of rotor. (And stator too). My angles might be set wrong in boundary file.. How can I determine this angle and what does it actually mean in cyclicGgi?

This error might occur because I think that autopatch moves my origin.. Atleast origin I see in paraView is not in right place.. Is origin that I see in paraFoam the actual origin used in solving?

How can I move origin or prevent it from moving when I use autopatch.. Also is there any other possible reasons why I get this error?

[prashant.A]

Comments :

1. If I am understanding the model physics right, how would you use moving mesh (icoDyMFoam) with a cyclic boundary ?
Remember, GGI is meant for data transfer between stator & rotor and if the rotor part starts rotating then just a periodic intersection would cease to intersect with it after few time steps. Right ?

2. Cyclic Boundary and not Cyclic GGI can be used in steady MRF type calculation and a moving mesh study cannot be done just with one periodic section


3. The GGI errors/issues that you see can be related directly to GGI definition. Follow the standard tutorial available with 1.5-dev closely to get rid of them.

All The Best !

[wllmk1]

Hello!

Thank you so much for your answer! This is exactly why I started this thread in the first place, I have no experience in cfd and things like this are not obvious to me.
Yes I think that you are right. I must use MRFSimpleFoam.

I tried with MRFSimpleFoam and cyclicGgi (I think that cyclicggi and MRFSimpleFoam should work fine together right?) I got all the weight factors in ggi interfaces defined with no errors. Solver also solved Ux Uy and Uz. Then it started to solve p and first I got time step continuity error and after that I got "floating point" type error.
What does this error type refer to?
Is there any tutorials with MRFSimpleFoam and cyclicGgi? I found one referred in pdf called mixer_2D_MRF_m4 but I cant find it..

-wllmk1

[prashant.A]

1. Its important to distinguish between periodic boundaries (i.e. cyclic section) and the GGI interfaces. I hope you are not mixing these two things

2. A trick to speed up your computations may be to remove the GGI pairs between stator and rotor, only possible if you have an interface with same node imprint on both the sides. This will not only reduce the computational overhead associated with GGI but also eliminate the complexity involved with the case.

3. Just to debug the setup, remove periodicity for a while and then test if the calculation fails !

[wllmk1]

Originally Posted by prashant.A

1. Its important to distinguish between periodic boundaries (i.e. cyclic section) and the GGI interfaces. I hope you are not mixing these two things

2. A trick to speed up your computations may be to remove the GGI pairs between stator and rotor, only possible if you have an interface with same node imprint on both the sides. This will not only reduce the computational overhead associated with GGI but also eliminate the complexity involved with the case.

3. Just to debug the setup, remove periodicity for a while and then test if the calculation fails !

Hello. Thanks for your answer.

I have understood that cyclicGgi is made to do exactly the same job as cyclic patch is. Only difference is that with cyclicGgi the nodes dont have to match. Check this link pages 23-26: http://www.openfoamworkshop.org/08/p...doin_Jasak.pdf

It's gonna be hard to do conformal mesh with my geometry..
Im going to try to remove periodicity for debugging like u said.

-wllmk1

[prashant.A]

1. If your meshing process involved creation of whole domain, from a unit periodic section then you should be having similar node imprint on both the sides which eliminates use of cyclicGGI

2. Take one step at a time, remove all GGI pairs for now, test& debug. Then moving on, test the rotor-stator GGI pair which is one pair . Right?

[wllmk1]

Hello!

I removed cyclicggi patches. In fact I modeled the whole (360 degrees) motor with coarse mesh (1,25 M cells) so there was only 1 element between insideSlider and statorwall etc...
I patched again with autopatch and createpatch. Everything seems ok..

I'm able to run this setup with icoDyMFoam and maybe turbDyMFoam.
However with MRFSimpleFoam I get 'floating point expection' error. This error occurs after Ux,Uy and Uz have been calculated and I have received time step continuity error after p residual etc...

Only thing really different when setting up case with MRFSimpleFoam is MRFZones file. I could have got something wrong here right? (Like cellZone definition).. Is there anything else what could cause this prob?

-wllmk1

[prashant.A]

Hello,
First, I must say you have been going good so far, hope that you will soon hit the target
A couple of questions:

1. Do you see a real rotation happening in the rotor with icoDyMFoam/turbDyMFoam. If yes, then I would suggest starting a calculation with it at a low Courant no. (<0.1) Dump the transient run data at, let's say, every 5 deg of rotation..


2. Which version are you using for MRFSimpleFoam? If 1.5-dev, then I would recommend using 1.7 release version, because this one has a lesser complicated set-up , I mean setting of faceZones not required etc.

[wllmk1]

Originally Posted by prashant.A

Hello,
First, I must say you have been going good so far, hope that you will soon hit the target
A couple of questions:

1. Do you see a real rotation happening in the rotor with icoDyMFoam/turbDyMFoam. If yes, then I would suggest starting a calculation with it at a low Courant no. (<0.1) Dump the transient run data at, let's say, every 5 deg of rotation..


2. Which version are you using for MRFSimpleFoam? If 1.5-dev, then I would recommend using 1.7 release version, because this one has a lesser complicated set-up , I mean setting of faceZones not required etc.

1. I didnt have time to wait results with turbDyMFoam but with icoDyMFoam yes, I see rotation happening. Where can I set courant no? And how do I dump transient data? And what does it mean to dump transient data? Sry stupid questions.. I really dont know anything about fluid dynamics.. I started to study heat transfer and fluid dynamics as minor few weeks ago.. my major is mechanical engineering..

2. I dont know which version it is.. but it does define faceZones automatically..

[prashant.A]

1. Check "system/controlDict" for the following :

writeControl runTime;//will dump a data file after a particular flow time
writeInterval 0.005;//is the data dump entry for above. Set this for 5deg rotation
adjustTimeStep yes; // will adjust time step based upon the Courant No entry
maxCo 0.1; //max. Courant No. allowed in a cell

These settings should do the needful for you !

2. "which MRFSimpleFoam" will tell you the version...

[wllmk1]

Hello!

Thanks for time step values you posted. I had to chance 5 deg rotation to 0,5 deg because solver crashed after few steps with 5deg (rotating speed is 3000 rpm). I left TurbDyMFoam running so I'll see in the morning if it has finished without problems..

What values should I use in transportprop? My nu is now 0,000015, nu0 and nuinf are 0,0000015.. and my models dimensions are in metres. Are these ok?

How many iteration rounds are ok with U and p ? U gets through with 5-20 iterations but p with 900-1000.. whats up with this?

-wllmk1

[prashant.A]

Hello wllmk1,

1. the nu value that you have corresponds to air, and that makes sense

2. Check the model dimensions, that you dont mistake simulating a pelton wheel in place of a motor !

2. The Courant No. criteria will auto-adjust the time step to a feasible value so that stability issues are minimised

4. MRFSimpleFoam could give you a good flow field to start from, and consequently the stability issues are minimised

[wllmk1]

Hello!

I continued my project today and following things occured:

1. TurbDyMFoam solved with different rpm's and timesteps (And maCo < 0,1) 2..3 timesteps succesfully. Then I got error which was something like: difference between inflow and outflow couldnt be adjusted with... something.. sorry I didnt remember to copy the actual error message. I think error is related to continuity error in massflow. What could cause this?

2.I got MRFSimpleFoam working! .... somehow. It solves 8..10 time steps and then I got error: floating point expection (core dumped). Results in first timesteps solved seem to be in right scale (U=20...60 m/s). But with last steps U raises to 10e10 m/s.. however I cant see any velocity vector having values this high.. all vectors seem to have value zero in this scale (0...10e10).. Any ideas?

Idea behind MRFSimpleFoam is mystery to me.. If it solves steady state, why it still solves time steps? Are results in last steps better than results in earlier steps?

My rotation per step is smaller than 5 deg/step in all cases.

-wllmk1

[wllmk1]

Hi

I would have some questions about MRFSimpleFoam on top of my last post.

- My version of MRFSimpleFoam defines facezones automatically if I dont define it. So this means that MRFSimpleFoam removes automatically boundary faces from definitions of 'rotating' faces right?

- How can I view my cellZone in paraview (to see that I got it right)?

[wllmk1]

Hello.

Since my last posts I have spent way too many hours trying little this and that to make model work. Mainly I have been working MRFSimpleFoam. I got simulation through with MRFSimpleFoam but velocity magn was 0.25 m/s when it should be about 25 m/s. I think I got something wrong with timestep or definition of facezones..
I have been trying to define facezone my self because automatic defining doesnt seem to work for me.. with automatic facezone defining velocity magn arises to infinite with 6 steps and I get floating point error.

I would have some questions if someone cares to help:

1. I have to define a cellzone which has all the 'rotating' cells in it, right?
2. With older versions I have to also define facezone, right? Lets say that I define facezone myself.
- I have to pick 'insidezone' defined by insideslider for this facezone right? How about wall type patch defining rotor's wall? Do I have to include that too? (My geometry is basicly two coincentric cylinders with little more complicated geometry)
- What should I define for patches and nonrotatingpatches in MRFZones file? I have put patch defining rotor's wall to patch. nonrotating patches I have left blank.

3. What would be good values for controlDict file when rotor's diam is 0,4 m and rpm is 1000-3000 ?

[wllmk1]

Hello again.

I believe that I got my MRFZone related issues solved now.

This time I tried to solve my continuity errors by reducing the rotating speed. First I tried with 100 rpm and model solved with no errors and really nice convergence. U magn. and p seemed to be in right scale and flow path was realistic.. I think that since model can be solved with low rotation speed there is no error related to MRFZones, boundaries or units.. (?)

Problem seems to be that my geometry is complicated and consists of some very small holes etc.. So it is prob natural that I get continuity errors with 3000 rpm (?)

Im trying next to solve first with 100 rpm then continue from there with 200 rpm and move on from there to see if I manage to get something out of this....

Btw.. Can anyone help me and tell how to turn off glyph vectors having value zero in paraView? Those really mess glyph picture up..
And does anyone know how to chance view to perspective in paraview?

-wllmk1

[wllmk1]

Hello.

increasing rotational speed step by step didnt work as well as I was hoping for.. I mean simulation might run well for 100 steps but then time step continuity error might jump to 1000 from 0.0001... and I get floating point error.
I also see that maximum value of epsilon increases steadily to smthing like 1e+8 while mean value is 300 ( with 100 rad/s).. Is this normal and what does value of epsilon mean actualy?
I'm still confused by controldict file with MRFSimpleFoam. What is the meaning of time step if simulation is steady? Do i get same results for case if:
- my time step size is 1 and end time is 5000 ?
- my time step size is 0.5 and end time is 2500 ?
I think that Im asking if time steps size is here unitless or actual seconds?

I got simulation running without errors for 24 hours when decreasing relaxation factors significantly.. But is this really a solution or just a indicator that something is wrong with bc or initial conditions? Ive checked them hundred times but still..

Simulation I had running 24 hours didnt finish because I got a message 'Killed' out of nowhere when I was viewing solved steps with paraview.. What does this message 'killed' mean? Ive got it some times before also..
Could it be because processor gets too stressed because Im doing smthing else with it at the same time solver is running?

-wllmk1

[wllmk1]

Hello again!

I haven't been posting much to this thread but I have continued working with my problem.

I'd like to believe that I have been able to solve my previous issues with stator/rotor + ggi. Everything seems to work fine now with MRFSimpleFoam + ggi + cyclicGgi and with turbDyMFoam + ggi. I'm able to get a solution with 3000 rpm and probably higher but havent tried yet. Anyone having similar problems with ggi than I did, post here and I'll help if I can.

So, my flow field is fine. Now I need to move to second part, which is heat transfer. Basicly my setup is this: I have rotor and stator and some cooling channels. And yes two fluids (air and cooling water. )
So I have some solid to solid and some fluid to solid interfaces. Rotor and stator both produce heat with 5000 [W]. I have flow fields for air and cooling water. Is there any incompressible, turbulent solver that can handle heat generation in [W]? I'm interested of solving the steady state temperature.

I have read from some thread here that it is possible to add a heat source to chtMultiregionFoam but it seems to have some problems with multiple regions.

What about the different meshes; do they have to match or can I use ggi similarly than with MRFSimpleFoam?

-wllmk1

[sam.ho]

Hi Foamers

I am simulating a Radial Inflow Turbine Blade passage using transonicMRFDyMFoam. I have few questions to be clarified

1. Can we use this transonicMRFDyMFoam with GGI instead of MRF ?
2. I have created the mesh in ICEM CFD then imported to OpenFOAM.
Later merged the mesh. After that set the boundary file and run the following to complete the preprocessing
setSet -batch setBatch
regionCellSets
setsToZones -noFlipMap
Now i am trying to simulate but I am getting the following error

sml5kor@BMH301562:~/OpenFOAM/sml5kor-1.6-ext/run/Test_mesh_merge$ transonicMRFDyMFoam 
/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM Extend Project: Open source CFD        |
|  \\    /   O peration     | Version:  1.6-ext                               |
|   \\  /    A nd           | Web:      www.extend-project.de                 |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 1.6-ext
Exec   : transonicMRFDyMFoam
Date   : Apr 08 2014
Time   : 15:00:42
Host   : BMH301562
PID    : 12281
Case   : /home/sml5kor/OpenFOAM/sml5kor-1.6-ext/run/Test_mesh_merge
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh turboFvMesh
Initializing the GGI interpolator between master/shadow patches: PERIODIC1/PERIODIC2

    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
    in file /home/sml5kor/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 544
    Uncovered faces found.  On master: 4216 on slave: 4216
Initializing the GGI interpolator between master/shadow patches: PER1_UPS/PER2_UPS

    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
    in file /home/sml5kor/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 544
    Uncovered faces found.  On master: 1302 on slave: 1302
Initializing the GGI interpolator between master/shadow patches: PER1_DWS/PER2_DWS

    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
    in file /home/sml5kor/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 544
    Uncovered faces found.  On master: 2728 on slave: 2728

    From function void GGIInterpolation<MasterPatch, SlavePatch>::rescaleWeightingFactors() const
    in file /home/sml5kor/OpenFOAM/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/GGIInterpolationWeights.C at line 544
    Uncovered faces found.  On master: 0 on slave: 1590


--> FOAM FATAL ERROR: 
Found uncovered faces for GGI interface IFC1_IMP_TO_UPS/IFC2_IMP_TO_DWS
This is an unrecoverable error. Aborting.

    From function void overlapGgiPolyPatch::calcPatchToPatch() const
    in file meshes/polyMesh/polyPatches/constraint/overlapGgi/overlapGgiPolyPatchGeometry.C at line 186.

FOAM aborting

Aborted (core dumped)

Please find the attached geometry and also the boundary file .
Can anyone help me ?

Regards,
Sangamesh Hosur