Interfaces in YAML input files

[David Schmider]

Hi all,

currently I'm trying to make our in-house code ready to work with YAML input files. The in-house code is written in C++ and so far relied on CTI/XML input files. It has a wrapper which is mainly responsible for the handling of Cantera input files.

One point I'am struggling with is the definition of interfaces in YAML input files. CTI files have the "phases" field and XML files have the "phaseArray" attribute, which both specify the adjacent bulk phases that are part of the interface.

When I use the cti2yaml/ctml2yaml converters on previously used input files, that also defined interfaces, I can't find any corresponding entries in the YAML output files specifying the adjacent bulk phases.

So far, the wrapper searched for the "phaseArray" entry in the xml files, saved the names of the adjacent bulk phases and passed those names to the constructor of the interface. I'm wondering how to get this information out of a YAML input file.

Many thanks in advance for your kind help!

Best regards,

David

[Steven DeCaluwe]

Hi David,

So one change with the YAML interface format is that you do not need to provide information on these “adjacent phases” as part of the input file.

The constructor is able to determine the required phases from the reaction strings.  If a phase does not participate in any reactions associated with that interface phase, then it is not actually required. 

Best,

Steven

--
You received this message because you are subscribed to the Google Groups "Cantera Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cantera-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cantera-users/7967fcf9-8c37-4017-9295-bebc04904436n%40googlegroups.com.

[Bryan Weber]

Hi David,

In addition to Steven's response, if you absolutely need to list the adjacent phases for other reasons, Cantera's YAML parser is pretty flexible and ignores any keys it doesn't know about. So you can create a new key that maps the adjacent phases to each other and add it to the file manually after the CTI/XML->YAML conversion.

Best,

Bryan

[David Schmider]

Hi Steven, hi Bryan,

thank you for your answers. Sounds like it should be easier to setup an interface phase then.

Nevertheless I'm getting an error:

Error in canteraWrapper_init(): Could not import interface >interface_LCO< from Test_inputfile.yaml

*******************************************************************************

CanteraError thrown by addReactions:

*******************************************************************************

InputFileError thrown by Reaction::checkSpecies:

Error on line 645 of ./Test_inputfile.yaml:

Reaction 'Li+[electrolyte] + V[LCO] + electron <=> Li[LCO]'

contains undeclared species: 'Li+[electrolyte]', 'V[LCO]', 'electron', 'Li[LCO]'

|  Line |

|   640 |   rate-constant: {A: 8.83836e+14, b: 0.0, Ea: 77.05475194 kJ/mol}

|   641 |   exchange-current-density-formulation: true

|   642 |   beta: 0.5

|   643 |

|   644 | interface_LCO-reactions:

>   645 > - equation: Li+[electrolyte] + V[LCO] + electron <=> Li[LCO]  # Reaction 2

            ^

|   646 |   id: LCO_reaction

|   647 |   rate-constant: {A: 8.20006e+12, b: 0.0, Ea: 72.32465359 kJ/mol}

|   648 |   exchange-current-density-formulation: true

*******************************************************************************

*******************************************************************************

Actually, the species have been defined before by initializing the corresponding phases before that interface. I am using the constructor 

Cantera::newSolution
(
const std::string & 
infile,

const std::string & 
name = "",

const std::string & 
transport = "",

const std::vector< shared_ptr< Solution >> & 
adjacent = {} 
)

without passing this adjacent vector, since this isn't needed with yaml. Am I using a wrong constructor?

Best regards,

David

[Steven DeCaluwe]

Hi David,

While you do not need to define the adjacent species in the yaml input file, you do still need to pass the instantiated phase objects to the constructor. 

I haven’t done this in C++ and am in the middle of a lake right now 😂, but when I’m back on dry land I’ll try and hunt down a C++ example for you. Looking at other test files is probably the easiest way to find one. 

Best,

Steven

Sent from my iPhone

On Aug 11, 2021, at 6:50 AM, David Schmider <divad.s...@gmail.com> wrote:

Hi Steven, hi Bryan,

To view this discussion on the web visit https://groups.google.com/d/msgid/cantera-users/a5396e28-fde2-47a1-922f-aff0a2638657n%40googlegroups.com.

[David Schmider]

Hi Steven,

sounds like I need to define a custom key in the input files, like Bryan has already suggested, to tell my wrapper which are the adjacent phase objects.

I'll try this out.

Thanks for your support.

Best,

David

[Ray Speth]

Hi David,

The old phaseArray XML node was never used internally by Cantera, except to require that the adjacent phases were present and had the specified names, which wasn’t that useful. So that’s why it was initially left out of the YAML format. However, I’ve been considering a revision to introduce an equivalent field to the YAML format, that would be similar to the functionality it seems like your code uses, that is, to allow the user to specify the name of the interface phase to import, and then have Cantera automatically import the adjacent phases. You can see the enhancement proposal here: https://github.com/Cantera/enhancements/issues/103. If you follow the format suggested there and access the adjacent-phases list from the first phase’s input AnyMap, your usage should be compatible with the future implementation of this enhancement.

Regards,
Ray

​

[David Schmider]

Hi Ray,

thanks for your hint. I solved it as you proposed with a key named adjacent-phases, which I add manually to the interface phases in the yaml input files after conversion from CTI. 

Now our code can properly import all phases from yaml input files. Nevertheless I had some further problems getting our code to work correctly and it took me quite a while to figure out what was wrong:

There seems to be one major difference between yaml and CTI/XML concerning the definition of the Kinetics Objects. With yaml, the species of the interface phase hosting the reactions are added first into Kinetics species array. With CTI/XML, they are added in the end. As our code worked only with CTI/XML before, the assumption of finding the interface species at the end of this array was hard-coded, and therefore messing things up now that the input file type was changed to yaml. Knowing that, it was easy to fix, so now everything works fine.

Maybe this information is useful to someone also switching to yaml input files.

Best,

David