Comments (22)
I understand that the first irreversible means reversible, my answer is built upon that assumption.
Print the chemical scheme in the reversible case (ReactionSet::print_chemical_scheme
) and verify that the reactions are not faster in the backward way. I've seen a lot of cases where the backward rate is way higher that the forward rate (don't ask me, chemists did this...). If this is the case, then everything is fine, if not, there is something very wrong somewhere...
In the latter case, or if my assumption is wrong, I want the kinetics input file to investigate (sometime in some hopefully near future...) this.
from antioch.
Sorry, the second instance was supposed to be reversible. Fixed above.
from antioch.
Alright, check the backward rate and the forward rate. A much higher backward rate than forward could still explain this. Are they supposed to be irreversible or reversible? GRI is supposed to be reversible if I remember correctly. From this file, they're all reversible but seeing the order of magnitude of the A parameter, I doubt they are faster in the backward way.
What is your mixture?
from antioch.
Also, are you using the ChemKin style input or XML style (from Cantera, say)?
As @SylvainPlessis said, printing the chemical scheme should report on all the details so we can check if there's a parsing problem.
from antioch.
I don't think it's a parsing problem-usually a non-standard reverse reaction rate in a reversible reaction is specified using the REV keyword in the Chemkin input file; otherwise it just uses equilibrium thermo to derive the reverse reaction rate. I don't see any REV keywords in the grimech file. And if that implementation is a problem, didn't we actually run grimech 3.0 through the chemtester test suite when we were checking the parsing this spring?
from antioch.
usually a non-standard reverse reaction rate in a reversible reaction is specified using the REV keyword in the Chemkin input file; otherwise it just uses equilibrium thermo to derive the reverse reaction rate.
Thanks, that's good to know. I would've assumed if it was a different backward rate that one would just specify it as two separate irreversible reactions.
And if that implementation is a problem, didn't we actually run grimech 3.0 through the chemtester test suite when we were checking the parsing this spring?
No idea what @SylvainPlessis tested when he developed this capability.
from antioch.
BTW, @beanSnippet, is this in the context of 0-D reactors (if so, what formulation)? 1-D flames? Other?
from antioch.
Yes, this is for a 0-D reactor for methane combustion, with a very similar set up to the example in the Antioch documentation. The grimech 3.0 input file that Sylvain linked to is what I initially tried to use, which yielded the strange endothermic results. When I changed all the <=>
to =>
then I got the more sensible results.
from antioch.
usually a non-standard reverse reaction rate in a reversible reaction is specified using the REV keyword in the Chemkin input file
Yep, so here we're supposed to have reversible reactions without any twist to the thermo. So we should check the thermo. I think though that in this case, we expect the much more reasonable approach @pbauman described, I'm not sure... Or Antioch does it automatically, I can't remember.
@beanSnippet, do you use the grimech file for the thermo also? What are the inputs you're using to compute the backward rate?
For reference, and I think we should add the pdf to the external_docs folder in the model_doc repo:
ChemKin reaction design. The rules for parsing are section 4 (pages 42 - 58 [44 - 60 for the pdf]), that's the set of rules in Antioch, without the auxiliaries, optional fancy stuff and using Antioch's rule in case of several copies of the same reaction (it becomes a duplicate reaction).
The parsing test is done with the test/input_file/test_parsing.chemkin file, that's a H2-O2 combustion scheme, I don't remember how this file ended there, I think it was the file Antioch was supposed to parse at the time. The test is simple, every reaction's constant rate is hard-coded defined, then the file is parsed, then we compare at the end, see the test/parsing_chemkin.C file for the details. There are also additional non-existing reactions to test the different kinetics models.
from antioch.
Yep, so here we're supposed to have reversible reactions without any twist to the thermo. So we should check the thermo. I think though that in this case, we expect the much more reasonable approach @pbauman described, I'm not sure... Or Antioch does it automatically, I can't remember.
To be clear, we use the equilibrium constant to compute the backward rate for reversible reactions. I have not checked that we don't do that for the REV
keyword that @variscarey mentioned --- we'll need to check the parsing. Regardless, that seems to be orthogonal to the issue here.
For reference, and I think we should add the pdf to the external_docs folder in the model_doc repo
In principle, I don't object. But, ChemKin is proprietary software and I worry about distributing their manual because its license is probably not compatible with ours. Certainly we can include a hyperlink.
from antioch.
@SylvainPlessis, the issue could be with the thermo file-- I now remember that I had to add some species to the default Antioch file to run methane. When I added a new one, I just filled in the rest of the slots with zeros. We had talked about this, so maybe we thought it would be okay because I was only running irreversible reactions at the time? I'm not adding any other inputs to compute backwards rates. Should I be?
However, I also had a similar experience with 0D hydrogen combustion, using the default Antioch thermo file. I could run the irreversible reactions fine, and saw normal exothermic behavior. When I tried making all the reactions reversible, the behavior of the system was very different (but I don't think it should be, most of the backwards rates in that case should also be negligible).
Sorry about the bad timing, but I'm going to be out of town until Monday. I'll jump back in the discussion then and give you more detailed input/output information as needed.
from antioch.
@beanSnippet, well I think you found the source of the problem. Until you fix the thermo inputs, there's no real need to dig deeper into this.
As a rule of thumb: never use default files, be explicit with your data. For a chemical system, provide
- a mixture (input file or vector of strings)
- a chemical species file, listing mandatory species characteristics
- a reaction set file
- a thermo file
If you use less than 4 files (or 3 if you declare your mixture with a vector), consider you're doing it wrong.
from antioch.
btw, a good idea is to look at the model docs and have an explicit input file for each default file listed in appendix C.
from antioch.
@beanSnippet Did you get all sorted out here?
from antioch.
@pbauman No, but I sorta abandoned it for the moment. I (probably) don't actually need reverse reactions, so I kept moving without them. But I am planning to go back and test a reverse reaction soon, I hope sometime this week. I'll let you know how it goes.
@SylvainPlessis I'm fine with the first three inputs you mentioned, but why shouldn't I be able to use the default Antioch thermo file? I want to do a simple reaction and I don't have other information about the species, i.e. I want to use standard thermo inputs. (It seems like the same could be true of the species characteristics file too.)
from antioch.
No, but I sorta abandoned it for the moment. I (probably) don't actually need reverse reactions, so I kept moving without them. But I am planning to go back and test a reverse reaction soon, I hope sometime this week. I'll let you know how it goes.
OK, cool.
And, sorry to speak for @SylvainPlessis (he can jump in at any time), but
I'm fine with the first three inputs you mentioned, but why shouldn't I be able to use the default Antioch thermo file?
The issue is that our default files (in share/antioch_default_files) don't have thermo information for all the species that are used in GRI 3. (Those defaults are from FIN-S, basically, and we only focused on species relevant to reentry, and not combustion). We could look into adding the missing GRI species to the default files. What @SylvainPlessis was suggesting was just use the files that are supplied for GRI 3. I.e. the kinetics, thermo, and transport. The ChemKin parser should understand those files and should just work. And if they don't please let us know. What you will need though, is the species characteristics for all the GRI 3 species, i.e. molecular weight, formation enthalpy, T-R dofs (1.5, 2.5, or 3.0 depending on whether the species is atomic, a linear molecular, or a nonlinear molecule, respectively).
I want to do a simple reaction and I don't have other information about the species, i.e. I want to use standard thermo inputs. (It seems like the same could be true of the species characteristics file too.)
So, you should have everything from the GRI 3 site, except the species characteristics. If you could identify which species we don't have in the default files, I can help you track down the values for each of those missing species so you can cook up a "GRI 3 species characteristics" file to parse.
from antioch.
BTW, @SylvainPlessis
If you use less than 4 files (or 3 if you declare your mixture with a vector), consider you're doing it wrong.
I don't agree with this comment, in general. Yes, if you're using an ASCII parser, then we have no choice, but we ought to be able to parse a single ChemKin file.
I do agree with the sentiment that it's better to supply input files to parse rather than relying on the defaults for simulation provenance.
Longer term, I'd prefer to have a single HDF5 file that we ship with all of this stuff in it and parse that (or have the user supply their own HDF5 file).
from antioch.
@pbauman Alright, thanks, that makes a lot more sense. (It makes sense to import GRI species files to use with the GRI mechanism.)
What about if I am just doing hydrogen combustion and all the species are already included in Antioch? Even if it's better to have total control with my own data, could I use the Antioch thermo files if I wanted to just explore general behavior of a (backwards) reaction without needing the most accurate answers?
from antioch.
Yeah, if we have the species in the default files, you should be good to go. One thing --- I need to verify the T-R dofs for H202 and HO2 (I say as much in the default file). That only comes into play if you're using StatMechThermodynamics
--- if you use IdealGasMicroThermo
(entirely reasonable for combustion), then it won't affect you.
(FYI: StatMechThermodynamics
uses gas dynamics formulas for computing the vibrational and electronic contributions to cp/cv (they are expensive to compute BTW). IdealGasMicroThermo
uses NASA fits (or whatever you supply) to compute the total cv/cp and then subtracts the translational+rotational cv/cp to get the vibrational cv/cp and neglects the electronic contributions. This makes sense for combustion since the temperatures aren't high enough to fully excite vibrational states nor excite any electronic states. This is not true for hypersonics.)
from antioch.
Awesome, and yes, I'd use the ideal gas thermo. Thanks!
from antioch.
Here's another question about forward and reverse reactions:
I have a reversible reaction with different forward and backward orders. In chemkin format, the reaction looks like this:
2H2 + O2 <=> 2H2O 4.45e21 -1.0 40.0
FORD/H2 1.5/O2 2.25/
RORD/H2O -1.0/
I noticed that changing these values in the 2nd and 3rd line doesn't have any effect on the output from Antioch. Is it possible to use different orders like this? (Also, I thought that standard chemkin format was okay, but maybe I missed something about how to formulate things.)
from antioch.
Going ahead and closing this. @beanSnippet feel free to reopen if this pops back up.
from antioch.
Related Issues (20)
- Hackothon todo list
- Test failing: kinetics_vec_unit_air_5sp HOT 15
- Check for "Scalar foo = bar;" initializations HOT 3
- API Consistency Between IdealGasMicroThermo and StatMechThermodynamics HOT 2
- Consolidate Testing Data into Classes
- Clean Up Testing Class Instantiations HOT 1
- Separate Vibrational and Electronic Data Parsing from ChemicalMixture constructor HOT 2
- Compute Species data from elements
- Implement XML parsing of transport data
- Cleanup ParserBase default implementations
- Add method to query thermo type in XML parser
- Respect efficiencies default in XML parser HOT 1
- XML Parser not converting ModifiedArrhenius (Kooij) to Arrhenius in Falloff Reactions
- Extend XML Parsing to Support Blottner, Sutherland Viscosity Data
- Refactor IdealGasMicroThermo
- Move NASA, Transport Species Data to ChemicalSpecies?
- Consolidate All Parsing Methods
- Update or Fix AsciiParser::species_list()
- Implement ChemKin Parsing of Transport Data
- Check Parsing Compatibility for Custom Molecular Weights
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from antioch.