Additional check for Troe coefficients being zero #601
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I encountered the problem that the "init" function of Troe reactions generates a floating point exception due to division by zero. I am using the FORCE Caltech mechanism from here:
http://www.theforce.caltech.edu/CaltechMech/
In the mechanism file
http://cvs.theforce.caltech.edu/cgi-bin/viewvc.cgi/CaltechMech/CaltechMech.chmech?view=co
there is the following reaction:
H+O2(+M) = HO2(+M) 5.590e+13 0.200 0.00
O2/0.89/ H2/1.50/ H2O/11.70/ CO2/2.18/ AR/0.52/ CO/1.09/
LOW / 2.650e+19 -1.300 0.00 /
TROE/ 0.7 0.00 10000000000.00 10000000000.00 /
The second Troe parameter is zero. According to the Chemkin Format
http://akrmys.com/public/chemkin/CKm_inp.html.en
this corresponds to T*** or "m_rt3" in Cantera:
cantera/src/kinetics/Falloff.cpp
Line 33 in 5c783c7
Using the standard installation of Cantera, this does not generate any errors. But in my case, I use Cantera together with another program (OpenFOAM), which throws hardware exceptions if this occurs. Of course, I could change this by hand in the mechanism file itself, but maybe it is nicer to handle this in the code.
This was actually handled in previous versions, but was removed in this commit:
84e6775#diff-4210fe882743537c1bb1cacdbe10255b
and this issue:
#404
I would argue to include a special treatment for zero in case Cantera is used together with programs like OpenFOAM which will trigger hardware exceptions if division by zero occurs.
Because this part of the code is not relevant to performance, I introduced an additional check. This will prevent hardware exceptions in case c[1] or c[2] are zero but will exactly keep the current behaviour if c[1] and c[2] are not zero.