2018-07-17 14:28 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002549OpenFOAMContributionpublic2017-11-02 16:05
Reporterbijan darbari 
Assigned Towill 
PlatformGNU/LinuxOSUbuntuOS Version15.10
Product Versiondev 
Target VersionFixed in Version 
Summary0002549: New particle force (Thermophoretic force) for lagrangian solvers
DescriptionWhen 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 ReproduceThe 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:

Kp 10;
Kc 0.6;
lambda 2e-10;

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 InformationThe 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. [1980] 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.

TagsNo tags attached.
Attached Files




bijan darbari (reporter)

Dear Prof Weller

If possible, Could you please respond to my issue!!

Best Regards.


will (manager)

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)

Dear will

Thanks for your attention.

I will do that as soon as possible.


bijan darbari (reporter)

Dear Will

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.


    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'').


will (manager)

Last edited: 2017-06-27 11:28

View 2 revisions

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)

Dear Will

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)

Dear will.

If possible, plase reply to my post.

Best regards.


will (manager)

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.


will (manager)

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.


will (manager)

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.

-Issue History
Date Modified Username Field Change
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
+Issue History