[lgtmelo]

Zoomed in pressure: https://i.imgur.com/fGsmLQF.mp4


Zoomed in velocity: https://i.imgur.com/qaWtUrp.mp4

[ghorrocks]

You can see the velocity field flapping about. So it definitely is transient. Whether that transient nature is significant for your model is another question, but the flow definitely has a major transient feature.

[lgtmelo]

Originally Posted by ghorrocks

You can see the velocity field flapping about. So it definitely is transient. Whether that transient nature is significant for your model is another question, but the flow definitely has a major transient feature.

thanks Glenn

any suggestion on how do I count the particles collision?

best regards

[ghorrocks]

I use the particle fate summary at the end of the simulation. You can also use the per-time step summaries as well. But if you run it transient you are going to have to run it for quite a while before enough particles go through for you to have reasonable statistics.

But note that the particle trapping performance might not be affected by the transient nature of the flow. If a steady state particle tracking model gives the same answers as a transient particle tracking model despite the transient flow then a steady state particle track model will be OK. And that will be orders of magnitude faster to run.

A final comment - have you considered using a Eularian particle tracking for for this rather than a Lagrangian one? If you only have one particle size and type the Eularian model can be quite efficient.

[lgtmelo]

Originally Posted by ghorrocks

I use the particle fate summary at the end of the simulation. You can also use the per-time step summaries as well. But if you run it transient you are going to have to run it for quite a while before enough particles go through for you to have reasonable statistics.

I did that when it was steady state, but now as transient it is confusing to me. this is the last particle fate summary:

+--------------------------------------------------------------------+
| Particle Fate Diagnostics |
+--------------------------------------------------------------------+
| Particle type | Fate type Particles |
+--------------------------------------------------------------------+
| BACTERIA | Entered domain : 5 |
| | Continue from last time step : 5745 |
| | Left domain : 1 |
| | Collected on walls : 2 |
| | Waiting for next time step : 5747 |
+--------------------------------------------------------------------+

Originally Posted by ghorrocks

But note that the particle trapping performance might not be affected by the transient nature of the flow. If a steady state particle tracking model gives the same answers as a transient particle tracking model despite the transient flow then a steady state particle track model will be OK. And that will be orders of magnitude faster to run.

I don't know much, but considering the flow only has the "dancing" after the infill, it seems steady state would be fine to me, as all that matter is up to the infill... how do I run the steady state model when it should be transient then?

Originally Posted by ghorrocks

A final comment - have you considered using a Eularian particle tracking for for this rather than a Lagrangian one? If you only have one particle size and type the Eularian model can be quite efficient.

I haven't, I went straight to Lagrangian because from what I read, it would be more reliable as it tracks each particle individually.


thank you for your inputs once again

[ghorrocks]

Make sur eyou understand what the categories are:

Continue from last time step : These are the number of particles in the flow and carrying over from the previous time step.

Left domain : These are the particle which exitted the domain, probably via the outlet.

Collected on walls : Obvious

Waiting for next time step : These particles are still in the domain at the end of the time step, so they will become "Continue from last time step" in the next time step.

Also note that if your domain is 1m long, with a velocity of 1m/s and 1E-6s time steps it will take 1000000 time steps for a particle to get from the inlet to outlet. This is no doubt what is happening in your case - you just need to wait longer.

The dancing as it exits the infill (which is clearly visible) means there might be dancing inside the infill which you cannot see. The stuff inside the infill might be important for particle deposition.

Definitely look at Eularian particle tracking. In many cases it is faster and more accurate than Lagrangian.

[lgtmelo]

Originally Posted by ghorrocks

Also note that if your domain is 1m long, with a velocity of 1m/s and 1E-6s time steps it will take 1000000 time steps for a particle to get from the inlet to outlet. This is no doubt what is happening in your case - you just need to wait longer.

but if i wait longer, more particles are injected, and ill never have a definite number of particles to analyze. there will always be particles in between the boundaries (didnt reach an "exit" yet). can I exclude these from the count so I'll know something like "out of X particles from INLET, Y were captured in the infill and Z went ahead to outlet" ?

[ghorrocks]

Yes, you only count the particles which are relevant to what you are trying to measure.

[lgtmelo]

how do i exclude the ones that are still travelling?

[ghorrocks]

By excluding the ones labelled as "Waiting for next time step".

[lgtmelo]

Originally Posted by ghorrocks

By excluding the ones labelled as "Waiting for next time step".

but how? the only way to filter I found was to select the ones that exit by each boundary.

[ghorrocks]

Are you using the output file to get your particle fates or CFD-Post? I get it from the output file as it is much easier.

[lgtmelo]

Originally Posted by ghorrocks

Are you using the output file to get your particle fates or CFD-Post? I get it from the output file as it is much easier.

hey glenn!

ive been using post, but i can switch to output. any tips?

[ghorrocks]

I am doing some work on particle capturing as well at the moment. I found the easiest way to get particle fates is to parse the output file. I have a python script which extracts the particle fates from the output file - so no need to fire up the post processor at all.

[lgtmelo]

Originally Posted by ghorrocks

I am doing some work on particle capturing as well at the moment. I found the easiest way to get particle fates is to parse the output file. I have a python script which extracts the particle fates from the output file - so no need to fire up the post processor at all.

can you share the script?

[ghorrocks]

It has been archived so will take me a bit to get it back. But it is very simple, just open the file and use a regular expression to find the right bit of the output file (or even just a simple text.split() command) to extract the text.

If you have not programmed in python before then this is a good introductory example to start with

[lgtmelo]

hi everyone, just wanted to give some updates and show some appreciation for all the help i got here

so i finished running a 30s simulation - long enough to have reasonable statistics -, and then I built two parsers to get the information i needed.

this is the graph i made from the output from solver:

glenn.png

and this is the info I got from the PT.trk file:

Particles shot: 29885

In transit/recirculation: 6447
Before infill: 3721
After infill: 2726

Finalized: 23438
Captured in infill: 10168 (43.38%)
Left domain: 13270 (56.62%)

I can upload the .py if anyone wants

thanks!


feedbacks will be appreciated! especially from you, Glenn!

[ghorrocks]

Make sure you are OK with those "exceeded time limit" particles. They are probably stuck in a recirculation - so if you want to know what happens to them you will need to make the particle time limits longer. If you are not interested in these longer lived particles then don't worry about it.

[lgtmelo]

Originally Posted by ghorrocks

Make sure you are OK with those "exceeded time limit" particles. They are probably stuck in a recirculation - so if you want to know what happens to them you will need to make the particle time limits longer. If you are not interested in these longer lived particles then don't worry about it.

thanks, just increased particle time limit and i like the result accuracy better now. no more time limit exceeded

[lgtmelo]

Originally Posted by ghorrocks

Then do a quick calc to see if the filter flow is turbulent: You say the diameter is ~3mm, and look at your simulations to see a typical velocity in them (or estimate the velocity if you can). Then you can get a representative Reynolds Number for the flow in the filter.

(But I know the answer already from experience: If the main flow is laminar then the flow in this infill is going to be laminar as well. This means you can turn off the turbulence model and just model it as laminar, and the turbulent dispersion force option is not available. This will greatly simplify your model.)

Dear Glenn, its been a long time

I am working on this model again, and I'd like to understand this quote: "If the main flow is laminar then the flow in this infill is going to be laminar as well". Is this empirical or is there any justification behind it?

All the best,

Leo