Dear all,
I'm trying to write
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 |
Hi David!
If the breakup mo
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) |
Dear all,
Bernhard, thank y
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 |
Hello,
I runned succesfully
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:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) 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 ------------------------------------------ |
Is it the icoLagrangian from t
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. |
Hello Bernhard,
Yes, the ic
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 |
Hello again,
I have just lo
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 |
OpenFOAM-1.3/src/lagrangian/ba
OpenFOAM-1.3/src/lagrangian/basic/particle/particle.C, lines 343 and onwards: treatment for cyclic and parallel.
Hrv |
Thanks you Hrv,
Anne
Thanks you Hrv,
Anne |
One more question ...
Can i
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 --------------------------------- |
Hi,
Any explanation on why
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 |
@anne: As it says on the page
@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: /**/) |
Dear all,
I would like to use
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 |
David.
No problem. I have s
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. |
Dear Bernhard,
Thank you so
|
Hello
I am using icoLgrangian
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 |
Hi
I run the same case (perio
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 |
i was wondering if someone cou
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 |
hi,
the only thing what is
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 |
Hi Alan!
In the posting of
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. |
Hi
what i'm trying to do is
Hi
what i'm trying to do is include resuspension into the model. to this end when a particle is deposited i can take note of it diameter, its mass , position it was deposited at , there i can work out what energy is needed in the fluid to resuspened (re entrain) it into the fluid. at the moment i have this in a struct (see below) struct pt{ int dep_num; int dep_numres; scalar tsdep; scalar Ead; vector posr; scalar dp; scalar mass; scalar Eres; scalar dep_res; //0-empty 1-deposit 2-resuspended } pdr[SIZE]; what i would like to be able to do is access this information in IncompressibleCloud.C. so i can just use the inject to place back particle into cloud. any advice would be most welcome, would like to start my test cases soon so i can be finished by deal line and this problem is something that i can't find away around. Thanks in Advance Alan Fergus |
Hi Alan!
Do I understand yo
Hi Alan!
Do I understand you correctly? Theses properties are to be stored per particle. Then they should not go into the Cloud-Subclass (IncompressibleCloud in IcoLagrangianFoam) but into the Particle-subclass (HardBallParticle in IcoLagrangianFoam). Look for the handling of mass_ and d_ in HardBallParticle as an example. That way it is easier to add or remover particles. Storing the particle properties in an array with a fixed size (that is how I interpret your pdr-array) is so FORTRAN. Don't get me wrong: some of the cleverest people I know program FORTRAN, it's just not the way things are done in OpenFOAM Bernhard |
Hello all,
I am trying to c
Hello all,
I am trying to compile icoLagrangianFoam on Openfoam 1.4 and get the following error: /home/mgo/OpenFOAM/OpenFOAM-1.4/src/finiteVolume/lnInclude/volPointInterpolation .H: In constructor 'Foam::IncompressibleCloud::IncompressibleCloud(co nst Foam::volPointInterpolation&, const Foam::volVectorField&)': /home/mgo/OpenFOAM/OpenFOAM-1.4/src/finiteVolume/lnInclude/volPointInterpolation .H:70: error: 'Foam::volPointInterpolation::volPointInterpolatio n(const Foam::volPointInterpolation&)' is private IncompressibleCloud.C:68: error: within this context IncompressibleCloud.C: In member function 'void Foam::IncompressibleCloud::track()': IncompressibleCloud.C:154: error: 'track' is not a member of 'Foam::Cloud<foam::hardballparticle>' make: *** [Make/linux64Gcc4DPOpt/IncompressibleCloud.o] Error 1 Need help to fix it. Thanks. mayank |
That is because the sources on
That is because the sources on the Wiki are for version 1.3 and there have been changes in the particle-codes for version 1.4. I have an adapted version for 1.4 on my hard-disk that I didn't publish yet because in my opinion it still had a problem with the second test case (particles didn't stop bouncing). I have uploaded it to a (not yet fully operational) Subversion repository. You can get it with the command (if you have Subversion installed on your machine)
svn checkout https://openfoam-extend.svn.sourceforge.net/svnroot/openfoam-extend/trunk/Breede r/solvers/other/IcoLagrangianFoam Be aware, that this is a very untested version (as opposed to the 1.3-version which was little-tested) |
Hi Bernhard,
I've got icoL
Hi Bernhard,
I've got icoLagrangianFoam from the repository, when I compiled it I got some errors, the same as those Aurelia obtained in the Thread "Changes in OF 1.4 and compilation issues". I've fixed the error due to track, but not the other, the one at line 68. Can you please tell me how can I solve it? Thanks in advance Francesco |
I've succeed in fixing the pro
I've succeed in fixing the problem, sorry for my stupid question
|
Hi all,
I am new to OpenFOA
Hi all,
I am new to OpenFOAM and want to simulate particles in a fluid. I use OF 1.5 and have difficulties compiling icoLagrangianFoam: Making dependency list for source file icoLagrangianFoam.C Making dependency list for source file HardBallParticle.C Making dependency list for source file IncompressibleCloud.C SOURCE=icoLagrangianFoam.C ; g++ -m64 -Dlinux64 -DDP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -march=opteron -O3 -DNoRepository -ftemplate-depth-40 -I/scratch/OpenFOAM/OpenFOAM-1.5/src/cfdTools/incompressible -I/scratch/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude -I/scratch/OpenFOAM/OpenFOAM-1.5/src/lagrangian/basic/lnInclude -I/scratch/OpenFOAM/OpenFOAM-1.5/src/cfdTools/general/lnInclude -I/scratch/OpenFOAM/OpenFOAM-1.5/src/finiteVolume/lnInclude -IlnInclude -I. -I/scratch/OpenFOAM/OpenFOAM-1.5/src/OpenFOAM/lnInclude -I/scratch/OpenFOAM/OpenFOAM-1.5/src/OSspecific/Unix/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/icoLagrangianFoam.o In file included from icoLagrangianFoam.C:35: HardBallParticle.H:56: error: expected template-name before '<' token HardBallParticle.H:56: error: expected `{' before '<' token HardBallParticle.H:56: error: expected unqualified-id before '<' token icoLagrangianFoam.C:118: error: expected `}' at end of input make: *** [Make/linux64GccDPOpt/icoLagrangianFoam.o] Error 1 Has anyone an updated version for 1.5 or may anyone help me to fix the problems. And I have a more general question: Are particles in this solver treated like pointwise particles? Is there a possibility with OpenFOAM to simulate particles with a finite Volume? Thanks in advance max |
Hi Max!
The current version
Hi Max!
The current version of the icoLagrangianFoam was NOT tested with 1.5 (and I'd be surprised if it worked). A more recent example of a lagrangian solver in 1.5 can be found in $FOAM_TUTORIALS/rhoTurbTwinParcelFoam. Yes the particles are treated pointwise. If you're looking for a continous approach have a look at $FOAM_SOLVERS/multiphase. Especially twoPhaseEulerFoam Bernhard |
Bernhard,
Can you send me a
Bernhard,
Can you send me a copy of that injection through patch code? My email is sripplinger@earthnet.us |
Hi Scott!
You are referring
Hi Scott!
You are referring to the posting from august 2006, are you? I can send it to you, but it would be an exercise in archeology because since then the Lagrangian-particle system went through some serious evolutions (which changed things for the better, I must add) especially in terms of the run-time-selectable injectors, I'd be surprised if the code compiles/works with recent versions of the particle system (and I currently haven't got the time to modify/test it), but if you insist, I can send it to you Bernhard |
Bernhard,
I am planning on
Bernhard,
I am planning on making use of the Solid Particle class in OF v1.5. Right now, however, I already have a solver that Jeff Allen put together based on your icoLagrangianFoam that runs with v1.3. So I could still use the pertinent pieces of code for patch injection, if you can find them. If it is an inconvenience I will make do with something else. |
Hi Scott!
I sent you an EMa
Hi Scott!
I sent you an EMail Bernhard |
volPointInterpolation error
Hello all,
I am using OF 2.1.x to simulate spray using sprayFoam. The fuel injected is a new fuel that has been added to the library. The solver encounters "volPointInterpolation" error (see below) after about 5ms of flow time. However, when an existing fuel from the liquidProperties library is injected, there are no errors. The error also refers to GeometricField and volMesh. But I'm certain that there are no issues with the snappy mesh (checkMesh -allGeometry shows no errors and face tets are OK). Thank you ! [8] #0 Foam::error::printStack(Foam::Ostream&) in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libOpenFOAM.so" [8] #1 Foam::sigSegv::sigHandler(int) in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libOpenFOAM.so" [8] #2 [8] at sigaction.c:0 [8] #3 void Foam::volPointInterpolation::interpolateInternalFi eld<Foam::Vector<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<Foam::Vector<double>, Foam::pointPatchField, Foam::pointMesh>&) const in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libfiniteVolume.so" [8] #4 Foam::tmp<Foam::GeometricField<Foam::Vector<double >, Foam::pointPatchField, Foam::pointMesh> > Foam::volPointInterpolation::interpolate<Foam::Vec tor<double> >(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) const in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libfiniteVolume.so" [8] #5 Foam::interpolationCellPoint<Foam::Vector<double> >::interpolationCellPoint(Foam::GeometricField<Foa m::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libfiniteVolume.so" [8] #6 Foam::interpolation<Foam::Vector<double> >::adddictionaryConstructorToTable<Foam::interpola tionCellPoint<Foam::Vector<double> > >::New(Foam::GeometricField<Foam::Vector<double> , Foam::fvPatchField, Foam::volMesh> const&) in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/lib/libfiniteVolume.so" [8] #7 Foam::interpolation<Foam::Vector<double> >::New(Foam::word const&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) in "/home/cfduser/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64Gcc46DPOpt/bin/sprayFoam" |
I think much of the particle functionality discussed in this post is out of date. A lot have happened in OpenFOAM on this field since then, especially from the 2.0-version until now. I suggest that you create a new thread for your problem, and try to describe your problem in more details. If you can, please also present examples and code snipplets. And you should always describe what you have done to fix the issue!
|
All times are GMT -4. The time now is 20:39. |