[carye]

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

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.

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;
}

[mohamadalimirzaei1994]

could you find the problem?

[GerhardHolzinger]

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.

[oswald]

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.

[carye]

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?

[oswald]

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?

[ktron]

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:

       interpolationSchemes
        {
                U.bulk  cellPointWallModified;
                U       cellPoint;
                rho.bulk        cell;
                rho     cell;
                mu.bulk cell;
                mu      cell;
                alpha.bulk cell;
                curlUcDt cellPatchConstrained; //for SaffmanMeiLiftForce

        }

[Patrick_18]

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 ??

[ktron]

Originally Posted by 16bme110@nirmauni.ac.in

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 ??

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.

[Patrick_18]

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.

[Patrick_18]

Can you provide more information about isotropy model - stochastic ??

[ktron]

Originally Posted by 16bme110@nirmauni.ac.in

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.

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.

[ktron]

Originally Posted by 16bme110@nirmauni.ac.in

Can you provide more information about isotropy model - stochastic ??

For OpenFOAM 8 MPPICFoam it would be defined in
const/kinematicCloudProperties under subModels as

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.