Turning off discontinuity in s/R, Cp/R warnings

[Nick Curtis]

Hi all,

Is there any way to easily turn off these warnings when loading a mechanism?

I'm using the USC mechanism in a multiprocessing script, and the warnings from the creation of so many Solution objects completely drowns out the output in my log file.

I've tried just redirecting stderr to a different file, but these appear to be printed to stdout

Thanks,

Nick

[Ray Speth]

Nick,

There is currently no way to disable these warnings. The warnings are printed from NasaPoly2::validate (defined in NasaPoly2.cpp), which is called from ThermoPhase::addSpecies. I'm okay with making these checks optional, if you'd like to propose an implementation. It seems a lot of published mechanisms contain these discontinuities, which I find a little troubling, but at the same time, most end users aren't going to be able to fix the problematic data.

Regards,

Ray

[Kyle Niemeyer]

Alright, I've come back to this issue... dealing with the same issues as Nick and tired of checking my output to only see these warnings.

So, I see that you can disable validation for species and/or reactions in the CTI file with 

validate(reactions='no' species='no')

so I suppose that could be one option; however, I can't tell if it is possible to disable this validation at the Python ct.Solution stage.

However, philosophically I wonder if disabling the basic correctness validation should be separate from disabling warnings like this, or if the idea behind disabling validation (e.g., previously validated mechanism) holds.

If we're ok with disabling the warnings separately, then it could be a bool flag that gets passed from the initial Solution object creation (e.g., `warnings=False`) down to the `NasaPoly2::validate` level in NasaPoly2.cpp

Kyle

[Ray Speth]

Kyle,

As far as I can tell, setting validate(species='no') in the CTI file has never actually done anything.

Implementing this as an option that can be set in a CTI / XML file is one option, but I worry that people would change it once and then never think again about the fact that they're using bad input data. If there's going to be an option to disable this kind of check, I'd like it to be glaringly obvious that you're running with the safeties turned off. If you have to write:

Solution('mymech.cti', allow_bogus_thermo_data=True)

That might be acceptable (the argument name is only slightly tongue-in-cheek). However, it's not quite clear how to implement that for the C++ interface, since it would be preferable to not have to add arguments to the several different functions that can be used to import a phase. Maybe it could be a (effectively global) variable within the Application class that gets toggled. Generally speaking, the validation checks are pretty fast, and I don't think there's a reason to disable them just because a mechanism has (supposedly) been previously validated. I think this used to be a bit more of a concern because the duplicate reaction check used to be pretty slow since it was implemented as an O(N^2) check over all reaction pairs, but I replaced that algorithm a while ago.

I don't really see this as being fundamentally different from the other validation that's done, i.e. duplicate reaction checks. At least in that case, there are legitimate reasons why you might want to express a rate as the sum of two Arrhenius expressions (hence the ability to declare duplicate reactions). I don't see any reason why the thermodynamic data for a species should be allowed to be discontinuous at a midpoint temperature that's just an arbitrary choice in a curve fitting exercise. I suspect that the reason these errors are present in so many mechanisms is simply because Chemkin does not perform this check.

Incidentally, I recently fixed a bug in the check for the continuity of the enthalpy expressions which caused discontinuities in the enthalpy to be ignored in most cases. In most of the cases where you previously saw warnings for Cp/R and S/R, there are now likely to be warnings for H/R as well, and I think H/R being discontinuous is even worse than Cp/R.

Regards,

Ray

[Kyle Niemeyer]

Hi Ray,

I agree that it's probably a good idea to that any way to disable the check should be obvious and purposeful.

However, perhaps there is another option: can we just direct these warning messages to stderr, the same way as warning messages from ck2cti, e.g? That way, people can just direct the stdout and stderr to different files if they want, and the warning messages don't cloud actual (desired) output.

If that's agreeable, then I suppose the next question is whether the writelog() function itself should direct to stderr. For most people, the change won't be distinguishable, but others can separate the log messages from intentional program output.

Kyle

[Ray Speth]

Kyle,

One issue with using stderr vs stdout, at least by default, is that there are then cases where stderr silently vanishes, e.g. when using the Matlab interface or a non-terminal-based Python interpreter such as the IPython Notebook. At the C++ level, there is already a function for changing what happens to log messages, which is the global 'setLogger' function. It would just require an implementation of Logger that logged to stderr, and then a wrapper function to set that logger.

Regards,

Ray

[Kyle Niemeyer]

For anyone else that discovers this thread, the conversation continued on GitHub in https://github.com/Cantera/cantera/issues/354, and Ray eventually added this option: https://github.com/Cantera/cantera/commit/aa4d07f543affc90b3cbcf26439e8b9efc6e940c

The option is

cantera.suppress_thermo_warnings()

(but use at your own risk!)