[m.kurjata]

Hello everyone,


I'm trying to set up a simulation of a fluidized bed using the coalChemistryFoam solver. There are two types of particles in the simulation - inert sand and plastic particles which are pyrolyzed. By default, coalChemistryFoam uses two clouds - limestone (= sand here) and coal (here plastic). However, both clouds do not interact directly with each other, which results in plastic particles falling through the sand bed and landing at the bottom of the reactor. Also, there is no direct heat transfer between particle types (only via gas phase).


As I found out, it's possible to use two injection models with different properties within one cloud. By doing that, I would end up with sand and plastic interacting with each other.


Unfortunately, I cannot find the correct injection model that suits all my needs. The only model where I can define density and chemical composition of particles within the model and not in constant properties of the entire cloud is reactingMultiphaseLookupTableInjection. However, using it, I can only define one constant parcel diameter for each injector - and I need to have a size distribution, e.g. Rosin Rammler. Also, it's not possible to have an initial particle bed using this model. I could achieve that with manualInjection, but it's not possible to set density or composition within it.


Is there any way to have
1) an initial particle bed
2) two particle types within one cloud, and
3) particles with a size distribution
in one simulation, using tools available in OpenFOAM?


I think it could be theoretically possible to delete the constant particle size from parcelInjectionProperties file used by reactingMultiphaseLookupTableInjection and add add a size distribution instead, but I have little experience with programming in OF and implementing new features in it.


Thanks in advance,
Max

[alainislas]

Hello,

In the standard coalChemistryFoam solver you can only work with 2 classes of clouds: 1) ThermoCloud (limestone) & 2) ReactingMultiphaseCloud (coal). Each cloud can consist of one or more injections, however, not the clouds nor the injections will interact among them. Please note that coalChemistryFoam is a two-way coupling solver, where interactions/collisions among particles are neglected (and heat transfer by conduction too!). This is usually valid for dilute flows, where the volume fraction is < 10%.
My feeling is that for your application (fluidized bed) you need DPMFoam, where particle-particle interactions are now accounted (only collisions!). However, this solver only accounts for KinematicClouds and doesn't consider any thermo/reacting feature, in other words it doesn't solve for ReactingMultiphaseClouds.

[m.kurjata]

The interactions among particles aren't neglected anymore in coalChemistryFoam (I use OFv2206). This used to be the case, but has been changed a year or two ago (see https://develop.openfoam.com/Develop...e_requests/406). DPMFoam wouldn't be a right choice for a fluidized bed, at least for my accuracy needs, since it resolves all particle-particle collisions, as far as I know, which makes the computation slow. Earlier, a four-way coupling solver that it would make sense to use would be MPPICFoam, which utilizes packing, damping and isotropy models to calculate particle-particle interactions. But just like DPMFoam, it can't solve for reactions.



However, as of now, all these 3 models are already included in the KinematicCloud, so there are particle-particle interactions within both coalCloud and limestoneCloud (which are instances of kinematicCloud), but not between these clouds. Hence my idea to circumvent it by using two injection models in the coalCloud, where one would inject inert sand particles and the other would inject plastic particles that undergo pyrolysis.


I could do it using reactingMultiphaseTableLookupInjection, but it only allows to define a single particle size for each injector, which I cannot accept. I need a size distribution.


This is what I need help with - finding (or creating) an injection model where it's possible to define a separate rho, cp, Y_i etc of parcels injected with this model (just like in reactingMultiphaseTableLookupInjection) AND at the same time to use a size distribution instead of a constant diameter for all parcels. I'm aware it might require some work with the OF source code.

[alainislas]

Ok, so

1) Yes, 4 way coupling is extremely computationally expensive.

2) So, since in OpenFOAM all the particle clouds contain intrinsically the KinematicCloud class as the 1st class, you saying that the MPPIC and DPM features are now added to all lagrangian solvers? I don't think so, but could you validate? I believe that this is just for that DPMDyMFoam and MPPICDyMFoam solvers which now use the derived template basicKinematicCloud instead of the old basicKinematicMPPICCloud & basicKinematicCollidingCloud. Please run the coalChemistryFoam's simplifiedSiwek tutorial with MPPIC or DPM features enabled, and validate?

3) Regarding the reactingMultiphaseLookupTableInjection, a smart way to define a size distribution would be to use the pdfPlot utility. You only need to specify your pdf parameters and OpenFOAM will generate a list of n particle diameters. Besides you will get a .xy file with the data organized by bins, ready to visualize as a pdf. Here is an example:

// Number of intervals/bins in pdf plot
nIntervals      20;

// Number of samples
nSamples        10000;

// Type of pdf
type            RosinRammler;

// Write data flag
writeData       true;

// PDF model coefficients
RosinRammlerDistribution
{
    minValue        1e-06;
    maxValue        200e-06;
    d               60.0e-06;
    n               0.8;
}

To define the remaining properties (rho, cp, U, Ygas, Yliquid, Ysolid, ...) perhaps you can use Matlab/excel?

4) again, my feeling is that "the standard" coalChemistryFoam v2206 is not suitable for simulating fluidized beds. Perhaps you can check the forum and find somewhere that many colleagues have already noticed this. In other words people have had to create their own reactingMultiphaseMPPICCloud & reactingMultiphaseCollidingCloud. Besides, defining 2 injections in the same coalCloud1Properties dictionary will apply the same submodels (drag, devolatilization, heat transfer, etc...) to both,which is not necessarily what you want for sand and plastic isnt it?

[m.kurjata]

Yes, since packing/damping/isotropy models are now included in the KinematicCloud, all lagrangian solvers that use this cloud class (i.e. all of them, I guess) by default have MPPIC features available. I don't know about DPM features as these are not relevant for me and I haven't looked into it.



MPPICCloud is a cloud type that adds the 3 models mentioned above:
https://www.openfoam.com/documentati...PPICCloud.html
but in the newer versions of OF KinematicCloud also has these 3 models:
https://www.openfoam.com/documentati...aticCloud.html
which makes the MPPICCloud obsolete.


When I run simplifiedSiwek with coalChemistryFoam, at the beginning of the simulation, additional lines are displayed (and weren't displayed in the older OF versions): "Selecting packing model : none", "Selecting damping model : none", "Selecting isotropy model : none". And probably a couple more. These are displayed even though, by default, no options regarding these models are included in the coalCloudProperties (or limestoneCloudProperties) file of the tutorial case. After copying example options from an MPPICFoam tutorial (I used Goldschmidt), the simplifiedSiwek case works without errors and the chosen packing/damping/isotropy models are displayed as enabled/used.


I don't see why I shouldn't use the same drag and heat transfer submodels for both sand and plastic. Is there a reason? An honest question. The solver would use diameters (drag) and cp value (heat transfer) etc of each separate parcel during calculation anyway, right? As for the devolatilization, I could probably turn it off for sand particles by defining a different chemical composition for them, e.g. with a very high heat of fusion (I haven't looked into the devolatilization models yet).


Thank you for the idea with pdfPlot, that might work. If I understand it correctly, I would end up with a parcelInjectionProperties file having, in your example code, 10000 lines, one for each injector with a predefined diameter?