Hello,
I am not sure what you consider a "trajectory-based" approach or how Fluent defines theirs. The statisistical approach in Code_Saturne seems to preclude this, as particle trajectories may be perturbed at each time step by a randomization based on turbulent dispersion (as I understand the method; I am not the specialists either). So if you disable turbulent dispersion, you will have a solution which would probably be extensible to a "trajectory" approach.
Otherwise, I am not sure why the efficiency you obtain varies so much, and whether it is an indicator of mesh convergence issues or not. It could be interesting to see if you have the same variablility when disabling turbulent dispersion, or even switching to 1st order scheme (2nd-order should be better, and bugs should be solved, but in case of doubt, those tests would be interesting).
I may try to run your case, but I already have a backlog of several user issues to check, so the more the work is cut out for me, the better my chances of handling the issue in the near term (sorry about that), but it is definitely quicker to check logs such as the ones you last sent me than run the full case). I expect to spend more time on Lagrangian aspects (rewrite boundary statistics and ttry t improve performance) early 2017, but before that, my time will be limited (i.e. I need to finish some other things already in progress first).
So I expect to test your case and fix/explain issues by then, but also probably won't be able to do much testing before that. Hoping that won't be too much of a wait (though we can still iterate on the tests I mentioned in the meantime)...
Regards,
Yvan
Particle tracking: newbie's questions
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
Yvan Fournier
- Posts: 4080
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Particle tracking: newbie's questions
Hi Antech and Yvan,
I also found the Lagrangian particle tracking in v4.3.1 has memory corruption problem. I hope to build from trunk too. How did you clone the source code it? I tried:
git svn clone http://code-saturne.org/viewvc/saturne/trunk/
It did not seem to work. It said:
Initialized empty Git repository in /home/ffan/packages/trunk/.git/
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-fBn2Y4/pkcs11: No such file or directory
Repository has been moved: Repository moved permanently to '/viewvc/saturne/trunk/'; please relocate at /usr/lib/git-core/git-svn line 2139
What is the correct way? Thanks.
- ffan
I also found the Lagrangian particle tracking in v4.3.1 has memory corruption problem. I hope to build from trunk too. How did you clone the source code it? I tried:
git svn clone http://code-saturne.org/viewvc/saturne/trunk/
It did not seem to work. It said:
Initialized empty Git repository in /home/ffan/packages/trunk/.git/
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-fBn2Y4/pkcs11: No such file or directory
Repository has been moved: Repository moved permanently to '/viewvc/saturne/trunk/'; please relocate at /usr/lib/git-core/git-svn line 2139
What is the correct way? Thanks.
- ffan
Re: Particle tracking: newbie's questions
Hi,
Never mind. It works now. Thanks.
- ffan
Never mind. It works now. Thanks.
- ffan
Re: Particle tracking: newbie's questions
Yvan Fournier
Hello.
The trajectory-based method is quite simple. You consider the fluid flow field from the current iteration and define some start points for particles on inlet boundaries. Then you trace particles one-by-one and step-by step. As an abstract simple example, we may use the explicit scheme. If we have forces balance for particle, it's initial velocity and it's timestep, we know the velocity and position of the particle after this timestep. You repeat it for every particle while it leaves the domain or the user-defined number of steps is exceeded. As a result, you have a sequence of N particle coordinates, connecting these points you get the trajectory. It means that you only need to calculate this number of steps (N) for every particle. Then you iterate for fluid flow, usually 10...20 iterations with relaxed particle moment and (if needed) enthaply sources and repeat the DPM (discrete particle model) iteration for all particles. In Fluent, if you turn on turbulent dispersion and visualize the single particle track, it will turn into several tracks starting from the same point. The other method in Fluent called "Unsteady particle tracking" and it's like in Saturne. It is, of course, compatible with unsteady tasks, but it's much more time consuming (both in Fluent and Saturne), as I described in previous post, because on every timestep for particular particle (starting point) you "move" lots of model particles instead of just one for steady trajectory approach.
I understand that you're busy with another work, it's OK, thanks for your attention to this forum. I obtained the same inconsistency in particle flows for many variants (trunk version 5), I will upload logs from these cases and check the results without turbulent dispersion and with 1st order scheme if I'll not forget.
ffan
Please compare the particle flow given by solver with result of integration over the outlet boundary if particle flows are important for you. Maybe there is some issue, because, as I described earlier, these results are almost the same for Fluent and various for Saturne.
Hello.
The trajectory-based method is quite simple. You consider the fluid flow field from the current iteration and define some start points for particles on inlet boundaries. Then you trace particles one-by-one and step-by step. As an abstract simple example, we may use the explicit scheme. If we have forces balance for particle, it's initial velocity and it's timestep, we know the velocity and position of the particle after this timestep. You repeat it for every particle while it leaves the domain or the user-defined number of steps is exceeded. As a result, you have a sequence of N particle coordinates, connecting these points you get the trajectory. It means that you only need to calculate this number of steps (N) for every particle. Then you iterate for fluid flow, usually 10...20 iterations with relaxed particle moment and (if needed) enthaply sources and repeat the DPM (discrete particle model) iteration for all particles. In Fluent, if you turn on turbulent dispersion and visualize the single particle track, it will turn into several tracks starting from the same point. The other method in Fluent called "Unsteady particle tracking" and it's like in Saturne. It is, of course, compatible with unsteady tasks, but it's much more time consuming (both in Fluent and Saturne), as I described in previous post, because on every timestep for particular particle (starting point) you "move" lots of model particles instead of just one for steady trajectory approach.
I understand that you're busy with another work, it's OK, thanks for your attention to this forum. I obtained the same inconsistency in particle flows for many variants (trunk version 5), I will upload logs from these cases and check the results without turbulent dispersion and with 1st order scheme if I'll not forget.
ffan
Please compare the particle flow given by solver with result of integration over the outlet boundary if particle flows are important for you. Maybe there is some issue, because, as I described earlier, these results are almost the same for Fluent and various for Saturne.
Re: Particle tracking: newbie's questions
Hello.
I think there is a bug in CS 5.0 trunk version. I calculated successfully my cyclone cases and tried to validate another case. The domain has 4 inlets, at each of that the particles-laden gas flow is introduced. The gas phase calculation is OK (isothermal with k-epsilon turbulence model), then I start the particles calculation on frozen gas phase flow field and particles are introduced in the domain through all 4 inlets (I can see it in PARTICLES.case in the postprocessing directory after some iterations). But if I look at the mean particles volume fraction in an axial slice in ParaView I see that the particles are "fully" present only at 2 of 4 inlets. Around the third inlet there is only a part of the area that is occupied by particles, and around the 4th inlet there are no particles at all. I mean that the particles are there in PARTICLES.case but they are missing at some areas in RESULTS.case. And it's easy to figure out that there is some problem with partitions (calculation runs in 8 threads so there are 8 mesh partitions). If the particles inlet belongs to only one partition (like in my cyclone cases) that there is all right with particles statistics inside the domain. But if some particles inlet occupies two or more partitions, like in my current case with gas ducts, then the particle statistics will only be calculated inside one partition (as at the inlet 3) or will not be calculated at all (as at the inlet 4). Solver's output in listing about particles flow at inlets are also incorrect, it gives 1 kg/s for the first 2 inlets (that are in the same partition) and zeroes for two other inlets (each of that shares two partitions).
I attached the case xml file and listing.
Like in cyclone study, I need particles flow rate at outlets, this case is similar in this sense (a kind of a particle trap). The problem is that, during the cyclone calculations I figured out that Saturne solver (5.0 trunk) gives incorrect particle flow at the outlets so the user must determine the particle flow integrating particle mass flow density over some slice near the outlet, results are in very good agreement with Fluent on various geometries with different efficiencies. But now I can't use the solver's particles flows in listing (because I know that they are wrong) and I cannot integrate inside the domain due to this problem with particle statistics when the particle inlet shares two mesh partitions. Can anybody help me? Is there any workaround?
Thanks for your attention.
I think there is a bug in CS 5.0 trunk version. I calculated successfully my cyclone cases and tried to validate another case. The domain has 4 inlets, at each of that the particles-laden gas flow is introduced. The gas phase calculation is OK (isothermal with k-epsilon turbulence model), then I start the particles calculation on frozen gas phase flow field and particles are introduced in the domain through all 4 inlets (I can see it in PARTICLES.case in the postprocessing directory after some iterations). But if I look at the mean particles volume fraction in an axial slice in ParaView I see that the particles are "fully" present only at 2 of 4 inlets. Around the third inlet there is only a part of the area that is occupied by particles, and around the 4th inlet there are no particles at all. I mean that the particles are there in PARTICLES.case but they are missing at some areas in RESULTS.case. And it's easy to figure out that there is some problem with partitions (calculation runs in 8 threads so there are 8 mesh partitions). If the particles inlet belongs to only one partition (like in my cyclone cases) that there is all right with particles statistics inside the domain. But if some particles inlet occupies two or more partitions, like in my current case with gas ducts, then the particle statistics will only be calculated inside one partition (as at the inlet 3) or will not be calculated at all (as at the inlet 4). Solver's output in listing about particles flow at inlets are also incorrect, it gives 1 kg/s for the first 2 inlets (that are in the same partition) and zeroes for two other inlets (each of that shares two partitions).
I attached the case xml file and listing.
Like in cyclone study, I need particles flow rate at outlets, this case is similar in this sense (a kind of a particle trap). The problem is that, during the cyclone calculations I figured out that Saturne solver (5.0 trunk) gives incorrect particle flow at the outlets so the user must determine the particle flow integrating particle mass flow density over some slice near the outlet, results are in very good agreement with Fluent on various geometries with different efficiencies. But now I can't use the solver's particles flows in listing (because I know that they are wrong) and I cannot integrate inside the domain due to this problem with particle statistics when the particle inlet shares two mesh partitions. Can anybody help me? Is there any workaround?
Thanks for your attention.
- Attachments
-
- listing.zip
- (34.06 KiB) Downloaded 245 times
-
- Ducts.xml
- (10.58 KiB) Downloaded 240 times
-
Yvan Fournier
- Posts: 4080
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Particle tracking: newbie's questions
Hello,
By this description, it really seems we have a bug. I'll try to check this first half of January (possibly before, but I prefer to keep expectations reasonable).
Could you post the associated mesh if it is not too big ? Also if you do not mind, posting this on the bugtracker could be a good idea, as it will be easier to find than if it gets buried in a series of posts on this forum.
Sorry to keep you waiting a bit longer.
Best regards,
Yvan
By this description, it really seems we have a bug. I'll try to check this first half of January (possibly before, but I prefer to keep expectations reasonable).
Could you post the associated mesh if it is not too big ? Also if you do not mind, posting this on the bugtracker could be a good idea, as it will be easier to find than if it gets buried in a series of posts on this forum.
Sorry to keep you waiting a bit longer.
Best regards,
Yvan
Re: Particle tracking: newbie's questions
Hello. Thanks for your response. Formally, the geometry is confidential, but I will make a simple "cube case" to demonstrate the bug (if it's reproducable) when I'll have some time. It will be lighter than the real case.
The "abstract cyclone" case for particle flow inconsistency demonstration is under calculation on a laptop (it's only at the "gas phase step", I will also need to introduce particles and it will take some time to track).
The "abstract cyclone" case for particle flow inconsistency demonstration is under calculation on a laptop (it's only at the "gas phase step", I will also need to introduce particles and it will take some time to track).
Re: Particle tracking: newbie's questions
Hello.
I prepared the case for Code Saturne developers that demonstrate the strange inconsistency in particle flow through the boundary reported by the solver and calculated by integrating the particle mass flux in ParaView (please note that for Fluent both methods give the same value).
How to see the difference:
1. Download the case: http://rgho.st/6SNdW2Kfc (Storage period is 3 months).
2. Launch ParaView and open "Abstract PrtFlow.pvsm" state file from Abstract directory.
3. Choose Abstract\RESU\RSM-Centered-Particles-DT=0.001\postprocessing]RESULTS.case as the data source.
4. A simple pipeline will appear in ParaView. There are two slices: at the inlet and at the outlet of the cyclone.
5. In the bottom spreadsheet view, select Integrate Inlet and read the PrtFlow column. It's the inlet particle flow that is set to 1 kg/s for convenience (calculation is on frozen gas flow so the particle flow is just for inlet/outlet comparison). For the inlet, PrtFlow must be 0.947. As you can see, it's near to 1.0.
6. Select Integrate Outlet in the bottom view. PrtFlow column has value around 0.15 kg/s. You can move the outlet slice up and down (while it doesn't intersect the larger part of the cyclone) and you will see something like 0.14...0.16 kg/s for the PrtFlow.
7. Open the Abstract\RESU\RSM-Centered-Particles-DT=0.001\listing text file. Scroll down to the end of file and fund the table with Zone and Mass flow rate (kg/s) for Lagrangian phase. Look at the value for "outlet", it will be around 0.60 kg/s if you average over 100 iterations and for various iterations you will see something like 0.41, 0.62, 0.68 e.t.c. As you can see, 0.60 is far from 0.15. From comparison Saturne and Fluent (not for this case but for 4 other real-geometry cyclones) I figured out that the second value is correct while the first is not.
So here is an inconsistency. I hope that this can be fixed in official version 5.0 if it's a bug. I made the nice colored scripts for Saturne monitoring (sorry, I made it for the company at worktime and cannot share). And there is an output of particle boundary mass flow from solver output, now it shows the incorrect value... I hope, in version 5.0 the particle flow in listing will be OK. Or, maybe, I made some mistake and estimated the particle flow at the outlet incorrectly? Maybe, someone can point out what's wrong with the particle flow integration in the state file specified above?
Additional files form that checkpoint directory:
Main restart file: http://rgho.st/8S7Vdzccz
Auxiliary restart file: http://rgho.st/7RjR2hFZk
I didn't upload the Lagrangian restart files because they are very large for upload (480 M).
please note that this cyclone case is only intended for program testing, it is more than enough to demonstrate the particle flow inconsistency but it is incorrect because there is no bottom BC for particle capture (I forgot about it
) and the calculation is incomplete.
Would you like me to create a corresponding bug on the bugtracker?
Ivan, also I reported the bug via the bug tracker on your site regarding particle variables in parallel mode:
http://code-saturne.org/mantis/view.php?id=212
I prepared the case for Code Saturne developers that demonstrate the strange inconsistency in particle flow through the boundary reported by the solver and calculated by integrating the particle mass flux in ParaView (please note that for Fluent both methods give the same value).
How to see the difference:
1. Download the case: http://rgho.st/6SNdW2Kfc (Storage period is 3 months).
2. Launch ParaView and open "Abstract PrtFlow.pvsm" state file from Abstract directory.
3. Choose Abstract\RESU\RSM-Centered-Particles-DT=0.001\postprocessing]RESULTS.case as the data source.
4. A simple pipeline will appear in ParaView. There are two slices: at the inlet and at the outlet of the cyclone.
5. In the bottom spreadsheet view, select Integrate Inlet and read the PrtFlow column. It's the inlet particle flow that is set to 1 kg/s for convenience (calculation is on frozen gas flow so the particle flow is just for inlet/outlet comparison). For the inlet, PrtFlow must be 0.947. As you can see, it's near to 1.0.
6. Select Integrate Outlet in the bottom view. PrtFlow column has value around 0.15 kg/s. You can move the outlet slice up and down (while it doesn't intersect the larger part of the cyclone) and you will see something like 0.14...0.16 kg/s for the PrtFlow.
7. Open the Abstract\RESU\RSM-Centered-Particles-DT=0.001\listing text file. Scroll down to the end of file and fund the table with Zone and Mass flow rate (kg/s) for Lagrangian phase. Look at the value for "outlet", it will be around 0.60 kg/s if you average over 100 iterations and for various iterations you will see something like 0.41, 0.62, 0.68 e.t.c. As you can see, 0.60 is far from 0.15. From comparison Saturne and Fluent (not for this case but for 4 other real-geometry cyclones) I figured out that the second value is correct while the first is not.
So here is an inconsistency. I hope that this can be fixed in official version 5.0 if it's a bug. I made the nice colored scripts for Saturne monitoring (sorry, I made it for the company at worktime and cannot share). And there is an output of particle boundary mass flow from solver output, now it shows the incorrect value... I hope, in version 5.0 the particle flow in listing will be OK. Or, maybe, I made some mistake and estimated the particle flow at the outlet incorrectly? Maybe, someone can point out what's wrong with the particle flow integration in the state file specified above?
Additional files form that checkpoint directory:
Main restart file: http://rgho.st/8S7Vdzccz
Auxiliary restart file: http://rgho.st/7RjR2hFZk
I didn't upload the Lagrangian restart files because they are very large for upload (480 M).
please note that this cyclone case is only intended for program testing, it is more than enough to demonstrate the particle flow inconsistency but it is incorrect because there is no bottom BC for particle capture (I forgot about it
) and the calculation is incomplete.Would you like me to create a corresponding bug on the bugtracker?
Ivan, also I reported the bug via the bug tracker on your site regarding particle variables in parallel mode:
http://code-saturne.org/mantis/view.php?id=212