[rmn_990]

Hi,
I did a simulation with DPMFoam and I considered different wall condition for each boundary( escape, rebound, etc.).
The illogical thing is that I just inject 550,000 particles in 5 seconds but after running, I can see that more than injected particles (999M particles on one of the boundaries), I have some particles which go outside of the system or stick on one of the boundaries. I am using OpenFoam 18.12 and for some reasons ( I want to use MPPICInterFoam solver in the future and it can not be found in OpenFoam 6) I cannot use another version.
This is the log file and it can show the distribution of particles on each boundary after 314s:

Courant Number mean: 0.111537 max: 0.968023
Interface Courant Number mean: 0 max: 0
deltaT = 0.00666667
Time = 314.193

Evolving kinematicCloud

Solving 3-D cloud kinematicCloud
GAMG:  Solving for kinematicCloud:alpha, Initial residual = 0.0014182, Final residual = 0.00109688, No Iterations 1000
Cloud: kinematicCloud
    Current number of parcels       = 287167
    Current mass in system          = 1.57878e-10
    Linear momentum                 = (2.97358e-15 -1.83809e-15 1.12724e-14)
   |Linear momentum|                = 1.1802e-14
    Linear kinetic energy           = 6.06593e-16
    Injector model1:
      - parcels added               = 549986
      - mass introduced             = 3.02371e-10
    Parcel fate: system (number, mass)
      - escape                      = 262819, 1.44492e-10
    Parcel fate: patch WALL_IN (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate: patch WALL_OUT (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate: patch LUMEN_WALL (number, mass)
      - escape                      = 0, 0
      - stick                       = 944675672, 5.19376e-07
    Parcel fate: patch OUTLET (number, mass)
      - escape                      = 262819, 1.44483e-10
      - stick                       = 0, 0
    Parcel fate: patch INLET (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Min cell volume fraction        = 0
    Max cell volume fraction        = 2.13323e-05
    Min dense number of parcels     = 5.5605

Continous phase-1 volume fraction = 1  Min(alphac) = 0.999979  Max(alphac) = 1
PIMPLE: iteration 1
smoothSolver:  Solving for alpha.water, Initial residual = 0.013389, Final residual = 0.0114096, No Iterations 100
Phase-1 volume fraction = 1  Min(alpha.water) = 1  Max(alpha.water) = 1
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 1  Min(alpha.water) = 1  Max(alpha.water) = 1
smoothSolver:  Solving for alpha.water, Initial residual = 0.0115916, Final residual = 0.0115598, No Iterations 100
Phase-1 volume fraction = 1  Min(alpha.water) = 1  Max(alpha.water) = 1
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 1  Min(alpha.water) = 1  Max(alpha.water) = 1
DICPCG:  Solving for p_rgh, Initial residual = 2.09388e-06, Final residual = 9.41566e-08, No Iterations 4
time step continuity errors : sum local = 5.14021e-11, global = -8.3902e-12, cumulative = -6.26016e-09
DICPCG:  Solving for p_rgh, Initial residual = 3.24005e-06, Final residual = 1.60079e-07, No Iterations 7
time step continuity errors : sum local = 8.73903e-11, global = -1.33005e-11, cumulative = -6.27346e-09
DICPCG:  Solving for p_rgh, Initial residual = 1.38674e-06, Final residual = 9.51116e-09, No Iterations 442
time step continuity errors : sum local = 5.19234e-12, global = 3.77542e-15, cumulative = -6.27346e-09
ExecutionTime = 40261.9 s  ClockTime = 40514 s

Courant Number mean: 0.111537 max: 0.968022
Interface Courant Number mean: 0 max: 0
deltaT = 0.00666667
Time = 314.2

This is KinematicCloudProperties file:

/*--------------------------------*- C++ -*----------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      particleProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solution
{
    active          true;
    coupled         true;
    transient       yes;
    cellValueSourceCorrection off;

    maxCo           1.0;

    interpolationSchemes
    {
        rho             cell;
        U            cellPoint;
        mu            cell;
    }

    averagingMethod dual;

    integrationSchemes
    {
        U               Euler;
    }

    sourceTerms
    {
        schemes
        {
            U           semiImplicit 0.00078;
        }
    }
}

constantProperties
{
    rho0            1050;
    alphaMax        0.9;
}

subModels
{
    particleForces
    {
        ErgunWenYuDrag
        {
            alphac alphac;
        }
        gravity;
    }

    injectionModels
    {
        model1
        {
            type            patchInjection;
            parcelBasisType fixed;
            SOI             0;
            patch       INLET;
            duration        5;
        nParticle       1;
            parcelsPerSecond 110000;
        massTotal       2.84e-11;
            U0              (0 0 0);
            flowRateProfile constant 2.5e-8;
            sizeDistribution
            {
        type        fixedValue;
                fixedValueDistribution
                {
                    value   0.000001;
                }
        }
        }
    }

    dispersionModel none;

    patchInteractionModel localInteraction;

    localInteractionCoeffs
    {
        patches
        (
            WALL_IN
            {
                type rebound;
                e    0.97;
                mu   0.09;
            }
            WALL_OUT
            {
                type rebound;
                e    0.97;
                mu   0.09;
            }
            LUMEN_WALL
            {
                type stick;
            }
            OUTLET
            {
                type escape;
            }
            INLET
            {
                type rebound;
                e    0.97;
                mu   0.09;
            }
        );
    }

    heatTransferModel none;

    surfaceFilmModel none;

    packingModel implicit;

    explicitCoeffs
    {
        particleStressModel
        {
            type HarrisCrighton;
            alphaPacked 0.6;
            pSolid 10.0;
            beta 2.0;
            eps 1.0e-7;
        }
        correctionLimitingMethod
        {
            type absolute;
            e 0.9;
        }
    }

    implicitCoeffs
    {
        alphaMin 0.0001;
        rhoMin 1.0;
        applyLimiting true;
        applyGravity false;
        particleStressModel
        {
            type HarrisCrighton;
            alphaPacked 0.6;
            pSolid 5.0;
            beta 2.0;
            eps 1.0e-2;
        }
    }

    dampingModel none;

    isotropyModel stochastic;

    stochasticCoeffs
    {
        timeScaleModel
        {
            type isotropic;
            alphaPacked 0.6;
            e 0.9;
        }
    }

    stochasticCollisionModel none;

    radiation off;
}


cloudFunctions
{}

[wyldckat]

Quick answer: I received the PM you sent me and I came here...
Oh, so you were the one who opened this bug report: https://bugs.openfoam.org/view.php?id=3228

I really need to ask you this: Why did you open the bug report on that website?

Because I'm still confused as to why you and many others will open a bug report at the wrong website... if you downloaded from OpenFOAM.com, why did you try to report it on OpenFOAM.org?
Sorry, it's just that I do want to help people, but if people ask the questions in the wrong place, we can't help them in the correct place...


OK, as for the problem you are having... Oh, it does look like a bug! A weird one a that!

 Parcel fate: patch LUMEN_WALL (number, mass)
      - escape                      = 0, 0
      - stick                       = 944675672, 5.19376e-07

This looks like a memory leak somewhere...


A question: Did you run the case in parallel mode or in serial mode? Because if you ran in parallel mode, this could the due to a bug in the parallelization algorithm...

Either way, what I suggest you do in order to get a proper solution for this:

1. If you don't have a small test case, create one. Preferably one based on the OpenFOAM v1812 tutorial cases and based on blockMeshDict only, so that it's a fairly easy mesh to generate and quick to simulate.
2. Package the case (compress the folder with ZIP) in a way where the case is ready to be meshed and simulated, but does not yet have the mesh generated nor any simulated time steps.
3. Then open a bug report and attach that case at the correct issue tracker, namely this one: https://develop.openfoam.com/Develop...AM-plus/issues

Because this really looks like a bug and without a good+quick test case, it's nearly impossible to diagnose what is going on wrong here.

[rmn_990]

Originally Posted by wyldckat

Quick answer: I received the PM you sent me and I came here...
Oh, so you were the one who opened this bug report: https://bugs.openfoam.org/view.php?id=3228

I really need to ask you this: Why did you open the bug report on that website?

Because I'm still confused as to why you and many others will open a bug report at the wrong website... if you downloaded from OpenFOAM.com, why did you try to report it on OpenFOAM.org?
Sorry, it's just that I do want to help people, but if people ask the questions in the wrong place, we can't help them in the correct place...


OK, as for the problem you are having... Oh, it does look like a bug! A weird one a that!

 Parcel fate: patch LUMEN_WALL (number, mass)
      - escape                      = 0, 0
      - stick                       = 944675672, 5.19376e-07

This looks like a memory leak somewhere...


A question: Did you run the case in parallel mode or in serial mode? Because if you ran in parallel mode, this could the due to a bug in the parallelization algorithm...

Either way, what I suggest you do in order to get a proper solution for this:

1. If you don't have a small test case, create one. Preferably one based on the OpenFOAM v1812 tutorial cases and based on blockMeshDict only, so that it's a fairly easy mesh to generate and quick to simulate.
2. Package the case (compress the folder with ZIP) in a way where the case is ready to be meshed and simulated, but does not yet have the mesh generated nor any simulated time steps.
3. Then open a bug report and attach that case at the correct issue tracker, namely this one: https://develop.openfoam.com/Develop...AM-plus/issues

Because this really looks like a bug and without a good+quick test case, it's nearly impossible to diagnose what is going on wrong here.

Thanks a lot for your response to my question.
I actually thought that openfoam.com and openfoam.org are the same but they provide a different version of op. So I deleted my thread there.

I tried to solve this case in serial and everything works fine.

If I want to discuss more this simulation:
First I wanted to do a simulation on my case study with MPPICFoam. The problem with this solver was that my flow was somehow buoyant and I couldn't get a good result. Especially for velocity which went high without any reason and there was backflow at the outlet with all the possible boundary conditions (I tried more than 100 BC and none of them worked). One of the experienced users of OpenFOAM suggested me to substitute P from MPPICFoam with p_rgh to handle this buoyant flow.

As far as I didn't know how to change the code, I tried to use MPPICInterFoam in OP18.12 (OP6 doesn't have this solver) that works with p_rgh instead of p. This could solve my problem with fluid flow.

Next problem which now I am facing is that the number of particles is not logical with MPPICInterFoam in parallel. I have heard that this bug solved in OP6.

Now the only solution which I have is to make a new solver from MPPICFoam in OP6 which solve p_rgh instead of P. Unfortunately, I couldn't find any tutorial for that.
It would be highly appreciated if you can help me in making this change.

Thanks

[wyldckat]

Quick answers:

Originally Posted by rmn_990

Next problem which now I am facing is that the number of particles is not logical with MPPICInterFoam in parallel. I have heard that this bug solved in OP6.

You can try building the development branch for OpenFOAM-plus: https://develop.openfoam.com/Develop...s/tree/develop - with luck this bug is already fixed in that development version.

If you need help building it, I will need to know which Linux Distribution you are using, in order to write the instructions for it.

Because even if it's not fully fixed on the current development line, you could them open the bug report and ask for the bug to be fixed. Then as soon as it is fixed, you can update your build.

Originally Posted by rmn_990

Now the only solution which I have is to make a new solver from MPPICFoam in OP6 which solve p_rgh instead of P. Unfortunately, I couldn't find any tutorial for that.
It would be highly appreciated if you can help me in making this change.

I don't have enough free time to try and help you with that, but here are a few steps I suggest you take:

1. Study the following tutorials on how to code in OpenFOAM:
   1. https://wiki.openfoam.com/Day_11
   2. https://wiki.openfoam.com/Day_12
   3. https://wiki.openfoam.com/Day_13
2. Compare the source code of the solvers pimpleFoam and buoyantPimpleFoam, to see what changes were done in order to properly account for buoyancy. You have a hard time finding where the source code for them are, then run these commands:
   

   find $FOAM_SOLVERS -name pimpleFoam
   find $FOAM_SOLVERS -name buoyantPimpleFoam

3. If you don't know how to compare source code, Meld and Kompare are at least 2 graphically interactive applications you can use to compare files and folders.

That said, I looked for your previous posts and found this thread of yours: Add P_rgh to solver with P - I will ask you a few more questions there...

[xuegy]

Hello,

I'm having similar problem using v1912, happens in both serial and parallel

    Current number of parcels       = 2811
    Current mass in system          = 1.54543e-12
    Linear momentum                 = (3.40417e-16 -1.45319e-20 -2.17755e-20)
   |Linear momentum|                = 3.40417e-16
    Linear kinetic energy           = 4.70115e-20
    Average particle per parcel     = 1
    Injector model1:
      - parcels added               = 3352
      - mass introduced             = 1.84286e-12
    Parcel fate: system (number, mass)
      - escape                      = 39221387, 2.15631e-08
    Parcel fate: patch walls (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate: patch inlet (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate: patch outlet (number, mass)
      - escape                      = 541, 2.9743e-13
      - stick                       = 0, 0

If you take a look at the number, 3352=2811+541. But how can 39221387 particles escaped the system?