hello everyone,
i test the case"fluid_bed_dem_2d_new" given by mfix with the dmp, and the mesh was set as 15*45, so i set the the gridmap to be as below:
3 6 1! NODESI, NODESJ, NODESK
0 5
1 5
2 5
0 5
1 5
2 5
3 5
4 5
5 20
0 1
but it didn’t work, and shows：
fluid_bed_dem_2d_new.zip (27.9 MB)
Hi @songchao1
A) DId you use the Submit bug report feature (or the bug_report.py) script to generate the zip file, or did you just zip up the project directory? I’m trying to understand why the ZIP file you uploaded contains the build/ subdir.
B) I did not run your case, but I think I see the problem. Look carefully at the error message: it’s complaining about item 3 in the list input. Now look more carefully at the file:
(mfix-23.3)$ cat gridmap.dat
3 6 1! NODESI, NODESJ, NODESK
0 5
1 5
2 5
0 5
1 5
2 5
3 5
4 5
5 20
0 1(mfix-23.3)$
The error messages specifies item 3 of the list input. Since the first line is the NODES setting, list item 3 is on line 4 of the file. Line 4 has extra space in it.
(mfix-23.3)$ cat -T gridmap.dat # -T shows tab characters as ^I
3 6 1! NODESI, NODESJ, NODESK
0 5
1 5
2^I ^I 5
0 5
1 5
2 5
3 5
4 5
5 20
0 ^I ^I 1(mfix-23.3)$
So, you have TABS in there, and you also are missing a newline at the end. Try converting tabs to spaces, add the missing newline, and try again. (How did you create this file?)
– Charles
Of course, it would be nice if the file reading code were a little less finicky about tabs and spaces. I’ll try to get this added to a future release.
hello cgw,
1)I build the gridmap.dat with the .txt file and changed the file suffix name to .dat. Is that any problem?
2)I changed the TABs to SPACEs, but the error still exist：
A) OK, you are not using the GUI and do everything from the command-line. I will add command-line access to the bug report tool for the next release. May I ask why you are not using the GUI version?
B) I think the problem may be the comment on the first line. The code in gridmap_mod.f is not very smart and I don’t see anything in there about skipping over comments. So try removing !NODESI NODESJ NODESK from the first line.
I think you just need to add a space between 1 and !, otherwise the code is trying to interpret 1! as an integer.
3 6 1 ! NODESI, NODESJ, NODESK
Aha! Thanks Jeff. So “list item 3” was referring to 1!. Slightly confusing error message.
Yes, I guess we should strip out the comment before parsing the line.
thanks jeff，it worked well.
A) thanks cgw,
beacuse i have a case which is coupled with chemical reaction and lots of particles, so inorder to have a faster calculation speed, i try it on a HPC.
besides, can you give me a clear guidance about this probelom:
“i wonder which version of the gfortran/GNUmake/Cmake/openmpi is suitable for mfix-22.2.2/mfix-23.1.1 and mfix23.2?”
waitting for your reply!!
You can still use the GUI to set up cases and submit bug reports. And if you do a little work to set up the correct queue template, you can submit HPC jobs and monitor them from the GUI as well. This will lead to a better experience (you can pause, modify, and resume simulations, etc).
If you install the 23.3 MFiX package you will automatically get (from conda-forge)
GNU Fortran (conda-forge gcc 13.2.0-2) 13.2.0
cmake version 3.27.6
mpirun (Open MPI) 4.1.6
We strongly recommend installing MFiX 23.3
If you can’t or won’t do this, you’ll need to make sure the compiler/cmake versions are recent enough.
I know the build scripts will complain if cmake is not at least version 3.16.
There’s also a check for GFortran version, it wants at least 4.6 but I think that check needs to be updated, I believe the solver will not compile without at least GFortran 8 (this needs to be verified). But in general, using a more recent compiler will do a better job of targeting modern CPU architectures and will produce faster code. Why use old tools when the new ones are free?
Thanks for your reply cgw, i will try 23.3 soon.