A problem: no mfixsolver generated after compilation

Hello everyone, I encountered a problem while compiling the solver. I used the command:

build_mfixsolver --batch --dmp

BUILD SUCCESSFUL was displayed, but two files, mfixsolver. sh and mfixsolver. so, were generated instead of mfixsolver. Attempting to run these two files was also unsuccessful.

My linux system is Ubuntu 18.04, MFiX version is 23.1.1, and a part of the output of the compilation process is as follows:

Building custom solver for Reaction.mfx
Running cmake command:
cmake -DENABLE_PYMFIX=ON -DENABLE_MPI=1 -G “Unix Makefiles” -DCMAKE_INSTALL_PREFIX=/home/southeast368/MFiX_work/Test -DUDF_DIR=/home/southeast368/MFiX_work/Test -DVERSION=23.1.1 /home/southeast368/anaconda3/envs/mfix-23.1.1/share/mfix/src

– Setting build type to ‘RelWithDebInfo’ as none was specified.
– MFIX build settings summary:
– Build type = RelWithDebInfo
– CMake version = 3.26.4
– Fortran compiler =
– Fortran flags =
– ENABLE_MPI = 1
– ENABLE_OpenMP = OFF
– ENABLE_CTEST = OFF
– ENABLE_COVERAGE = OFF
– The Fortran compiler identification is GNU 7.5.0
– The C compiler identification is GNU 7.5.0
– Detecting Fortran compiler ABI info
– Detecting Fortran compiler ABI info - done
– Check for working Fortran compiler: /usr/bin/f95 - skipped
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working C compiler: /usr/bin/cc - skipped
– Detecting C compile features
– Detecting C compile features - done
– Performing Test ffpe_trap
– Performing Test ffpe_trap - Success
– Performing Test ffpe_summary
– Performing Test ffpe_summary - Success
– Found MPI_C: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so (found version “3.1”)
– Found MPI_Fortran: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_usempif08.so (found version “3.1”)
– Found MPI: TRUE (found version “3.1”)
– Found Git: /home/southeast368/anaconda3/envs/mfix-23.1.1/bin/git (found version “2.40.1”)
– Found PythonInterp: /home/southeast368/anaconda3/envs/mfix-23.1.1/bin/python (found version “3.10.11”)

Found UDFs:
/home/southeast368/MFiX_work/Test/usr_rates.f;/home/southeast368/MFiX_work/Test/species.inc
– Found Python: /home/southeast368/anaconda3/envs/mfix-23.1.1/bin/python
– Configuring done (2.6s)
– Generating done (0.1s)
– Build files have been written to: /home/southeast368/MFiX_work/Test/build
Build command:

cmake --build . --target install

[100%] Built target Merge_UDF
[100%] Building Fortran object CMakeFiles/mfixsolver_ext.dir/model/dummy.f.o
[100%] Building C object CMakeFiles/mfixsolver_ext.dir/model/gfortran_init.c.o
[100%] Linking Fortran shared library mfixsolver.so
[100%] Built target mfixsolver_ext
Install the project…
– Install configuration: “RelWithDebInfo”
– Installing: /home/southeast368/MFiX_work/Test/mfixsolver.so
– Set runtime path of “/home/southeast368/MFiX_work/Test/mfixsolver.so” to “”
– Installing: /home/southeast368/MFiX_work/Test/mfixsolver.sh

                 BUILD SUCCESSFUL

So how can I successfully create mfixsolver?

Thank you all!

Pan

Those messages are all normal.

does the file
/home/southeast368/MFiX_work/Test/mfixsolver.sh
exist?

what do you see if you do ls in the MFiX_work/Test directory?

Thank you for your reply. The sh file exists, as does mfixsolver.so.

The contents of the folder after the ls command are as follows:

build mfixsolver.sh mfixsolver.so Reaction.mfx usr_rates.f

It is worth mentioning that I used mfix-21.4 to perform the same operation, but successfully created the mfixsolver, and everything was OK. Nevertheless, I still want to know if it is possible to successfully compile using mfix-23.1.1.

Oh, I see…
Normally, the build_mfixsolver script generates a symbolic link from mfixsolver to mfixsolver.sh - this is really just for convenience:

$ ls -l mfix*
lrwxrwxrwx 1 cgw cgw       13 May 26 11:23 mfixsolver -> mfixsolver.sh
-rwxr-xr-x 1 cgw cgw      195 May 26 11:22 mfixsolver.sh
-rwxr-xr-x 1 cgw cgw 12026512 May 26 11:23 mfixsolver.so

Looks like for some reason the .sh file is there, but the symlink didn’t get generated… I don’t see any error message about this though, which is strange:

        if not WINDOWS:  # symlink requires extra privileges on Win
            try:
                try:
                    os.unlink('mfixsolver')
                except OSError as e:
                    if e.errno != errno.ENOENT:
                        raise
                os.symlink('mfixsolver.sh', 'mfixsolver')
            except OSError as e:
                print("Error creating symbolic link:", e)

if that os.symlink call failed there should have been an error.

What happens if you go in the project directory and type

$ ln -s mfixsolver.sh mfixsolver

Yes, there were no error messages during the compilation process, which is strange.
When I type:

$ ln -s mfixsolver.sh mfixsolver

A link file named ‘mfixsolver’ has been generated in the directory. Then, I type:

mpirun -np 2 ./mfixsolver -f Reaction.mfx NODESI=2 NODESJ=1 NODESK=1

to try to run this file, it reports error:

usage: pymfix.py
[-h]
[-f FILE]
[-d DIRECTORY]
[-p]
[-l LOG]
[-c]
[-s]
pymfix.py: error: unrecognized arguments: NODESI=2 NODESJ=1 NODESK=1
usage: pymfix.py
[-h]
[-f FILE]
[-d DIRECTORY]
[-p]
[-l LOG]
[-c]
[-s]
pymfix.py: error: unrecognized arguments: NODESI=2 NODESJ=1 NODESK=1

Primary job terminated normally, but 1 process returned
a non-zero exit code… Per user-direction, the job has been aborted.


mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

Process name: [[18101,1],0]
Exit code: 2

It seems like pymfix.py cannot unrecognize the command.

For the interactive solver, the NODESI, NODESJ, and NODESK should be in the file not on the command line.

The batch solver still accepts these args on the command line. If you are not using the MFiX GUI and don’t need interactive features (ability to pause/resume the simulation and change keyword values during a run) you can build a batch-mode solver with:

$ build_mfixsolver --batch

The GUI will not be happy with this mfixsolver but if you’re just launching from the command line anyway it doesn’t really matter.

OK, after I compile and run from the GUI interface, MFiX-23.1.1 can simulate normally (although it generates link file, sh file and so file).
In fact, when I used the old version of MFiX, I was accustomed to running from the command line, and I think for the new version, this is a habit that needs to be corrected, maybe.
Thank you very much for your help!