Hi Julia - two-part reply:
(1) Regarding gdb - you’re not doing anything wrong - you’re on the right track. There’s just some extra complexity involved.
The mfix solver can be built in 2 different ways. In the “legacy” (or batch) mode, build_mfixsolver produces a normal Fortran binary executable.
When we run MFiX in the GUI there are some additional features - the ability to pause and modify settings and resume, and monitoring of job status - that are implemented in a Python process that uses HTTP to communicate with the GUI. In this mode, the Fortran MFiX code gets turned into a library which is “wrapped” in Python. So the mfixsolver you tried to run in GDB is actually a Python script (“pymfix”) - or more correctly a shell script that starts the Python script which imports the wrapped Fortran code. Let’s take a peek behind the curtains:
The file command on Linux, if you are not familiar, is very useful, it will attempt to deduce the type of file you specify. So when gdb says “not in executable format” you can see what file says:
% file mfixsolver
mfixsolver: symbolic link to /tmp/Absorption_column_2d/mfixsolver.sh
% file /tmp/Absorption_column_2d/mfixsolver.sh
mfixsolver.sh: POSIX shell script, ASCII text executable
% cat mfixsolver.sh
env PYTHONPATH="/tmp/Absorption_column_2d":"/home/cgw/Work/NETL/mfix":${PYTHONPATH:+:$PYTHONPATH} /usr/lib/python-exec/python3.9/python -m mfixgui.pymfix "$@"
You can debug this module by starting Python itself in gdb (with the correct PYTHONPATH), then importing and running pymfix - at the GDB prompt you type run -m mfixgui.pymfix -f /path/to/PROJECT.mfx
but this is the slightly more difficult way of doing it - the easier way is to build the batch-mode solver that doesn’t have the Python extensions.
To do this, add --server=none to your build_mfixsolver command line, or if you are using the GUI, go into “Settings” on the main menu, click “Enable developer mode”, and then the build popup will show a new selector for “Interactive support”, set this to “None (batch)”
and then when you build you will get a directly debuggable executable:
% file mfixsolver
mfixsolver: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
You can start this in GDB, but you have to specify the name of the mfix input file - if no name is specified, the solver will look for the “traditional” name of mfix.dat. So either call your input file mfix.dat, or, when you start the process in gdb, specify the path to the input file with the -f flag like so:
% gdb mfixsolver
[...]
(gdb) run
**********************************************************************
From: mfix.f
Error 1000: Input data file does not exist: mfix.dat
Aborting.
**********************************************************************
(gdb) run -f Absorption_column_2d.mfx
[MFiX simulation starts running]
Another issue you will likely run into on repeated debugging runs is that MFiX will exit if the output files are already present. In that case you get an error that looks something like
ERROR open_files.f:206
File exists but RUN_TYPE=NEW
Cannot create file: ABSORPTION_COLUMN_2D.RES
and you simply have to delete the output files and try again (this is usually handled by the GUI)
Note that the batch-mode solver will not work correctly if you try to launch it from the GUI - the necessary communication between GUI and solver is not enabled, so the front end won’t be able to stop/pause the solver or track its progress. So, for normal use I do not recommend the batch solver. We have a goal of making debugging in the GUI easier (integrated debugger) and removing this batch/interactive distinction but that is still a long way off.
=============================================================
(2) The garbled text in the build output is really just the space character rendering as an “á” - this is a slightly embarrassing Unicode vs ASCII mixup which is happening on some platforms - we caught this right after the 21.2 release went out. It does not affect the compilation of the solver in any way. I have a fix for it, which will be present in 21.3 (Sep/Oct) or 21.2.1 if we decide to do a bugfix release before then. I think the “Style not available” message can be ignored. Please let me know if you see any other irregularities in the 21.2 GUI - we depend on feedback from users like you. Thanks!
– Charles
I was suspicious from reading other forums that the mfixsolver script could be a bash/Python script instead of a binary executable, but I didn’t know what to do with that information.
