[kamranian]

Hi Foamers,

I`m particularly interested in DEM-CFD coupling. My question is about icoUncoupledKinematicParcelFoam. The solver name includes `uncoupled` which leads me to the conclusion that is not capable of solving coupled problems.
Could please anybody clarify if coupling by interaction of fluid and particles (forces) is already possible in OpenFoam v2.0 or if the coupling is still work in progress ?
If OpenFoam v2.0 already includes some coupling functionality what source files should I look at ?
I also checked the doxygen documentation and could not find anything about icoUncoupledKinematicParcelFoam solver yet.
Is there any document or tutorial that shown the procedure of modeling and modeling parameters?

Best Regards,
A. Kamranian

[AMahrla]

Hi!

The icoUncoupledKinematicParcelFoam is only a coupled solver in the sense that particle-particle interaction is considered. Any coupling between fluid and particulate phase is neglected.

Please refer also to this thread!

Best,

Astrid

[kamranian]

Dear Astrid,

Thank you for your reply. If it is possible to couple this solver with fluid interaction? I am interested to use CFD-DEM to simulation of four-way coupling via OpenFOAM. Can I do it in OpenFOAM? Do you have any recommand for me?

Regards,
A. Kamranian

[AMahrla]

Hi again!

The implementation of coupling to the continuous phase should be possible, but IMO you have to dig into the code around the particle class which is not THAT top level..

Maybe you can find a starting point within the tutorials on extend-wiki and get to know the implementation of particles in OpenFOAM?

Best,

Astrid

[Toorop]

Hi,

I'm investigating how to track particles within the fluid domain in OpenFOAM.

Initially, I thought that there's a simple method to perform one-way coupling with basic solvers (icoFoam, pisoFoam, pimpleFoam) - solidParticle class describes itself as a spherical particle class with one-way coupling with the continuous phase. Unfortunately didn't find anything. Instead, there's some tutorials about how to "hack" it into a desired solver. So is there an elegant interface where one can describe passive particle (parcel) cloud / emission?

At first, I thought that icoUncoupledKinematicParcelFoam can handle this sort of simulations - is it possible to couple this with another solver?

[gara1988]

Hello Toorop, Have you find a solution of you question? I have the same problem.

[rama13]

Hi Foamers,

I have a very simple question for you.

1) icoUncoupledKinematicParcelFoam solves for the interaction between particles as pointed out here (and if you look into the code no continuum phase is solved).

2) in the User Guide it is describerd as "Transient solver for the passive transport of a single kinematic particle could"

3) if you look into the case directory there is a 0/U field in which (my guess) you can set the velocity field at which your particles get convected away, and I think is what has been done in this nice video.

My question is: if particles get carried away by the fluid

1) they cannot bump into other particles since two streamlines does not collide (so no need to solve interaction)

2) even if they would, they will get a different momentum from the fluid particles they are going with, so they will be no more "passive"?!

I hope someone more expert than me can point me out the clue!

Thanks for your attention,
Damiano

[Tobi]

Hi,

old thread but due to the fact that other people may read it in feature too I will give a clearer answer.

icoUncoupledParcelFoam is a transient solver for passive parcel motion. That means that the particels do not influence the fluid but the parcels can interact between each other. If you think the particels are just moving along the streamlines, then you are wrong because for the particels we solve drag forces and so on that will finally change the direction of the particel. Just imagine a hydrocyclone. The particels will not follow the flow due to additional forces that act on the particels (like inertia). Depending on the particels properties (density, diameter and so forth), the parcels follow more or less the streamlines of the flow.

[rama13]

Thank you very much for your answer Toby!

[Tobi]

Hi,

you 're welcome but I think you already knew it (: (after the long time)

[rama13]

All the same, a reliable confirmation is always useful, and a kind reply is always good accepted!! Thanks again!

[randolph]

Originally Posted by Tobi

Hi,

old thread but due to the fact that other people may read it in feature too I will give a clearer answer.

icoUncoupledParcelFoam is a transient solver for passive parcel motion. That means that the particels do not influence the fluid but the parcels can interact between each other. If you think the particels are just moving along the streamlines, then you are wrong because for the particels we solve drag forces and so on that will finally change the direction of the particel. Just imagine a hydrocyclone. The particels will not follow the flow due to additional forces that act on the particels (like inertia). Depending on the particels properties (density, diameter and so forth), the parcels follow more or less the streamlines of the flow.

Hi, so in the source code of icoUncoupledParcelFoam. what's the function of
laminarTransport.correct();
mu = laminarTransport.nu()*rhoInfValue;
these two lines?

Thanks in advance

[amuzeshi]

Originally Posted by gara1988

Hello Toorop, Have you find a solution of you question? I have the same problem.

DPMFoam is what u need.

[AKBALOM]

Hi,
I want to simulate droplet trajectories analysis of airfoil profile.
I have already simulate flow field analysis with simpleFoam. So, I have velocity valıue for all domain mesh. After this step, ı want to simulate droplet trajectories with existence velocity flow field with lagrangian or eulerian approach. I hear that icoUncoupledKinematicParcelFoam with Lagrangian approach is useful for this approach.
But, ı colud not set up simulation cases. Is there any experience about this? Ho I can do it step by step for these calculation.
Thanks for listening and answering.

[randolph]

Hi,

If you just simulate the particle transport on a "frozen" velocity field. You do not need to hassle yourself with the "solver".

Since you are dealing with the decoupled the simulation. You just simply use the ‘Pluggable’ solvers.

For lagrangian:
icoUncoupledKinematicCloud

For eulerian:
scalarTransport

If you are using RANS, pay attention to the handling of the "turbulence" diffusion.

If you are using wall function, pay attention to the near-wall interaction between your flow solution and particle transport.

Thanks,
Rdf

[Mars409]

Does anyone know a way to make icoUncoupledKinematicParcelFoam not recreate files for volume fields of the flow in every time directory? I would think to satisfy ParaView creating links to the volume fields under the 0/ directory would suffice.

Not sure how this disk space saving trick should work when using multiple processors. I assume both 'mpi' and 'reconstructPar' need to do likewise.

===============

Turns out 'reconstructPar' doesn't care as long as all the volume field files in the processor<n>/ directories are deleted beforehand.

I guess 'mpi' doesn't care either, as it's the application (here icoUncoupledKinematicParcelFoam) that is to decide whether or not to write out the volume fields.

So all is left is to find an option--if it exists--to stop the application from writing out the volume fields. This will not only save lots of disk space but speed up execution as well.

===========

A brute force way will be to write a Python or shell script to watch for new time directories being created and whenever it happens delete all volume field files in older time directories. This saves disk space on the fly but does not save disk write time though.

[Tobi]

HI,



the simplest way is to stop the application to write out the field.

cd $FOAM_SOLVERS/lagrangian/icoUncoupledKinematicParcelFoam/
vim createFields.H

Change the following:

Info<< "Reading field U\n" << endl;                                             
volVectorField U                                                                
(                                                                               
    IOobject                                                                    
    (                                                                           
        "U",                                                                    
        runTime.timeName(),                                                     
        mesh,                                                                   
        IOobject::MUST_READ,                                                    
        IOobject::NO_WRITE                                                    
    ),                                                                          
    mesh                                                                        
);

And recompile:

wclean

wmake

Done. The solver does not write the velocity field anymore.
The problem here is, if you cancel the calculation and re-run the guy, it does not work as the velocity field is not there anymore. I am not sure but you can check the following:

volVectorField U                                                                
(                                                                               
    IOobject                                                                    
    (                                                                           
        "U",                                                                    
        "0",                                                     
        mesh,                                                                   
        IOobject::MUST_READ,                                                    
        IOobject::AUTO_WRITE                                                    
    ),                                                                          
    mesh                                                                        
);

[amuzeshi]

Originally Posted by Mars409

Does anyone know a way to make icoUncoupledKinematicParcelFoam not ....

Hello,
Compile this solver as a new one with the change shown below in RED in createFields.H:

Info<< "Reading field U\n" << endl;
volVectorField U
(
    IOobject
    (
        "U",
        runTime.timeName(),
        mesh,
        IOobject::MUST_READ,
        IOobject::NO_WRITE
    ),
    mesh
);

[Mars409]

Tobias, Ali, Thanks. It works!

This solver is such a great tool. I absolutely love it.

================

On the replacing 'runTime.timeName()' with "0", I guess you are right, though I haven't tried: runTime.timeName() returns the 'startFrom' time directory named in controlDict, and so if the controlDict has 'startFrom' set to 'latestTime' and the previous run's latest time directory doesn't have the velocity volume field then the solver will fail. I am guessing here, but got my confirmation from https://openfoamwiki.net/index.php/ScalarTransportFoam (found by search word 'runTime.timeName')
where it says

runTime.timeName() defines from which time directory the file has to be read, according to what specified in controlDict by the user.

It seems that, in order to restart from time 0, the user can just set 'startFrom' value to 0 or 'startTime' in controlDict, instead of hard coding "0" in createField.H.

OTOH, if the user wants to resume simulation from the latest time (by setting startFrom to 'latestTime' in controlDict), just creating soft links in the latest time directory to link to the volume fields in the '0/' directory will do. So, in this instance, retaining "runTime.timeName()" in createField.h still has its use.

[Tobi]

Hi, I disagree to you last statement:

• if you run from 0 s to 10 s and stop the calculation and you re-run it with startTIme = 0, then you recalculate also the times from 0 s to 10 s which you probably would not want to do
• Hence, I said that you could be add the change the U field with the "0" look-up folder

But in any case. I am happy that you are done.
By the way, you could also make the symbolic links within the solver itself. The workaround should be somehow like that:

if (runTime.write())
{
    ::symlink(const char  *name1, const char *name2);
}

Tobi