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

Improve warning messages in C++ #741

Merged
merged 11 commits into from Nov 11, 2019
Merged

Conversation

ischoegl
Copy link
Member

@ischoegl ischoegl commented Nov 4, 2019

Please fill in the issue number this pull request is fixing

Fixes #683

Changes proposed in this pull request

  • introduce warn_user in C++ layer (in analogy to warn_deprecated)
  • create uniform formatting for warnings
  • add information on method raising the warning
  • replace various occurrences of ad-hoc formatted writelog warnings with warn_user
  • issue warn_user for Troe when T2 (i.e. T**) is zero

Notes

Some ck2cti/ck2yaml converters appear to create length-4 arrays for Troe parameters, which raises the warning that was suggested for #683 in the unit test suite. I.e.

test_surface_mech (cantera.test.test_convert.ck2ctiTest) ... UserWarning: 'Troe::init': Zero T2 value is suppressed.
ok
test_reaction_units (cantera.test.test_convert.ck2yamlTest) ... UserWarning: 'Troe::init': Zero T2 value is suppressed.
UserWarning: 'Troe::init': Zero T2 value is suppressed.
UserWarning: 'Troe::init': Zero T2 value is suppressed.
UserWarning: 'Troe::init': Zero T2 value is suppressed.
ok
test_surface_mech (cantera.test.test_convert.ck2yamlTest) ... UserWarning: 'Troe::init': Zero T2 value is suppressed.
ok

It's probably not worth fixing ck2cti, but it also affects ck2yaml. Edit: the YAML import issue is fixed.

Other thoughts

Long-term, it may make sense to use a logger that allows for a meaningful differentiation of levels, e.g. Boost.Log. The introduction of warn_user now will facilitate a central replacement in application.h/.cpp in the future.

@codecov
Copy link

codecov bot commented Nov 4, 2019

Codecov Report

Merging #741 into master will decrease coverage by <.01%.
The diff coverage is 38.98%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #741      +/-   ##
==========================================
- Coverage   70.84%   70.83%   -0.01%     
==========================================
  Files         372      372              
  Lines       43704    43720      +16     
==========================================
+ Hits        30962    30970       +8     
- Misses      12742    12750       +8
Impacted Files Coverage Δ
src/base/application.h 75% <ø> (ø) ⬆️
src/oneD/Sim1D.cpp 71.72% <0%> (ø) ⬆️
src/transport/MMCollisionInt.cpp 84.44% <0%> (-1.92%) ⬇️
src/oneD/StFlow.cpp 86.94% <0%> (ø) ⬆️
src/thermo/PDSS_HKFT.cpp 67.6% <0%> (ø) ⬆️
src/thermo/MixtureFugacityTP.cpp 28.63% <0%> (-0.14%) ⬇️
src/equil/ChemEquil.cpp 77.95% <0%> (-0.11%) ⬇️
src/thermo/RedlichKwongMFTP.cpp 76.48% <0%> (+0.09%) ⬆️
src/equil/vcs_VolPhase.cpp 74.94% <0%> (-0.16%) ⬇️
src/oneD/Domain1D.cpp 62.3% <0%> (ø) ⬆️
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 02c433b...a69151d. Read the comment docs.

src/base/global.cpp Outdated Show resolved Hide resolved
@ischoegl ischoegl force-pushed the introduce-user-warning branch 2 times, most recently from f24db7d to 5b7772f Compare November 4, 2019 14:01
Copy link
Member

@speth speth left a comment

Choose a reason for hiding this comment

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

This looks pretty good to me. I don't think it's a full fix for #683 yet, unless you also want to make the appropriate modifications to the Chemkin conversion scripts.

I would like to avoid adding Boost.Log to our dependencies -- While I generally like Boost, this is unfortunately one of parts that has a compiled library component, and my experience has been that these are very messy dependencies to deal with when you need to support multiple operating systems and a range of different Boost versions. However, a method for raising these warnings through the Python warnings module would be interesting as a future extension.

include/cantera/base/global.h Outdated Show resolved Hide resolved
src/base/application.cpp Outdated Show resolved Hide resolved
src/base/application.cpp Outdated Show resolved Hide resolved
src/thermo/PDSS_HKFT.cpp Outdated Show resolved Hide resolved
src/transport/MMCollisionInt.cpp Outdated Show resolved Hide resolved
@@ -40,41 +40,36 @@ Description:
Chemical equilibrium.
Equilibrium composition and pressure for a range of temperatures at constant density.


**** WARNING ****
UserWarning: 'NasaPoly2::validate':
Copy link
Member

Choose a reason for hiding this comment

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

I'm wondering if it would look better to format the warning message without quotes around the method name.

Copy link
Member Author

Choose a reason for hiding this comment

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

No problem. Also suggesting CanteraWarning to make things a little clearer

Copy link
Member

Choose a reason for hiding this comment

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

👍 on CanteraWarning

include/cantera/base/global.h Outdated Show resolved Hide resolved
@@ -55,7 +55,8 @@ int equil_example1(int job)
std::cout << "Chemical equilibrium." << std::endl;
if (job > 0) {
std::cout << "Equilibrium composition and pressure for a "
<< "range of temperatures at constant density." << std::endl;
<< "range of temperatures at constant density."
<< std::endl << std::endl;
Copy link
Member

Choose a reason for hiding this comment

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

It feels a little bit like cheating if you have to modify the output before a warning is issued to get it formatted as desired. One possibility to make multiline warnings more readable would be to automatically add a newline before and after a warning message if it already contains a newline.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added the extra newline here to remain consistent with the existing output, so this is pretty problem specific. I really don't like adding newlines before ... it's up to the user to format things as needed after.

src/kinetics/Falloff.cpp Show resolved Hide resolved
@ischoegl
Copy link
Member Author

ischoegl commented Nov 9, 2019

@speth ... thanks for the review! Will make the changes which won’t take long.

a method for raising these warnings through the Python warnings module would be interesting as a future extension.

I’ve been wondering about this also, but cannot think of an elegant solution. Definitely another PR

@ischoegl
Copy link
Member Author

ischoegl commented Nov 10, 2019

One final comment for the record: I noticed that the following warnings depend on a log level. I don't want to change it without discussion as this PR should not change the overall behavior.

if (m_loglevel > 2) {
writelogf("\nT* fit at delta* = %.6g\n", deltastar);
writelog("astar = [" + vec2str(vector_fp(a, a+degree+1))+ "]\n");
if (rmserr > 0.01) {
warn_user("MMCollisionInt::fit",
"RMS error = {:12.6g} for A* fit", rmserr);
}
writelog("bstar = [" + vec2str(vector_fp(b, b+degree+1))+ "]\n");
if (rmserr > 0.01) {
warn_user("MMCollisionInt::fit",
"RMS error = {:12.6g} for B* fit", rmserr);
}
writelog("cstar = [" + vec2str(vector_fp(c, c+degree+1))+ "]\n");
if (rmserr > 0.01) {
warn_user("MMCollisionInt::fit",
"RMS error = {:12.6g} for C* fit", rmserr);
}
}

@ischoegl ischoegl requested a review from speth November 10, 2019 00:58
Copy link
Member

@speth speth left a comment

Choose a reason for hiding this comment

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

With the change to ck2yaml, I agree that this resolves #683.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistency between TROE formula and code when T** is zero.
2 participants