Dear MFiX community,
EDITED SEE BELOW!
Dear MFiX community,
EDITED: I had made some errors in my original post but the question still stands. Sorry!
I would like to create GSP particles that are different from those generated from the built in generator. I am working with irregular particles such as the one imaged here
For this purpose I would like to create multi-sphere particles like those generated in this paper. You can simply see the graphical abstract to see what i mean without paying for the paper.
https://www.sciencedirect.com/science/article/abs/pii/S0032591015300267
To me it seems the MFiX GSP generator tries to create semi regular agglomorations of particles while also minimizing overlap. This makes sense if we are trying to model heat transfer within the particle and we need to track which sphere contact which. I am not interested in this and therefore its fine for me to use the implicit GSP option in MFiX. Since im interested in the contact I want to reconstruct the surface as good as possible as shown in the linked paper. I also want to minimize the number of sphere due to computational cost.
As an example here is an example of 41 sphere aggregate created in MFiX and a 32 sphere aggregate created in the commercial STAR-CCM+ solver which seems to use a similar approach to the one in the paper. Note I want to use MFiX and not STAR-CCM+ since I am using some custom code and i hate commercial solvers 
My questions are:
- Can i create such a particle in MFiX if I manually create the gsp config files? I
- If yes to 1. does anyone have some tips on how to do this? Specifically I am interested in tips on what the columns in the gsp file mean. see image below
What I tried so far
I have created a .csv file with x,y,z and relative d based on the STAR-CCM+ particle attached below. My next quest is to figure out the meaning of the remaining variables in the config file which through guesswork is related to which of the spheres are “in contact” with the other spheres within the same GSP particle.
POM_6.3+__p4_simplified_32spheres_with_diameter_forMFIX.csv (5.2 KB)
I tried inputting this into the MFiX sim by copying the remaining columns from the mfix generated gsp-config.csv file
As one might expect this did not work as can be seen in the attached mfix sim.
I have managed to load it into MFiX as can be seen here
However, the sim crashes if it try to run it which I guess indicates that either the remaining columns are important or this fundamentally will not work.
Best Regards
Simon
EDIT! I accidently added the wrong file before
000_2026-06-10T102324.316268.zip (2.3 MB)
You should be able to import GSP from other software, with some caveats.
-
I see that the configuration you have imported has overlapping spheres. I do not know if this will be an issue with MFiX. Our GSP generator creates non-overlapping spheres.
-
Your simulation is crashing with a zero-divide error. This was easier to see when running without SMP/DMP, which is always a good idea when debugging a crash. The error turned out to be in this line in
set_bc_dem_mi.f
! Calculate the number of particles of mass phase M are injected per
! second for each solid phase present at the boundary
NPMpSEC(M) = VOL_FLOW / p_vol
Adding a write statement showed that p_vol is zero. For GSP particles, the particle volume is read from the gsp_config.csv file.
In your project you have 2 different GSP particles, mfix_41_spheres (phase 1) and starccm_32_spheres (phase 2). The top-level gsp_config.csv in the project dir has 75 lines (41 + 32 + 2 lines of header). But look, the final field (pid or phase ID) of each line is 1, which menas they are all describing phase 1. The gsp_config.csv in the top-level is assembled (when the GUI saves files) from the separate per-particle gsp_config.csv in the different GSP-n directories. So the file GSP-2/gsp_config.csv needs to have a 2 at the end of each line instead of 1. When this is fixed, the files are combined correctly and the simulation runs.
$ head GSP-2/gsp_config.csv
#version = 1
x,y,z,rel_d,rel_sa,w,e,s,n,t,b,w_na,e_na,s_na,n_na,t_na,b_na,pid
-0.15631765253517962,-0.039688222234782855,0.01863134608303438,0.3312884504289939,0.023035512331766518,-1,4,-1,14,2,-1,0.0,0.010429710862295046,0.0,0.014854566168469169,0.004977762675398741,0.0,2
0.11320423449202772,-0.024251412798265534,-0.0165467147546417,0.2607606088400761,0.023035512331766518,-1,4,-1,14,2,-1,0.0,0.010429710862295046,0.0,0.014854566168469169,0.004977762675398741,0.0,2
Fix this file, remove the top-level gsp_cofig.csv, re-save the project, and it should run.
However there are still some questions:
-
As mentioned previously, I’m not sure if overlapping spheres are OK. @kerenjie127 can you comment on this?
-
I’m also not 100% clear on what the columns mean
x,y,z,rel_d,rel_sa,w,e,s,n,t,b,w_na,e_na,s_na,n_na,t_na,b_na,pid
x,y,z are position, rel_d and rel_sa are relative diameter and relative surface area, w,e,s,n,t,b would seem to be west,east,south,north,top,bottom but I’m not sure wah these mean, or their _na variants. pid is Phase ID as discussed above
@kerenjie127 may have further insights as he’s the original author of this code.
– Charles
1 Like
@SimonEberhard @cgw
Overlapping is okay as long as they not concentric, concentric just does not have any sense.
If you are not interested in energy solver, then you can have any config you want, even the one from starccm+. Only the x,y,z,rel_d,pid columns matter. Note that we all used relative value in gsp_config.csv. It should be scaled by the particle bounding diameter to obtain the actual position and radius of each component sphere. What ever you got from starccm+ might be the actual value. So I suggest you tell mfix that bounding diameter is 1 so you can use the value from starccm. Make sure you fill out the other column with random values.
w,e,s,n,t,b represent the id of neighbor component sphere in that direction, so you can put integers here, or simply -1. w_na,e_na,s_na,n_na,t_na,b_na represent the contact area with the neighbor components. All there are used for the heat transfer you just need to make sure those columns are not empty.
1 Like
Thanks a lot it seems to be working.
However, I do have a problem related to the DEM time-step needed for the GSP model to be stable but I found that also to apply to the MFiX generated shapes so its probably not related to this.