Allow logging in CCPP physics schemes

[gold2718]

Description

While the current rules prohibit a CCPP scheme from writing to a log file (any output), many developers would like to be able to log information from a scheme. This can be for diagnostic (e.g., debugging) or informational (e.g., process statistics) purposes.

Solution

Add two now CCPP standard names to allow the host model to control output from physics schemes:

• log_output_unit (integer): Provides a Fortran unit for log output
• do_log_output (logical): .true. on task(s) which are allowed to write to log_output_unit.

[gold2718]

Note, I think this feature requires a change to the CCPP Framework rules. However, I did not see it in the rules. The closest I got was the "Reason" behind C12.

[nusbaume]

Quoting a suggestion on this topic from @gold2718 that was brought up in a different PR:

Here is an idea (not to be implemented here). Right now, we have ccpp_error_message and ccpp_error_code. The framework only checks ccpp_error_code for non-zero status to decide if it needs to return early. It could also collect any content in ccpp_error_message when ccpp_error_code == 0 and return all such output if the final ccpp_error_code == 0. Then the host model could log the output in such cases. If this is not obviously a terrible idea, I can help flesh out the concept in the CCPP Framework repo.

My personal take is that this idea seems reasonable assuming we don't build a more formal logging system in the framework. However, I might vote to create a new CCPP variable instead of overloading ccpp_error_message, as I feel like containing non-error information in ccpp_error_message could cause confusion, especially when handling the message on the host-model side.

[dustinswales]

Quoting a suggestion on this topic from @gold2718 that was brought up in a different PR:

Here is an idea (not to be implemented here). Right now, we have ccpp_error_message and ccpp_error_code. The framework only checks ccpp_error_code for non-zero status to decide if it needs to return early. It could also collect any content in ccpp_error_message when ccpp_error_code == 0 and return all such output if the final ccpp_error_code == 0. Then the host model could log the output in such cases. If this is not obviously a terrible idea, I can help flesh out the concept in the CCPP Framework repo.

My personal take is that this idea seems reasonable assuming we don't build a more formal logging system in the framework. However, I might vote to create a new CCPP variable instead of overloading ccpp_error_message, as I feel like containing non-error information in ccpp_error_message could cause confusion, especially when handling the message on the host-model side.

How often do we encounter the case where ccpp_error_code=0 and ccpp_error_message != '' ?
(I'd like to believe/hope that this is not common practice)

[climbfuji]

Quoting a suggestion on this topic from @gold2718 that was brought up in a different PR:

Here is an idea (not to be implemented here). Right now, we have ccpp_error_message and ccpp_error_code. The framework only checks ccpp_error_code for non-zero status to decide if it needs to return early. It could also collect any content in ccpp_error_message when ccpp_error_code == 0 and return all such output if the final ccpp_error_code == 0. Then the host model could log the output in such cases. If this is not obviously a terrible idea, I can help flesh out the concept in the CCPP Framework repo.

My personal take is that this idea seems reasonable assuming we don't build a more formal logging system in the framework. However, I might vote to create a new CCPP variable instead of overloading ccpp_error_message, as I feel like containing non-error information in ccpp_error_message could cause confusion, especially when handling the message on the host-model side.

We could consider renaming it to ccpp_log_message or something else, but keep in mind that these variables are mandatory and that you need to change each and every CCPP scheme (and every host model) for that change.

[climbfuji]

Quoting a suggestion on this topic from @gold2718 that was brought up in a different PR:

Here is an idea (not to be implemented here). Right now, we have ccpp_error_message and ccpp_error_code. The framework only checks ccpp_error_code for non-zero status to decide if it needs to return early. It could also collect any content in ccpp_error_message when ccpp_error_code == 0 and return all such output if the final ccpp_error_code == 0. Then the host model could log the output in such cases. If this is not obviously a terrible idea, I can help flesh out the concept in the CCPP Framework repo.

My personal take is that this idea seems reasonable assuming we don't build a more formal logging system in the framework. However, I might vote to create a new CCPP variable instead of overloading ccpp_error_message, as I feel like containing non-error information in ccpp_error_message could cause confusion, especially when handling the message on the host-model side.

How often do we encounter the case where ccpp_error_code=0 and ccpp_error_message != '' ? (I'd like to believe/hope that this is not common practice)

So far, none, because the rule was that only in the event of an error would you change the error code to something else and then add a meaningful error message to the error message variable (which may change as part of this discussion).

[gold2718]

My personal take is that this idea seems reasonable assuming we don't build a more formal logging system in the framework. However, I might vote to create a new CCPP variable instead of overloading ccpp_error_message, as I feel like containing non-error information in ccpp_error_message could cause confusion, especially when handling the message on the host-model side.

For the record, I would much prefer that we introduce a new and improved error / logging method and introduce it as an alternative to ccpp_error_message and ccpp_error_code. In another project (to be picked up again some day I hope), I created a prototype of what could be such an object:

https://github.com/ESMCI/history_output/blob/development/src/util/hist_msg_handler.F90

I think the way to introduce it would be to allow the framework to generate either at the top level (i.e., in the caps) and then have ways to convert one into the other. Going from ccpp_error_message and ccpp_error_code to the new object (let's call it ccpp_log_messages for now after @climbfuji's suggestion) would just add the error message to the log (in the case of an error condition). Going the other way would entail a loss of information (log only messages would have to be dropped). Given that all the current schemes use the "old" method, I think implementing this in the caps and host models would be fairly straightforward.