[sachin]

hi all,
Thanks Bernhard
I would like to add thermal effect for drag force calculation and eventually to the momentum change in particle....so would like to know where are the calculation for smoment_ is done so that i can add these term...smoment_ is actually defined just above tsource calculation where it is used then where are the calculations for smoment_ done

thanks in advance
sachin

[suraj]

Hello All,
I am Suraj. I am trying to integrate Lagrangian particle tracking with interFoam (OpenFOAM-1.5). The code icoLagrangianFoam (written for OpenFOAM-1.5) was really very helpful.
Now, I am ready with my code but it does not work very well in parallel .

I added some more physical variables apart from U (ie, pd and rho) to the code and changed the equations of motion. What the code does is that it runs in parallel for some time steps and after that it just does not do anything, as if it is in an infinite loop. It also does not respond to the changes made to controlDict. Is that an MPI issue? Is it common for particle codes (I did not see decomposeParDict in any of Lagrangian code tutorials)?

It would be very helpful to have your suggestion on this.

Another thing I saw in the code was the time step passed to the the HardBallParticle::updateProperties(...) function (ie the line updateProperties(deltaT,data,cellI,face()); ) . I think it should be dt, as defined in HardBallParticle::move(...) function.


Thanks,
Regards,
Suraj Deshpande

[gschaider]

Originally Posted by suraj

Hello All,
I am Suraj. I am trying to integrate Lagrangian particle tracking with interFoam (OpenFOAM-1.5). The code icoLagrangianFoam (written for OpenFOAM-1.5) was really very helpful.
Now, I am ready with my code but it does not work very well in parallel .

I added some more physical variables apart from U (ie, pd and rho) to the code and changed the equations of motion. What the code does is that it runs in parallel for some time steps and after that it just does not do anything, as if it is in an infinite loop. It also does not respond to the changes made to controlDict. Is that an MPI issue? Is it common for particle codes (I did not see decomposeParDict in any of Lagrangian code tutorials)?

It would be very helpful to have your suggestion on this.

At first: which version of OF are you using and which version of the solver?

One word of warning: I'm not planing to port the solver to OF 1.6 as starting with 1.5 there are example solvers that use lagrangian particles in the distribution. The 1.5-version of icoLagrangianFoam was just a straight port from the 1.4.1-version and didn't use the new particle classes.

Could you be more specific on the topic "hangs": what is the last output (that would help to tell in which phase the problem occurs)?

Have you ever run a debug-version of the code? Some problems come to light when running one (if you do any serious development you should have one)

Does this always happen or only with certain decompositions? Try some different decompositions

Originally Posted by suraj

Another thing I saw in the code was the time step passed to the the HardBallParticle::updateProperties(...) function (ie the line updateProperties(deltaT,data,cellI,face()); ) . I think it should be dt, as defined in HardBallParticle::move(...) function.

That may be right. I'll have a look

Bernhard

[suraj]

Dear Bernhard,

I am using OpenFOAM-1.5. I am making changes to the standard interFoam solver that came with it. I have not used the debug version of the code.

The code stops while moving the particles. To be more precise, it stops at the statement: this->move(td) in IncompressibleCloud.C .

I have seen this happen with larger (about half a million cells) cases; smaller 2D cases do not stop. Also, interestingly, the case hangs at different times for different number of decompositions (it hangs much earlier for cases decomposed into large number of subdomains eg 32 and does not hang at all for single processor cases, no matter how big the case is). This is what leads me into thinking if this is a problem with inter-processor communication in my code.

This is what I see in the log:

Courant Number mean: 0.0022608 max: 0.166463
Moving Particles
529 Particles moved. 0 walls hit. 0 particles left the model. 1 particles injected.
Time = 4.0672

MULES: Solving for gamma
Liquid phase volume fraction = 0.517803 Min(gamma) = -2.17137e-09 Max(gamma) = 1
MULES: Solving for gamma
Liquid phase volume fraction = 0.517803 Min(gamma) = -1.04872e-10 Max(gamma) = 1
DICPCG: Solving for pd, Initial residual = 0.00124773, Final residual = 4.05203e-05,
No Iterations 3
DICPCG: Solving for pd, Initial residual = 0.000151898, Final residual = 6.90998e-06
, No Iterations 6
DICPCG: Solving for pd, Initial residual = 3.09272e-05, Final residual = 9.78173e-08
, No Iterations 43
time step continuity errors : sum local = 3.48316e-10, global = -7.79987e-11, cumulat
ive = 3.38557e-09
ExecutionTime = 538.01 s ClockTime = 541 s

Courant Number mean: 0.00226081 max: 0.167813
Moving Particles

...... hangs here

Also, there are times when the the number of particles crossing processor patch goes astronomically high (3-4Million) for number of droplets as small as 150. I am not sure if this an issue too...

Thanks,
Suraj

[gschaider]

Originally Posted by suraj

Dear Bernhard,

I am using OpenFOAM-1.5. I am making changes to the standard interFoam solver that came with it. I have not used the debug version of the code.

The code stops while moving the particles. To be more precise, it stops at the statement: this->move(td) in IncompressibleCloud.C .

I have seen this happen with larger (about half a million cells) cases; smaller 2D cases do not stop. Also, interestingly, the case hangs at different times for different number of decompositions (it hangs much earlier for cases decomposed into large number of subdomains eg 32 and does not hang at all for single processor cases, no matter how big the case is). This is what leads me into thinking if this is a problem with inter-processor communication in my code.

This is what I see in the log:

Courant Number mean: 0.0022608 max: 0.166463
Moving Particles
529 Particles moved. 0 walls hit. 0 particles left the model. 1 particles injected.
Time = 4.0672

MULES: Solving for gamma
Liquid phase volume fraction = 0.517803 Min(gamma) = -2.17137e-09 Max(gamma) = 1
MULES: Solving for gamma
Liquid phase volume fraction = 0.517803 Min(gamma) = -1.04872e-10 Max(gamma) = 1
DICPCG: Solving for pd, Initial residual = 0.00124773, Final residual = 4.05203e-05,
No Iterations 3
DICPCG: Solving for pd, Initial residual = 0.000151898, Final residual = 6.90998e-06
, No Iterations 6
DICPCG: Solving for pd, Initial residual = 3.09272e-05, Final residual = 9.78173e-08
, No Iterations 43
time step continuity errors : sum local = 3.48316e-10, global = -7.79987e-11, cumulat
ive = 3.38557e-09
ExecutionTime = 538.01 s ClockTime = 541 s

Courant Number mean: 0.00226081 max: 0.167813
Moving Particles

...... hangs here

Also, there are times when the the number of particles crossing processor patch goes astronomically high (3-4Million) for number of droplets as small as 150. I am not sure if this an issue too...

But sometimes particle cross to other processors sucessfully? No idea. Sprinkle the HardballParticle.C with "

Pout << something << endl;

statements (especially the stuff concerning parallelization) to find what might be the problem

Bernhard

[suraj]

Thanks Bernhard,
I will try this and let you know if I see something interesting.

Thanks again,
Regards,
Suraj Deshpande

[suraj]

Hi Bernhard,
I used the Pout statements as you suggested. I think I have a problem in Cloud<HardBallParticle>::move(TrackingData& td) of Cloud.C. The code stops at the statement "combineReduce(allNTrans, combineNsTransPs());" .
I will try to see what this function does.
Any suggestions?

Thanks,
Suraj Deshpande

[gschaider]

Originally Posted by suraj

Hi Bernhard,
I used the Pout statements as you suggested. I think I have a problem in Cloud<HardBallParticle>::move(TrackingData& td) of Cloud.C. The code stops at the statement "combineReduce(allNTrans, combineNsTransPs());" .
I will try to see what this function does.
Any suggestions?

This is hardcore (that part should work in any case). Do ALL processors reach that statement?

Which version of 1.5 are you using (unpatched, 1.5.x or something in between)? (I think there was a fix sometime it affected parallel running of dieselFoam which might have been the same problem)

Bernhard

[flying]

Hello OpenFoamer:

I wish all of you are enjoying the life now.

I am implementing a model in the icoLagrangianFoam which can solve the sub-micro particles. I need to generate the random number. I try to use the class random().scalar01() in the HardBallParticle::updateProperties, but it is pity that there is some error as following:

HardBallParticle.C:181: error: request for member 'scalar01' in 'random()', which is of non-class type 'long int'

who can give me some hint on it?

[flying]

Hello OpenFoamer:

I wish all of you are enjoying the life now.

I am implementing a model in the icoLagrangianFoam which can solve the sub-micro particles. I need to generate the random number. I try to use the class random().scalar01() in the HardBallParticle::updateProperties, but it is pity that there is some error as following:

HardBallParticle.C:181: error: request for member 'scalar01' in 'random()', which is of non-class type 'long int'

who can give me some hint on it?

[jiejie]

Originally Posted by flying

Hello OpenFoamer:

I wish all of you are enjoying the life now.

I am implementing a model in the icoLagrangianFoam which can solve the sub-micro particles. I need to generate the random number. I try to use the class random().scalar01() in the HardBallParticle::updateProperties, but it is pity that there is some error as following:

HardBallParticle.C:181: error: request for member 'scalar01' in 'random()', which is of non-class type 'long int'

who can give me some hint on it?

I tried to include the Random.H header file, but it doesn't really help either???

Any help will be appraciated.

[gschaider]

Originally Posted by jiejie

I tried to include the Random.H header file, but it doesn't really help either???

Any help will be appraciated.

Case is important in C++. "random" is a system-function (that returns a long int - thus the error). "Random" is a class in Foam.

BTE: the way you call it will probably always give you the same number - but I would have to look at the implementation to be 100% sure

[jiejie]

Originally Posted by gschaider

Case is important in C++. "random" is a system-function (that returns a long int - thus the error). "Random" is a class in Foam.

BTE: the way you call it will probably always give you the same number - but I would have to look at the implementation to be 100% sure

Thanks gschaider. Hope to hear from you soon.