I used PSD to solve for sand particles, but encountered an error and did not run. How can I solve this problem? I suspect that the large gaps between my particles caused them to overflow from the reactor and not run.
0.09.zip (68.3 MB)
error：Initial condition 2, Phase 1: Unsuccessful seeding
Please adjust seeding volume fraction, or advanced seeding options (lattice, spacing).
To bypass this error (not recommended), set IC_DES_ABORT_ON_FAILED_SEEDING(ICV,M)=.FALSE.
My situation is the same as this, but he is using DEM and I am using CGP, which is slightly different, so how should this be operated;
Secondly, can the particle input.dat generated by this code be directly placed in the file I want to simulate?
We have modified MFiX to take particle input from a CSV file rather than the particle_input.dat file with its fixed format and header. The old format is still supported but we strongly suggest using the CSV format. We have several tutorials which use particle_input.csv: fb_sqp_particle_input (SQP), fb_gsp_particle_input (GSP), fluid_bed_2d (DEM), mixer_3d (DEM), screwfeeder_3d (DEM), and hopper_3d (DEM) all use the CSV particle input format.
For CGP, each row in the CSV file represents one parcel, not an individual particle. You will have to specify statistical weight or real particle size. If your script can write this CSV, it can be loaded into MFiX as the initial particle configuration. Let us know if you need help with this.
You may also find this thread helpful MFIX-24.3.1 bimodal grain size from cumulative size distribution
This shows a different approach to seeding, where a mass inlet is created at the top of the domain, and particles are allowed to fall and settle. You can select “Save particle positions at end of run” and run with the mass inlet for a fixed period of time, then remove the mass inlet and use that settled particle bed as your initial configuration (renaming particle_output.csv to particle_input.csv)
– Charles
Thank you for your reply. I was planning to release particles downwards at the output, but after running for 0.4 seconds, the simulation will stall. I don’t know where the problem lies, so I am requesting your help
input_particle.zip (67.1 MB)
I’m getting this error at t=0.4
Error: There exists a NORMAL particle in a GHOST cell.
Particle may have gone OUT-OF-BOUNDS.
To resolve this issue, please consider:
a) Verify all wall boundary conditions are defined
b) Reducing the value of the variable NEIGHBOR_SEARCH_N (Solids>DEM>Max steps between neighbor search)
c) Increasing the particle and/or wall stiffness (Solids>DEM>Normal spring constant or Young's modulus)
Current particle location (x, y, z coordinates): 0.6206E-01, 0.5063 , 0.2131E-01
Current particle velocity (u, v, w components) : -1.109 , 0.1710E-01, 102.5
Did you follow the suggestions in the error message?
I tried the above method, but it couldn’t completely solve the problem. It just changed from 0.4s to 0.47s
Hello, I think the reason for the stagnation of the particle falling case is due to the collision between large and small particles during the falling process. Therefore, I think it is possible to consider directly inserting particle input.csv. Using Python to generate particles as mentioned before, but DEM and CGP are different. Do you have any solutions?
It’s not stagnating, particles are leaving the domain, and we have to figure out why.
The only difference between DEM and CGP seeding is that the CGP particle_input.csv requires colums for either statistical weight or real particle size, as mentioned previously