Error at building the solver

There will be a problem with the reaction preprocessor whenever there is more than one project file in a directory. This is fallout from the decision to allow the project file to have a name other than mfix.dat. The reaction preprocessor is picking up the wrong project file. It’s supposed to check that there is only one project file in the project directory, but that check is not working properly. This will be fixed in an upcoming release.

2 Likes

I would like to thank you all very much for your help.

I understand your point and the error is gone now as I removed the mfix.dat file. However, I added the mfix.dat file in order to be able to add species that do not exist on the GUI (for example: char). As you all know the default project file (Wang.mfx in my case) is not editable. So what can I do to define a new species in this case?

Thanks,

Hi Mariam.

Chemical reactions are defined by going into the “Chemistry” pane and using the built-in reaction editor, pictured below. Click ‘+’ to define a new reaction. This will also check that your chemical reactions are balanced.

The Wang.mfx file is not directly editable in the MFiX GUI because we expect users to set up cases using the graphic interface, and editing the file directly will put the interface out of sync with the file contents. If you really need to edit the project file, you can exit MFiX, edit it in an external editor, and restart MFiX - this shouldn’t really be necessary though, anything that you need to do to set up the case should be doable through the GUI. (You still have to edit FORTRAN code to define reaction rates, but we are working on that.)

Having both an mfix.dat file (“old” name) and Wang.mfx (“new” name) in the same directory will only cause problems. We’re adding checks to MFiX to look for this and print a warning when it happens.

  • Charles

2 Likes

Hi Charles,

I had only 1 methane.mfx file in my methane/ folder, and defined all my chemical reactions through the GUI. I checked my mfx file, and made sure CH4 and O2 were defined. I also used the newest version 20.4.3, but still got error saying “CH4/O2 has no implicit type.” Could you help me take a look? Here are my files. methane.mfx (12.5 KB) usr_rates.f (764 Bytes)

Here are the errors
C:\Users\Administrator\methane\usr_rates.f:19:0:

ReactionRates(IJK, CH4_Combustion) = RATES(CH4_Combustion)
1
Error: Cannot assign to a named constant at (1)
C:\Users\Administrator\methane\usr_rates.f:10:32:

c_CH4 = (RO_g(IJK) * X_g(IJK,CH4))/MW_g(CH4)
1
Error: Symbol ‘ch4’ at (1) has no IMPLICIT type
C:\Users\Administrator\methane\usr_rates.f:14:20:

RATES(CH4_Combustion) = 6.7d12 * exp(-2.4358d4/T_g(IJK)) * &
1
Error: Symbol ‘ch4_combustion’ at (1) has no IMPLICIT type
C:\Users\Administrator\methane\usr_rates.f:9:30:

c_O2 = (RO_g(IJK) * X_g(IJK,O2))/MW_g(O2)
1
Error: Symbol ‘o2’ at (1) has no IMPLICIT type
C:\Users\Administrator\methane\usr_rates.f:15:4:

EP_g(IJK) * (c_O21.3) * (c_CH40.2)
1
Error: Function ‘ep_g’ at (1) has no IMPLICIT type
mingw32-make.exe[2]: *** [CMakeFiles/udfs.dir/C_/Users/Administrator/methane/usr_rates.f.obj] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/udfs.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
CMakeFiles\udfs.dir\build.make:86: recipe for target ‘CMakeFiles/udfs.dir/C_/Users/Administrator/methane/usr_rates.f.obj’ failed
CMakeFiles\Makefile2:117: recipe for target ‘CMakeFiles/udfs.dir/all’ failed
Makefile:148: recipe for target ‘all’ failed

                  BUILD FAILED 

==============================================================

The examples on the website only show excerpts of the files. You should study complete simulation setups, say the silane pyrolysis case. From the GUI, go to the main menu> New project and select the “silane_pyrolysis_2d” TFM project. From the source tarball, navigate to mfix-20.4.3/tutorials/tfm/silane_pyrolysis_2d. There are two things you need to add to your usr_rates.f file:

  • Modules that have the necessary variables referenced in usr_rates.f. For example, if you need to use the void fraction (EP_G), then make sure you have:
USE fldvar

This will give you access to all field variables defined in model/fldvar_mod.f. If you only need EP_G, you could use

USE fldvar, only: EP_G
  • The include file that has the species alias definition:
INCLUDE 'species.inc'

All other variables need to be declared and we recommend using an IMPLICIT NONE statement to force the declaration of all variables.

Please see the attached example. I believe you used cgs unit for the reaction rates so I did a unit conversion, please verify. I also bumped the temperature so the reaction takes place and added the reaction rate to the vtk file (note the nrr=1 in the mfx file).

methane.mfx (12.6 KB)
usr_rates.f (2.1 KB)

It’s clear that setting up user reactions is a bit difficult! We’re going to address this in a future version of MFiX

Some suggestions:

  1. You must include 'species.inc'
    to get the symbol defintions for the species. This file is created by the build scripts.

  2. After fixing that, the next build fails with unkown symbol mw_g. To fix that, you need to add a USE statement. This requires a bit of knowledge of the MFiX solver, or a litle bit of searching:

$ cd mfix/model; grep -riw mw_g|grep -i -m1  use
check_data/check_chemical_rxns.f:      use physprop, only: MW_g, MW_s

shows that we need to add a use physprop

Iterating, we find that we also have to add fldvar for x_g

$ grep -riw x_g |grep -m1 -i use
set_bc0.f:   use fldvar, only: x_g, x_s, scalar

and we also have to add use rxns to pick up nrr. Basically if you are going to access MFiX variables you need to add a use statement. Hopefully we can automate this a bit in the GUI to make it easier for users.

With the following changes your case builds and runs:

SUBROUTINE USR_RATES(IJK, RATES)
      use physprop              !mw_g
      use fldvar                !x_g
      use rxns                  !nrr

      include "species.inc"

but as soon as it starts, it fails:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7f291e456dcf in ???
#1  0x7f28d1d3a70d in usr_rates_
	at /tmp/methane3/usr_rates.f:20
#2  0x7f28d1e26f3b in __stiff_chem_MOD_calc_reactions
	at /home/cgw/Work/NETL/mfix/model/chem/stiff_chem_mod.f:335
#3  0x7f28d1e27363 in __stiff_chem_MOD_stiff_chem_solver
	at /home/cgw/Work/NETL/mfix/model/chem/stiff_chem_mod.f:199

This is just a garden-variety division-by-zero error

RATES(CH4_Combustion) = 6.7d12 * exp(-2.4358d4/T_g(IJK)) * &
EP_g(IJK) * (c_O2**1.3) * (c_CH4**0.2)

you have nothing guarding against the case T_g == 0

I see. Thank you both very much for your help! I can build the solver successfully now both with my modified code and Jeff’s code, but when I tried to run the methane tutorial, I could not use the solver because the tester said I had a segmentation fault. Is it saying something is too big that will eat up all the memory on my computer? Thanks!

Here is the error message:

The solver test failed with the following error:

/Users/jackz/Documents/methane/mfixsolver: line 3: 48310 Segmentation fault: 11 env PYTHONPATH="/Users/jackz/Documents/methane":"":${PYTHONPATH:+:$PYTHONPATH} /Users/jackz/opt/anaconda3/envs/mfix-20.4.3/bin/python3.7 -m mfixgui.pymfix “$@”

Are there any other messages? A stack trace? A core file?

If you have a core file, please try to get a stack trace using gdb.

I’ll see if I can reproduce your error here.

– Charles

Jack - the error is reproducible. This has nothing to do with running out of memory, it’s an out-of-bounds array access. If you suspect running out of resources, use top while running to see how much memory, etc is being used.

I used gdb to get a stack trace:

$ pwd
/tmp/methane

$ ls -l core
-rw------- 1 cgw cgw 1332269056 Feb 16 07:59 core

$ file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/lib/python-exec/python3.9/python -m mfixgui.pymfix -s -f /tmp/methane/meth', real uid: 103, effective uid: 103, real gid: 1000, effective gid: 1000, execfn: '/usr/lib/python-exec/python3.9/python', platform: 'x86_64'

$ gdb /usr/lib/python-exec/python3.9/python core
#0  0x00007fb6e47e77c1 in usr_rates (ijk=2.1219958423480995e-314, rates=...)
    at /tmp/methane/usr_rates.f:21
21	EP_g(IJK) * (c_O2**1.3) * (c_CH4**0.2)

(gdb) list
16	c_CH4 = (RO_g(IJK) * X_g(IJK,CH4))/MW_g(CH4)
17	
18	! Methane Combustion
19	!-----------------------------------------------------------------//
20	RATES(CH4_Combustion) = 6.7d12 * exp(-2.4358d4/max(1.0,T_g(IJK)))* &
21	EP_g(IJK) * (c_O2**1.3) * (c_CH4**0.2)
22	
23	! Store the reaction rate for output/post processing.
24	IF(CH4_Combustion <= NRR) &
25	ReactionRates(IJK, CH4_Combustion) = RATES(CH4_Combustion)

(gdb) p ijk
$4 = 2.1219958423480995e-314

That value of ijk seems erroneous. Where is it coming from?

(gdb) up
#1  0x00007fb6e48d3f4c in stiff_chem::calc_reactions (ijk=104)
    at /home/cgw/Work/NETL/mfix/model/chem/stiff_chem_mod.f:335
335	      CALL USR_RATES(IJK, RATES)

(gdb) p ijk
$5 = 104
(gdb) down
#0  0x00007fb6e47e77c1 in usr_rates (ijk=2.1219958423480995e-314, rates=...)


So IJK has valid value in the calling function but when we get to the usr_rates.f the value is invalid. HMMM. I’ll get back to you on this (or maybe someone else has a clue?)

It would be good if MFiX reported more details on this sort of error but it looks like we are not trapping and reporting the SEGV errors the same way we do the zero-division. There is definitely room for improvement in this area and your error reports are helping us greatly.

Note - I do get a stack trace in the MFiX console window, it just doesn’t turn into an error popup. If you scroll back a bit in the console you should see something like

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
    #0  0x7fcffe412dcf in ???
    #1  0x7fcfb1cf684b in usr_rates_
	at /tmp/methane/usr_rates.f:22
    #2  0x7fcfb1de2feb in __stiff_chem_M

which helps pinpoint the error but is not as good as a full gdb session because it doesn’t show variables.

– Charles

1 Like

Jack - you have

DOUBLE PRECISION, INTENT(IN) :: IJK ! Fluid Cell Index

IJK is an integer (array index). That line should be:

INTEGER, INTENT(IN) :: IJK ! Fluid Cell Index

Fixing this gets me past the bizarre value of IJK but I’m still getting a seg fault!

  • Charles

Can someone share the files to reproduce the segfault? The files I shared in Error at building the solver - #13 by jeff.dietiker run fine with me both in the GUI and at the prompt. There is no limiter in the version I uploaded, but it is running.

@Jeff: I’m getting the seg fault with Jack’s original methane.mfx and this slightly modified usr_rates.f

usr_rates.f (952 Bytes)

I suspect it’s depenent on compiler version. What gfortran are you using?

@jeff: I just tried with your usr_rates.f and I did not get a segfault. This confirms that it takes a high degree of expertise to write a usr_rates.f that works :slight_smile:

Jack, can you please confirm you can run the files I sent?

Make sure you have

DOUBLE PRECISION, DIMENSION(NO_OF_RXNS), INTENT(OUT) :: RATES ! Reaction Rates

instead of

DOUBLE PRECISION, INTENT(OUT) :: RATES(:) ! Reaction Rates

I started from the sample file in the silane tutorial instead of what is in the doc. We will need to update the documentation, these examples are outdated.

Yeah I used exactly the files that you shared with me and it gave me the same error. I tried both editing mine and using Jeff’s directly. Both built the solver but got the same error when I tried to run it.

I’m using gfortran 10.2.0.

gfortran --version

GNU Fortran (Homebrew GCC 10.2.0_1) 10.2.0

Copyright © 2020 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Jack - please scroll back in the console and see if there’s a stack trace there. If so, please post it here. The stack trace should contribute to the “# Errors” but currently it doesn’t, this will be addressed in the next release.

No I don’t see anything there. Here is the full console.

“Solver test failed with the following error” isn’t the message from a failed run. It’s a message from the run popup, trying out the available solvers, before even starting the run. I suggest removing all solvers from this popup:

and trying again.

yeah I tried that again and it still gave the same error…