Dears,
I receive this error while running the solver:
“Error: Symbol ‘h2o’ at (1) has no IMPLICIT type”
I wonder why the solver doesn’t recognize the symbol “H2O” which refers to water. What can I do about it?
Thanks,
Did you modify any fortran files? can you post your case?
Are you referring to it as h2o in one place and H2O in another?
I did all H2O “upper case”. I attached the file too.
Thanks,
looks like there is no H2O defined in your species.inc file. The reaction pre-processor used the mfix.dat file in your project directory instead of the Wang.mfx file. I suggest deleting the mfix.dat file from your run directory.
!This file was generated by C:/ProgramData/Anaconda3/envs/mfix-20.2.1/share/mfix/src/model/cmake/rxn_preproc.py
!from C:/Users/mariamyehia/Desktop/CH4/Wang/Wang/mfix.dat on Wed Feb 10 13:19:43 2021
!Edit at your own risk!!!
INTEGER, PARAMETER :: wood = 1
INTEGER, PARAMETER :: moisture = 2
INTEGER, PARAMETER :: char = 3
INTEGER, PARAMETER :: ash = 4
INTEGER, PARAMETER :: R2 = 1
1 Like
I had a similar issue that I asked several days ago as well. I copied this file methane.mfx (13.9 KB) from the tutorial to simulate methane combustion, and when I tried to build the solver it also gave me the “no IMPLICIT type” error.
19 | ReactionRates(IJK, CH4_Combustion) = RATES(CH4_Combustion)
| 1
Error: Syntax error in IF-clause after (1)
/Users/jackz/Documents/methane/usr_rates.f:9:4:
9 | c_O2 = (RO_g(IJK) * X_g(IJK,O2))/MW_g(O2)
| 1
Error: Symbol ‘c_o2’ at (1) has no IMPLICIT type; did you mean ‘c_02’?
/Users/jackz/Documents/methane/usr_rates.f:10:32:
10 | c_CH4 = (RO_g(IJK) * X_g(IJK,CH4))/MW_g(CH4)
| 1
Error: Symbol ‘ch4’ at (1) has no IMPLICIT type; did you mean ‘c_ch4’?
/Users/jackz/Documents/methane/usr_rates.f:14:20:
14 | RATES(CH4_Combustion) = 6.7d12 * exp(-2.4358d4/T_g(IJK)) * &
| 1
Error: Symbol ‘ch4_combustion’ at (1) has no IMPLICIT type
/Users/jackz/Documents/methane/usr_rates.f:9:30:
9 | c_O2 = (RO_g(IJK) * X_g(IJK,O2))/MW_g(O2)
| 1
Error: Symbol ‘o2’ at (1) has no IMPLICIT type
make[2]: *** [CMakeFiles/udfs.dir/Users/jackz/Documents/methane/usr_rates.f.o] Error 1
make[1]: *** [CMakeFiles/udfs.dir/all] Error 2
make: *** [all] Error 2
BUILD FAILED
==============================================================
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
1 Like
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:
-
You must
include 'species.inc'
to get the symbol defintions for the species. This file is created by the build scripts. -
After fixing that, the next build fails with unkown symbol
mw_g. To fix that, you need to add aUSEstatement. 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?