write_hdf() inconsistent cols=[] argument behavior for one_dim flames

[kahilah]

Dear developers and community members.

I noticed inconsistent behavior when using write_hdf function for one-dimensional flame objects. By default, the function writes density, temperature and molar fractions into an hdf5 file. However, while for the SolutionArray object one can give extra columns ( cols=('T', 'P', 'X')) as an argument, this is not accepted when write_hdf is called for a flame object.

Below an example which shows the failure. On the last lines I have also added working examples via solution array approach.

I think this is a matter of re-defining the function argument behavior in onedim.py

Below an example which reproduces the error, i.e. use of cols=[] argument in f.write_hdf() is not recognized as it is done in the SolutionArray variant.

import cantera as ct
import numpy as np

# Simulation parameters
p = ct.one_atm  # pressure [Pa]
Tin = 300.0  # unburned gas temperature [K]
reactants = 'H2:1.1, O2:1, AR:5'  # premixed gas composition
width = 0.03  # m
loglevel = 0  # amount of diagnostic output (0 to 8)

# IdealGasMix object used to compute mixture properties, set to the state of the
# upstream fuel-air mixture
gas = ct.Solution('h2o2.xml')
gas.TPX = Tin, p, reactants

# Set up flame object
f = ct.FreeFlame(gas, width=width)
f.set_refine_criteria(ratio=3, slope=0.06, curve=0.12)
f.show_solution()

# Solve with mixture-averaged transport model
f.transport_model = 'Mix'
f.solve(loglevel=loglevel, auto=True)

# NOT WORKING
f.write_hdf("test.h5", cols=('T', 'P', 'X'), group="myGroup",  mode='w')

# WORKS without cols:
#f.write_hdf("test.h5",  group="myGroup",  mode='w')

# WORKS via solutionArray and cols
#arr = f.to_solution_array('flame')
#arr.write_hdf("test.h5", cols=('T', 'P', 'X'), group="myGroup",  mode='w')

System information

• Cantera version: dev-version via conda
• OS: Centos 7
• Python

[ischoegl]

@kahilah ... this is indeed not implemented at the moment. While the method names are the same, the objects that are saved to HDF are quite different. In a nutshell, the onedim variant converts each of the domains that constitute the object to a SolutionArray, which are saved together. As the original intent was to recreate the onedim object, other columns are not necessary. Please also note that the to_solution_array method picks only one of the three domains, I.e. the generated HDF files are not equivalent.

It would help to know what you’d like to accomplish by adding the cols parameter. It’s likely not a major change though ...

[kahilah]

Thanks for clarification. When I noticed this, I was after saving a pressure variable in the domain (or on boundary) and at that time I realized that it was not available, while temperature and density were available as they are hard-coded. Of course, pressure does not change accross the flame in this example but I wanted to include information on P to later e.g. plot a bunch of flames run with different pressure levels.

[ischoegl]

Thanks for the background - in that case I'd recommend to just code the pressure into the group name. Pressure can of course be easily obtained from a onedim object after it is restored ... while I wrote the HDF export/import, I'll let the maintainers chime in as I don't view the current behavior as a bug.

[kahilah]

I agree with you, this is not a bug as such but more like a note about inconsistency. And indeed the easiest way ist to write new groups/datasets whenever required.