|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002549||OpenFOAM||Contribution||public||2017-05-13 19:12||2017-11-02 16:05|
|Target Version||Fixed in Version|
|Summary||0002549: New particle force (Thermophoretic force) for lagrangian solvers|
|Description||When using lagrangian solvers to simulate discrete particles movement in the continuous fluid, particle movement can be affected by some external forces. There are many available forces in OpenFOAM lagrangian library containing Drag, Gravity, SaffmanMei lift, Pressure gradient, etc. However, Thermophoretic force an important force is not included in current version of OpenFOAM until now. |
This force is generated due to the temperature gradient in the continuous phase. For particles with micron or submicron sizes, this force can affect particles movement considerably and shouldn‘t be ignored. Accordingly, I think that it is better to include this force in OpenFOAM lagrangian library.
I have created a new submodel for this force in “src/lagrangian/intermediate/submodels”. This force is tested and the particle velocity created by this force is verified with theory expression (See additional information). The verification results are attached and there is a good agreement between the results of simulation and the theory expression. As a result, this force works well in OpenFOAM.
Note that this force is calculated by the reliable expression introduced in “Talbot, L.; Cheng, R. K.; Schefer, R. W.; Willis, D.R.; Thermophoresis of particles in heated boundary layer ; (1980) J. Fluid Mechanic“
|Steps To Reproduce||The following steps can be used to include Thermophoretic force in OpenFOAM lagrangian library:|
1-Copy “Thermophoretic” folder to “src/lagrangian/intermediate/submodels/kinematic/particleforces”
2-Copy and replace “makeThermoParcelForces.H” by “src/lagrangian/intermediate/parcels/include”.
After that, this force is included in the list of lagrangian particle forces and can be used as an available force. It should be noted that this force can be activated when the temperature distributions of continuous phase is known by solving the energy equation for the continuous phase.
Note that this force should be defined as a dictionary in the following form “case/constant/cloud1Properties/subModels/particleForces” as follows:
where, “Kp” and “Kc” are particle thermal conductivity (e.g. 10 W/mK) and continuous phase thermal conductivity (e.g. 0.6 W/mK), respectively. Moreover, “lambda” denotes continuous phase molecular mean free path (e.g. 0.2 nm).
|Additional Information||The particles with small sizes (micron and submicron particles) suspended in a carrier fluid experience a force in opposite direction of temperature gradient due to the temperature gradient. This force is called Thermophoretic force.|
Patel et.al.  studied about the calculation of thermophoretic force. They introduced an expression for this force. Their expression is very reputable and is used by many researchers. Accordingly, I have used it to calculate the thermophoretic force in the OpenFOAM.
The expression of Thermophoretic force is presented in “Fig1” (see attached file)
Particle velocity has a known value when drag and Thermophoretic forces act only on a particle in a stagnant fluid. This value is calculated by the expression presented in “Fig2” (see attached file)
Verification of new lagrangian particle force:
For verification of OpenFOAM thermophoretic force, a simple 2D case including a square is considered. The top and bottom walls of square have a constant temperature and sidewalls are adiabatic. There is no flow in the square. So the temperature gradient in all of the domain is known and has a constant value ((Tup-Tdown)/(deltaY)). Moreover, the temperature gradient is created only in Y direction.
A single solid particle is injected at the middle point of the square where only drag and thermophoretic forces are activated. For particles with different thermal conductivities, the particle velocity in Y direction obtained by OpenFOAM is compared with thermophoretic velocity of expression “Fig2”. The results of this comparison are plotted in “Fig3”. As a result, OpenFOAM thermophoretic force is verified very well.
The verification case is attached here. It is solve by “reactingParcelFoam” solver. The reference paper for calculating the expression and verification of thermophoretic force is also attached.
|Tags||No tags attached.|
bijan darbari (reporter)
Dear Prof Weller
If possible, Could you please respond to my issue!!
I will be handling this issue, not Henry. I'm sorry that this may take some time, but we are very busy.
I have looked at your implementation, and in general I think it is a good piece of work. The reason I haven't put it in is that the carrier thermal conductivity is supplied as a parameter to the model. This data already exists in the continuous flow field. Look at ThermoParcel.C. It looks up and interpolates the conductivity. Asking the user to supply the value manually risks an inconsistency between different parts of the simulation.
I would request that you change your implementation to utilise the thermal conductivity already available for the carrier field.
bijan darbari (reporter)
Thanks for your attention.
I will do that as soon as possible.
bijan darbari (reporter)
I have tried to implement the interpolation of the carrier phase thermal conductivity in this code as it is done in thermoParcel.C. But the solver displays the following error when running the case and the interpolator doesn’t access to the carrier phase thermal conductivity (kappa) field, although it can access to the carrier phase density, viscosity, etc.
—> FOAM FATAL ERROR:
request for volScalarField kappa from objectRegistry region0 failed
available objects of type volScalarField are
The new “Thermophoretic” submodel with implemented kappa interpolator ( that I mentioned above ) is attached here. (see the file with the name of ''Thermophoretic_1.zip'').
Last edited: 2017-06-27 11:28
Sorry for the delay. I've been away.
Yes, this is a pain. The kappa field is generated on the fly by the continuous phase thermodynamics model, so it isn't in the database. You would need to look up the thermodynamics instead:
const basicThermo& thermo = this->mesh().template
Then kappa can be generated using thermo.kappa(). This would need storing in the same way as gradT.
What's annoying is that the tracking data already has a kappa field and an associated interpolator, but The API at present doesn't allow a particle force model to access it.
bijan darbari (reporter)
Sorry for my late reply and Thanks for your helpful guide.
I implemented an interpolator for "thermo.kappa()" in my new submodel and it Worked well.
Now my new submodel can access to the local carrier phase thermal conductivity and uses it for the calculation of thermophoretic force.
This new thermophoretic force attached ( Thermophoretic_2.zip ) and I hope that it can be putted in OpenFOAM.
bijan darbari (reporter)
If possible, plase reply to my post.
Apologies for the lack of a response.
I am not putting this in OpenFOAM at present. Kappa and it's interpolator are already stored in the thermo parcel tracking data, and to make another copy is wasteful. Accessing this tracking data from within a sub-model is, at present, impossible, as it is templated on a different type to that of the model. I am working to resolve this, as doing so would solve a number of other problems with the Lagrangian library (notably memory usage and ever expanding argument lists).
Beyond this, it has come to my attention that it is possible to calculate kappa for the particle, too, via the thermo cloud's thermo model. This might also be true for lambda. The point I made earlier regarding possible inconsistency between duplicated inputs stands. If tracking data were accessible to the sub-model then particle kappa could be stored there, too, and this issue could be avoided.
In short, we may put this model in if/when it fits with our ongoing development strategy for Lagrangian. Until then, I recommend that you can continue using it as a local add-on.
|As a side-note, if I were to put this in today, your code would still require significant modification. The kappa caching you have implemented does not release the memory at the end of the cloud evolution, and the interpolations are being made with the un-optimised global position method (hint, you should be passing p.coordinates() instead of p.position()). Beyond that, the formatting is not as our style guide requires; the indenting is inconsistent, there are lines over 80 characters long, and some of the methods are not commented appropriately for doxygen.|
|This isn't viable until Lagrangian is changed to make access and storage of sub-model specific data (in this case kappa) more convenient. Closing.|
|2017-05-13 19:12||bijan darbari||New Issue|
|2017-05-13 19:12||bijan darbari||File Added: Thermophoretic.zip|
|2017-05-13 19:13||bijan darbari||File Added: makeThermoParcelForces.H|
|2017-05-13 19:14||bijan darbari||File Added: verificationcase.zip|
|2017-05-13 19:15||bijan darbari||File Added: Fig1.JPG|
|2017-05-13 19:15||bijan darbari||File Added: Fig2.JPG|
|2017-05-13 19:16||bijan darbari||File Added: Fig3.png|
|2017-05-13 19:18||bijan darbari||File Added: talbot.et.al1980.pdf|
|2017-05-20 05:36||bijan darbari||Note Added: 0008171|
|2017-05-22 09:54||will||Note Added: 0008184|
|2017-05-31 18:28||bijan darbari||Note Added: 0008197|
|2017-06-18 15:27||bijan darbari||Note Added: 0008227|
|2017-06-18 15:47||bijan darbari||File Added: Thermophoretic_1.zip|
|2017-06-27 11:25||will||Note Added: 0008272|
|2017-06-27 11:28||will||Note Edited: 0008272||View Revisions|
|2017-08-11 20:12||bijan darbari||Note Added: 0008562|
|2017-08-11 20:16||bijan darbari||File Added: Thermophoretic_2.zip|
|2017-08-25 08:38||bijan darbari||Note Added: 0008629|
|2017-08-25 09:46||will||Note Added: 0008630|
|2017-08-25 09:47||will||Note Added: 0008631|
|2017-11-02 11:58||will||Assigned To||=> will|
|2017-11-02 11:58||will||Status||new => closed|
|2017-11-02 11:58||will||Resolution||open => won't fix|
|2017-11-02 11:58||will||Note Added: 0008980|
|2017-11-02 16:05||will||Resolution||won't fix => suspended|