[coolcrasher]

Hi Foamers,

I working on simulating the Centrifugal pump using openfoam 2.3 and 2.4.

I have worked on simulating the pump in steady case using simpleFoam with fvoptions and now am working to simulate the transient case of it using pimpleDyMFoam.

I am using a hexa-mesh with boundary layer refinement ( finer mesh at the boundaries ) Also using kOmegaSST turbulence model.

I am running for 10 revolutions of the pump and with a timestep around 1e-4.
The case is running fine but the problem is that the flowrate at the outlet is not balancing with the inlet.

I see that the flow is good in parafoam and nothing weird happens. But I don not know why its violating the continuity eqn.

Following are the last lines of my simulation. Last pimpleIterations in my last timestep.

PIMPLE: iteration 21
smoothSolver:  Solving for Ux, Initial residual = 1.81812e-06, Final residual = 1.28061e-07, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 2.08545e-06, Final residual = 1.66683e-07, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 1.4747e-06, Final residual = 1.15936e-07, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.000158004, Final residual = 6.30531e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 4.20168e-05, Final residual = 2.96428e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 1.65084e-05, Final residual = 1.74725e-06, No Iterations 1
time step continuity errors : sum local = 1.97894e-08, global = 2.05632e-09, cumulative = -0.00426009
PIMPLE: iteration 22
smoothSolver:  Solving for Ux, Initial residual = 1.42268e-06, Final residual = 9.61881e-08, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 1.63339e-06, Final residual = 1.31126e-07, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 1.12777e-06, Final residual = 9.08367e-08, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.000118318, Final residual = 5.41193e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 3.36414e-05, Final residual = 2.36806e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 1.28282e-05, Final residual = 1.56865e-06, No Iterations 1
time step continuity errors : sum local = 1.77666e-08, global = 6.6472e-10, cumulative = -0.00426009
PIMPLE: iteration 23
smoothSolver:  Solving for Ux, Initial residual = 1.03994e-06, Final residual = 7.27674e-08, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 1.26104e-06, Final residual = 1.0543e-07, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 8.65528e-07, Final residual = 8.65528e-07, No Iterations 0
GAMG:  Solving for p, Initial residual = 8.91992e-05, Final residual = 4.13268e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 2.71277e-05, Final residual = 2.02234e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 1.03066e-05, Final residual = 1.17841e-06, No Iterations 1
time step continuity errors : sum local = 1.33468e-08, global = -6.52495e-10, cumulative = -0.00426009
PIMPLE: iteration 24
smoothSolver:  Solving for Ux, Initial residual = 7.56872e-07, Final residual = 7.56872e-07, No Iterations 0
smoothSolver:  Solving for Uy, Initial residual = 9.8225e-07, Final residual = 9.8225e-07, No Iterations 0
smoothSolver:  Solving for Uz, Initial residual = 7.97271e-07, Final residual = 7.97271e-07, No Iterations 0
GAMG:  Solving for p, Initial residual = 6.28922e-05, Final residual = 2.75308e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 1.87359e-05, Final residual = 1.57989e-06, No Iterations 1
GAMG:  Solving for p, Initial residual = 8.41619e-06, Final residual = 8.41619e-06, No Iterations 0
time step continuity errors : sum local = 9.53217e-08, global = -4.68415e-10, cumulative = -0.00426009
PIMPLE: iteration 25
smoothSolver:  Solving for Ux, Initial residual = 1.17849e-06, Final residual = 2.35881e-07, No Iterations 1
smoothSolver:  Solving for Uy, Initial residual = 1.50485e-06, Final residual = 3.16389e-07, No Iterations 1
smoothSolver:  Solving for Uz, Initial residual = 1.10602e-06, Final residual = 2.30695e-07, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.173375, Final residual = 0.000960098, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.0175896, Final residual = 0.000171438, No Iterations 4
GAMG:  Solving for p, Initial residual = 0.00764653, Final residual = 9.4887e-07, No Iterations 25
time step continuity errors : sum local = 1.08774e-08, global = -2.42187e-09, cumulative = -0.00426009
smoothSolver:  Solving for omega, Initial residual = 0.00311044, Final residual = 9.36237e-07, No Iterations 5
smoothSolver:  Solving for k, Initial residual = 0.00813339, Final residual = 9.22485e-07, No Iterations 7
PIMPLE: converged in 25 iterations
ExecutionTime = 27986.5 s  ClockTime = 28839 s

faceSource FlowRateInlet output:
    sum(INBLOCK-INFLOW) for phi = -0.135129

faceSource FlowRateOutlet output:
    sum(OUTFLOW) for phi = 0.137318

Unfortunately I cannot share the geometry details or any photographs of the pump since its company data and am not allowed to share.

But I can share the other settings which I have used. You can download from the folllowing drop-box link. You can download the case folder but cannot run it since I have removed the polymesh folder and included the boundary and cellzones file seperately in constant folder.

https://www.dropbox.com/s/1h8dg9ba4t...ation.zip?dl=0

Please help me in this regard. let me know where am going wrong.

I have been stuck on this for quite a long time. I have worked on changing the time schemes, pimple parameters, solvers but anything did not work.

Any help would be appreciated. Thanks in advance.

[coolcrasher]

Hi people ...

Any help guys ....

No one faced such problem yet ????

Please let me know if any more information is needed

[tomf]

Hi, have a look at this bug report:

http://www.openfoam.org/mantisbt/view.php?id=797

[coolcrasher]

Dear Tom,

Thank you for your valuable reply.

I have gone through the thread and have not understood few things.

1) There was a lot of confusion if the bug is resolved and an updated version of openfoam has been released without these bugs.

2) They also said that it may be due to problem the boundary conditions set. But I have the same case and boundaries used in MRF case ( simpleFoam case ). Do I need to change the boundary conditions during the transient case.

3) I have run the simulation with hexa mesh and tetra mesh but still I am facing this problem. I have checked only at inlet and outlet. I would also check the results at AMI patches and post the graphs of what I am getting.

[tomf]

1) A bug was resolved, but not the one about "small errors". Please note that the error between inlet and outlet that you reported is moderately small (1-2%)
2) You may need to change some parts from fixedValue to movingWallVelocity inside the rotating part. There are probably some threads on the forum about this issue.
3) That would be a good way of diagnosing your particular issue.

Good luck,
Tom

[JNSN]

I agree with Tom, if you have a transient simulation with pimpleDyMFoam, you have to set movingWallVelocity. Have a look at the propeller tutorial.

Maybe it also helps tightning the solver tolerances for the pressure equation, let's say from 1e-6 to 1e-8.

Best regards,
Jan

[coolcrasher]

Thanks for reply Jan and Tom

I will look into your suggestions and will post the results how it works before and after changing the boundary conditions.

I shall post the graphs for them

[coolcrasher]

Please find the graphs for flowrates for transient case of ten revolutions and twenty revolutions. Mesh used was hexamesh with boundary treatment.

You can get the graphs from dropbox:
https://www.dropbox.com/s/lzl9iscjlk...sults.zip?dl=0

We can clearly see that there is a increase in flowrate after the fluid passes from AMI1 to AMI2 ( stationary ) this is the reason behind increase in flowrate at outlet.

We observe that the flowrate is fluctuating at Outlet ( which was cased by AMI patches ). The error observed was around 2%.

Also I am looking for results trying movingWallVelocity boundary conditions and also try to simulate similar conditions for tetramesh too.

Is the flowrate at Outlet is expected to fluctuate ? Also is this 2% error is due to bug in pimpleDymFoam or any problem with boundary condition specification.

Any help is welcomed.

Thanks in advance

[tomf]

Well at least these graphs confirm that there is an error generated at the AMI interface. Since it is oscillating, it may be because of the "weights" of the AMI faces that change from one timestep to the next.

Look for lines similar to this:

Patch source sum(weights) min/max/average = 1.00011, 1.00011, 1.00011

If you can match a peak in the error with a low weight (<< 1) or high (>> 1) This may give you an explanation. In that case you would need to remesh especially your AMI interfaces to keep them closer to 1. This value represents how much a face on one of the AMI patches is covered by the neighbouring AMI patch (a value of 0 would represent no covering at all), a value of 1 would indicate a perfect match.

[coolcrasher]

Hi Tom

Thank you for replying.

I have some confusion for your reply.

Do you mean that the flowrate should not fluctuate that much and the cause for it is due to weights at AMI ?

Following is the log for last 5 timesteps for the AMIs.

Courant Number mean: 0.367706 max: 45.7357
Time = 0.403536

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.403536 transformation: ((0 0 0) (0.99916 (0 0 0.040991)))
AMI: Creating addressing and weights between 4228 source faces and 2688 target faces
AMI: Patch source sum(weights) min/max/average = 0.994855, 1.00022, 1.00003
AMI: Patch target sum(weights) min/max/average = 0.999925, 1.00036, 1.00009


Courant Number mean: 0.367705 max: 45.5008
Time = 0.403648

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.403648 transformation: ((0 0 0) (0.999479 (0 0 0.0322889)))
AMI: Creating addressing and weights between 4228 source faces and 2688 target faces
AMI: Patch source sum(weights) min/max/average = 0.993563, 1.00024, 1.00003
AMI: Patch target sum(weights) min/max/average = 0.999912, 1.00028, 1.00009


Courant Number mean: 0.367743 max: 45.3004
Time = 0.40376

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.40376 transformation: ((0 0 0) (0.999722 (0 0 0.0235843)))
AMI: Creating addressing and weights between 4228 source faces and 2688 target faces
AMI: Patch source sum(weights) min/max/average = 0.994106, 1.00024, 1.00003
AMI: Patch target sum(weights) min/max/average = 0.999914, 1.00034, 1.00009


Courant Number mean: 0.367833 max: 45.1381
Time = 0.403872

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.403872 transformation: ((0 0 0) (0.999889 (0 0 0.014878)))
AMI: Creating addressing and weights between 4228 source faces and 2688 target faces
AMI: Patch source sum(weights) min/max/average = 0.994089, 1.00022, 1.00003
AMI: Patch target sum(weights) min/max/average = 0.999959, 1.0003, 1.00009


Courant Number mean: 0.367862 max: 44.8518
Time = 0.403984

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 0.403984 transformation: ((0 0 0) (0.999981 (0 0 0.0061705)))
AMI: Creating addressing and weights between 4228 source faces and 2688 target faces
AMI: Patch source sum(weights) min/max/average = 0.993948, 1.00023, 1.00003
AMI: Patch target sum(weights) min/max/average = 0.999902, 1.00028, 1.00009

From above I have understood that max and average weights for AMI patches are more than one. Also these values change in every time step.

Should they be less than one always and be constant in every timestep ??

Also is this the cause for my mass flowrate error of 2% ?

Please explain.

[tomf]

Hi,

These values are about as good as it can get. They should be around 1. They will oscillate a bit since you are approximating a circular patch discretely. The closer to 1 they are, the better, but the values you report are no problem at all. If they are less than 0.9 at anytime this may be a reason. But you would have to check your log file.

Maybe there is also an influence from the Courant number (45 may be a bit high), you could try to reduce the timestep and see if you have smaller errors.

Please note that I do not know what is causing the error in your case, I am just giving you pointers in directions to investigate from the information you provide.

Regards,
Tom

[coolcrasher]

Hi Tom

That explains everything. Thank you for making time to explain.

Thank you for pointers for investigation though

However, I have some questions:

1) In your previous comments you have mentioned to try movingWallVelocity instead of fixedValue inside the rotating part. I would try so but can you explain me the difference between them. I have read in couple of posts that it should be used when wall is moving with different velocity in each timestep. Like in http://www.cfd-online.com/Forums/ope...ixedvalue.html
Is it exactly the same or am I missing something.

2)Also the equations in Rotor zone are solved in relative frame of reference using parameters set in dynamicMeshDict. when we use foamcalc mag U and patchIntegrate magU at some patch in rotating zone. Does it calculate the velocities in relative frame or absolute frame.

Thanks a lot in advance. questions may be quite silly but am new to openfoam and am very confused how stuff works in pimpleDymFoam.

[tomf]

Hi,

Maybe the following has changed in the most recent versions of OpenFOAM, however I have not checked this:

1). There is a difference between MRF and dynamic mesh here. In MRF you are calculating indeed in a different reference frame depending on the zone. In a dynamic mesh case you are not doing this. The reference frame is the same, however the mesh motion is taken into account. This means in dynamicMesh if you use movingWall, the flux through the wall is being fixed to 0. If you use fixedValue this is not the case.

The thread you mention says that if you have constant velocity you can use fixedValue. However this is only the case if there is no normal velocity to be expected. In case of rotation the velocity is not constant (the direction changes) and this is automatically picked up by the movingWallVelocity boundary condition.

2). No they are not, see the comment above. In case of MRF: yes, otherwise no. As far as I know foamCalc is not aware of any dynamic mesh or MRF, it just looks at the generic Cartesian reference frame.

[coolcrasher]

Thank you for the clarification Tom

Hopefully I get some clues on solving my problem.

Thank you for the information again

[JNSN]

Hi Sravan,

how much is your pump rotating in one time step? A good rule of thumb (at least for open water propeller cases is 0.5 - 1 deg per time step).

Best regards,
Jan

[coolcrasher]

Hi Jan

My pump is rotating 1 degree per timestep.

Also i would like to share the graphs for using movingWallVelocity boundary conditions on my rotating patches. In the following link I have my changed case folder for movingWall BCs and also graphs for flowrates , velocities. unfortunately you cannot run the case since geometry of the pump cannot be shared.

https://www.dropbox.com/s/dffjvidz6w..._Case.zip?dl=0

What I have observed is
1) There is a huge loss of mass flowrate as the flow goes from Rotating AMI to Stationary AMI. ( It was just 2% for fixedValue BC case )
2) There are less fluctuations in flowrate at AMI patches. ( There was high magnitude of fluctuations at the AMI )

I guess movingWallVelocities do not give any better results than fixedValue in my case.

[tomf]

Hi,

From your cellZones file I find that you have less than 300 000 cells for the entire case. This seems to be a bit low. Maybe the error will decrease if you refine the mesh. Obviously this will slow down the simulation. Other settings seem ok at first glance, you may want to investigate the influence of the time discretisation (Backward is more accurate, but less robust than Euler).

Further information could probably come from looking at the results, but you would have to do that yourself since it is proprietary information I guess.

Maybe you can show the output of checkMesh for some other clues.

Regards,
Tom

[coolcrasher]

Hi Tom,

Thank you for your update.

Following is the checkMesh results requested:

Create time

Create polyMesh for time = 7000

Time = 7000

Mesh stats
    points:           311575
    faces:            889864
    internal faces:   846488
    cells:            289392
    faces per cell:   6
    boundary patches: 12
    point zones:      0
    face zones:       2
    cell zones:       2

Overall number of cells of each type:
    hexahedra:     289392
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
   *Number of regions: 2
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "7000/cellToRegion"
  <<Writing region 0 with 178544 cells to cellSet region0
  <<Writing region 1 with 110848 cells to cellSet region1

Checking patch topology for multiply connected surfaces...
    Patch               Faces    Points   Surface topology                  
    OUTFLOW             1184     1229     ok (non-closed singly connected)  
    PIPE                3432     3520     ok (non-closed singly connected)  
    CASING              9676     9870     ok (non-closed singly connected)  
    IF2BACKCHANNEL      1208     1359     ok (non-closed singly connected)  
    IF2IMP-AMI1         4228     4379     ok (non-closed singly connected)  
    PASSAGE-HUB         4786     5090     ok (non-closed singly connected)  
    PASSAGE-SHROUD      4786     5090     ok (non-closed singly connected)  
    PASSAGE-OUTFLOW-AMI22688     2856     ok (non-closed singly connected)  
    BLADE               5472     5814     ok (non-closed singly connected)  
    INBLOCK-HUB         2142     2244     ok (non-closed singly connected)  
    INBLOCK-SHROUD      2142     2244     ok (non-closed singly connected)  
    INBLOCK-INFLOW      1632     1734     ok (non-closed singly connected)  

Checking geometry...
    Overall domain bounding box (-0.252091 -0.232021 -0.526682) (1.15 0.274332 0.0749815)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-5.44028e-17 -2.3469e-17 -9.54647e-17) OK.
    Max cell openness = 1.04888e-15 OK.
    Max aspect ratio = 97.4788 OK.
    Minimum face area = 8.72446e-08. Maximum face area = 0.000588455.  Face area magnitudes OK.
    Min volume = 1.29892e-10. Max volume = 1.56608e-06.  Total volume = 0.0428573.  Cell volumes OK.
    Mesh non-orthogonality Max: 77.509 average: 24.5895
   *Number of severely non-orthogonal (> 70 degrees) faces: 597.
    Non-orthogonality check OK.
  <<Writing 597 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
 ***Max skewness = 4.01477, 2 highly skew faces detected which may impair the quality of the results
  <<Writing 2 skew faces to set skewFaces
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

Yesterday I have compared the velocities at the patches for which I have used movingWallvelocities in rotor region.

I have used movingWallvelocities for the following patches which belong to rotor region:
INBLOCK-HUB, INBLOCK-SHROUD, PASSAGE-HUB, PASSAGE-SHROUD, BLADE

I have used cyclicAMI for the AMI patches. All other patches, same boundary conditon was used as in the normal case which we have been using since long. Please check the following dropbox link for the graphs.

https://www.dropbox.com/s/nix99g5y63...re_mw.zip?dl=0

( Note: _mw has been used to signify that it is for movingWall case )

I have used patchAverage at the patches to get the velocity at the patches. Following are the observations found.

1) For the patches which are used in rotor region ( Check VelComparisonRotorRegion folder ), we see that for fixedValue case the velocities are zero at the patches. While for the same patches using movingWallVelocities they have some positive velocities at the walls.
2) For the AMI patches used, we see that fluid has same velocity at both the patches in both fixedValue case and movingWall case. ( Check VelComparisonAMIs,OUTLET folder )
3) Also For AMI patches used, we see that less velocity fluctuations in case of movingWall than in fixedValue case. Mean vel at AMI patches for movingWall case is just a little higher than in fixedValue case ( say 0.5 - 1% ). This should not cause much difference in flowrate which was very huge ( more than 30 % )
4) For the patch in stationary domain ( compared only for IF2BACKCHANNEL ) we see that velocity at patch is zero for both the cases, since same boundary condition of fixedValue was used at the patch.

From these comparisons I see that there is not much change in velocites at AMI patches in both cases but there is there is a huge change in flowrates in both the cases. Am curious whats the reason behind it. Since velocities and surface areas are same we expect same flowrates in both the cases.

Also to cross check I have checked the flowrates calculations manually. Like the following
flowrate = SurfaceArea * mean velocity at patch.

I got the same results as calculated by OpenFoam for Inlet and Outlet patches. But for AMI patches its not the same. Also it is more than what is required ( which is 0.135, I get around 1.4 ). Not sure how the flowrate has been calculated at AMIs by OpenFoam.

[tomf]

If I understand correctly you see similar velocities on the AMI patches, but different flowrates?

I do remember some problems with orientation of faces and also found this bug report: http://www.openfoam.org/mantisbt/view.php?id=1380

I do not know if this is related to your problem, but it might be.

Maybe it helps to use paraview to calculate the flow rates?

Regards,
Tom

[coolcrasher]

Hi all,

Last few days we were running some simulations and this time we have used tetramesh with finer mesh at boundaries ( previously hexamesh with boundary layer refinement ). We have tried with both fixedValue and movingWall boundary condition for rotating patches for velocities. ( like suggested , from propeller tutorial )

We have seen that the for fixed value the flowrates are almost balancing but a difference of 1-2% is observed. But the velocities , pressure, moments values are not meaningful, physical and are very high values.

For movingWall case the flowrates are not balancing, a difference of 7% is observed. But velocities , pressures , moments are meaningful and not sure if they are correct. Further reducing the timestep by half we can reduce this error to 5% maximum. ( timestep taken is 1 deg of rotation per timestep )

Following are the Plot results of velocities and flowrates at inlet, outlet, AMIs.
https://www.dropbox.com/s/mhtrg63q1m...gWall.zip?dl=0

As said before we see that at AMIs there is a mismatch of flowrates of 7% and also the area averaged magU over both the AMI patches are same ( calculated using foamCalc magU, patchAverage magU).

Is this 7% loss due to AMI error already present in pimpleDyMFoam ( the bug which we were referring to before )

Any suggestions for further improvement of the case ??