# uncoupledKinematicParcelFoam Examples

 Register Blogs Members List Search Today's Posts Mark Forums Read

 September 30, 2010, 02:17 uncoupledKinematicParcelFoam Examples #1 New Member   Chris Butler Join Date: Jun 2010 Posts: 21 Rep Power: 8 Hi all, I am trying to do some simple Lagrangian particle calculations with OpenFOAM. The actual computation of the particles is relatively simple: One case with solid particles within an incompressible flow One case with massless infinitesimal particles (i.e. stream tracers calculated within OF). I need to do this with respect to both a steady state and unsteady flow field. I have two questions then: 1) Is uncoupledKinematicParcelFoam the right solver for for the the problem at hand? It looks to me like it may not be able to evolve over a changing flow field. 2) How do I setup a case with uncoupledKinematicParcelFoam? Everything seems to go to hell when I need a temperature field for my fluid. Cheers, Chris Butler

 October 1, 2010, 02:59 #2 Senior Member   matej forman Join Date: Mar 2009 Location: Brno, Czech Republic Posts: 104 Rep Power: 9 Hi, the nature of all ways how to compute the particles in OpenFoam is transient. uncoupledKinematicParcelFoam can be used for computation of a flow field already computed. The solver reads this field and does numerical integration of lagrangian equations on it using kinematicParcel class. So it's a kind of aposteriori method. You can use it for changing flow-field, but you need appropriate frequency of time steps stored. The steady-state issue - if you have a steady state flow you may run a transient computation with large time steps for long enough time for particle to pass through the domain. The temperature issue - the kinematicParcel cloud is defining isothermal particles. you would need to use thermalParcel or if you want reactions, reactingParcel class. They are all described in \$FOAM/src/lagrangian/intermediate. It looks very messy and complicated but it's not that bad. For your application you can use several approaches: (1) adopt the uncoupledKinematicParcelFoam to thermalParcel (2) use some solver which computes the particles together with the flowfield (especially if the particles are exchanging heat with the surrounding, yoy shoud run the particles together with the flow anyway) like reactingParcelFoam without the reactions. (3) use spray class. good luck matej Mojtaba.a and potentialFoam like this.

October 3, 2010, 21:03
#3
New Member

Chris Butler
Join Date: Jun 2010
Posts: 21
Rep Power: 8
Quote:
 Originally Posted by matejfor Hi, the nature of all ways how to compute the particles in OpenFoam is transient. uncoupledKinematicParcelFoam can be used for computation of a flow field already computed. The solver reads this field and does numerical integration of lagrangian equations on it using kinematicParcel class. So it's a kind of aposteriori method. You can use it for changing flow-field, but you need appropriate frequency of time steps stored. The steady-state issue - if you have a steady state flow you may run a transient computation with large time steps for long enough time for particle to pass through the domain. The temperature issue - the kinematicParcel cloud is defining isothermal particles. you would need to use thermalParcel or if you want reactions, reactingParcel class. They are all described in \$FOAM/src/lagrangian/intermediate. It looks very messy and complicated but it's not that bad. For your application you can use several approaches: (1) adopt the uncoupledKinematicParcelFoam to thermalParcel (2) use some solver which computes the particles together with the flowfield (especially if the particles are exchanging heat with the surrounding, yoy shoud run the particles together with the flow anyway) like reactingParcelFoam without the reactions. (3) use spray class. good luck matej
Hi matej,

It seems that I had a more fundamental problem than I thought. Now my C++ is pretty poor, however, I think the problem is that the basicKinematicCloud constructor (inherited from KinematicCloud) presumes a compressible field (i.e. requires volumetric fields for rho and mu). This is also reflected in createFields.H for the solver.

For incompressible solvers I think that the passiveParticle library is what needs to be used.

Chris Butler

 October 4, 2010, 04:05 #4 Senior Member   matej forman Join Date: Mar 2009 Location: Brno, Czech Republic Posts: 104 Rep Power: 9 Hi Chris, You are right you need density and viscosity of the fluid to calculate the drag. But you may easily create these fields in the start directory and use this approach. Or you may use passive scalar as well. There are several ways. It is true that the passive scalar seems to be more easy to understand the code. good luck matej

October 6, 2010, 00:26
passiveParticleCloud Help!
#5
New Member

Chris Butler
Join Date: Jun 2010
Posts: 21
Rep Power: 8
Hi all,
Wondering if anyone has had success with passiveParticleFoam. I am am trying (as a first stage) to re-implement uncoupledKinematicParcelFoam for a incompressible solver. I am having trouble finding how to 'evolve' the particles. I think the function is:
Foam::Cloud::move()
However, my C++ is rudimentary and I don't quite understand the follow error:
passiveParticleParcelFoam.C:61:21: error: no matching function for call to ‘Foam:assiveParticleCloud::move()’

Any help would be much appreciated.

Chris Butler
Attached Files
 passiveParticleParcelFoam.tar.gz (3.3 KB, 40 views)

 October 6, 2010, 03:15 #6 Senior Member   matej forman Join Date: Mar 2009 Location: Brno, Czech Republic Posts: 104 Rep Power: 9 Hi Chris, the error clearly saiz what's wrong. There is no function move() for passiveParticleCloud defined. You should have the definition in the definition of class passiveParticleCloud. The compiler cannot find it. Now the thing with the compressibility.... The computation of uncoupledKinematicParcelFoam is not compressible at all. Look where the mu a rho is used in the code. You will find that it's used only for the particles the fluid flow is still incompressible. the mu and rho is there only for the implementation reasons as when you extend the kinematic to thermal cloud, you have rho and mu in the field anyway so you do not need to have extra overloading of the clouds. good luck with you c++ matej

 October 6, 2010, 22:56 #7 New Member   Chris Butler Join Date: Jun 2010 Posts: 21 Rep Power: 8 Hi Matej, I figured out my confusion. Because the Cloud class was templat'ed it did not inherit Foam::Cloud::move(). I think that you are right that the existing uncoupledKinematicParcelFoam will be easier to work with. It looks like passiveParticleCloud is not implemented. All i have to do is trick KinematicCloud into thinking I have a density field. Chris Butler

 August 18, 2015, 12:37 icoUncoupledKinematicParcelFoam Two-Way Coupling #8 New Member   matin Join Date: Nov 2014 Posts: 3 Rep Power: 3 Hi everyone, I'm trying to use icoUncoupledKinematicParcelFoam solver for the Two-Way coupling by turning the "Coupled" option "On" in the KinematicCloudProperties directory. I ran a case, having fluid flow and particles, and noticed that the flow field does not change and it seems turning the "Couple" option On or Off does not affect the simulation and it solves for One-Way coupling. I have read that this solver is suitable for the precalculated velocity field and that the particles do not affect the fluid field, but why they have defined such option in the KinematicCloudProperties directory to couple and decoupled the simulation ? I also know that there are other solvers like DPMFoam and MPPICFoam which consider two-way coupling, but I want to know whether I can use icoUncoupledKinematicParcelFoam solver for two-way coupling or not. I really appreciate if anyone could give me some information about their experience using this solver, Thanks, Matin

 August 19, 2015, 03:48 #9 Senior Member   matej forman Join Date: Mar 2009 Location: Brno, Czech Republic Posts: 104 Rep Power: 9 Hi, as the name of the solver says it is uncoupled, so trying to use it for coupling is no-go even from the grammatical point of view. The best way to find out what your solver can or cannot do is to read the description in the source of the solver. In your case try: less \$FOAM_SOLVERS/lagrangian/icoUncoupledKinematicParcelFoam/icoUncoupledKinematicParcelFoam.C and read the description, where you will learn that this solver is reading the velocity fields in previously calculated and stored in appropriate time directories and evolves (integrates the lagrangian equation for the particle) in this velocity field. So no coupling whatsoever. happy foaming

 August 19, 2015, 21:00 #10 New Member   matin Join Date: Nov 2014 Posts: 3 Rep Power: 3 Matej, Thank you so much for your prompt response.

July 8, 2016, 13:46
#11
New Member

Join Date: Oct 2015
Posts: 23
Rep Power: 2
Quote:
 Originally Posted by matejfor The steady-state issue - if you have a steady state flow you may run a transient computation with large time steps for long enough time for particle to pass through the domain.
I will take for example flow of particles in vertical channel. Let us assume there exists steady state.
How to set up pseudo - transient approach? Due to integration of Newton's law of motion, time step has to be small and Courant number has to be less than 1. Also if soft sphere model is used, with large time step, computation time is going to be very high. How to overcome this problem?

Regards,
Darko

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Freeman FLUENT 5 February 3, 2011 17:28 A Siddiqui Main CFD Forum 3 November 8, 2005 04:03 Maciej Matyka Main CFD Forum 9 November 3, 2003 06:11 lei FLUENT 1 June 20, 2003 22:38 Greg Perkins Main CFD Forum 3 June 25, 2001 08:10

All times are GMT -4. The time now is 19:01.