Incorrect temperature ranges in nasa_condensed data

[speth]

Problem description

Some of the species in the nasa_condensed.yaml file specify temperature ranges for the NASA polynomials that are not monotonically increasing, leading to some unexpected results.

Steps to reproduce
For example:

- name: Fe(c)
  composition: {Fe: 1}
  thermo:
    model: NASA7
    temperature-ranges: [1000.0, 1665.0, 1000.0]
    data:
    - [61.010999, -0.160945061, 1.68369493e-04, -7.74563702e-08, 1.3309129e-11,
      -1.65335454e+04, -313.710668]
    - [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

Consistent with such a definition, the species reports that both the min and max temperature for the phase is 1000 K. The first polynomial is used below the "middle" temperature, and the second polynomial is used above.

>>> Y = {s.name: s for s in ct.Species.list_from_file("nasa_condensed.yaml")}
>>> Y["Fe(c)"].thermo.min_temp
1000.0
>>> Y["Fe(c)"].thermo.max_temp
1000.0
>>> Y["Fe(c)"].thermo.cp(900)
39960.63009984842
>>> Y["Fe(c)"].thermo.cp(1100)
34006.03123840939
>>> Y["Fe(c)"].thermo.cp(1700)
0.0

This error in the temperature ranges is a result of strange temperature ranges being specified in the nasa_condensed.cti file:

species(name = "Fe(c)",
    atoms = " Fe:1 ",
    thermo = (
       NASA( [ 1184.00,  1000.00], [  0.000000000E+00,   0.000000000E+00, 
                0.000000000E+00,   0.000000000E+00,   0.000000000E+00,
                0.000000000E+00,   0.000000000E+00] ),
       NASA( [ 1000.00,  1665.00], [  6.101099900E+01,  -1.609450610E-01, 
                1.683694930E-04,  -7.745637020E-08,   1.330912900E-11,
               -1.653354540E+04,  -3.137106680E+02] )
             )
    # note = "J 3/78"
       )

However, the behavior is slightly different:

>>> C = {s.name: s for s in ct.Species.listFromFile("nasa_condensed.cti")}
>>> C["Fe(c)"].thermo.min_temp
1184.0
>>> C["Fe(c)"].thermo.max_temp
1665.0
>>> C["Fe(c)"].thermo.cp(900)
0.0
>>> C["Fe(c)"].thermo.cp(1100)
34006.03123840939
>>> C["Fe(c)"].thermo.cp(1200)
33941.28191262115
>>> C["Fe(c)"].thermo.cp(1300)
34649.86510008518
>>> C["Fe(c)"].thermo.cp(1800)
40037.53067186088

Based on files that were present in the repo at the time this file was originally introduced, it appears to have been generated from a CK-format input that specified the species as:

THERMO NO_TMID
 300.0   1000.0   5000.0
...
Fe(c)             J 3/78FE 1.   0.   0.   0.C  1184.000  1665.000     55.84700 1
 6.10109990E+01-1.60945061E-01 1.68369493E-04-7.74563702E-08 1.33091290E-11    2
-1.65335454E+04-3.13710668E+02 0.00000000E+00 0.00000000E+00 0.00000000E+00    3
 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00    4

Besides the "NO_TMID" declaration, which I've never seen before, this file is identical to the one hosted by Caltech's Explosion Dynamics Laboratory at https://shepherd.caltech.edu/EDL/PublicResources/sdt/SDToolbox/cti/NASA7/nasa7.dat.

I don't know that there's ever been a version of ck2cti that can handle this format where the last value in the first line is the molecular weight rather than the mid temperature. ck2yaml somewhat predictably writes this value as the mid temperature, e.g.:

- name: Fe(c)
  composition: {Fe: 1}
  thermo:
    model: NASA7
    temperature-ranges: [1184.0, 55.84, 1665.0]
    data:
    - [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    - [61.010999, -0.160945061, 1.68369493e-04, -7.74563702e-08, 1.3309129e-11,
      -1.65335454e+04, -313.710668]
    note: J3/78

Interestingly, the EDL page also has another file, https://shepherd.caltech.edu/EDL/PublicResources/sdt/SDToolbox/cti/NASA7/nasa7mod.dat, where the mid temperature has been inserted for each species, except for those where there is only one valid temperature range, and the description specifically says that it is "useful for generating Cantera .cti files by converting Chemkin-style input files". In this file, the entry for Fe(c) looks like:

Fe(c)             J 3/78FE  1    0    0    0S  1184.000  1665.000              1  
 6.10109990E+01-1.60945061E-01 1.68369493E-04-7.74563702E-08 1.33091290E-11    2
-1.65335454E+04-3.13710668E+02 0.00000000E+00 0.00000000E+00 0.00000000E+00    3
 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00    4

Of course, this has several formatting errors that have to be corrected before ck2yaml is happy, at which point we end up with:

- name: Fe(c)
  composition: {Fe: 1}
  thermo:
    model: NASA7
    temperature-ranges: [1184.0, 1000.0, 1665.0]
    data:
    - [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
    - [61.010999, -0.160945061, 1.68369493e-04, -7.74563702e-08, 1.3309129e-11,
      -1.65335454e+04, -313.710668]
    note: J3/78

which doesn't seem quite right, either.

System information

• Cantera version: 2.6.0b2 / e7b931b

[bryanwweber]

McBride's report from 1993 shows that the last column should be Molecular weight, page 9 here: https://shepherd.caltech.edu/EDL/PublicResources/sdt/refs/NASA-TM-4513.pdf (finally found the NASA NTRS page for it, https://ntrs.nasa.gov/citations/19940013151. Joe's site ranks higher in Google 😄 )

and that the implicit midpoint temperature is 1000 K. As usual, the first 7 coefficients are for the high-temperature range, but it appears that the "high-temperature range" is defined as ">= 1000 K" in the table on page 9, implying that if the minimum temperature in the first line is >1000 K, and the "low-temperature range" is all zeros, then the minimum temperature is as specified and not at 1000 K.

It appears that report is also the original source of the data in the file, Table 2 starting on Page 10.

[speth]

I don't think Cantera's aim has ever been to convert the NASA format though, but to convert the Chemkin format, where these columns are specified to contain "Common temperature (if needed, else blank)". In the EDL "modified" file, there are a couple of entries where the max temperature is less than 1000 K, for example:

C6H5NH2(L) anilin P 6/90C   6H   7N   1    0L   298.150   552.000  552.        1  
 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00    2
 0.00000000E+00 0.00000000E+00-2.51374023E+02 2.85261227E+00-1.11414497E-02    3
 1.93994205E-05-1.26299216E-08 1.80035120E+04 9.53411670E+02 3.78871828E+03    4

Here, the common/mid temperature is set the same as the max, and the high temperature coefficients are just zero. For cases where the min temperature is greater than 1000 K, the format seems to be to omit the mid temperature, with the low temp coefficients set to zero:

Fe(c)             J 3/78FE  1    0    0    0S  1184.000  1665.000              1  
 6.10109990E+01-1.60945061E-01 1.68369493E-04-7.74563702E-08 1.33091290E-11    2
-1.65335454E+04-3.13710668E+02 0.00000000E+00 0.00000000E+00 0.00000000E+00    3
 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00 0.00000000E+00    4

But I don't know of any explicit documentation specifying this format.

In the McBride report, it seems that when the min temperature is greater than 1000 or the max temperature is less than 1000, the same coefficients are given for both temperature ranges.

[bryanwweber]

But I don't know of any explicit documentation specifying this format.

I think it's implied by the statement I quoted from the table on page 9

the same coefficients are given for both temperature ranges.

At least for the few examples I looked at in the iron series, the unused coefficients are set to zero.

I don't think Cantera's aim has ever been to convert the NASA format though, but to convert the Chemkin format

Yeah, I agree with this statement. It's unfortunate that there appear to be minor discrepancies in the format, presumably as NASA continued to evolve it and make it more flexible while the CHEMKIN format froze the status quo when it came out.

I'm not totally sure how to handle this. It hasn't been a problem up to now, at least in so far as no one has reported it. On the other hand, converting into garbage isn't the best behavior...

If cases like this can be reliably detected (a single temperature region), they can be "upgraded" to a NASA9 which supports the single temperature region a little better by setting a0 and a1 to zero.

[bryanwweber]

the same coefficients are given for both temperature ranges.

At least for the few examples I looked at in the iron series, the unused coefficients are set to zero.

Looked a little farther today, one example of the duplicated coefficients is AlF3(a). So it seems both conventions are used.

[speth]

I'm not totally sure how to handle this. It hasn't been a problem up to now, at least in so far as no one has reported it. On the other hand, converting into garbage isn't the best behavior...

I think there are two issues to deal with here. One is to fix what's in nasa_condensed.yaml, where we don't entirely have the corresponding original input. The other is to possibly update ck2yaml to be smarter about the mid temperature if it is either not specified or apparently outside the min/max temperature range.

If cases like this can be reliably detected (a single temperature region), they can be "upgraded" to a NASA9 which supports the single temperature region a little better by setting a0 and a1 to zero.

I don't think it's necessary to convert them to the 9-coefficient format; You can just duplicate the parameters for the two temperature ranges (as is done in some of the entries in the McBride database).