hi，everyone
I’m using dmp parallel operations （x-1, y-2, z-1） in mfix24.1.1,
This example starts to appear something when it runs to 0.832s.like
MFiX running, simulation time: 0:00:0.832 elapsed time: 4:45:28
MFiX running, simulation time: 0:00:0.832 elapsed time: 4:46:29
MFiX running, simulation time: 0:00:0.832 elapsed time: 4:47:29
MFiX running, simulation time: 0:00:0.832 elapsed time: 4:48:30
MFiX running, simulation time: 0:00:0.832 elapsed time: 4:49:30.
Please tell me if there is any way to crack it.thank you！
01-crfy.zip (83.4 MB)
Will anyone solve this problem，I would appreciate it if it was solved
Hi @Qianbinhui
I’ve been looking at the case you submitted and have several comments
-
There are a large number of FORTRAN files in your project directory but none of these seem to have significant modifications from the original MFiX source. It creates extra work for us to have to debug user-modified code, so I deleted these files and am using the default (pre-built) MFiX solver for testing.
-
I had to remove the keywords
read_kf(1), read_kf(2), read_kf(3), read_kf(4)from your project file. These were all set to.FALSE.anyway, so removing them had no effect. We have a new method of handling keyframe files as of the 24.2 release (built in to the solver, no code modifications are required - there is a “Keyframe” pane directly in the MFiX GUI.
-
Your DMP partitioning is not ideal. Partitioning along the Y axis is not efficient since most of the particles are at the bottom of the column. The top partition is basically empty. So I changed the partitioning to 4x1x1 (4 partitions along the X axis). However, running your case this way caused the MFiX sovler to crash! After some investigation, there was an uninitialzed BC variable in the MFiX code that was causing this. This bug has been fixed in MFiX version 24.3.1 which was just released today.
I have not yet run the case to t=0.832s but so far ti seems to be proceeding normally. I’ll let you know if I see anything unusual once it’s run for several hours.
– Charles
