Particle tracking: newbie's questions

[Antech]

Hello. I need to do a cyclone modelling for my work. I made it with Saturne 4.0 and RSM turbulence model. The results are promising (resembling Fluent RSM results that I need to verify) but the target is not just a velocity profiles but also a cyclone efficiency. I cannot import Saturne's CGNS in Fluent (it gives a file read error) so I decided to track particles inside Saturne. I set up a simple particle tracking via GUI but when Solver starts it says:

idepst = 1@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@
@ @@ ATTENTION : ARRET A L'EXECUTION DU MODULE LAGRANGIEN
@ =========
@ LE MODELE SPECIFIQUE DE DEPOT (Guingo & Minier, 2008)
@ EST ACTIVABLE UNIQUEMENT AVEC UN SCHEMA D'ORDRE 1
@
@
@ Le calcul ne sera pas execute.
@
@ Verifier les valeurs de idepst et nordre dans la
@ subroutine USLAG1.
@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I checked out the uslag1.f90 file and there is idepst = 0, not 1. What's the problem? I searched the forum but didn't find any posts about idepst. There is a case (without mesh and results) in attach. Thanks for your attention. Hope somebody can help me...

[Antech]

Sorry, I found the problem. I checked boundary conditions twice and there was no deposition model. But I occasionally enabled the Turbulent deposition model in Particle and droplet tracking - Global settings (I hurried and messed it with turbulent dispersion because the word looks very similary).
I disabled this Deposition option and now the calculation runs!

[Antech]

Hello. I have another questions regarding lagrangian tracking...

1. I launched the frozen-field calculation successfully, particles of 10 various size classes being introduced in the domain every iteration and follow their path. But I found that, unlike many other softwares, Saturne represent real particles as model particles, not as particle tracks. As a result, I need a very long calculation to estimate a cyclone efficiency instead of just a minute or so in Fluent (with 1 core) that uses "trajectory approach" (it also has an "unsteady particle tracking" option but the default is trajectory-based method). Is there a way to speed-up a particle calculation in Saturne? I tried increasing the time step in Numerical parameters in GUI but it results in "lost particles" (they travel till about half a height of a cyclone and then disappear).

2. I enabled the boundary statistics for particles in Particles and droplets tracking - Statistics in the GUI and I see the corresponding output in listing but the mass flux and number of impacts of particles at the outlet is absolute zero, while on particle postprocessing (PARTICLES.case file in postprocessing dir) I clearly see that there are particles hitting the outlet and the solver says that there are particles that has left the domain. I mean the following lines:

ln newly injected 100 0.14974E+11
ln out, or deposited and eliminated 11 0.00000E+00

...

Boundary statistics :

Number of iterations in steady-state statistics: 150
Total number of iterations in the statistics: 155

Min value Max value
lp Part_impact_number 0.26131E+04 0.38878E+11
lp Part_bndy_mass_flux 0.00000E+00 0.00000E+00

No deposition is enabled so that may only be particles that has left the domain through outlet (that is seen in the ParaView). But, at the same time, boundary particle mass flux is absolute zero. I also checked the "part_bndy_mass_flux" variable at the outlet boundary in ParaView. The variable is defined but it is absolute zeor throughout the outlet. What's wrong? I think I didn't setup something needed for particles but I can't understand what exactly. Flow rate of each class is given with volumic (mass) flow rate in kg/s.

If I need to specify the statistical weights of particles, would you, please, provide an exact correlation between particle properties (like size and density), mass flow rate for the class and statistical weight?

Some case files are in attachment (with the beginning of the listing from Saturne's GUI output window, relevant particle statistics output is there).

Thanks for your attention. Hope somebody will help...

[Yvan Fournier]

Hello,

There is a bug in version 4.0 to 4.3 which limits to logging of the max flux to some zones. It was fixed last week only in "trunk" (future 5.0).

Also, particles are "dropped" after too many sub-trajectories, in case they get stuck (due to limitations in the trajectory algorithm). This corresponds to a CFL of about 30, which you could change by modifying the hardcoded _max_propagation_loops value in src/lagr/cs_lagr_tracking.c. This value was set to 100 in versions 4.2 and 4.3.

The trajectography was improved this summer, and handling of particles with possible trajectography issues has been improved, so particle trajctories are truncated, but the particles not dropped, so they continue at the next time step.

So I don't usually recommend this, but installing from "trunk" might be a solution here (as you can expect 5.0-beta early December, which might be a bit of a wait). This requires a few more installed software packages and an additional initial step, but it is all documented in the user manual.

Regards,

Yvan

[Antech]

Hello.
Thanks for your reply.
I will now try to install the "trunk" version but I have some questions, just to understand better.

1. The target CFL number for fluid is usually set in Saturne GUI in Time step tree item. Should I use the same value to define CFL/timestep for particles? (Target CFL, ititial timestep, min and max timestep multipliers)

2. The problem is not only a statistic output in listing. There is also zero Part_bndy_mass_flux on inlet and outlet boundaries, although the particles are seen on outlet in ParaView and they are definitely present at the inlet. Will the trunk version solve this problem or it's an another issue?

3. I calculated with statistical weights. But, while with the "Volumic flow" option all particles was OK and reached the outlet, with statistical weights (1.0 for all 10 classes) the particle destruction began at DPM iteration 6 and at iteration 22 and later there was almost steady destruction of around 100 particles per iteration (the same as the number of introduced particles). As a result, particles only penetrated a half of cyclone height and no any particles reached the outlet (in PARTICLES.case file viewed with ParaView). As I can see, the statistical weight determines a mass of "model particle" that consist of many "real particles" and cannot affect a CFL because there is a frozen fluid flow field. Why Saturne removed these particles while with mass flow given they was successfully tracked? Is this a bug or I set something wrong? Case files are in attach in my previous message, the only changed parameters are "Volumic flow" / "Statistical weights with value" and weights of 1.0 for all classes.

Update
Yvan, I cannot install the trunk version. The source directory is missing "configure" script (there is only "configure.ac" file). I also browsed the trunk and didn't find the configure script:
http://code-saturne.org/viewvc/saturne/trunk/
Automatic install (install_saturne.py) fails because it cannot find the configure script too. But I need the manual installation to enable Catalyst (I have a small script with configure options for 4.x versions and "Catalyst edition" of ParaView 4.3 that I built in summer 2015 when I worked with Catalyst configuration intensively).

Also, I noticed that the command "git svn checkout ..." specified in the download section of this site doesn't work (no such option). I used the "git svn clone ..." instead because I just needed to download the source, not to develop it. I use CentOS 6.7 on this machine, git-svn package was installed from this distribution's repository. May be it will be useful for people that are not familiar with developer tools if you will make a kind of a small instruction on how to install the trunk version.

Update
I understand what's the problem but cannot solve it on this machine. I have to run sbin/bootstrap but it requires gettext-0.18, I have only 0.17 for my CentOS. Will try to run this bootstrap on Ubuntu, it usually has newer packages in repository.

[Yvan Fournier]

Hello,

Yes, the issue with configure is what I mentioned in my previous post, indicating an additional step described in the installation documentation. You need to call ./sbin/bootstrap, but check the documentation for the additional tools you may need installed for this.

1) Otherwise, the CFL is based on the fluid. You do not have a separate value for the Lagragian module (actually, internally, one is defined, but always set to the Eulerian time step, and never tested otherwise).

2) Yes, the way the statistics are coded, the "boundary mass flux" actually seems to represent something else than a mass flux, that is the equivalent mass flux of particles rebounding or depositing. It is probably useless for you.

3) The issue with different weights is quite strange. I would not expect a difference here either.

Regards,

Yvan

[Antech]

Thanks for your information and support!

Yesterday I was able to build the trunk version on my home PC with Ubuntu (12.04+updates). A had to play around with packages and then it bootstraped, configured and built successfully but without MED (there is an "unresolved external function" if I enable MED support, possibly it requires newer MED than in SALOME-7.x that I fed to configure). I even tried to calculate (without particles, only gas flow inside a cyclone) and found that the time per iteration has increased several times compared to 4.0 version although the case files are the same.

But it's more important for me that boundary flux in statistics is actually not a flux through the inlet or outlet. For the inlet, I know the particle mass flow I specify, but how should I determine the mass flux of particles leaving the cyclone? Or, if one model the coal combustion, how he should determine the mass flux of unburnt carbon at the furnace outlet. In Fluent, there is a useful feature of particle tracking that outputs the tables with particles summary (fluxes of particle components like ash or char through inlets and outlets, summary mass flux e.t.c). I think, something similar should be available in Saturne, it even has a relatively simple slagging model (one viscosity-based model with Fereday's correlation), Fluent has no any built-in slagging model at all. For the current case, I only need the mass flow of particles on outlet...

Regarding the strange behaviour with statistical weights. I prefer not to use them because I didn't find an exact formula (flow=>weight) and it requires additional pre-calculation, it's simple but it's more convenient to give mass fluxes for fractions (classes) of particles. Now I know that my "mass flow problem" is not connected with the particle inlet BC, so I just will use particle mass flow at the inlet.

Update
I have compiled the trunk (5) version on my working laptop with CentOS using bootstrap results from my home Ubuntu PC and configure options for Catalyst compilation with ParaView-4.3. Configure, make and make install did their job without obvious issues. Catalyst works. I restarted with particles from my previous (version 4.0) calculation on frozen gas flow field and now this calculation is in progress. The main question remains the same: Part_bndy_mass_flux is zero (as expected now) but, I hope, you will suggest any workaround to get the outlet particle mass flux. Meanwhile, I noticed some bugs or so:
1. The "Stop now" and "Stop at" buttons doesn't work on CentOS 6.7. On Stop now, nothing happens. On Stop at, pop-up window with target iteration number displays, but after confirming the control_file doesn't appear and I only can write it by hand (with max_time_step) and solver stops properly. If it's a kind of script I will try to find the reason if I'll have time.
2. If you create the new case in GUI, the Preprocess/Calculate toolbar buttons are inactive and the treeview is in brief state (only calculation-related items). You need to reload the newly created case to make GUI working. Sometimes this bug doesn't come out but most of times I start GUI it's there.
3. Time for the time step disappeared from the listing (it was very useful in previous versions, even CFX doesn't have such small but nice feature).
4. When creating new case, "Create MESH dir" and "Create POST dir" checkboxes functions are incorrect. Checking MESH checkbox creates POST dir and vice versa.
5. In the toolbar, Calculation and Preprocessing button functions seems to be incorrect (as I can see, you should swap their functions).
6. In the Notebook, variables added but not deleted.
7. There are lost particles again. Looks scary. The GUI became more strict and I can't set variable (in space) time step how I did in version 4, now the only constant time step is allowed (my old case didn't start because it had CFL-based timestep). If I understood you right, the local CFL-based timestep was used in my version 4 setup for particles too. But now there is only a constant timestep and it is set to 0.01 s by default. I will check with smaller timestep but I remember that in new version particles shouldn't be lost. Am I still have to keep the time step small enough when working with particles? I restarted with 0.003 s (from 0.01 s results) but the behaviour is the same: tens of lost particles on iteration while introducing 100 particles per iteration. The good thing is that with iterations particles loss almost vanishes.

I understand that some issues may be due to Qt/PyQt versions. On my CentOS laptop they are as follows:
Qt version: 4.6.2
SIP version: 4.9.3
PyQt version: 4.6.2
(Above is an output from script from python.org)
Python version: 2.6.6

[Yvan Fournier]

Hello,

Note that if you have SALOME installed, you can use SALOME's MED and HDF libraries when configuring Code_Saturne. This way you are sure to avoid version compatibility issues. in The version of SALOME 7.8 I downloaded from the salome-plaform.org sirt, HDF5 is in Salome-V7_8_0-public/prerequisites/Hdf5-1814, and MED in Salome-V7_8_0-public/tools/Medfichier-320.

I'll need to check if we reproduce the GUI bugs. I confirm the inversion of MESH and POST, which should be easy to fix.

I'm surprised that you still lose particles, as there is only 1 way this can occur now (vs 2 or 3 ways before).

It is also surprising that the time per calculation has increased without particles. The default pressure solver has changed (multigrid as a smoother for PCG, not as a solver anymore), but is usually (though not always) faster. The code builds with OpenMP enabled by default now, so with 1 thread, you might have a slight slowdown due to functions being outlined. It can be build without OpenMP using --disable-openmp at configure time.

I plan to re-write the Lagrangian boundary statistics before the final 5.0 release around next April, but won't have time to get to it before mid December at best (it definitely needs a rewrite).

There is also a suggested patch for outlet statistics in the bugtracker, but I need to adapt it to make it a bit more generic.

Time for the time step voluntarily dissapeared from the listing, as it made comparison of otherwise identical cases more difficult: it is replaced by the first column of the timer_stats.csv file, which provides time for subsets in other columns. To update that file (which is smaller, so not flushed as often), add an empty control_file ("touch control_file" in the execution directory does the trick).

If you have a relatively small case in which you lose particles, could you post it here (or send it to me in any other way) ?

Regards,

Yvan

[Antech]

Thanks for fast response.

Regarding MED. I indeed used SALOME's MED on home PC (SALOME 7.7.x AFAIR, cannot remember exactly, I'm at work office now). But I noticed that on CentOS laptop there is a stand-along MED version 3.0.8 and Saturne compiles OK against it. So MED is not a problem (If I will assemble a Zen calc machine at home I will do an installation on Ubuntu but with software packages that are on laptop now; my present home PC have only 4 cores and I usually only test CFD freeware on it).

About lost particles. They actually almost disappeared with iteration progress. Recent 50 iterations are without lost particles. I think that the tracking works as it should be. Sorry, I cannot share the mesh/topology because it's an industrial boiler project. The simplest way to reproduce is to create a simple cyclone-like thing with inlet velocities around 10...20 m/s. I will create an abstract STEP geometry for you if I'll have a time (I'm busy with may ANSYS cases).

About the solver performance. I used 8 processes (4 cores + multi-threading) bot on 4 and 5 Saturne versions. OpenMP is not a case because the slowdown is not slight but several times. I noticed new options for linear solver (Smoothing) but didn't check their influence yet because it was the late evening when I compiled the code. Today is a particle tracking day , laptop is hot due to 4 cores are in work most of the day tracking particles on frozen field so I didn't experiment with linear solver options.

Thanks for tips about time for the time step.

If I understand right, there is no way to determine the particles flux at the outlet. I will use integration of ParticleVolumeFraction * ParticleDensity * GasVelocity * dF in ParaView, although it's not precise. The result is acceptable for the inlet where the discrete and eulerian phase velocities are the same (real: 1 kg/s, integration: 0.95 kg/s), but I don't know what about outlet where particle and gas velocities may be sufficiently different. I will replace the gas velocity with average particle velocity and check the difference but it will be formally still inapplicable because various particles (especially of various classes) has various velocities and volume fractions but I will only operate on integral volume fraction and velocity.

Update
I prepared the test geometry and mesh for you. It's an abstract cyclone for particle tracking test.
Geometry STEP: http://rgho.st/6jj4rRVJh
Mesh CGNS: http://rgho.st/6Yz6mdjWW
Other initial data: see my attached cases. The recent one has particles.

[Yvan Fournier]

Hello,

You should have information on the outlet mass flux in the trunk version (with a fix from 1 or 2 weeks ago). It simply does not provide details relative to particle statistical classes (if you use those).

For the slowdown, could you post a "performance.log" from version 4.0 and one from the trunk ? Thanks.

Regards,

Yvan