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

Accept floating point representations of valid integer geometry flags in ck2yaml #1396

Merged
merged 2 commits into from Jan 24, 2023

Conversation

corykinney
Copy link
Contributor

@corykinney corykinney commented Sep 26, 2022

Changes proposed in this pull request

This pull request automatically converts floating point representations of valid integer geometry flags to integers by casting to a float then to an int and checking equality between the two results.

Closes #1395

Checklist

  • The pull request includes a clear description of this code change
  • Commit messages have short titles and reference relevant issues
  • Build passes (scons build & scons test) and unit tests address code coverage
  • Style & formatting of contributed code follows contributing guidelines
  • The pull request is ready for review

@bryanwweber
Copy link
Member

bryanwweber commented Sep 27, 2022

Thanks for this @cory-kinney! To be honest, I feel quite ambivalent about this change... on the one hand, this change seems sensible and some simple testing on my end shows that it should be pretty robust. It would certainly improve the user experience.

On the other hand, the CHEMKIN spec (as much as can be found publicly) states that this value is an index, which I interpret to mean an integer. I think that's the most reasonable interpretation. In Python, indices to access elements in sequences need to be ints, for example. As CHEMKIN is closed source, we can only go by the published materials that are available when implementing this. Specifically, I feel quite reluctant to base Cantera's behavior on CHEMKIN's current (inconsistent in my opinion) behavior, as they can change behavior without warning or recourse from our side. In this specific case, it seems like they'd be unlikely to cause such a backwards-compatibility-breaking change for a fairly minor inconsistency, but the principle remains...

In the end, I think this change is probably worth it. I'll just ask you to fix up the failing test which explicitly checks for this error, and change it to a test that ensures this behavior is robust. The case I'd be specifically worried about is automatic writers that format something that should be 2.0 as just slightly less than 2.0 (likewise for 1.0)... Python's default behavior with int is to floor the input, that is:

In [45]: int(float("2.0") - sys.float_info.epsilon)
Out[45]: 1

That is, if some software writes out a non-linear molecule with a geometry of 1.999999999999999999, it will be turned into a linear molecule with this change. I'd rather error in that case, than produce incorrect results in Cantera.


On the less productive side, I also feel like this is another chance for Cantera to point out where CHEMKIN is either incorrect or (in this case) inconsistent with its own documentation. So I'm also inclined to keep this as an error, if only to point out to users that CHEMKIN should not be the de-facto baseline. But, as I said, that's not super productive from a user standpoint 😄

@ischoegl
Copy link
Member

ischoegl commented Sep 27, 2022

I also feel like this is another chance for Cantera to point out where CHEMKIN is either incorrect or (in this case) inconsistent with its own documentation. So I'm also inclined to keep this as an error, if only to point out to users that CHEMKIN should not be the de-facto baseline.

I believe the best way forward would be to issue warnings instead of errors, and convert for the user for cases like the one that is reported. Silently accepting incorrect syntax is not ideal.

@ischoegl ischoegl added the Input Input parsing and conversion (for example, ck2yaml) label Sep 27, 2022
Copy link
Member

@ischoegl ischoegl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cory-kinney ... thanks for the PR! As mentioned, I am not opposed to being more permissive when it comes to CHEMKIN input, but would request some changes to your approach.

interfaces/cython/cantera/ck2yaml.py Outdated Show resolved Hide resolved
interfaces/cython/cantera/ck2yaml.py Outdated Show resolved Hide resolved
corykinney added a commit to corykinney/cantera that referenced this pull request Oct 3, 2022
- Add warning message when float is automatically converted to integer
- Change test case for float transport data to test for floating point rounding errors
Copy link
Member

@bryanwweber bryanwweber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @cory-kinney! A few more changes based on the updates

interfaces/cython/cantera/ck2yaml.py Outdated Show resolved Hide resolved
Comment on lines 3 to 4
H2 0.999999999999999999 38.000 2.920 0.000 0.790 280.000
H2O 1.999999999999999999 572.400 2.605 1.844 0.000 4.000
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you adjusted these so that we're testing the new behavior, but I think the tests are still going to fail because you need to adjust the code over here:

def test_transport_float_geometry(self):

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bryanwweber what changes would need to be made? Wouldn't the existing test case fail since it would raise an InputError with the phrase "geometry flag" in it since --permissive won't apply?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also need a test where --permissive is passed and the conversion is successful. There should also be a case testing passing --permissive and the check fails because of the rounding issue.

The existing test is only checking one of the code paths, as you note the one without --permissive

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cory-kinney ... I think the only remaining task preventing this from being approved/merged is the test @bryanwweber mentioned?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ischoegl That's correct, I've just been a bit busy so I haven't gotten around to it! I'll try to do that sometime this next week.

corykinney added a commit to corykinney/cantera that referenced this pull request Oct 3, 2022
Add missing check in ck2yaml for non-integer equivalent floats
@codecov
Copy link

codecov bot commented Oct 3, 2022

Codecov Report

Merging #1396 (824d890) into main (f6744ec) will decrease coverage by 0.31%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1396      +/-   ##
==========================================
- Coverage   71.03%   70.72%   -0.31%     
==========================================
  Files         363      378      +15     
  Lines       51855    55141    +3286     
  Branches    17362    18164     +802     
==========================================
+ Hits        36834    38998    +2164     
- Misses      12676    13633     +957     
- Partials     2345     2510     +165     
Impacted Files Coverage Δ
interfaces/cython/cantera/ck2yaml.py 88.96% <100.00%> (+0.05%) ⬆️
include/cantera/kinetics/InterfaceKinetics.h 28.57% <0.00%> (-57.15%) ⬇️
include/cantera/cython/utils_utils.h 38.88% <0.00%> (-24.27%) ⬇️
src/kinetics/Reaction.cpp 68.33% <0.00%> (-12.29%) ⬇️
src/kinetics/KineticsFactory.cpp 81.81% <0.00%> (-11.74%) ⬇️
src/numerics/ODE_integrators.cpp 40.00% <0.00%> (-10.00%) ⬇️
include/cantera/transport/Transport.h 18.69% <0.00%> (-8.34%) ⬇️
include/cantera/kinetics/ReactionData.h 67.85% <0.00%> (-8.15%) ⬇️
include/cantera/base/ExtensionManager.h 42.85% <0.00%> (-7.15%) ⬇️
include/cantera/kinetics/InterfaceRate.h 81.92% <0.00%> (-6.03%) ⬇️
... and 238 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@corykinney
Copy link
Contributor Author

It would seem that the additional tests implemented originally failed because, for the original value chosen to test handling of floating point arithmetic error, float(0.999999999999999999) evaluates to 1.0 so the error was not being raised; therefore, the value with the fewest number of digits after the decimal place that did not evaluate to 1.0 was chosen (0.9999999999999999) so that the error would be raised and the test would pass. Does that satisfy the concern about accidental floors @bryanwweber?

Let me know if there are any other changes that should be made. Should I go ahead and squash my commits and write a proper commit message now?

@corykinney
Copy link
Contributor Author

I believe it's ready for review now @ischoegl !

Copy link
Member

@bryanwweber bryanwweber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @cory-kinney, I have a few more suggested updates here to make sure that the tests provide appropriate coverage.

By the way, the failing tests here seem to be failing on the main branch too, so you don't need to worry about that.

Comment on lines 696 to 702
try:
geometry = float(geometry)
except ValueError:
raise InputError(
"Bad geometry flag '{}' for species '{}'. "
"Flag should be an integer.", geometry, label) from None
if geometry == int(geometry):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like there isn't a test of this case, which could be triggered by putting something that's not a number into the transport field. I'm basing this on the coverage comment here, although I do see what looks like it should be the right test below, test_transport_bad_geometry.

I'd suggest updating the error messages to be slightly different so that we can actually check for them appropriately and make sure that we have tests that cover all the cases:

  1. Invalid input (character instead of number)
  2. Float which rounds to 0, 1, or 2 and is only an error if permissive=False, and succeeds otherwise
  3. Integer 0, 1, or 2 (this should already be well covered)
  4. Integer or float >=3 which fails

Comment on lines 346 to 353
self.convert('h2o2.inp',
transport='h2o2-float-geometry-tran.dat',
output='h2o2_transport_float_geometry', permissive=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test should also check that the converted mechanism has the appropriate type for the geometry. Otherwise we're not sure what the value is actually is.

@ischoegl ischoegl dismissed their stale review December 19, 2022 19:59

Requested changes have been addressed.

@ischoegl
Copy link
Member

ischoegl commented Dec 19, 2022

I believe it's ready for review now @ischoegl !

I believe that my own initial review comments have been addressed a while ago. I know that @bryanwweber has things under control here, so I am happy with where this is going.

@corykinney
Copy link
Contributor Author

@bryanwweber I finally got around to implementing the changes you requested (I haven't had to convert a mechanism with this issue in a while, so it was on the back burner), let me know if the latest commit properly addresses them.

@corykinney
Copy link
Contributor Author

I'm having some trouble verifying the tests work properly now because of a build error that has started occurring recently for unknown reasons.

In file included from C:\Users\Cory\AppData\Local\Programs\Python\Python311\Include/Python.h:94,
                 from src\extensions\pythonExtensions.h:6,
                 from src\extensions\PythonExtensionManager.cpp:10:
C:\Users\Cory\AppData\Local\Programs\Python\Python311\Include/pylifecycle.h:37:38: note: declared here
   37 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetProgramName(const wchar_t *);
      |                                      ^~~~~~~~~~~~~~~~~
src\extensions\PythonExtensionManager.cpp:127:22: error: '_PyNamespace_New' was not declared in this scope
  127 |     PyObject *spec = _PyNamespace_New(attrs);
      |                      ^~~~~~~~~~~~~~~~
scons: *** [build\src\extensions\PythonExtensionManager.o] Error 1
scons: building terminated because of errors.

@bryanwweber
Copy link
Member

@speth @ischoegl Can you guys help out with Corey's error above?

Copy link
Member

@bryanwweber bryanwweber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One teeny tiny change 😄 Great work @corykinney I'd approve but it looks like you're having some trouble compiling, plus there's the failing .NET job which I'm not sure about.

interfaces/cython/cantera/ck2yaml.py Outdated Show resolved Hide resolved
@corykinney
Copy link
Contributor Author

corykinney commented Jan 23, 2023

@bryanwweber I was able to build it just fine on my laptop with Python 3.10, so I can now confirm that the test cases pass. I just had to update the check for the error you fixed, as it was looking for Invalid geometry flag entry. To distinguish from the other error messages without further modification, I just switched it to Invalid geometry flag ' to catch the first single quote which isn't in the other three possible error messages.

@corykinney
Copy link
Contributor Author

@speth @ischoegl Can you guys help out with Corey's error above?

Look like this was already fixed in f04d482 in November, which was slightly after my latest rebase of this pull request.

@ischoegl
Copy link
Member

ischoegl commented Jan 23, 2023

@corykinney ... the error you posted looks like it's related to #1382, but apparently went away after the fix you indicated. Given that CI passes (coverage failed for a different reason), this should be ready to merge. I'll leave the approval to @bryanwweber ... 😁

@bryanwweber
Copy link
Member

@corykinney Sorry, it looks like you committed the .idea folder, can you remove that? If you want to avoid this in the future, you can add .idea to the .gitignore, I think PyCharm is a common enough editor that we can ignore the config for it globally.

If `permissive` is given, `float` geometry flags are cast to `int` and are accepted if the values are equal, otherwise, `InputError` is raised. If `permissive` is not given, existing behavior is unchanged.

Add tests to check for correct behavior with and without permissive, for float rounding error, and for character inputs.

Closes Cantera#1395
Ignore `.idea/` folder associated with PyCharm IDE data
Copy link
Member

@bryanwweber bryanwweber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the work here. In it goes!

@corykinney
Copy link
Contributor Author

@bryanwweber Good catch! For whatever reason I've avoided modifying the .gitignore like I normally do for fear of accidentally committing that, but then I ended up committing the .idea folder anyway haha

@bryanwweber
Copy link
Member

If you want to ignore files just for yourself, you can add it to .git/info/exclude in the repo. That file has the same syntax as .gitignore but it only works for the computer you're on

@bryanwweber bryanwweber merged commit c0ae563 into Cantera:main Jan 24, 2023
@corykinney
Copy link
Contributor Author

If you want to ignore files just for yourself, you can add it to .git/info/exclude in the repo. That file has the same syntax as .gitignore but it only works for the computer you're on

That's a super helpful tip!

And thank you both @bryanwweber @ischoegl for your patience and help in figuring out my first pull request! 🎉
Hopefully next is #1421!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Input Input parsing and conversion (for example, ck2yaml)
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Floating point representations of valid integer geometry flags crash ck2yaml
3 participants