-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Antioch fails to read gri30.xml #211
Comments
Antioch is much more explicit than the gri30.xml, indeed... But I wonder why I haven't coded a gri-compatible parser. The fix is to make I'm on it. |
We should have a more helpful error message too, e.g. write out what was found (if anything) and then list what is currently understood by Antioch. |
Thanks, @SylvainPlessis ! But don't feel bad if this gets put on the back-burner - this is something I'd like to fix for other users' benefit, not something I need for myself. Changing the XML file to be Antioch-compatible was pretty trivial, and I'm actually going to be using a different reaction dataset in the end anyway. |
I should also note that, if you enjoy pain, I'm pretty sure the ChemKin GRI3 input file is parsed correctly (I'd tested this several months ago). |
@pbauman, we get the "list what is currently understood by Antioch" part right; but the error message omits the "what was found" part, presumably because if you had verbose=true that part was already just printed. |
This is linked to issue #184, du to #172. This is where I explain that indeed, we were not GRI (Cantera) compatible for falloff. It was an answer to #163. PR #212 is where I fixed it. To sum it up, the GRI/Cantera way was not explicit/rigorous enough for me (and I guess I was lazy enough not to look for the order of the Troe parameters), so I used a more explicit description. |
Looks like we're not quite there yet. #212 doesn't seem to handle three-body reactions? |
Now this one is unexpected... The only supposed difference is Should I start crying or there's something else? |
When parsing reaction 0085, I now get
Looks like the problem here is that there's again no explicit 'threeBody' or 'ThreeBody' keyword in the file. The reaction type="falloff", there's a falloff type="Troe", but the only clue that it should really be TROE_FALLOFF_THREE_BODY instead is that there's a "(+ M)" in the equation and there's an efficiencies section in the rateCoeff. |
Ah... I suggest that the |
I'm feeling annoyed that they didn't put the metadata into the metadata. My personal preference would be to check for That way we're still correct in the case where a three-body equation is specified but the efficiencies tag was left out as a way of implying all efficiencies are 1.0. I'd also move the verification out of an assert... parsing isn't in an inner loop, and these files are clearly ill-defined enough that we want to be extra careful when reading them. |
This one made me smile from ear to ear. Welcome into a chemicaler world 😄 |
Can I use |
I take it this means your vote is "yes, mandate at least C++11" for the question in #206? Works for me, then. |
Indeed. |
I don't know about checking that there are no extra information in the description. This is typically so much more painful. As of now, there is no check of that sort (apart from the Arrhenius in place of Kooij stuff, because this is way too irritating).
This is ensured by the |
Taken care of in #228. |
And now I'm hitting another parsing failure, as soon as I add nitrous oxide into the mix:
|
I think I found the reason. This is a Kooij rate constant labeled Arrhenius with a zero power parameter. So a very (very) badly described Arrhenius (unless you add uncertainties on the power parameter, in this case it's a classic Kooij, but I didn't consider this option as we do not describe uncertainties in the input files). I think the problem lies between the zero test in xml_parser.C and read_reaction_set_data.C. They don't seem to agree. If I'm correct, you should have no warning on this reaction, the expected (and uncorrect by the way, the warning should not be printed in an Arrhenius case) behavior would be having the warning of the second zero test. The simplest way to verify this is to print the I can't verify it right now, cppunit v 1.13.1 does not agree with Hope it helps |
Ok I've found the problem, it's not in the Now the thing is, the test for the power parameter is whether the parser finds a power parameter, which in this case will turn out to be true. The filtering of the Arrhenius badly written as a Kooij should operate at the The quick solution:
We will lose the power optimisation for the falloff in the case of both rate constants are the double agent Arrhenius, but it'll work. Ok, I've posted the PR (#230), and I didn't post this one before... I though I did... This is the post the PR refer to. |
I believe this is good. I'm hitting GRI3 XML much harder in #254 and it's parsing fine. So I'll go ahead and close. Looks like this is related to #253 in @SylvainPlessis comment above. |
We get an antioch_not_implemented() error in read_reaction_set_data.C, when the code can't decide what sort of reaction "falloff" is.
In the XML file, there's a
<falloff type="Lindemann"/>
tag, but our code seems to be assuming that we'll have specified that astype=LindemannFalloff
instead.The text was updated successfully, but these errors were encountered: