Big particle

Submitted by rqwang on Wed, 09/14/2011 - 16:45

Hi, cfdemers,

I am using a very dense gridmesh.
When I simulate a single particle settling in water, all the momentum induced by the particle seems to transfer into one single cell.

Is there any way to disperse the induced momentum into a large area.

In another words, is it possible not to restrict the induced momentum in a single cell, but by some averaging model like PSI-cell method?

Thanks.

rq

cgoniva's picture

cgoniva | Wed, 09/14/2011 - 16:48

Hi!

have a look at the bigParticle voidfraction model -
you can "boost" the volume and "disperse" the momentum and volume to a larger area.

Cheers,
Chris

rqwang | Thu, 09/15/2011 - 00:05

Thanks for your advise, Chris.

I used bigParticle but the process has some unknown error like this

Time = 0.0001

Courant Number mean: 0 max: 0
- evolve()
Starting up LIGGGHTS
Executing command: 'run 100 '
run 100 Setting up run ...
Memory usage per processor = 6.01829 Mbytes
Step Atoms KinEng 1 Volume
1 1 0 0 0.0020971516
101 1 0 0 0.0020971516
*** glibc detected *** cfdemSolverPiso_shared: free(): invalid next size (fast): 0x000000001f5c2aa0 ***
*** glibc detected *** cfdemSolverPiso_shared: free(): invalid next size (fast): 0x0000000011bbb190 ***
*** glibc detected *** cfdemSolverPiso_shared: free(): invalid next size (fast): 0x000000001cd2ff60 ***
Loop time of 0.0692714 on 8 procs for 100 steps with 1 atoms

Pair time (%) = 1.28746e-05 (0.0185857)
Neigh time (%) = 0 (0)
Comm time (%) = 0.000263721 (0.380707)
Outpt time (%) = 2.31862e-05 (0.0334716)
Other time (%) = 0.0689716 (99.5672)

Nlocal: 0.125 ave 1 max 0 min
Histogram: 7 0 0 0 0 0 0 0 0 1
Nghost: 0 ave 0 max 0 min
Histogram: 8 0 0 0 0 0 0 0 0 0
Neighs: 0 ave 0 max 0 min
Histogram: 8 0 0 0 0 0 0 0 0 0

Total # of neighbors = 0
Ave neighs/atom = 0
Neighbor list builds = 0
Dangerous builds = 0
LIGGGHTS finished

timeStepFraction() = 1
evolve done
update Ksl.internalField()
totaldragforceEuler calculus
totaldragforceEuler = 0
======= Backtrace: =========
======= Backtrace: =========
/lib64/libc.so.6[0x3452071ce2]
/lib64/libc.so.6[0x3452071ce2]
======= Backtrace: =========
/lib64/libc.so.6(cfree+0x8c)[0x345207590c]
/lib64/libc.so.6(cfree+0x8c)[0x345207590c]
/lib64/libc.so.6[0x3452071ce2]
/usr/local/OpenFOAM/OpenFOAM-2.0.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4Foam8OSstream5writeEPKc+0xd8)[0x2b8435a38d38]
/usr/local/OpenFOAM/OpenFOAM-2.0.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4Foam8OSstream5writeEPKc+0xd8)[0x2b55359edd38]
/usr/local/OpenFOAM/OpenFOAM-2.0.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4FoamlsERNS_7OstreamEPKc+0xa)[0x2b84359f918a]
/usr/local/OpenFOAM/OpenFOAM-2.0.0/platforms/linux64GccDPOpt/lib/libOpenFOAM.so(_ZN4FoamlsERNS_7OstreamEPKc+0xa)[0x2b55359ae18a]
cfdemSolverPiso_shared[0x457cd0]
cfdemSolverPiso_shared[0x457cd0]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x345201d974]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x345201d974]
cfdemSolverPiso_shared(_ZNK4Foam11regIOobject11writeObjectENS_8IOstream12streamFormatENS1_13versionNumberENS1_15compressionTypeE+0xd9)[0x41c1d9]
======= Memory map: ========
cfdemSolverPiso_shared(_ZNK4Foam11regIOobject11writeObjectENS_8IOstream12streamFormatENS1_13versionNumberENS1_15compressionTypeE+0xd9)[0x41c1d9]
======= Memory map: ========
/lib64/libc.so.6(cfree+0x8c)[0x345207590c]
00400000-00475000 r-xp 00000000 00:1b 27462736 /gpfs/home/zhao0129/OpenFOAM/zhao0129-2.0.0/platforms/linux64GccDPOpt/bin/cfdemSolverPiso_shared
00675000-00677000 rw-p 00075000 00:1b 27462736 /gpfs/home/zhao0129/OpenFOAM/zhao0129-2.0.0/platforms/linux64GccDPOpt/bin/cfdemSolverPiso_shared
1bdee000-1bfa3000 rw-p 1bdee000 00:00 0
1bfa3000-1bfa5000 rw-p 1bfa3000 00:00 0
1bfa5000-1bfa6000 rw-p 1bfa5000 00:00 0
1bfa6000-1c0e5000 rw-p 1bfa6000 00:00 0
1c0e5000-1c284000 rw-p 1c0e5000 00:00 0
1c284000-1c2a4000 rw-p 1c284000 00:00 0
1c2a4000-1c2a5000 rw-p 1c2a4000 00:00 0
1c2a5000-1c2a6000 rw-p 1c2a5000 00:00 0
1c2a6000-1c2a7000 rw-p 1c2a6000 00:00 0
1c2a7000-1c2c7000 rw-p 1c2a7000 00:00 0
1c2c7000-1c2c9000 rw-p 1c2c7000 00:00 0
1c2c9000-1c2cd000 rw-p 1c2c9000 00:00 0
1c2cd000-1c2ce000 rw-p 1c2cd000 00:00 0
1c2ce000-1c2cf000 rw-p 1c2ce000 00:00 0
1c2cf000-1c2d1000 rw-p 1c2cf000 00:00 0
1c2d1000-1c2d5000 rw-p 1c2d1000 00:00 0
1c2d5000-1c2d7000 rw-p 1c2d500400000-00475000 r-xp 00000000 00:1b 27462736 /gpfs/home/zhao0129/OpenFOAM/zhao0129-2.0.0/platforms/linux64GccDPOpt/bin/cfdemSolverPiso_shared
00675000-00677000 rw-p 00075000 00:1b 27462736 /gpfs/home/zhao0129/OpenFOAM/zhao0129-2.0.0/platforms/linux64GccDPOpt/bin/cfdemSolverPiso_shared
1e677000-1e82c000 rw-p 1e677000 00:00 0
1e82c000-1e82e000 rw-p 1e82c000 00:00 0
1e82e000-1e82f000 rw-p 1e82e000 00:00 0
1e82f000-1e96e000 rw-p 1e82f000 00:00 0
1e96e000-1eb0d000 rw-p 1e96e000 00:00 0
1eb0d000-1eb2d000 rw-p 1eb0d000 00:00 0
....

Got any idea?

My CFDEM version is 2.0.4. Is there any update of bigParticle in the latest version?

Thanks.

rq

cgoniva's picture

cgoniva | Thu, 09/15/2011 - 09:10

Hi!

There might have been some changes, please try the current version. In case the error persists we need to have a closer look at that error.

Cheers,
Chris

rqwang | Thu, 09/15/2011 - 17:15

Hi Chris,

I updated the CFDEM to the latest version.

I found a bug in subModels/momCoupleModel/implicitCouple/implicitCouple.C

In line 129, is it suppose to be

dimensionSet (1, -3, -1, 0, 0),

After fixing this bug, the program runs, but the CFL number quickly go to infinite.

I think the big particle model still needs improvement. May I suggest use some PSI-cell instead ?

Thanks.

rq

cgoniva's picture

cgoniva | Fri, 09/16/2011 - 09:50

Hi!

That's not a bug, there was a change in the dimensions of Ksl.
The new dimension is now [0 0 -1 0 0] as there was a modification in the solver. (see latest tutorial cases)

Cheers,
Chris

rqwang | Fri, 09/16/2011 - 20:52

Hi Chris,

Is the rho taken into account in the new Ksl?

For my simulation, it seems that Ksl is not divided by density.

Please confirm.

Thanks.

rq

cgoniva's picture

cgoniva | Tue, 09/20/2011 - 16:37

Hi!

There was a bug that, the solver only gave correct results when the system was scaled to rho=1.
So there was a change at solver level where Ksl/rho was replaced by Ksl and the dimension of Ksl was changed to [0 0 -1 0 0].

I did a first test to check whether a simple settling gives correct results for different rho fluid. And it was ok.

Please let me know if you detect some inconsistency.

Cheers,
Chris

rqwang | Wed, 10/12/2011 - 16:45

Hi Alice and Chris,

As my understanding, the momentum induced by particle (e.g. drag force, etc) is transferred back to fluid phase via VoidFraction model (I am using bigParticleVoidFraction).

My question is whether the drag is calculated based on such voidfraction model, i.e. the drag force is based on the local velocity at a point or an averaged velocity where the area is given by bigParticleVoidFraction?

Thanks.

rq

alice's picture

alice | Wed, 10/12/2011 - 18:05

Hi!
The actual calculation of the drag force onto the particle takes place in the ShirgaonkarIB-force model. This model uses the information about the location of the particle wrt the cell IDs which it gets from the voidfraction model. so the drag model uses the velocity information from each cell, the particle covers.
Cheers,
Alice

cgoniva's picture

cgoniva | Thu, 10/27/2011 - 16:56

Hi rq,

the bigParticle voidfraction model will help to disperse the particles' volume and momentum over several cells.

for IB method (resolved CFD_DEM) the drag force is calculated in a DNS manner from the pressure and visous forces acting on the particle. (see Alices post below)

in case you use the bigParticle voidfraction model together with the unresolved CFD-DEM (e.g. cfdemSolverPiso_shared) in order to diffuse the exchange fields drag is still calculated from a "classical" drag model (e.g. DiFelice) using the cell centered fluid velocity, the particle centre is located in.

Cheers,
Chris

rqwang | Fri, 09/30/2011 - 19:36

Hi Chris,

So far the big particle model works smoothly, thank you again for the update.

Furthermore, I want to distribute the void fraction radially decay from the particle center, since I found the simulation is sensitive to the parameter scaleUpVol (for my case, scaleUpVol=20 seems not feed back the momentum too concentrated but also not too diluted).

May I know the meaning and functions of particleWeights and particleVolumes?

I also don't understand this line: voidfractionNext_[cellI] -=occupiedVolume/particleCloud_.mesh().V()[cellI];

I cited the code as below:
for(label i=0; i< hashSetLength-1;i++)
{
label cellI=hashSett.toc()[i];
particleCloud_.cellIDs()[index][i+1]=cellI; //adding subcell represenation

voidfractionNext_[cellI] -=occupiedVolume/particleCloud_.mesh().V()[cellI];
particleWeights[index][i+1] += 1.0/hashSetLength;
particleVolumes[index][i+1] += occupiedVolume;

//Info << "AFTER:set voidfraction in cellI=" << cellI
// << ", voidfraction =" << voidfractionNext_[cellI] << endl;

}

Thank you for your help!

rq

cgoniva's picture

cgoniva | Sat, 10/01/2011 - 15:01

Hi!

These terms assure that you distribute axactly the same volume onto the cells as represented by the particle.
Further this is needed for calculated the average particle phase velocity in a cell.

For more details please contact Alice if she could give some more insight on that in the forum.

Cheers,
Chris