MFIX-24.3.1 bimodal grain size from cumulative size distribution

Hi,

We used to be able to get automatic particle generation to do denser packing, here even adjusting the ic_des_spacing to 0.0001d it does not allow me to pack much more than with concentration of 0.1. I tried the cubic packing too. Why is that? it is clearly not using the space in x for instance that is available.
IC_PSD_0002_0001.txt (247 Bytes)
fluid_bed_dem_2d_24.3.1.mfx (7.9 KB)

Also this may be useful to others, this is how to do a bimodal size distribution mixed (rather than all small below or above the coarse fraction).

when trying a true bidisperse size distribution, I get an error when loading the file, not sure why:
IC_PSD_0002_0001.txt (248 Bytes)
fluid_bed_dem_2d_24.3.1_2024-11-06T103409.470112.zip (627.2 KB)

I did get lots of error before the initial file even worked, and had to reload, click on random things and eventually it worked… but this second one is not playing ball.

When trying to make it work again with the original file, same error as above… this is a small bug that is a pain to go around.
fluid_bed_dem_2d_24.3.1_2024-11-06T104438.567887.zip (596.8 KB)

Hi Eric

There is a known bug in the IC_DES_SPACING code which will be fixed in the next release. (see eg MFIX-SQP automatic particle generation fails)

In the meanwhile I suggest you use a particle_input.csv file if possible (note, we have changed to a more flexible CSV format for the particle input file, although the old format is still supported)

What is the exact error you are seeing when loading the IC_PSD file? It loaded for me without any problem. If you can tell me how to reproduce the problem I’ll fix it.

Thanks,

– Charles

I need an automatic particle generation, does not the .csv requires me to input all these properties for each particle size for classic DEM?

|X|Y|Z|phase_id|diameter|density|U|V|W|

rather than me static the target size distribution?

When I opened it, it ran, then if I try to reload the file:

; only works if i try to change the name of the distribution even if reloading the same file. rewritting seems to be an issue

Hi again @ebreard6

  1. As of 24.3.1 only X, Y and Z are required in the CSV.

  2. Jeff is working on a fix for the spacing error. Maybe we can send you a code patch that you can apply.

  3. The SameFileError is annoying. We will fix this in the next release. I have to admit, we did not give enough thought to the use case of editing and reloading a PSD definition file. How are you reloading it?

Note that it is not really necessary to reload the file in the GUI when you modify it, unless you want to update the displayed stats (mean, stddev, min, max). Double-clicking the row in the “Particle size distribution” window will bring up an option to plot the distribution, which will plot the current file contents. The PSD file will be loaded by the mfix solver when you run the simulation and will pick up whatever the file contents are at that time. The mean, stddev, etc in the GUI are just for your information, they do not affect the particle generation.

I think part of the reason you are running into trouble with the PSD file is that we were expecting users to use a more descriptive name like “bimodal.txt” and then when it gets applied to particular IC and phase, the GUI will copy it to IC_PSD_####_####.txt. But you already have it set to IC_PSD_0002_0001.txt. This should not be a problem, but it’s not exactly the way we expected people to use this feature.

Also I see you are on Windows - there’s some code in solids_dem.psd which is checking to see if the file needs to be copied:

            data['type'] = 'Custom'
            if (os.path.isabs(p.filename)
                and os.path.dirname(p.filename) != os.getcwd()
                and p.ui.checkbox_copy_file.isChecked()):
                basename = os.path.basename(p.filename)
                shutil.copyfile(p.filename, basename)

but on Windows, I see that os.getcwd() returns a path like

C:\Users\ebreard\Documents\fluid_bed_dem_2d_24.3.1

(with backslashes) while p.filename is

C:/Users/ebreard/Documents/...

(with forward slashes) so the string comparison fails. Cursed Windows backslashes strike again! :imp:

A somewhat hackish workaround would be to edit the file

%CONDA_PREFIX%\Lib\site-packages\mfixgui\solids_dem.py

and change the section around line 1400 from

                basename = os.path.basename(p.filename)
                shutil.copyfile(p.filename, basename)

to

                basename = os.path.basename(p.filename)
                if not shutil._samefile(p.filename, basename):
                    shutil.copyfile(p.filename, basename)

This is not the ideal fix but it will silence the annoying error popup you are seeing.

Thanks as always for the error report, we will follow up on both of these issues.

– Charles

1 Like

Another issue is that when you do particle seeding with a PSD, the lattice is based on the largest particle (I think), so this will also limit the density you can achieve.

yeah it is pretty hard to do packed seeding, but I got a matlab code that does seeding with concentration of 0.3 for polydisperse so hopefully we can get a little higher than 0.1…

Some further comments:

  1. Jeff’s patch which fixes a bug in particle spacing:

patch.txt (1.2 KB)

  1. Your IC_PSD_0002_0001.txt file is a bit odd:
10, 1
CDF
!Diameter CDF
2.9156e-04 0.0000e+00
2.9000e-03 0.0000e+00
2.9500e-03 0.0000e+00
3.0000e-03 0.7000e+00 
3.0500e-03 0.7000e+00
4.9000e-03 0.7000e+00
4.9500e-03 0.7000e+00
5.0000e-03 1.0000e+00  
5.0500e-03 1.0000e+00
5.1000e-03 1.0000e+00

The , 1 should not be present on the top line, and the lines with the same CDF are redundant. I suspect that the lines 5.05e-3 and 5.1e-3 are throwing off the seeding, since the maximum diameter appears to be 5.1. But of course the maximum diameter is 5e-3 since the cumulative density has already reached 1.0. You could trim this down to

4
CDF
!Diameter CDF
2.9500e-03 0.0
3.0000e-03 0.7
4.9500e-03 0.7
5.0000e-03 1.0
  1. What packing densities can we expect for a distribution of 30% particles of diameter 0.005m and 70% 0.003m?

For a cubic lattice:
density with uniform spheres, ignoring edge effects: π/6 ≈ 0.5236
density of sphere mix: 0.7*(3/5)**3 + 0.3 ≈ 0.4512
density with mixed spheres, based on 0.005m lattice: 0.5236*0.4512 = 0.2362

For a hexagonal packing:
theoretical max: π/(3sqrt(2)) ≈ 0.7405
density with mixed spheres: 0.7405*0.4512 = 0.3311

However this is disregarding edge effects, and in your case the edge effects are very significant, especially since I notice that the MFiX particle generation seems to stay farther away from the edges than it needs to, as you will see in the VTK output (I added an output for ep_g so you can see the enclosing box).

I am able to achieve a density of 0.1585 (hexagonal) or 0.132 (cubic)

Hexagonal:

Cubic:

Note that this is with Jeff’s patch and with IC_DES_SPACING=0.

I believe that it’s the fact that MFiX seeding is so shy of the edges which contributes to the low densities we are able to achieve. I think we are not getting close to the theoretical max because we are leaving a large part of the volume unpacked. We will address this in a future MFiX release.

  1. Some practical advice: what can we do to get the bed packing density you are looking for? If you have MATLAB code that does it, you could write a CSV file from MATLAB and use that as a particle_input.csv. But what I’d do is this: turn the top outlet into a mass inlet, with the desired PSD, and let the particles “rain” from above…

    (note that if Y-axial velocity is 0 you will get a zero-division error, another bug that will be fixed in the next release - 24.3.2 or 24.4)
    I set the stop time to 2s, and enabled “Save particle positions at end of run” in the Output pane. I also added a monitor for particle count. We get to a total of 3719 particles after 2 seconds. You can run longer if you want more particles in the bed, or for a shorter time if you want fewer. Then rename particle_output.csv to particle_input.csv, change the top BC back to an outlet, and disable particle generation, and you should be all set.

Here’s the plot of particle count vs time:

You can see in this movie how the initial column of particles does not fill the region but spreads out when it hits the bottom, you can also see the region filling up with new particles as they enter from above:

I hope this is helpful.

@cgw EXTREMELY INDEED!