|
[Sponsors] |
strange stuck particles on the rebound wall in MPPICFoam |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 13, 2020, 23:56 |
strange stuck particles on the rebound wall in MPPICFoam
|
#1 |
Member
Join Date: May 2013
Posts: 34
Rep Power: 13 |
Hi foamers!
recently I am working on a cyclone simulation using the MPPICFoam. However, in my simulation some strange thing happens... I set the wall of the cyclone body as rebound, but find many particles "stuck" on some wall cells, as the figure shows... These particles have almost zero velocity, and never move anymore. This behavior causes some cells that have particles "Max cell volume fraction" large than 1 and finally leads to diverge. It is quite weird, but I don't know why this happen... I used checkMesh -allGeometry -allTopology and found mesh is no problem. here I uploaded the checkMesh output and the kinematicCloudProperties, hope that you can help me to figure out why this happen. Thank you! checkMesh Code:
Mesh stats points: 528659 faces: 1549270 internal faces: 1500346 cells: 511636 faces per cell: 5.96052 boundary patches: 4 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 493776 prisms: 13532 wedges: 0 pyramids: 0 tet wedges: 24 tetrahedra: 0 polyhedra: 4304 Breakdown of polyhedra by number of faces: faces number of cells 4 2316 5 1988 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. Upper triangular ordering OK. Face vertices OK. Topological cell zip-up check OK. Face-face connectivity OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology Bounding box inlet 360 403 ok (non-closed singly connected) (0.15 -0.075 -0.075) (0.15 1.38778e-17 -0.045) outlet_down 392 409 ok (non-closed singly connected) (-0.0281238 -0.675 -0.0281238) (0.0281238 -0.675 0.0281238) outlet_up 708 741 ok (non-closed singly connected) (-0.0374992 0.0749962 -0.0374992) (0.0374992 0.075 0.0374992) walls 47464 49813 ok (non-closed singly connected) (-0.075 -0.675 -0.0750128) (0.15 0.075 0.075) Checking faceZone topology for multiply connected surfaces... No faceZones found. Checking basic cellZone addressing... No cellZones found. Checking geometry... Overall domain bounding box (-0.075 -0.675 -0.0750128) (0.15 0.075 0.075) Mesh has 3 geometric (non-empty/wedge) directions (1 1 1) Mesh has 3 solution (non-empty) directions (1 1 1) Boundary openness (-6.66068e-17 7.19281e-17 -2.11363e-16) OK. Max cell openness = 2.90223e-16 OK. Max aspect ratio = 4.39896 OK. Minimum face area = 1.66225e-06. Maximum face area = 1.35877e-05. Face area magnitudes OK. Min volume = 1.78339e-09. Max volume = 2.88198e-08. Total volume = 0.00798391. Cell volumes OK. Mesh non-orthogonality Max: 45.3365 average: 2.78553 Non-orthogonality check OK. Face pyramids OK. Max skewness = 1.01824 OK. Coupled point location match (average 0) OK. Face tets OK. Min/max edge length = 0.000804677 0.00521602 OK. All angles in faces OK. Face flatness (1 = flat, 0 = butterfly) : min = 0.8901 average = 0.999757 All face flatness OK. Cell determinant (wellposedness) : minimum: 0.0270408 average: 0.946175 Cell determinant check OK. Concave cell check OK. Face interpolation weight : minimum: 0.165768 average: 0.494947 Face interpolation weight check OK. Face volume ratio : minimum: 0.134485 average: 0.973873 Face volume ratio check OK. Mesh OK. Code:
FoamFile { version 2.0; class dictionary; format ascii; location "constant"; object kinematicCloudProperties; } solution { active true; coupled true; averagingMethod dual; transient true; cellValueSourceCorrection false; maxCo 0.9; sourceTerms { schemes { rho explicit 1.0; Yi explicit 1.0; h explicit 1.0; U semiImplicit 1.0; radiation explicit 1.0; } } interpolationSchemes { U.air cellPoint; U cellPoint; rho.air cell; rho cell; mu.air cell; mu cell; } integrationSchemes { T analytical; U Euler; } } constantProperties { rho0 1185.8; // alphaPacked 0.6; // e 0.9; alphaMax 0.9; // constantVolume true; } subModels { injectionModels { injector_1 { type patchInjection; duration 50.0; patch inlet; massTotal 0.0826; parcelsPerSecond 50000; // massFlowRate 0.0; parcelBasisType mass; // nParticle 10; U0 (-3.411222923 0.0 0.0); SOI 2.0; // start of injection flowRateProfile constant 1.0; sizeDistribution { type normal; normalDistribution { minValue 2.0E-6; expectation 10.0E-6; variance 2.0E-6; maxValue 50.0E-6; } } } } compositionModel none; phaseChangeModel none; collisionModel none; dispersionModel none; devolatilisationModel none; heatTransferModel none; stochasticCollisionModel none; breakupModel none; isotropyModel none; radiation none; surfaceReactionModel none; dampingModel none; atomizationModel none; surfaceFilmModel none; particleForces { gravity; ErgunWenYuDrag { alphac alpha.air; } } patchInteractionModel localInteraction; localInteractionCoeffs { patches ( inlet { type rebound; e 0.97; mu 0.09; } outlet_down { type escape; } walls { type rebound; e 0.97; mu 0.09; } outlet_up { type escape; } ); } packingModel none; dampingModel none; isotropyModel none; } |
|
September 3, 2020, 12:43 |
|
#2 |
New Member
mohamad ali mirzaei
Join Date: Feb 2017
Posts: 27
Rep Power: 9 |
could you find the problem?
|
|
September 4, 2020, 04:39 |
|
#3 |
Senior Member
Gerhard Holzinger
Join Date: Feb 2012
Location: Austria
Posts: 342
Rep Power: 28 |
What is the boundary condition for the fluid velocity?
I experienced problems with Lagrangian particle tracking with particles also getting stuck on the walls. The reason was caused by an interaction of the fluid boundary condition (noSlip) and the velocity-interpolation scheme (cellPoint) for the particles. In cells next to the wall, the fluid velocity is linearly interpolated between the cell value and zero at the wall. The noSlip BC for the fluid mandates the zero value at the wall, and the cellPoint interpolation mandates the linear interpolation between the two values. Try the interpolationCellPointWallModified interpolation scheme for the particle velocity, which was added by commit 63b641a. This interpolation scheme should avoid the linear interpolation down to zero near the wall. |
|
September 4, 2020, 04:58 |
|
#4 |
Member
Join Date: Sep 2010
Location: Leipzig, Germany
Posts: 96
Rep Power: 16 |
As I also encountered this behaviour sometimes, here are some of my thoughts on this:
1) The drag force model is not valid in near wall regions. There are models for correcting this, see for example here: https://aip.scitation.org/doi/10.1063/1.3082232 2) As the fluid velocity is set to zero at the wall, it won't be much more in some µm-scale distance. As your particles are quite small, they might be stuck in a region with very small velocity as they adapt the fluid velocity very fast.) 3) You could try enabling the shear lift force (for solid particles use SaffmanMeiLift). This should lift your particles away from the wall (at the cost of a little more computational effort). @GerhardHolzinger: Thanks for this hint. I had never thought about using this interpolation method. |
|
June 18, 2021, 06:22 |
|
#5 |
Member
Join Date: May 2013
Posts: 34
Rep Power: 13 |
Hey, thank you for your replies!
I haven't done the cyclone calculation for a while, but I started a new research related to particles and got the same problem again. I have tried the cellPointWallModified interpolation scheme for particle velocity, but did not solve the problem: particles still got stuck on some wall cells. However, I found the stochastic isotropyModel enables the calculation to avoid the stuck problem, but I don't know why. Next I'd like to try to add the SaffmanMeiLift for particles to see what will happen just as you guys suggested. But, what I'm confused about is that I set both the ErgunWenYuDrag and gravity force for particle. So if it is related to the noSlip BC and the particle velocity becomes zero, why not the particle start to fall due to the gravity? |
|
June 24, 2021, 03:25 |
|
#6 |
Member
Join Date: Sep 2010
Location: Leipzig, Germany
Posts: 96
Rep Power: 16 |
Maybe there are some additional mechanisms due to inter-particle stress etc. which keep the particles at the wall? What is the mass/volume fraction in these regions?
Furthermore, without knowing more about the case it is hard to develop ideas why the particles get stuck. Maybe gravity and drag cancel out each other as soon as particles see a non-zero velocity near these walls? |
|
March 7, 2022, 07:54 |
Stuck particles resolved
|
#7 |
New Member
Kathrin Skinder
Join Date: Apr 2021
Location: Germany, Clausthal-Zellerfeld
Posts: 12
Rep Power: 5 |
Hi,
I faced the same problem of strangely stuck particles at walls. I tried the three previous suggestions (1. SaffmanMeiLiftForce I was using anyway, 2. isotropyModel changed from "none" to "stochastic", 3. interpolation scheme for U changed from "cellPoint" to "cellPointWallModified"). They did not solve the problem for me. However, I had suspected for some time, that the problem was caused by the interpolation of the bulk velocity at the cell adjacent to the wall. So I tried using "cellPointWallModified" not for U, but for U.bulk. And it worked! Thank you so much for pointing out that there is an interpolationCellPointWallModified. I did not know that before. I then read a little about it in here: https://cpp.openfoam.org/v8/classFoa...lModified.html where it says about "interpolationCellPointWallModified": "As interpolationCellPoint, but with the point field modified on wall faces. This method is defined only for vectors. The point field is extrapolated from the cells to the wall faces, and then rotated towards the (reverse) point normal so that the vectors do not point out of the domain. The result is also scaled so so if the necessary rotation exceeds 90 degrees, it is clamped to zero. This prevents unresolvable drag-rebound couplings when applied to the velocity interpolation in a Lagrangian simulation." If I understand this correctly, the stuck particle problem is caused by velocity vectors pointing out of the domain when using "cellPoint" interpolation. CellPoint seems to also extrapolate from cell centers to the wall faces, so sometimes it may cause a nonzero velocity pointing outwards at the wall. When using this with the wallInteractionModel "rebound", the particles can not get out, and in my case they also did not stick to the wall. That is really bad, because those particles will still be calculated and slow down the whole calculation, although they are practically in a "stick" condition. Not to mention, that the calculations will be just wrong Also, this might explain why the strange particles at the wall do not follow the direction of gravity, even though their velocity is zero (I also observed this and did not have a clue how this could happen ). But with an outward pointing extrapolated bulk velocity, it would make sense. Hope this helps someone maybe! Here is my setup for the interpolationSchemes in kinematicCloudProperties, OpenFOAM v8, solver MPPICFoam, for clarity: Code:
interpolationSchemes { U.bulk cellPointWallModified; U cellPoint; rho.bulk cell; rho cell; mu.bulk cell; mu cell; alpha.bulk cell; curlUcDt cellPatchConstrained; //for SaffmanMeiLiftForce } |
|
April 4, 2022, 03:55 |
Particle stick on the wall
|
#8 |
New Member
Pratik
Join Date: Oct 2018
Posts: 11
Rep Power: 8 |
I have solved problem of solid particle (as given lagrangian folder of Openfoam) in which I have included in built drag formula and added ho and leal lift equation. I have tried your suggestions 1) cellpoint wallpoint modified scheme for fluid velocity 2) rebound formulation as given in local interaction. But still particle are attached with wall and moving with particle velocity at every time step .
Boundary condition : fluid Inlet uniform velocity wall no-slip velocity outlet zero gradient particle : Inlet uniform velocity outlet escape wall rebound Can you provide any solution for this ?? |
|
April 4, 2022, 06:42 |
|
#9 | |
New Member
Kathrin Skinder
Join Date: Apr 2021
Location: Germany, Clausthal-Zellerfeld
Posts: 12
Rep Power: 5 |
Quote:
Hi, your boundary conditions look fine. Can you give more details? Are you using MPPICFoam solver? What do you mean by "But still particle are attached with wall and moving with particle velocity at every time step." ?They are attached to the wall, but still moving? Then maybe it is not the same problem. Or did you mean to say, they move with the wall velocity? Where is your wall located, and are you using "gravity" force? Are you completely sure, that particles at the wall is the "wrong" solution? Did you assign coefficients for the rebound model (e and mu)? If so, maybe try leaving them out once for making sure your particles are not just very slow due to elasticity and friction at the wall. Also, see post from carye: Maybe try isotropyModel stochastic. |
||
April 4, 2022, 07:37 |
Particle stuck on wall
|
#10 |
New Member
Pratik
Join Date: Oct 2018
Posts: 11
Rep Power: 8 |
I am using own solver simpleLPTfoam solver, which uses lagrangian modified soldiparticle. The fluid pressure and velocity are map using mapfield from other simplefoam solver.
I used rebound criteria with e =1 and mu =0 When I played trajectory of particle, at intermediate time-step it stick on the wall. when I move to next time step, particles are remains stuck on the wall but it moves according to lagrangian velocity. I have entered only drag and lift equation in lagrangian velocity calculations. |
|
April 4, 2022, 08:20 |
|
#11 |
New Member
Pratik
Join Date: Oct 2018
Posts: 11
Rep Power: 8 |
Can you provide more information about isotropy model - stochastic ??
|
|
April 4, 2022, 08:30 |
|
#12 | |
New Member
Kathrin Skinder
Join Date: Apr 2021
Location: Germany, Clausthal-Zellerfeld
Posts: 12
Rep Power: 5 |
Quote:
So the particle position does not change from one to the next timestep, but it is assigned a velocity value significantly larger than zero, which points in a direction that the particle could move in? It sounds to me, like this is a different problem than what carye originally described, and that I also had. I'm afraid I can't help you, I have never seen particles having a velocity but not moving. If your are using a custom solver, maybe there is something wrong with the particle positions updating. But honestly, I have no clue. |
||
April 4, 2022, 08:52 |
|
#13 | |
New Member
Kathrin Skinder
Join Date: Apr 2021
Location: Germany, Clausthal-Zellerfeld
Posts: 12
Rep Power: 5 |
Quote:
For OpenFOAM 8 MPPICFoam it would be defined in const/kinematicCloudProperties under subModels as Code:
subModels { isotropyModel stochastic; } I don't know the details about it, just read that it helped carye with the stuck particle problem. So, not sure if it is a good idea to use it. But try it and see what it does See the description here https://cpp.openfoam.org/v8/Stochastic_8H_source.html But I think your solver probably does not use the same cloud type, so I don't know how it can be defined in your case. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Divergence in AMG solver! | marina | FLUENT | 20 | August 1, 2020 12:30 |
Wall-Modeled LES Strange Behavior Near Wall | Sereff | OpenFOAM Running, Solving & CFD | 6 | May 21, 2020 17:27 |
When particles rebound, what's the wall velocity? | d849c8 | OpenFOAM Programming & Development | 1 | July 13, 2015 21:09 |
Difficulty In Setting Boundary Conditions | Moinul Haque | CFX | 4 | November 25, 2014 18:30 |
strange wall heat transfer coefficient | Lea | FLUENT | 2 | December 18, 2012 10:23 |