Do a pass-through on FATES log notifications

[rgknox]

Summary of Issue:

FATES will periodically generate log/output statements for the user that are non-debug information snippets. For instance we will specify the time, or mention dynamics is being called.

It may be useful to set a flag that turns on and off these "standard notifications", I'm not partial either way just yet. But we should definitely make sure that these messages are only called on masterproc.

Expected behavior and actual behavior:

Steps to reproduce the problem (should include create_newcase or create_test command along with any user_nl or xml changes):

What is the changeset ID of the code, and the machine you are using:

have you modified the code? If so, it must be committed and available for testing:

Screen output or output files showing the error message and context:

[bandre-ucar]

Might want to add a logging verbosity parameter to the netcdf file. Have values like critical, info, verbose, debug.

[rosiealice]

That's a nice idea :)

…

On 2 March 2017 at 14:51, Ben Andre ***@***.***> wrote: Might want to add a logging verbosity parameter to the netcdf file. Have values like critical, info, verbose, debug. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQyB6vMWSBWmm-y4LewWuyK-1Ugylks5rhzn5gaJpZM4MRk7c> .

-- ------------------------------------------------------------------------ Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305 USA. +1 303-497-1706 http://www.cgd.ucar.edu/staff/rfisher/

[bandre-ucar]

To expand a bit, there should be some global parameters like:

integer, parameter :: fates_logging_level_silent = 0
integer, parameter :: fates_logging_level_critical = 1
integer, parameter :: fates_logging_level_info = 2
integer, parameter :: fates_logging_level_verbose = 3
integer, parameter :: fates_logging_level_debug = 4

Then read a parameter: fates_global_logging

use is:

if (fates_global_logging >= fates_logging_level_verbose .and. master_proc()) then
    write(fates_log(), *) 'something verbose'
end if

[rgknox]

yeah, I like this system, and I like those levels.

This may sound counter-intuitive, but I feel it is almost easier to change the fates_global_logging_level as an integer parameter specified in the code, rather than in netcdf. Once the xlm pre-processor is up and running, I suppose either as an xml or as a coded parameter both work.

do you guys think anyone will confuse logging with tree logging?

log, or infolog, or am I being overly concerned?

I'm wondering if there is also some macro we can make that is added to the fates_log() call that will auto-generate and prepend a string with node/machine information, like node index, thread index and some basic geographical specs like lat and lon.

[bandre-ucar]

At least as far as testing/debugging goes, changing the logging level is far more useful as a runtime parameter than a compile time. I'd recommend setting it as a namelist variable to start.

[rgknox]

I think that would work, but in general I would like to keep the pipeline of information into FATES relegated to as few sources as possible. If both HLMs want to adopt this system for logging levels and want to use the namelist, that's just as well. I think we are talking about the interim right? I liked your original idea of getting this into the parameter file for its permanent home.