|
[Sponsors] |
January 17, 2016, 17:07 |
about parcel evolve function
|
#1 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
Hi,
In some OpenFOAM lagrangian solver, such as coalChemistryFOAM, the link for this solver is Code:
https://github.com/OpenFOAM/OpenFOAM-2.3.x/blob/master/applications/solvers/lagrangian/coalChemistryFoam/createClouds.H#L16 Code:
coalParcels.evolve(); limestoneParcels.evolve(); Code:
Info<< "\nConstructing coal cloud" << endl; coalCloud coalParcels ( "coalCloud1", rho, U, g, slgThermo ); Info<< "\nConstructing limestone cloud" << endl; basicThermoCloud limestoneParcels ( "limestoneCloud1", rho, U, g, slgThermo ); |
|
January 19, 2016, 15:59 |
|
#2 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
The source file for coalCloud is as follows:
Code:
namespace Foam { typedef ReactingMultiphaseCloud < ReactingCloud < ThermoCloud < KinematicCloud < Cloud < coalParcel > > > > > coalCloud; } Code:
typedef ReactingMultiphaseCloud <ReactingCloud<ThermoCloud<KinematicCloud<Cloud<coalParcel>>>>> coalCloud; Code:
typedef ReactingMultiphaseParcel < ReactingParcel < ThermoParcel < KinematicParcel < particle > > > > coalParcel; Last edited by openfoammaofnepo; January 28, 2016 at 15:39. |
|
January 20, 2016, 08:24 |
|
#3 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
Follow the template trail. It's defined in ReactingCloud:
$FOAM_SRC/src/lagrangian/intermediate/clouds/Templates/ReactingCloud/ReactingCloud.[C,H] |
|
January 25, 2016, 09:17 |
|
#4 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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: Code:
template<class CloudType> void Foam::ReactingCloud<CloudType>::evolve() { if (this->solution().canEvolve()) { typename parcelType::template TrackingData<ReactingCloud<CloudType> > td(*this); this->solve(td); } } ----------------- 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);? Last edited by openfoammaofnepo; January 25, 2016 at 09:29. Reason: some comments |
|
January 25, 2016, 13:33 |
|
#5 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
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. Last edited by cnsidero; January 25, 2016 at 16:48. |
|
January 25, 2016, 15:52 |
|
#6 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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 |
|
January 26, 2016, 13:06 |
|
#7 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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? |
|
January 28, 2016, 12:03 |
|
#8 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
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. Code:
find $FOAM_SRC/lagrangian "*.[C,H]" | xargs grep -n UTrans\(\) | grep -v lnInclude |
|
January 28, 2016, 15:35 |
|
#9 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
Dear Chris,
Your following comment is very helpful for my understanding the code structure, so I mark here: Code:
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/). Code:
$FOAM_SRC/src/lagrangian/intermediate/clouds Code:
$FOAM_SRC/src/lagrangian/intermediate/parcels |
|
January 28, 2016, 16:06 |
|
#10 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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 |
|
January 28, 2016, 16:36 |
|
#11 |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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. |
|
January 28, 2016, 22:42 |
|
#12 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
"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. |
|
January 29, 2016, 05:38 |
|
#13 | |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
Quote:
|
||
October 18, 2016, 18:20 |
|
#14 | |
Senior Member
Join Date: Jan 2013
Posts: 372
Rep Power: 14 |
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 Quote:
|
||
March 8, 2018, 06:13 |
CoalChemistryFoam
|
#15 |
New Member
Join Date: Jun 2017
Posts: 12
Rep Power: 8 |
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 |
|
June 26, 2020, 08:54 |
|
#16 | |
New Member
Jiaui Zhang
Join Date: Aug 2018
Location: Changsha, China
Posts: 17
Rep Power: 7 |
Quote:
|
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Other] refineWallLayer Error | Yuby | OpenFOAM Meshing & Mesh Conversion | 2 | November 11, 2021 11:04 |
compressible flow in turbocharger | riesotto | OpenFOAM | 50 | May 26, 2014 01:47 |
[blockMesh] error message with modeling a cube with a hold at the center | hsingtzu | OpenFOAM Meshing & Mesh Conversion | 2 | March 14, 2012 09:56 |
Compilation errors in ThirdPartymallochoard | feng_w | OpenFOAM Installation | 1 | January 25, 2009 06:59 |
Problem with compile the setParabolicInlet | ivanyao | OpenFOAM Running, Solving & CFD | 6 | September 5, 2008 20:50 |