about parcel evolve function
 

Hi,

In some OpenFOAM lagrangian solver, such as coalChemistryFOAM, the link for this solver is
There is the following lines:
The objects of coalParcels and limestoneParcels are defined in "createClouds.H":
But I did not find the function of evolve() in OpenFOAM, I mean the specific form of this function. Could anybody give me some hints about this? Thanks.

The source file for coalCloud is as follows:

"coalParcel" is defined in coalParcel.H as follows:

Follow the template trail. It's defined in ReactingCloud:

$FOAM_SRC/src/lagrangian/intermediate/clouds/Templates/ReactingCloud/ReactingCloud.[C,H]

Dear Chris,

Thank you for your reply. I have checked that but it is still not clear for me to find how 'this->solve(td);' in this "evolve" function, i.e. in the following source codes from the files you mentioned:

Could you please give me some further hints about what is the operation for this->solve(td);? Thank you so much.

-----------------
For pulverized coal combustion case, I guess the changes of individual particles caused by devolatilization and char (solid carbon) combustion are included in this this->solve(td);?

Go back to coalCloud.H. You'll notice one of the classes the coalCloud typedef is created from is KinematicCloud. KinemeticCloud contains the definition for solve. Line 91 in

$FOAM_SRC/lagrangian/intermediate/clouds/Templates/KinematicCloud/KinematicCloud.C

The Lagrangian classes are rather complex due to its policy-based design with templates. It can be a struggle to find where things are and how it all fits together. There's a simple explanation of policy-based design on Wikipedia: https://en.wikipedia.org/wiki/Policy-based_design

ReactingMultiphaseCloud is the host class and the nested classes are the policy classes. As the Wikipedia article mentions, in policy-based design, the host class inherits the methods of the policy classes hence the solve method from KinematicCloud can be called.

Dear Chris,

Thank you so much for your help. I am reading some source files for the lagrangian solvers in OpenFOAM and found that it is indeed very struggling.

In the Lagrangian solver of OpenFOAM, what is the difference between the terminologies "particle", "parcel" and "cloud"? Since we have "coalParcels.evolve();", so the number of ODEs for the mass, momentum and energy is consistent with the number of parcles?

Thank you again.

OFFO

Dear Chris,

in the KinematicCloud.H [or .C], how is the quantity "UTrans" is caluclated? This is the source term for the momentum equation, but is it related to the models for the different forces?

parcel: represents many particles with identical particle properties
cloud: represents many parcels with varying parcel properties

UTrans: I'm doing all the work here for you so I'll point you in the right direction one more time and then you're own you're own. In KinematicCloud.[C,H] you'll notice the private data member UTrans_ is created or updated from a KinematicCloud<CloudType> object. So the trick is again to recognize the policy-based design of the Lagrangian library. The last policy class coalCloud is defined from is coalParcel, which itself is defined in a similar manner (look in coalParcel.H). The parcel classes are where UTrans is updated (look in $FOAM_SRC/lagrangian/intermediate/parcels/Templates/).

Good luck, Chris

Tip: The shell utilities 'find' and 'grep' are your friend. E.g.

will search all .C and .H files in the lagrangian library for the string "UTrans()" and ignore results from the lnInclude directories (duplicates).

Dear Chris,

Your following comment is very helpful for my understanding the code structure, so I mark here:

I think this is the "channel" between the classes in the following two folders:

and
Thanks a lot.

About the policy-based programming, the following from Wikipedia is help and is paste here for other people's reference:

A key feature of the policy idiom is that, usually (though it is not strictly necessary), the host class will derive from (make itself a child class of) each of its policy classes using (public) multiple inheritance. (Alternatives are for the host class to merely contain a member variable of each policy class type, or else to inherit the policy classes privately; however inheriting the policy classes publicly has the major advantage that a policy class can add new methods, inherited by the instantiated host class and accessible to its users, which the host class itself need not even know about.) A notable feature of this aspect of the policy idiom is that, relative to object-oriented programming, policies invert the relationship between base class and derived class - whereas in OOP interfaces are traditionally represented by (abstract) base classes and implementations of interfaces by derived classes, in policy-based design the derived (host) class represents the interfaces and the base (policy) classes implement them. It should also be noted that in the case of policies, the public inheritance does not represent an is-a relationship between the host and the policy classes. While this would traditionally be considered evidence of a design defect in OOP contexts, this doesn't apply in the context of the policy idiom.

--Wikipedia

For the cloud related classes in $FOAM_SRC/src/lagrangian/intermediate/clouds, are they only for the policy based coding? Because I found that all the physical and modelling calculations (e.g. the inter-phasic interactions between the continuous and dispersed phases, and also the source terms such as SU, SYi, Srho and Shs) have been performed at the level of parcels, which are in $FOAM_SRC/src/lagrangian/intermediate/parcels.

So that means coalParcels have already all the required terms and interactions, as shown in #2 post above. So in this case, we still use cloud related classes. This seems difficult to understand.

"however inheriting the policy classes publicly has the major advantage that a policy class can add new methods, inherited by the instantiated host class and accessible to its users, which the host class itself need not even know about."

I want to emphasize this statement, in particular the bold, because this is what makes the policy design difficult to follow. Since a host class inherits methods from the policy classes, one needs to be aware of the methods within all the policy classes because they're not as obvious as they would be with inherited classes in object oriented design.

Thanks, very useful explanations!

Dear Chris,

For flows laden with particles or droplets, we will always be told about the mass flow rates of the particles and droplets. Based on those, we can easily estimate the number of real particles per second. But typically how many particles should exists in the parcels for a good simulation?

Thank you.

oFFo

CoalChemistryFoam
 

Hello all,
I have started working on coalChemistryFoam. The gas phase equations are given in the solver but i could not find the particle equations(eg-particle mass, particle velocity etc.). Can anyone please help me and tell where can i find the particle equations. I have been stuck for a long time.

Any help is highly appreciated.

Thank You

Particle equations are solved in the lagrangian class, for example, the particle temperature is updated by calcHeatTransfer in ThermoParcel.C