[davidpalko]

Dear all,
I'm trying to write a sover for droplet breakup and coalescence using Lagrangian-Eulerian approach (as my thesis work). As I found, there already exist libraries for breakup in ../src/lagrangian/, and they are also implemented into DieselFoam. However DieselFoam solves all the chemistry etc.. that is not relevant for my water-steam flow.
As a good start I found icoLagrangianFoam, where basic lagrangian tracking is implemented. However, I would like to ask you, how I can find a piece of code, where the forces acting on a particle are implemented?

Thank you very much for your help.

Regards,

David

[gschaider]

Hi David!

If the breakup models in ./src/lagrangian/ are relevant for your case I would suggest one of these two approaches:

- take the dieselFoam-sources and lobotomize them (remove chemistry etc) until it fits your case or
- take a solver of your choice and add basic Lagrangian particles to it (using icoLagrangian as a template), then take a look at dieselFoam-sources (where they insert the hooks to the breakup model) and modify your solver similar

That way you can test your solver with breakup-models that other people have already implemented for you. If these models don't fit your need it should be easy to add another one (and it will be run-time selectable)

[davidpalko]

Dear all,

Bernhard, thank you for your reply. Actually I already implemented your first suggestion and I lobotomized dieselFoam solver, which looks that would work.
If you or anyone else don't mind to answer, I've got a few more questions:

1. In specifing particular case, when using water droplets as a Lagrangian particles, is it right to specify it's properties just by setting the following in thermophysicalProperties? :

liquidFuelComponents
(
H2O
);

H2O H2O defaultCoeffs;

and modify chem.inp file to looks like:

ELEMENTS
H O
END
SPECIE
H2O
END

2. How can I properly set up the properties of eulerian field, let's say for steam for example?

3. (and the last one) Regarding definition of injector: I would like to use the whole inlet surface (wall) of a channel as an injector. Is there any way to do so? (I went through the discussion and did not find the answer for that, but maybe I didn't read it carefully)

Thank you so much. Your replies are very helpful for me.

Regards,

David

[anne]

Hello,

I runned succesfully lagragian tracking particles solver (OpenFoam 1.3)
based on icolagragianFoam in
a cavity flow configuration and as well in a 2D laminar jet (for testing).

However, when I tried to run it in a periodic
turbulent channel flow I have a message error (see below) due
to non cyclic patch implemented for "evaluate()".

Is there any way to fix this ?

Thanks,

Anne


--------
Mean and max Courant Numbers = 0.005621971 0.05081659
Moving Particles


--> FOAM FATAL ERROR : Not implemented

From function void CyclicPointPatchField<patchfield,>::evaluate()
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/CyclicP ointPatchField.C at line 187.

FOAM aborting

Foam::error::printStack(Foam:stream&)
Foam::error::abort()
Foam::CyclicPointPatchField<foam::pointpatchfield, > >::evaluate()
Foam::GeometricField<foam::vector<double>, Foam::pointPatchField, Foam::pointMes h>::GeometricBoundaryField::evaluate()
void Foam::volPointInterpolation::interpolate<foam::vec tor<double> >(Foam::Geome tricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam: :GeometricField<foam::vector<double>, Foam::pointPatchField, Foam::pointMesh>&) const
Foam::tmp<foam::geometricfield<foam::vector<double >, Foam::pointPatchField, Foam ::pointMesh> > Foam::volPointInterpolation::interpolate<foam::vec tor<double> >(F oam::GeometricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh> con st&) const
Foam::interpolationCellPointFace<foam::vector<doub le> >::interpolationCellPointF ace(Foam::volPointInterpolation const&, Foam::GeometricField<foam::vector<double>, Foam::fvPatchField, Foam::volMesh> const&)
Foam::interpolation<foam::vector<double> >::adddictionaryConstructorToTable<foam> > >::New(Foam::volPointInterpo lation const&, Foam::GeometricField<foam::vector<double>, Foam::fvPatchField, Fo am::volMesh> const&)
chanLagr [0x80d98b5]
chanLagr [0x80d439c]
chanLagr [0x805f429]
__libc_start_main
__gxx_personality_v0
Aborted
------------------------------------------

[gschaider]

Is it the icoLagrangian from the Wiki you are refering to? I'd be surprised (and I should know) if that one knows how to treat periodic BCs for particles (but it's not that difficult, it's all in the dieselFoam-sources). It all boils down to inserting a special treatment to the boundary treatment in HardBallParticle.C (somwhere after if(onBoundary()) )

If I interpret the icoLagrangian-code on the Wiki correctly ("Any code older than 3 months could have been written by anybode else"), if a particle hits any type of patch except for wall-patches it is removed from the simulation (=leaving). Which is some kind of treatment for periodic BCs (not the best obviously)

Have you changed the original solver massivly and could you share a stack trace after applying
http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/2686
with us? Line numbers and files would help.

[anne]

Hello Bernhard,

Yes, the icoLagrangianFoam I have
downloaded is from the wiki site.

Actually, I have now fixed the problem I had with
periodic BCs. As I had mentionned in my
email I had some doubts that it could come from,
not from the icoLagrangianFoam, but from the
cyclic BC implemented in OpenFoam 1-3.
(There was indeed the same message error when
using the postprocessing tools paraFoam or sample
on any application containing periodic patches).
About this last bug there is already a solution
to fix it that I couldn't apply successfully
on my binary
version because of some errors when
recompiling the libso library
(see http://www.cfd-online.com/cgi-bin/Op...cus/discus.cgi
)
However, on a installed version from the sources I could compile libso and run
icoLagrangiaFoam on a periodic channel.

I have been using icoLagrangianFoam
for only a few time and I am not sure about the
implementation of the cyclic patch for the particles. You mention that at any pacth, except a wall, the particle leaves the domain. BUT,
do you know if for a periodic patch the particle
is reinjected ? It should be, I will try to
find it out.


I thank you a lot for your help,

Anne

[anne]

Hello again,

I have just looked at the boundarytreatment.H
in the sources of diesel foam and I
disn't see any implementation for periodic
patches in a lagrangian tracking particles.
Only are defined symmetric, wall and outlet/inlet
patches.

Anne

[hjasak]

OpenFOAM-1.3/src/lagrangian/basic/particle/particle.C, lines 343 and onwards: treatment for cyclic and parallel.

Hrv

[anne]

Thanks you Hrv,

Anne

[anne]

One more question ...

Can icoLagrangianFoam be runned in parallel?

I have tried it without sucess.
when calling move particles, I have the error:

---------------------------------------------
Mean and max Courant Numbers = 0.005646263 0.05081659
Moving Particles
[0]
[0]
[0] --> FOAM FATAL ERROR : given patch field does not correspond to the mesh. Field size: 4030 mesh size: 3770
[0]
[0] From function void PointPatchField<patchfield,>::setInInternalField(F ield<type1>& iF, const Field<type1>& iF) const
[0] in file /disco06/c_fosiles/u5303/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/PointPatch Field.C at line 268.
[0]
FOAM parallel run aborting
---------------------------------

[lillberg]

Hi,

Any explanation on why the symmetryPlane treatment in particle.C is commented out? (line 332 ->)

else if (typeid(patch) == typeid(symmetryPolyPatch))
{
/*
label facei = patchFace(patchi);

vector nf = patch.faceAreas()[facei];
nf /= mag(nf);

transformProperties(I - 2.0*nf*nf);
*/
}

Regards

/Eric

[gschaider]

@anne: As it says on the page where it was published
* particles can bounce from walls or die
* particles leave the system at in or outlet. All other boundary types are not treat correctly
That means: No.

But parallelizing isn't that difficult: look at parcel.C in the original sources. You're looking for the lines in the move-method that say
if (typeid(pbMesh[patch(facei)]) == typeid(processorPolyPatch))
{
switchProcessor = true;
}
Look for other occurences of switchProcessor and modify the move-method accordingly. The Cloud::track-method should take care of the rest.

@eric: the commented out source means that the particle gets reflected at the symmetry boundary. The physical interpretation would be that at the moment a particle traverses the symmetry plane it passes through another particle which happens to go in the symmetrical direction. Not very likely.... So I think, that what the out-commenter (comment-outter ?) wanted to tell us is: "I can't think of a meaningful implementation for symmetry-boundaries because you never know what is on the other side ..." (and thinking of the philosophical implications he would add " ... particle-wise")
(But I'm only interpreting four letters here: /**/)

[davidpalko]

Dear all,
I would like to use the whole inlet surface of a channel as an "injector" of Lagrangian particles (within a DieselFoam case). Is there any way to do so?
I mean, to define the number of particles with a given diameter and velocity that are randomly injected from a given surface into the system.
Thank you very much.

Regards,

David

[gschaider]

David.

No problem. I have something like that sitting around on my harddisk. Drop me a mail and I'll send you the relevant parts (but be aware that it's not very general - you'll have to adapt it for your own case). Basically it's only looping over all the faces in the inlet and deciding for each (randomNumber<threshold) whether a particle should be injected here. If yes: place it on the center of the face, give it a velocity and let it fly.

[davidpalko]

Dear Bernhard,

Thank you so much. My e-mail is palko@m.kth.se

Regards,

David

[aurelia]

Hello
I am using icoLgrangianFoam to track particles in a channel.
First I set an oscillating BC at the inlet
After some iterations, the particles cross the outlet and desappear, but after a few more iteration, the solver keep "searching" but doesn't produce any further results.
As I needed to change the BC to set periodic BC,I created a new mesh, with cyclic BC (I used createPatch and couplePatches)
Then I mapped the first channel on the new one
But it does not map the lagrangian directory.
I looked in MapVolFields and meshToMesh, but I can't figure out what I should write.
If I copy the lagrangian directory from the first case (27363 cells) to the second one (27316 cells), the solver has some trouble with 2 particles (at cell 27353 and 27354), but it manages to found the nearest cell thanks to the position of the cells. It is working well : the particles which disappear at the "outlet" appear at the "inlet" (I changed HardBallParticule.C to take care of the cyclicPatch )
But after a few iterations nothing happen (like when I run with an inlet and an outlet)
Has anyone some experience in this topic and could help me?
Thanks a lot!
Aurelia

[aurelia]

Hi
I run the same case (periodic channel mapped from a non-periodic channel) without the lagrangian directory and it is running fine, so the problem comes from the particules, not from the flow.
Can it be because of the number of particules (around 3000) ? Is it too much?

Is there a nice way to mapp the lagrangian data?

Regards
Aurelia

[alan_fergus]

i was wondering if someone could help me. I have modified icoLagrangianFoam to be a more realisitc particle tracking model (including resuspension collisiopns etc.) i would like to be able to run it in parallel. This was posted this in the forums

By Bernhard Gschaider on Tuesday, August 15, 2006 - 07:45 am: Edit Post@anne: As it says on the page where it was published
* particles can bounce from walls or die
* particles leave the system at in or outlet. All other boundary types are not treat correctly
That means: No.

But parallelizing isn't that difficult: look at parcel.C in the original sources. You're looking for the lines in the move-method that say
if (typeid(pbMesh[patch(facei)]) == typeid(processorPolyPatch))
{
switchProcessor = true;
}
Look for other occurences of switchProcessor and modify the move-method accordingly. The Cloud::track-method should take care of the rest.


i was wondering if someone could explain this a little more for me
Thanks in Advance
Alan Fergus
NUI Galway

[stephan]

hi,

the only thing what is not parallel in liblagrangian is the collisionmodel.(as far as i looked through the source..)
so the case that a particle on one side of a processorboundary collides with a particle on the other side of the processorboundary does not exist.
- they have to belong to the same particle-cloud, which is defined on the mesh.

stephan

[gschaider]

Hi Alan!

In the posting of mine you were refering to I did not look at the Wiki-Page before writing that. On it (the Wiki page) it says in the history-section that the icoLagarngianFoam on the Wiki is already parallelized (I should make a habit of reading my own stuff).

Basically what the code snipplet you cited does is (this is the program speaking to itself): "Oh. We hit some kind of patch. Let's see what kind of patch. It's the boundary to another processor. Great. It's not my problem any more. Just put a flag on it and then that other processor will take care of it" The actual work of transfering the particle to the other processor is done be the lagrangian-library.

Hope that helps. And sorry for the misinformation about icoLagrangianFoam NOT being parallel.