How to add some usr-defined function in postmfix (bubble properties)

After finish simulation, I need to get some characters (bubble diameter, bubble rise velocity, etc.) on fluidized bed simulation. But, I don’t know how to add such function by POSTMFIX

  1. You can add such functions in file usr_post.f

Or you can use the following options to analyse size/shape/velocity of 2D bubbles:
2. For DEM simulation. Directly read in particle position. The code is shared at:
3. For TFM simulation, generate epg field using postmfix. The attached code will do the analysis. The algorithm is same to that for DEM simulation and it is detailed in the CEJ paper.

cclmfixtfm.cpp.f (15.3 KB)

If you are exporting VTU files, you can script Paraview to extract the bubble properties. A pipeline such as:

  1. contour Epg = 0.9
  2. marching cubes to segment the contours
  3. vtk mass properties to extract bubble size, etc.

Bubble rise velocity is a little more difficult. Need to match bubbles between time steps and calculate the displacement.

I found the script that I wrote for Paraview 3 years ago. (6.1 KB)

Thank you some much!!!

Your answer is very heuristic. And, I can make a lot of jobs based on it.
Thank you very much!

I used this code and it really works well for the calculation of bubbles volume, but for bubbles location, it gives the same data for all bubbles.
I mean if there are three bubbles in the bed at a specific time step, the location (x,y, and z) of each one is the same. And it is not true for none of them.
How I can fix it?

Hi, Weber

When we calculate bubble velocity between two frames, the main difficulty is that bubble velocity is uncertain and the shape of bubble can be deformed. It means that it may be hard to track bubbles between two subsequent frames , especially when there is a group of bubbles in the bubbling bed, in which the split and coalescence of bubbles make this problem more tough. That is, the displacement of bubble is difficult to be determined. Due to the uncertain velocity of bubble, the fps of output files is also hard to be determined. I have reviewed some relevant paper, but, I haven’t found a convincing method to get over this problem. What do you think of this problem? What is your deep insight?

I would just save bubble positions (center of mass/volume) at a high frame rate so that the centers move less between frames than the closest neighboring bubble. Then you can just use a “nearest neighbor” algorithm to stitch the centers together.

You could also use other metrics like bubble size, etc. to make sure you are matching the same bubble. Or you could also do what I do in Tracker for tracking particles velocities, based on the previous velocity, project where the bubble should be, then find the closest bubble to that projected location.

1 Like

@onlyjus @arsalanjalali

I wanted to ask if you were able to fix the Python script to export the valid x, y, and z for each bubble.

I have not tried that script since I wrote it 7 years ago now. It should be close, although some calls would probably need updated to work with the latest paraview/vtk releases as they have moved some things around.

1 Like

@onlyjus; thank you! Surprisingly, the code still works fine. The only issue I see it that the x, y, z of the bubble centroid is inaccurate and the same for all the bubbles.

So the vtkCenterOfMass filter is not working? And you are calling the Update() method of the vtkCenterOfMass?

@onlyjus: Yes, the update() method is being called.