Skip to content
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

Upgrade/sensitivity #142

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

SylvainPlessis
Copy link
Contributor

Same remark for the tag than the get/set PR. This is a work in progress, but quite big so it comes slowly and progressively.

This is the first implementation of the derivative with respect to parameters for the kinetics. Except for the photochemistry, all models have the sensitivity_*PARAMETER* implemented, both with the StateType T and the KineticsConditions cond version. To limit overloading, I've also added a structure, return_type<T>. This returns T except if T is a KineticsConditions object, in which case it returns a StateType.

So this enables to have two fork methods for every kinetics models:

typename return_type<InputType>.::type
  operator(const InputType & T) const {return this->rate(T);}

typename return_type<InputType>::type
  sensitivity(const InputType & T, KineticsModel::Parameters parameter) const;

The used methods within theses (rate and sensitivity_*PARAMETER*) are overloaded to enable both versions of the temperature. A good idea for the future would be to use a similar design for derivative.

temperature and a KineticsConditions object.

This structure will probably be useful as the KineticsConditions object
will be generalized.
  - operator() is using return_type<> so it does not need to be overloaded
  - sensitivity() same remark, plus all the sensitivity methods added
… and in the

non F part (falloff, three body falloff)
  - forward rate
  - equilibrium constant
  - backward rate
  - rate of progress

This requires overloading for
  - kinetics parameters
  - chemical process parameters
  - thermo parameters
…ole rate sources and

rate of progress are treated.

Let's note also that there is yet no string-to-enum considerations, only enum
at this point.
@SylvainPlessis
Copy link
Contributor Author

Alright I'm almost there (tests not considered…). Everything's in place for kinetics but only with the enum. I need to know exactly how the strings will be passed to Antioch for this. This computations will be heavily performed, so passing a string to KineticsEvaluator to perform string-to-enum operation does not sound a good idea…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant