Skip to content

What should we do with all our input files? #22

@bryanwweber

Description

@bryanwweber

Abstract

We have many input files that are just committed to the repository and others that are distributed with Cantera. We should discuss which of these should be deprecated and removed, which should be removed without deprecation, and where the files that are staying should live.

Motivation

In Cantera/cantera#768, we determined that several input files should be deprecated and/or removed. However, due to the size of that PR, specific discussion was deferred. This issue is where I propose to have the relevant discussion.

At present, the following input files are committed to the repository:

The list of files in the data folder
data
├── inputs
│   ├── KOH.cti
│   ├── air.cti
│   ├── air.inp
│   ├── airNASA9.cti
│   ├── airNASA9.inp
│   ├── argon.cti
│   ├── argon.inp
│   ├── critProperties.xml
│   ├── diamond.cti
│   ├── elements.xml
│   ├── graphite.cti
│   ├── gri30.cti
│   ├── gri30.inp
│   ├── gri30_highT.cti
│   ├── gri30_ion.cti
│   ├── h2o2.cti
│   ├── h2o2.inp
│   ├── liquidvapor.cti
│   ├── lithium_ion_battery.cti
│   ├── methane_pox_on_pt.cti
│   ├── nDodecane_Reitz.cti
│   ├── nasa.cti
│   ├── nasa_condensed.cti
│   ├── nasa_gas.cti
│   ├── ohn.cti
│   ├── ptcombust.cti
│   ├── silane.cti
│   ├── silane.inp
│   ├── silicon.cti
│   ├── silicon_carbide.cti
│   ├── sofc.cti
│   └── water.cti
├── thermo
│   ├── airDataNASA9.dat
│   ├── gri30_thermo.dat
│   └── nasathermo.dat
├── transport
│   ├── gri30_tran.dat
│   └── misc_tran.dat
├── KOH.yaml
├── air.yaml
├── airNASA9.yaml
├── argon.yaml
├── diamond.yaml
├── graphite.yaml
├── gri30.yaml
├── gri30_highT.yaml
├── gri30_ion.yaml
├── h2o2.yaml
├── liquidvapor.yaml
├── lithium_ion_battery.yaml
├── methane_pox_on_pt.yaml
├── nDodecane_Reitz.yaml
├── nasa.yaml
├── nasa_condensed.yaml
├── nasa_gas.yaml
├── ohn.yaml
├── ptcombust.yaml
├── silane.yaml
├── silicon.yaml
├── silicon_carbide.yaml
├── sofc.yaml
└── water.yaml

There are several "classes" of files here:

  • CTI/YAML input files for examples (e.g., lithium_ion_battery.cti)
  • CTI/YAML input files for data (e.g., nasa_condensed.cti, liquidvapor.yaml)
  • CHEMKIN-style input files
  • XML files for fundamental data (critProperties.xml, elements.xml)

Some input files might be cross some of these lines (e.g., liquidvapor.yaml), so the distinctions are a little fuzzy.

Possible Solutions

To get the discussion started, I'll propose the following changes:

  1. Remove all CHEMKIN input files from the data folder. They are (or will shortly be) no longer needed at build time, so they will become clutter. Select files should be moved to test/data for tests of the conversion scripts.
  2. Move input files that are used in one example to the folder with that example. IMO, the word data implies that the files therein are more important somehow, and moving the input files to an example-specific folder removes some of the implicit endorsement that we are giving to these files by distributing them.
    a. This is mildly complicated because several files are used in several examples across a few interfaces
  3. Data files elements.xml, critProperties.xml, and liquidvapor.yaml remain in the data folder
  4. All other files that are not used in an example are deprecated and removed

I'm not particularly attached to this arrangement, just throwing it out there to get something started. I'm also not particularly attached to this happening on any particular timeline, so discussion is more than welcome.

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature-requestNew feature requestquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions