[GPesch]

Hi,

I am facing a weird error.

I implemented another BinaryCollisionModel to the dsmcSolver in order to run simulations with the VSS-Model.

I am simulating a 1000nm long cube, which is a highly porous structure. On the one side is an inlet, the four long sides of the cube are a cyclic boundary condition and on the far end of the cube is a reflecting wall. Inside the cube are a lot of particles which were cutted out with snappy Hex Mesh in order to generate a highly porous structure.
Volume is filled with 1 atm of O2, the inflow has the same number density but with 1 % CO and 99 % of O2.

Everytime I run the case its freezing at 2.005e-08s of simulated time. The output simply stops after the inflow of the particles (after the inflow comes the particles movement routine and then the calculation of the collisions).
As i dont have a debug version of OF installed I made marks into the code to find out whats happening and I get stuck in the "particle::trackToFace" routine in the first loop:

do
{
...
}
while (faceI_< 0);

Apparently for one specific parcel in the cloud faceI_ never gets over 0 and an infinite loop is created.

I didn't look closely enough to the code do identify what the routine does exactly. I am pretty sure that it doesn't have anything to do with me playing around with the collisionModels because the applied changes are minor!

I'm working with OF-Version 2.1.1. but the dsmc library I am using comes from OF-201..

Apparently the error is also occuring when using OF201, a friend told me he was facing the same error in OF201 when simulating the same structure as I do.

It always occurs at the same time and I am pretty sure that my random generator is always producing the exact same sequence of pseudo-random numbers (running dsmcInitialise twice results in the exact same positions of generated parcels...) DsmcCloud uses a static number for initialising rndGen which is (971501 + 1526 * processorNumber). Is it usual that always the same number sequence is generated when the seed is the same? If yes, why not use a different number as seed, timestamp, etc?


So - back to my main question: Anybody ever faced freezing in dsmcFoam or has enough insides into the code of trackToFace to tell me what could possibly go wrong?
Would be very grateful, thanks in advance!

Best regards
Georg

[wenjie]

Hi,

I am also facing exactly the same problem. It looks very much like a dead loop in the code but I haven't figured out yet. If what you found is correct, then I know the trackToFace loop searches for the face/boundary that the particle trajectory is intersected by, until the remaining trajectory is small enough to be neglected.

I will continue look into that and post here any new progress.

[oswald]

I stumpled upon a similar problem. Not with dsmcFoam, but with some other lagrangian calculations. This thread helped me a lot, especially the changes supposed in post #7:
http://www.cfd-online.com/Forums/ope...ubroutine.html

Maybe it is of interest for you two.

[wenjie]

Originally Posted by oswald

I stumpled upon a similar problem. Not with dsmcFoam, but with some other lagrangian calculations. This thread helped me a lot, especially the changes supposed in post #7:
http://www.cfd-online.com/Forums/ope...ubroutine.html

Maybe it is of interest for you two.

Thanks a lot! I will have a look at it.