Supporting YAML format for thermochemistry data

[mbkumar]

Currently OpenMKM is based on Cantera 2.4. The newer version, Cantera 2.5, supports YAML format to specify the thermochemistry data. This is easy on the eye compared to the XML format. There is also an added advantage of not having to work with CTI file and the associated conversion.

Things to do:

1) Generate YAML file from pMuTT conforming to dict format required by Cantera for terms already supported by Cantera. 2) Rebase openmkm branch of Cantera to incorporate updates from upstream 3) Support YAML format for thermochemistry inside OpenMKM 4) Define YAML format for BEP and lateral interactions 5) Support BEPs and lateral interactions to be read from YAML file inside Cantera 6) Implement the associated code in pMuTT (as part of 1) for BEPs and lateral interactions

Handlers:

Task-1: Jon Task-2: Bharat, Task-3: Bharat Task-4: Bharat, Jon, and Gerhard Task-5: Bharat Task-6: Jon.

Reference: https://cantera.org/tutorials/yaml/defining-phases.html

[jonlym]

I support using YAML for thermo. The CTI format required a lot of text processing.

For task 4, I think the format we had for BEPs worked well (i.e. id, slope, intercept, direction, cleavage_reactions, synthesis_reactions). For lateral interactions, are we assuming users define them pairwise, a matrix, or either? I think the pairwise approach is more flexible.

[mbkumar]

For lateral interactions, I am thinking to for the matrix format. Though pairwise approach is flexible, I haven't seen anyone using more than one slope. The physics also dictates that the interaction terms should be symmetric for the two species involved.

On Tue, Mar 31, 2020 at 12:36 PM Jonathan Lym notifications@github.com wrote:

I support using YAML for thermo. The CTI format required a lot of text processing.

For task 4, I think the format we had for BEPs worked well (i.e. id, slope, intercept, direction, cleavage_reactions, synthesis_reactions). For lateral interactions, are we assuming users define them pairwise, a matrix, or either? I think the pairwise approach is more flexible.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/VlachosGroup/openmkm/issues/12#issuecomment-606738816, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA62VEHM5TTR4UPE23BJGYTRKILXTANCNFSM4LXT5RXA .

--

Bharat Medasani

Computational Scientist Delaware Energy Institute University of Delaware

[jonlym]

@mbkumar, the adsorption reactions that we use were created in OpenMKM, right? If so, we should add that to our list for tasks 4 and 5.

[mbkumar]

@jonlym and @wittregr The tasks 2-5 are completed. @jonlym Adsorption reactions are defined in Cantera. We don't have to do anything for adsorption reactions.

[mbkumar]

I am closing this, since work on OpenMKM is completed.

[jonlym]

Hi Bharat,

I read over the documentation and I have a couple of questions:

1. For the reactions and interactions keys in the phase dictionary, is "all" used when all declared reactions in the YAML file are on that phase and "declared-species" used when only some of the reactions are over that phase? Also, does this mean I do not need to keep track of IDs anymore?

2. For surface phases, do we not have to specify the interacting phases anymore (e.g. gas and bulk)?

3. Is the state key required for phases? If it's being overwritten by the value in reactor.yaml anyway, can we omit it?

[mbkumar]

Hello Jon,

Please find my responses inlined below.

On Thu, May 14, 2020 at 2:24 PM Jonathan Lym notifications@github.com wrote:

Hi Bharat,

I read over the documentation and I have a couple of questions:

1.

For the reactions and interactions keys in the phase dictionary, is "all" used when all declared reactions in the YAML file are on that phase and "declared-species" used when only some of the reactions are over that phase? Also, does this mean I do not need to keep track of IDs anymore?

Yes. With YAML input format, the way the data is read is changed.

1. 2.

For surface phases, do we not have to specify the interacting phases anymore (e.g. gas and bulk)?

There is no option in YAML to give that data. But the code internally expects it. This again refers to point 1, that the way data read is changed. That dependency has to be given manually. At present we have one gas phase and one bulk phase at max, which are used for all the surfaces. We may have to slightly rethink this if different surfaces have different bulk phases.

1. 2.

Is the state key required for phases? If it's being overwritten by the value in reactor.yaml anyway, can we omit it?

state key is optional. If not supplied, default value of T=298.15 K and P=1 Atm are used. Its better to omit the state keyword.

1.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/VlachosGroup/openmkm/issues/12#issuecomment-628809262, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA62VEENOYUKS5UQJIKPFQDRRQZMNANCNFSM4LXT5RXA .

--

Bharat Medasani

Computational Scientist Delaware Energy Institute University of Delaware

[jonlym]

Thanks! These changes actually made it a lot easier for pMuTT to write the input files.