CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   icoUncoupledKinematicParcelFoam (https://www.cfd-online.com/Forums/openfoam-solving/92556-icouncoupledkinematicparcelfoam.html)

kamranian September 18, 2011 04:26

icoUncoupledKinematicParcelFoam
 
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 September 20, 2011 11:42

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 September 21, 2011 05:04

icoUncoupledKinematicParcelFoam
 
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 September 21, 2011 06:40

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 November 18, 2011 10:28

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 January 18, 2013 06:01

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

rama13 July 14, 2014 14:05

icoUncoupledKinematicParcelFoam
 
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":confused:?!

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

Thanks for your attention,
Damiano

Tobi July 5, 2016 11:17

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 July 5, 2016 11:31

Thank you very much for your answer Toby!

Tobi July 5, 2016 11:36

Hi,

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

rama13 July 5, 2016 11:42

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

randolph July 19, 2017 13:19

Quote:

Originally Posted by Tobi (Post 608077)
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 March 3, 2018 07:22

Quote:

Originally Posted by gara1988 (Post 402610)
Hello Toorop, Have you find a solution of you question? I have the same problem.

DPMFoam is what u need.

AKBALOM October 13, 2019 12:20

icoUncoupledKinematicParcelFoam droplet trajectories
 
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 October 13, 2019 12:49

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 June 16, 2020 10:09

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 June 16, 2020 13:59

HI,



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



Code:

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


Change the following:


Code:

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


And recompile:


Code:

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:


Code:

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


amuzeshi June 16, 2020 15:57

Quote:

Originally Posted by Mars409 (Post 774744)
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:
Code:

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


Mars409 June 17, 2020 00:54

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
Quote:

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 June 17, 2020 05:20

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:


Code:

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


Tobi


All times are GMT -4. The time now is 20:07.