Parallel using icoLagrangianFoam
 

Hey Foamers:

It is very my pleasure to discuss the parallel running of icoLagrangianFoam.

When I use icoLagrangianFoam, at first I use the command' decomposePar' and there are two folders of 'processor0' and 'processor1' to be created. And then I used the command of ''mpriun -np icoLagrangianFoam'.

The case is run, but there is no result to be saved in the folder of 'processor1'and'processor0', and the result is saved under the folder of case.

I feel a little confused whether the icoLangrangianFoam could be run paralleled or the result is saved under the folder of case other in the 'processor*`. Would anyone like to help me for the question?

Thanks and best wishes!

Try again with
mpriun -np 2 icoLagrangianFoam -parallel
(what you did was run two serial runs in parallel

Bernhard

Sincerely thanks! And it is work now. But for running paralleled with two processors is even slower than one processor.

For small cases that is not surprising, because the communication needs more time than the actual calculation

Thanks a lot

Long time no see. And wish all foamers are fine.

There are big bugs on "icoLagrangianFoam" in the case of paralleling computing. There is no problem for the case are computed using one process. If the mesh is decomposed in the z direction for cavity, the particle could be moved, but the result is different with case of using one process, it is the same situation for the y direction. The worst thing is that the particles can not be moved if it is decomposed in x direction after the computation starts some steps. It is absolutely there is some problem for the particle transfered between processors.

Does anyone also find the bug?
It is very sad I know few about the part of transfer field of particles. Who would like to give me some advice on it?

Thanks and best wishes!

Before we start talking: which version? (OpenFOAM and icoLagrangianFoam)

I just had a quick look at the latest version and noticed that in method HardBallParticle::hitProcessorPatch it reads
td.switchProcessor=false;
where in my opinion it should be
td.switchProcessor=true;
but I'm not 100% sure whether this will fix it and I havn't got the time to test it

Bernhard

It is icoLangrangianFoam for OpenFoam 1.5.

In the HardBallParticle.C, there is no lines in the member function of HardBallParticle::hitProcessorPatch. Maybe I should add these lines. I will try it. Thanks a lot.

There are two such methods. One is empty. The other not.

Hi Bernhard,

Yes, this solves the problem.
However, if I set useMomentumSource to 1, i.e. two-way coupling of solid and fluid phase, a extremely high value of Co will be achieved. This obviously not physical. This may be dedicated to the suddenly appearance of particles in a new processor.

Any idea to solve this?

Thanks.

Roro

Does this happen only in parallel runs? (I doubt it)

I think it IS physical: particles with a momentum appear out of nowhere (OK. THAT is unphysical). What should the fluid do? Suffer silently (that would be unphysical) or try to incorporate the additional momentum (that is what you're seeing)

Solutions all have to do with the injector:
- inject less (volume fraction of the particles should be well below 10% for the solver to be valid)
- inject slower
- write a different injector (on the patch, one that injects with no relative velocity to the fluid)

Bernhard

Hi, Bernard,

Yes, it's not the parallel problem. Particles can smoothly pass the processorPatch.

Thanks.

Roro

problems in parallel
 

Hi All,

I downloaded the icoLagrangianFoam from (http://openfoam-extend.svn.sourcefor...agrangianFoam/) and everything compiled fine in OF-1.5-dev

I tried to run icoLagrangianFoam in parallel and it failed, giving the following error messages:

I thought it might be a recent update of my kernel, but a quick parallel run of interFoam on the damBreak case finished without any problems.

I ran a parallel run using
Im sure its something I'm doing wrong. Any help?

Dan

Hi Dan!

Could you try the same with the rhoTurbTwinParcelFoam? Just to make sure whether the problem is with the solver or with the library?

Bernhard

same error...
 

Thanks for the reply, I tried the rhoTurbTwinParcelFoam solver and it compiled fine. When i ran the test case received the error:

the code works fine in serial.

I then went to the lagrangian folder in the $FOAM_SRC and performed and "svn update" and then recompiled the lagrangian files with the ./Allwmake script. Still the same error. Is there another folder I should update? Should I do a complete update of 1.5-dev?

Dan

update and recompile did not help
 

I just wanted to make sure it wasn't something else that was out of date and needed to be updated. I updated all of of-1.5-dev through svn and recompiled the changes, tried to run parallel again with icoLagrangianFoam and same error messages.

I'm working on 64bit ubuntu 9.10

Dan

This seems to be a general problem with the 1.5-dev (I'm getting it too). The nature of the stack-trace indicates that somewhere memory is freed twice somewhere

Bernhard

Hi All,

Does anyone know how to get around the failure with resulting stack trace problem when running icoLagrangianFoam in parallel?.
I am also getting this with OF 1.5-dev. It works fine on one processor, but as soon as I try to run it in parallel I also get this error.

I also noted that icoLagrangianFoam is not included in OF 1.6-ext. I tried to move it across but when I tried to compile it with (wmake icoLagrangianFoam ) it complains about a missing CintDefs.H file.

Thanks in advance (again),

Paul.

Hi Paul!

icoLagrangianFoam should be in 1.6-ext, but not in the solver directory but in $FOAM_TUTORIALS/lagrangian

Bernhard

Hi Bernhard,

I compiled the icoLagrangianFoam files in $FOAM_TUTORIALS/lagrangian of OF 1.6-ext and everything now works.

Thanks again,

Paul.

particles in Parallel runs do not get injected
 

dear Bernard and others,

I have modeified coalChemistryFoam in OF-1.6 with 3 types of coal particles, viz., coalCloud1, coalCloud2 and coalCloud3.

If I run just a single node run, then all the particles get injected from the three patches.

But if I decompose the run into multiple processors (say 16, 32 or 64), then somehow particles do not get injected. As if the solver does not have any information about lagrangian particle injection.

This is just strange and I am wondering if anyone knows what could be the reason for this.

Please let me know your inputs, if any.

Thanks,
Nir

Hi Nir!

Some questions:
- have you tried running the regular coalChemistryFoam-solver in a similar configuration (just to rule out that the problem is with your modification)
- Which version of 1.6 are you running? Vanilla 1.6, 1.6.x (that one should have bug-fixes) or 1.6-ext
- how is this question related to icoLagrangianFoam

Bernhard

Hi Bernard,

Probably this is not very connected to IcoLagrangianFoam, but because there are particle models involved, I thought I will ask this question here. The reguglar coalChemistryFoam does work in multiple processors.

I guess I should re-check on my implementation before I have more questions on it.

Thanks,
Nir

You can't have done much wrong (if you just added the Clouds). Which injection model do you use? Try varying that and try disabling 2 of the 3 clouds (by setting active to false in the properties-dictionary)

Bernhard

Hello Bernard and Folks,

I think I was able to get the 3 clouds done eventually.

But I want to know if anyone of you are aware of any extention of ManualInjection options with continuous injection for multiple locations. In one of my case I have to have 12 injections. I am guessing it may be simpler to convert ManualInjection at multiple points to have multiple Cone injections from those points?

Any ideas, information!

Thanks,
Nir

Hello Folks,

I think I found something in the InjectionModel. I think ConeInjectionMP can handle injections from multiple points.

-Nir

ConeInjectionMP
 

Has anyone used ConinjectionMP. I am trying to use injections from 24 different locations, but it only injectios from 6 locations.

Has anyone experienced this kind of behaviour with ConeInjectionMP? How can I check if it is really reading the number of injections that I am specifying.

Thanks,
Nir

Hi, Nir,

My experience is avoid injecting close to processor's boundary. Sometimes wired things happen. Please check it.

Thanks.

Roro

Hey Gschaider:

I hope you are fine and I feel you can help me about the question.

I have make the icoLagrangianFoam run in the paralleled way, but when I compute smaller particles such as around 2 micro meter. The time step becomes very small. For example in normal 1.0e-6 is enough, but in this particle size, it can be 1.0e-7. Even this time step, it doesn't work and I have to change it to 1.0e-8.

By the way, I feel confused that when I try to identify the call process of the function, I find it doesn't call the function of HardBallParticle::Move() in the paralleled computation. It should call it, but I can see it calls the function. In the single process, I can see it call the function through outputting in the function, but in the paralleled computation, I can not get any information through outputting.

So small step is not acceptable for me, please give me some advice on it.

Thanks and best regards

I hope you are fine and I feel you can help me about the question.

I have make the icoLagrangianFoam run in the paralleled way, but when I compute smaller particles such as around 2 micro meter. The time step becomes very small. For example in normal 1.0e-6 is enough, but in this particle size, it can be 1.0e-7. Even this time step, it doesn't work and I have to change it to 1.0e-8.

By the way, I feel confused that when I try to identify the call process of the function, I find it doesn't call the function of HardBallParticle::Move() in the paralleled computation. It should call it, but I can see it calls the function. In the single process, I can see it call the function through outputting in the function, but in the paralleled computation, I can not get any information through outputting.

So small step is not acceptable for me, please give me some advice on it.

Thanks and best regards

With such small particles the question is whether you need a lagrangian solver (because the particles will immidiately follow the flow)

Don't know about your concrete problem.

For output on parallel processes use Pout instead of Info (you will get the same output but with the processor number)

Bernhard

Dear gschaider:

Thanks so much for your reply. For my problem, I am sure that the lagrangian solver is fine for me. I will try to output it again and try to identify the reason and I update the further result about it. Thanks so much.

Dear Gschaider:


As your suggestion, I use the 'Pout' to output the information. And finally, I find the problem happens during the process of particle transferring. It seems that, the particles doesn't change so much in the case that the dt is too big. If it is small enough. After some steps. it will be carried forward. It seems that dt influences the particles' transformation. It is sad that I don't know the way. Would you please give me some hint about it?

It seems that the update method is not influenced so much by the time step as the particle transferring in different processors.

This may or may not (I have not time to check) this bug:

http://www.cfd-online.com/Forums/ope...l-patches.html

Dear Gschaider:

Thanks so much for it. I think it is very possible. Would you mind providing me some idea on how to solve the problem? In fact, definitely I need to give the WallImpactdistance function.

Thanks so much and best wishes!

Dear Gschaider:

There is another question which is funny as well. In the paralleled computation. If I injected the particles at different time step. Cell number is less than 0, but it is still injected, but cellI is totally strange in the injected data. I am also trying to solve this problem. If it is possible, would you please give me some hint on it.

Thanks and best wishes!

I am sorry that I didn't see the patch file. Sorry again. I will try again

Dear Gschaider:

I have solved the problem as the guide in the link.

If it is possible, I would like to inquire you for another problem.

During injection particles in paralleled computation, although the cellI is -1, but particles are still injected and it is double as in the single processor. If I change the mesh.findNearestCell. It will be four times of the particles number in single processor.

Would you please give me some hint about how particles is injected in the paralleled computation? Then I probably find the reason.

So many thanks and best wishes!