Hey all,
Has anyone attempted to use Paraview to evaluate per-particle coordination number from MFIX DEM data/VTK outputs? It seems like this should be a pretty straightforward post-processor using one of Paraview’s built-in filters or toolboxes, but I’m not finding anything in the Paraview documentation that seems relevant.
LMK if this would be more appropriate to post on the Kitware forum. Thanks!
Okay, this was actually pretty easy to do. I decided to create a user variable (DES_USR_VAR) that keeps track of the number of overlapping neighbors (OVERLAP_N > 0) that each particle has. This requires just a few lines of code in the calc_force_dem subroutine.
If anyone else needs help doing this, let me know and I’m happy to share my code.
Hi Julia,
I am interested in cohesive particles. I am thinking about how to make this kind of picture like below. Particles in this figure are colored by liquid bridge coordination number.
Fei,
This should be pretty straightforward - all you need is a loop summing the number of liquid bridge particle-particle contacts, store this in the DES_USR_VAR of your choice, and then color your spherical glyphs according to that DES_USR_VAR in Paraview.
Hi Julia,
Thanks for your help. I can show liquid bridge coordination number now. I solve this problem by adding a variable Coordination in some code files such as discretelement_mod.f and so on. Then, this variable is binded to an available button in Output/VTK like density. This means that if this button is enabled before caculation, the coordination number can be output and visualized in post-processing.
Of course, to count the number of liquid bridge between particles in calc_force_dem is the core.
Much thanks for your advice.
Fei,
Nicely done! There are certainly multiple ways to tackle problems like this.
One thought I had - if you go this route, I recommend adding some kind of consistent label in your code comments to mark sections of the source code that you are modifying (I use ‘! MY-MOD’ for example). Otherwise, updating to a new version of MFIX is rather slow because you have to hunt down all of your modified lines of source code and copy-paste them into the new subroutines.
Hi, I am using Mfix-24.1 to perform CFD-DEM simulations recently, and trying to figure out the coordinate number for particles. I would appreciate it if you could share your codes for me! My email is 3424273703@qq.com. Thanks again!
–Zhiyong Jia
Hi, @julia.hartig,I have noticed an issue with determining the coordination number (CN) by counting the occurrences of OVERLAP_N in calc_force_dem.f. Actually, the particle neighbor search algorithm in MFIX-DEM does not repeatedly traverse neighboring particles. In simple terms, if particle J has already been identified as a neighbor of particle I, then particle I will not be included when searching for neighbors of particle J. This implies that using the aforementioned method to determine the CN of particles can result in some particles having a reduced CN. For instance, in the attached figure, some particles have a CN of 1, while their contacting particles have a CN of 0, which is clearly unreasonable. It is possible that my own handling method is incorrect. How do you address this issue?
Could you kindly provide your corrected version of the calc_force_dem.f code?
I solved the problem by adding an extra segment of code to iterate through all the particles and perform contact checks. However, this approach definitely sacrifices computational efficiency.The results shown in the latest attached figures also confirm that using OVERLAP_N in calc_force_dem.f to determine the number of particle contacts might be unreasonable.
