Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when parsing ck2cti or ck2yaml with large element number(more than 3 digits) #853

Closed
12Chao opened this issue May 27, 2020 · 4 comments · Fixed by #857
Closed

Error when parsing ck2cti or ck2yaml with large element number(more than 3 digits) #853

12Chao opened this issue May 27, 2020 · 4 comments · Fixed by #857

Comments

@12Chao
Copy link
Contributor

12Chao commented May 27, 2020

System information

  • Cantera version: 2.5.0
  • OS: Ubuntu 18.0.4
  • Python/MATLAB version: 3.8.0

Expected behavior

Regarding to the issue on Cantera google user group. The expected behavior is a successful conversion.
Actual behavior

It was not clear where is the error position when the user used ck2cti in Cantera 2.4.0 and python 3.7, so I tried Cantera 2.5.0 and python 3.8. The reason was that there are several species has element numbers more than 3 digits, for example, BIN7AJ C 1250H 812 G 300.00 3500.00 1260.00 1.
The function in ck2cti, readThermoEntry(line 1032 composition = self.parseComposition(lines[0][24:44], 4, 5) ) does not split the string correctly, [24:44] only covers part of the element symbols and numbers, especially when the element number is very large (species BIN12AJ in the thermo file). Besides, the input value to function parseComposition on line 1032 only successfully converts when the element number has less than 3 digits.

I am not sure if these large number are added in the file accidentally, but should Cantera add some feature to enable conversion for species with large element number?

To Reproduce

Steps to reproduce the behavior:

  1. Open the directory where the chemkin files are saved
  2. Run ck2cti --input=input.CKI --thermo=thermo.CKT --transport=trans.TRC --output=new.cti --debug --permissive
  3. See error
Traceback (most recent call last):
  File "/home/chao/anaconda3/envs/cantera38/bin/ck2cti", line 11, in <module>
    load_entry_point('Cantera==2.5.0a4', 'console_scripts', 'ck2cti')()
  File "/home/chao/anaconda3/envs/cantera38/lib/python3.8/site-packages/cantera/ck2cti.py", line 2352, in script_entry_point
    main(sys.argv[1:])
  File "/home/chao/anaconda3/envs/cantera38/lib/python3.8/site-packages/cantera/ck2cti.py", line 2323, in main
    surfaces = Parser.convertMech(inputFile, thermoFile, transportFile,
  File "/home/chao/anaconda3/envs/cantera38/lib/python3.8/site-packages/cantera/ck2cti.py", line 2264, in convertMech
    surface_names = parser.writeCTI(name=phaseName, outName=outName)
  File "/home/chao/anaconda3/envs/cantera38/lib/python3.8/site-packages/cantera/ck2cti.py", line 2068, in writeCTI
    speciesNames = self.getSpeciesString(self.speciesList, 21)
  File "/home/chao/anaconda3/envs/cantera38/lib/python3.8/site-packages/cantera/ck2cti.py", line 2012, in getSpeciesString
    raise InputParseError("Undefined elements in species '{}':"
cantera.ck2cti.InputParseError: Undefined elements in species 'BIN7AJ': '1'

Attachments

input.txt
thermo.txt
trans.txt

Additional context

@speth
Copy link
Member

speth commented May 27, 2020

I don't think the values here are accidental / erroneous, but they don't seem to follow input file format rules. Those rules pretty clearly describe the format for the elemental composition in columns 25–44 as consisting of 4 entries of 5 characters where the first two characters are for the element name and the remaining three characters are for the number of atoms of that element. This file doesn't even work in a certain commercial tool where one might expect it to.

To allow for additional elements / longer element names / larger molecules, the format does allow a syntax where those are given on additional lines of the input file, e.g. as shown here:

BIN6J PYRENEJ1 C 0H 0 0 0G 300.000 5000.000 1401.000 01&
C 778 H 263
3.63345177E+01 3.13968020E-02-1.09044660E-05 1.71125597E-09-1.00056355E-13 2
4.05143093E+04-1.77494305E+02-1.20603441E+01 1.59247554E-01-1.41562602E-04 3
6.26071650E-08-1.09305161E-11 5.56473533E+04 7.68451211E+01 4
BIN6 PYRENE C 0H 0 0 0G 300.000 5000.000 1401.000 01&
C 778&
H 264
3.65839677E+01 3.36764102E-02-1.16783938E-05 1.83077466E-09-1.06963777E-13 2
9.29809483E+03-1.81272070E+02-1.29758980E+01 1.63790064E-01-1.43851166E-04 3
6.31057915E-08-1.09568047E-11 2.48866399E+04 7.94950474E+01 4

I think the only modification that should be made to Cantera here would be to provide a more helpful error message, for example showing the entire thermo entry for the offending species, like we do for some other thermo errors.

@12Chao
Copy link
Contributor Author

12Chao commented May 27, 2020

Thanks for the response @speth , I think showing entire entry is helpful and I can work on it. I forgot to mention that the conversion was completed with CanteraError when I was using ck2yaml as converter. The message is shown as

Wrote YAML mechanism file to 'new.yaml'.
Mechanism contains 576 species and 27369 reactions.
Validating mechanism...FAILED.

***********************************************************************
CanteraError thrown by Phase::addSpecies:
Species 'BIN7AJ' contains an undefined element '1'.
***********************************************************************

In this case, if I want to make changes like showing the entire entry, should I make it in the .cpp file or should I add another function into ck2yaml file to prevent the completed conversion by ck2yaml with wrong species compositions in it and throw an error message?

Here is the yaml file.
new.txt

@12Chao
Copy link
Contributor Author

12Chao commented May 28, 2020

I would try to raise error with the entire thermo entry from ck2yaml. To my understanding, the Phase.cpp file only validates the converted yaml file, and it cannot show the entire thermo entry same with the original format in the thermo.txt file because they are already converted. Please correct me if I am wrong.

@speth
Copy link
Member

speth commented May 28, 2020

Yes, that sounds correct. I think this could be detected at the time the composition is parsed, perhaps using the fact that an element name shouldn't start with a number as a criterion for identifying this kind of error.

12Chao pushed a commit to 12Chao/cantera that referenced this issue Jun 3, 2020
symbol string which includes number in it, issue Cantera#853
12Chao pushed a commit to 12Chao/cantera that referenced this issue Jun 3, 2020
symbol string which includes number in it, issue Cantera#853
12Chao pushed a commit to 12Chao/cantera that referenced this issue Jun 3, 2020
symbol string which includes number in it, issue Cantera#853
12Chao pushed a commit to 12Chao/cantera that referenced this issue Jul 1, 2020
symbol string which includes number in it, issue Cantera#853
12Chao pushed a commit to 12Chao/cantera that referenced this issue Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants