libantioch / antioch Goto Github PK

We tagged 0.0.6 in order to be able to do concrete timing before and after using auto/decltype to aid in performance. #12 hit alot of that. @roystgnr - anything left along these lines? Should we start doing release preparation?

They're bloating what should be tarballs of a few megabytes into tarballs of a few dozen megabytes.

#7 had some discussion of using this for the VexCL interface, but there's plenty of other places we should be able to use it.

@roystgnr started down this road in the auto_decltype branch. Wanted to open this issue to track discussion.

@roystgnr, I just successfully built against 62c4bc9 using OS X clang (in c++11 mode). Correspondingly confirmed build failure with gcc 4.7.3 on OS X

In file included from ../../../master/src/transport/include/antioch/mixture_viscosity.h:33:0,
                 from ../../../master/src/parsing/include/antioch/blottner_parsing.h:34,
                 from ../../../master/src/parsing/src/blottner_parsing.C:33:
../../../master/src/core/include/antioch/chemical_mixture.h: In instantiation of 'class Antioch::ChemicalMixture':
../../../master/src/parsing/include/antioch/blottner_parsing.h:76:6:   required from 'void Antioch::read_blottner_data_ascii(Antioch::MixtureViscosity, NumericType>&, std::istream&) [with NumericType = double; std::istream = std::basic_istream]'
../../../master/src/parsing/src/blottner_parsing.C:43:26:   required from here
../../../master/src/core/include/antioch/chemical_mixture.h:253:3: error: too few arguments to function

For posterity, clang version is

Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

I'll build gcc 4.8.1 and post results from that as well.

I admit ignorance in what the ParticleFlux stuff is doing, but it is potentially taking away thread safety.

So *Mixture classes are intended to be "program constant" classes while *Evaluators are (intended to be) lightweight objects that are cheap to construct (from the *Mixture classes) so that we construct *Mixtures once and *Evaluators many times (e.g. once a thread is forked). However, at least in the case of Planet-INC/Planet_INC, the particle flux pointer is getting reset many times during the program lifetime and, in particular, will be reset by multiple threads at once leading to thread safety problems.

Is there anyway we can move the ParticleFlux business up to the KineticsEvaluator level? It looks like the ParticleFlux is being used to augment the reaction rate - can't we just do that in the KineticsEvaluator when the rate is actually used?

my locale defines comma as decimal separator and 'atof' does not parse anything after the '.' .
There is some suggestions here:
http://stackoverflow.com/questions/1333451/c-locale-independent-atof/1333534#1333534
What do you think about it?

Antioch needs to be able to treat chemkin input files. At this stage, it seems that the easiest way to do it would be to have a small app of the type chemkin2xml to generate the corresponding xml file from the chemkin input file.

I'll work on it starting Monday, it should not be very complicated, any thoughts about it welcome.

I'm wondering, would it be interesting to add options to that application? I'm thinking about unit conversion. Chemkin is defaulted to calories for instance, I personally prefer the SI system, so something of the sort chemkin2xml --convert-unit cal J could be interesting.

We ought to be able to instantiate a set of Antioch objects using DualNumber as the coefficient type and DualNumber (or some vectors of same) as the state type, and then get parameter sensitivities by reinitializing the independent parameter properly. Let's try that and get it into a (enabled-iff-metaphysicl) unit test.

We need a better parsing'n'check reading code for the kinetics. This is not urgent but on the TODO list.

We'll start with a paranoid checking, meaning if your kinetics inputs do not match exactly the requirements of the kinetics model, it'll crash yelling at you. The only tolerated error is the mixing between Kooij and Arrhenius, as it is quite usual (the code will still cry in that case, though).

Another API change possible here...

The current CEA curve fit is one case of the NASA polynomials, the question is, at the mixture and evaluator levels, do we keep the "cea" name?

A more correct name would be nasa_mixture and nasa_evaluator, then you define the type of polynomials you want (CEA or NASA) but that would make another API change.

By the way, those two models are indeed different polynomials, it is not only a question of generalizing the temperatures and the number of intervals; CEA being a NASA 9 polynomials, the "classical" (understand ChemKin, see for instance Berkeley combustion) one being a NASA 7 polynomial.

So?

We need to get gradient information out of Antioch. This will involve essentially take the form, d(outputs)/d(parameters), e.g. derivative of the species concentration with respect to a diffusion coefficient, for instance.

However, I need some help to proceed with this. In particular, I'm curious we are already forming a Jacobian elsewhere in Antioch, as well as knowing how much of Roy's AD infrastructure has already been incorporated into the codebase. Any help getting me on the appropriate track would be appreciated.

It can happen, specially in the Titan framework, that a rate constant is zero. Thing is, if you want the derivatives (differentiates? English is so unclear...) of the rate of progress with respect to concentrations, you go through the line
const StateType facfwd = Rfwd/kfwd; ( reaction.h, kfwd being the forward rate constant.

I can see two ways of solving it, and I prefer asking before deciding which is preferable:

• either calculating facfwd explicitely, no division but more operations,
• testing facfwd against zero.

The first way needs very few changes, initializing facfwd to one and multiply by val (lines 953 and 969), not too much overload of work for the processor.
I personally don't really like the second choice, I never appreciated comparing real numbers to zero, specially if we're not clear on the type, but I'll let someone else make the choice.

If the first choice is chosen, I'll pull request around 10 second after I aware of it.

Should we store strings and let the user create its own Antioch::Units object or should we create instances of Units and store pointers to them (or anything else)?

I think I favor the second choice, it'll be easy then if ever we want unit conditionning possible (I mean, if the user want another unit system than SI internally)

If b = 0.0 in the input, Antioch starts to convert to Kooij, but doesn't finish the job. @SylvainPlessis, please have a look.

Wouldn't it be a good time to create a dev branch? I am putting this as I just commited a new test and a bugfix for my last pull (constant rate constant model). I'd feel more confortable if there would be a dev branch between the pull requests (at least mine) and the reference branch.

Adding Travis-CI support shouldn't be too bad. See https://github.com/RhysU/ar/blob/master/.travis.yml for an example YML file. You might add the gcc and clang compilers per http://about.travis-ci.org/docs/user/languages/cpp/.

The test for the kinetics theory models uses values from Antioch at long double precision.

It's delicate to have a golden value from somewhere else because of the spline evaluation of the Stockmayer potential. One workaround is to cook up a molecule with dipole moment and Lennard-Jones parameters such that we evaluate the spline on nodes.

For this workaround we need the reduced dipole moment and the reduced temperature to be on node. See the model documentation (Stokmayer potentials section) for details on these values.

1. GSL should be optional - I got a configure error when trying to configure without GSL.
2. Adding GSL, make check is failing to build the spliner test correctly. Probably not passing all the flags correctly.

Will get to this after AnitochCon2015 is over with...

I've seen the above error message when linking together multiple objects built with Antioch. I suspect the problem is that get_antioch_version() is not declared static.

The efficiency is set by default to 1.0, and only the explicitly given efficiencies can be changed. So if ever (for some reason I cannot understand), someone wants an efficiency default different than 1, it's not possible.

Though I would consider it weird practice to use a non-unity default efficiency, it could be interesting to add a set_efficiency_default(const StateType & default);, if only to give some sense to the default="1.0" meta-data in the xml input file.

It should not be done before #24 is merged.

Hit this with Sutherland. It happily gave me N2 and did not scream that it didn't populate the other species in the requested species_list. That's not very nice.

Doxygen front page and others were copied over from another package. Needs to be updated and made relevant.

I just ran methane combustion with grimech30. When all reactions are set as irreversible, the output makes sense: heat release and ignition time (about 10e-4 sec) are close to other sources. However, if all reactions are set to be reversible, then the code does something very different. The overall reaction becomes endothermic and temperature drops to zero in about 10e-10 sec. Maybe something is up with computed reversible rates?

We want to have a class ParserFactory is an excellent candidate to take care of the current type of code

ParserBase<CoeffType> * parser(NULL);
switch(type)

This class should take a ParserBase in its constructor and send back the correct version of the pointer.

Doesn't really test much, only the underlying quantities needed for viscosity. We need to at least add "gold standard" values and be testing those.

Dudes! Attempting to compile third-party sources with Antioch headers without linking libantioch.la dies with missing tinyxml symbols. Consequently this doesn't seem like a header-only library...?

This shouldn't be required in src/Makefile.am...

#----------------------------------------------
# List of source files to build dynamic library
#----------------------------------------------
libantioch_la_SOURCES =

# core
libantioch_la_SOURCES += core/src/chemical_species.C
libantioch_la_SOURCES += core/src/chemical_mixture.C

# kinetics
libantioch_la_SOURCES += kinetics/src/reaction.C
libantioch_la_SOURCES += kinetics/src/reaction_set.C
libantioch_la_SOURCES += kinetics/src/kinetics_evaluator.C
libantioch_la_SOURCES += kinetics/src/kinetics_type.C

# parsing
libantioch_la_SOURCES += parsing/src/tinyxml2.cpp
libantioch_la_SOURCES += parsing/src/read_reaction_set_data_xml.C
libantioch_la_SOURCES += parsing/src/blottner_parsing.C
libantioch_la_SOURCES += parsing/src/sutherland_parsing.C
libantioch_la_SOURCES += parsing/src/cea_thermo_ascii_parsing.C
libantioch_la_SOURCES += parsing/src/species_ascii_parsing.C

# thermo
libantioch_la_SOURCES += thermo/src/cea_curve_fit.C
libantioch_la_SOURCES += thermo/src/cea_thermo.C
libantioch_la_SOURCES += thermo/src/stat_mech_thermo.C

# transport
libantioch_la_SOURCES += transport/src/wilke_mixture.C

# utilities
libantioch_la_SOURCES += utilities/src/antioch_version.C
libantioch_la_SOURCES += utilities/src/input_utils.C

and even if it is, then definitely under tests/Makefile.am

LDADD = $(top_builddir)/src/libantioch.la

shouldn't be required.

This comes up because the Sysnet modules are installed as if compiler-independent but the installed lib/libantioch.la shows a compiler-version-dependent standard library requirement. This has subtly broken builds using mismatched compilers. E.g. Suzerain with GCC-4.6 atop Antioch installed via GCC-4.8.

I'm getting some strange output while trying to use reset_coefs(). I will try to give you all the relevant pieces.

This is the line in my code, where i is an unsigned int and newValues is a standard vector of doubles:

reaction_set.reaction(i).forward_rate().reset_coefs(newValues);

This is (part of) the compile time error:

/workspace/rebeccam/bin/antioch-kin_reset/include/antioch/kinetics_type.h:398:86: error: passing ‘const Antioch::KooijRate’ as ‘this’ argument of ‘void Antioch::KooijRate::reset_coefs(const VectorCoeffType&) [with VectorCoeffType = std::vector, CoeffType = double]’ discards qualifiers [-fpermissive]

It also returns the same error for all the other rate types (even though I'm not using them). I know that the test passes, so I'm not sure where the problem is. But here is some speculation: the method in reset_coefs is not const, but kinetics_type.h returns a const object of type KooijRate. However, in the test, KooijRate is not defined as a const, so it still works there.

See here.

Would be nice to have an (configure optional? runtime optional?) extrapolation capability for CEA quantities. Right now, I trip asserts on some that are only fit unto 6000K, but it's early in a Newton iteration and if I run in opt mode, the extrapolation is good enough to get me where I want to go.

It would be really great if Antioch's doxygen pages were up online.

In libMesh we have a simple test script that compiles

#include <libmesh/foo.h>
int main(void) { return 0; }

for each foo.h

This verifies that each header includes all the dependencies it needs.

I'm not sure that script would be as useful here, since a lot of real checks on template code don't happen until they're instantiated. We might be stuck with creating manual tests for each file, to include the file and instantiate the class(es) within.

@ddemidov pointed out the following in #149:

Is it possible to disable specific tests based on environment variables (There is TRAVIS=true for example)?

I bet we could add some sauce to the configure checks. Say check for TRAVIS in the environment and AC_DEFINE(IS_TRAVIS). Further, check the value of CC and AC_DEFINE(IS_CLANG). Then, we could do the usual automake workaround and skip whatever tests are killing Travis during make check. This way, we'd still run all the tests with GCC+VexCL and get some Clang+VexCL. But would lose the coverage of Clang without VexCL. Maybe two different builds - one with VexCL and one without?

I'm dense and don't know what s/foo/bar/g I need to run to placate the following message

An equation of the form "A * (T/Tref)^beta * exp(-Ea/(R*T))" is a
Kooij equation,
I guess a modified Arrhenius could be a name too.  Whatever, the
correct label is
"Kooij", or, << à la limite >> "ModifiedArrhenius".  Please use those
terms instead,
thanks and a good day to you, user.

which mucks up my otherwise pleasantly crisp test logs.

The offending files are presumably https://github.com/RhysU/suzerain/blob/master/apps/reacting/data/air_13sp.xml and/or https://github.com/RhysU/suzerain/blob/master/apps/reacting/data/air_5sp.xml.

How far back in the Antioch releases is this change backwards compatible?

This line, when StateType is vex::vector<T>, should probably initialize a vector of some size with values of 0.14. Instead, it calls vex::vector(size_t) constructor, which creates a vector of size size_t(0.14) == 0.

Found this while compiling kinetics_regression_vec with clang (clang shows a warning here).

Look at the original paper and if it has additional species and molecules, add them.

We should have an examples folder. Examples would be (basically the tests):

• kinetics regression with transport with given temperature/pressure, vectorized and not,
• kinetics/transport reset examples,
• reading using the different parser available.

What should be showed:

• how to set/reset everything (the order and dependancies of objects, how-to for parsers),
• how to extract physical quantities (chemical rates, transport rates, chemical heat)

I'm starting this, I'll populate this thread with more detailed messages before I start on an example. Any request/suggestion is welcome.

As of now Antioch only supports partial rate constant formalism, considering every reaction independent. This is correct only in the case of independent information about the reaction, which is not always the case.

So it is only natural that Antioch should be able to handle branching ratios. Basically this is but adding a CoeffType _branching_ratio parameter in a Reaction object and multiplying the rate constant's value by it.

This parameter must be unity by default, and in the case of a reaction with branching ratios, a check a the reading step should be performed for consistency, meaning that the sum of the branching ratios is indeed one.
It raises one question, what if one channel's got a molecule that is filtered? Do we renomalize the other branching ratios, or the global rate constant, or do we suppress the whole reaction? Another solution would be to have a well channel, to ensure consistent loss rate of the reactants and production rate of the products no matter what, but frankly, even if it is the most data consistent method, it looks a little ugly...

As per the discussion in #44 we would like to introduce Antioch::shared_ptr to clarify memory management of certain Antioch classes. This would be a shim around std::shared_ptr falling back on boost::shared_ptr or tr1::shared_ptr if necessary. If anyone objects to Antioch requiring C++11-or-Boost, speak up now.

It'll soon be time to worry about this. We need something much more easy-to-play-with/reliable/performant than xml, and HDF5 is wonderful, specially in view of #41.

Should also there be some xml to HDF5 and HDF5 to xml capability in the form of an application or this is the user's problem?

We need to decide once and for all how Antioch deals with unit. My targets include R, molecular weights, pre-exponential parameters, activation energy, concentration and mass. If we go to SI, it means we should use mol,kg,m3 and s. Right now only the mol unit is not respected, kmol is used instead.

Changing to ``pure'' SI would require to change R and molecular weight (I think there are the only ones) and to treat accordingly the input kinetics parameters. The state is, at that point:

• the pre-exponential parameter is in m3/kmol/s if the unit is not provided,
• the activation energy is in cal/mol/K (international table calorie, for those who knows the problem with calorie) when not provided,
• the mass is in kg,
• R is in J/kmol/K or cal/kmol/K, there does not seem to be a clear convention here,
• molecular weight in g/mol, or kg/kmol.

Changing to ``pure'' SI would make life a lot easier to anyone who needs an intermediary parameter value, the unit would be obvious. I cannot really see any downside to it, except that it'll need a bit more code. Also, the unit of a parameter should be within the object (basically, kinetics object will store one or several unit). How do we do that? Should we store strings only and let the unit processing be a read-only method (thus happen outside the object) or do we store a pointer to an unit object to be able to change the unit of the parameter itself? My opinion on this is that the latter option is too dangerous, there is (and will not be) any unit check in this level of the code for performance reasons. Changing the unit of an internal parameter could lead to wrong results.

In brief, we need to:

• Send an error message when the input file does not provide unit
• Set all the internal parameters to SI (yes/no?)
• Store the unit of parameters (string/pointer to unit object?)

The ChemKin version is const (out of necessity I see) leading to warnings that the base wasn't. However, as the XML version is coded right now, it can't be const. @SylvainPlessis, anyway to make this const on the top of your head before I dig through the code? This was the last warning for me to clear up.

There's some two-temperature model support here and there, but it's incomplete. The thing that will make this hard is what the general API should look like, i.e. do we want to try and support three and four temperature models (more??)?

I would like to change parameters (A, \beta, E) within reaction_set. I still want to use the standard input file to initially read and create the reaction mechanism, but then I want to be able to change the parameters to do calibration. @SylvainPlessis, I heard you might be interested in providing this functionality?

Although cantera-style .xml files can have more than one reactionData section, Antioch currently only reads the first section in the file. This doesn't actually affect anything that only has one section, but it would be a good capability to restore for future compatibility.

We want to enhance antioch to fully support the reaction chemistry in S3D. Using Jackie Chen's paper on S3d as a model document, we the following capabilities:

• Mixture-averaged diffusion coef. determined from binary diffusion coef and the mixture composition.
• Only treat (N-1) species, with the last coming from constraint (e.g. \sum Y_i = 1)

S3D assumes an ideal gas mixture, so the equation of state is all set. I need to read through the documentation more carefully, and then will propose Antioch files to modify.

Looks like we have species cv there, but not cp. Would be useful to have in the API. @nicholasmalaya volunteered to implement this.

Antioch should have stored only the atoms' mass, not the molecules. Molecules's mass should be calculated by atom decomposition, it would make the process of adding species soooo much easier and less prone to errors.

I'll do something about it sometimes in the not-too-far futur.

The KineticsEvaluator object should be able to produce the production and loss terms of a species' rate.

This is a trivial thing to add, the only concern is technical, I need the Unit pull request (#24) to be merged first for the test regression value, the nice R value that changes to 10^-6 between the cal/mol value and this very same value when computed from J, so the test won't crash when merging it.

So basically, once the unit branch is merged, this will be a following pull request.

I'm putting this here to be sure I won't forget it.

The VectorCoeffType type is required for photochemistry. It is defined in read_reaction_set_data.h at line 430. The type of the data defined at that line is the VectorCoeffType and is std::vector<CoeffType>, using the CoeffType denomination.

The chain of template inheritance is:

KineticsType<CoeffType,VectorCoeffType = std::vector<CoeffType> > ----> Reaction<CoeffType, VectorCoeffType = std::vector<CoeffType> > --////--> ReactionSet<CoeffType> --////--> KineticsEvaluator<CoeffType,StateType>

VectorCoeffType custom definition stops at ReactionSet<CoeffType> as it contains a std::vector<Reaction<CoeffType>*>.

So we need to finish the template inheritance with ReactionSet and KineticsEvaluator.
One consequence will be that read_reaction_set_data will require to be templated around VectorCoeffType too.

Once the template inheritance chain is done, VectorCoeffType will be defined by the declaration of ReactionSet and KineticsEvaluator, and the world will be a better place.

I get the follow error for the xml file that I'll post here when I try and use Antioch kinetics.

/fry1/data/shared/software/libs/antioch/master/gcc/4.8.4/gsl/1.16/include/antioch/read_reaction_set_data.h, line 188, compiled Mar  5 2015 at 09:14:13
terminate called after throwing an instance of 'Antioch::UnitError'
  what():  Error in reaction O + O [=] O2
Ea parameter's unit should be homogeneous to "J/mol", or "K" and you provided "K"
Aborted (core dumped)

This requires ddemidov/vexcl@36300ff to be of any use, but would be backwards compatible. Should help us make sure we're only copying vectors when we mean to be.

@SylvainPlessis

Here

You are passing c*M_s, i.e. molar density times species molar mass. What is that? Cross checking the documentation with the thermal conductivity implementation, it looks like you want species mass density, i.e. \rho_s. That is not c*M_s; that is, for example, rho* Y_s (or whatever symbol we're using for mass fraction). I actually put rho*Y_s in and the thermal conductivity gold value failed in wilke_evaluator_unit, but using c*M_s, as you have it now, the test passes.

So what should it be? I'm going to press forward with rho*Y_s, but I wanted to get confirmation from you here.

Once I have confirmation, I'll put in a PR with the correction and rebase my transport-refactor branch.