CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Particle Fate in DPMFoam or MPPICFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes
  • 2 Post By wyldckat
  • 1 Post By wyldckat

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 29, 2019, 13:53
Default Particle Fate in DPMFoam or MPPICFoam
  #1
Member
 
Ramin
Join Date: Oct 2015
Posts: 33
Rep Power: 7
rmn_990 is on a distinguished road
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:
Code:
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:
Code:
/*--------------------------------*- 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
{}

Last edited by wyldckat; April 30, 2019 at 19:34. Reason: [QUOTE]->[CODE]
rmn_990 is offline   Reply With Quote

Old   April 30, 2019, 19:52
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,962
Blog Entries: 45
Rep Power: 123
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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!
Code:
 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 and NatJ like this.
__________________
wyldckat is offline   Reply With Quote

Old   April 30, 2019, 22:05
Default
  #3
Member
 
Ramin
Join Date: Oct 2015
Posts: 33
Rep Power: 7
rmn_990 is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
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!
Code:
 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
rmn_990 is offline   Reply With Quote

Old   May 1, 2019, 10:44
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,962
Blog Entries: 45
Rep Power: 123
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quick answers:
Quote:
Originally Posted by rmn_990 View Post
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.

Quote:
Originally Posted by rmn_990 View Post
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:
    Code:
    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...
rmn_990 likes this.
wyldckat is offline   Reply With Quote

Old   April 22, 2020, 04:24
Default
  #5
Member
 
Join Date: Jun 2016
Posts: 61
Rep Power: 6
xuegy is on a distinguished road
Hello,

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

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

Last edited by xuegy; April 22, 2020 at 11:31.
xuegy is offline   Reply With Quote

Reply

Tags
dpmfoam, mppicfoam, particle

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
UDF for particle interception with pt_termination fortran routine abcdefgh CFX 6 October 6, 2019 13:30
Lagranian particle graph plotting in DPMFoam or MPPICFoam surajkvs OpenFOAM Post-Processing 0 July 15, 2017 05:30
Particle tracking error alchem OpenFOAM Bugs 5 May 6, 2017 16:30
Can we use MPPICFoam or DPMFoam for particle transport in open environment? Mehar OpenFOAM Running, Solving & CFD 0 December 14, 2016 00:41
injection problem Mark New FLUENT 0 August 4, 2013 01:30


All times are GMT -4. The time now is 04:22.