Add diagnostic object to CCPP-framework

[peverwhee]

Description

A new object for which the data would be handled by the framework would be a nice have for CCPP; it would mean you could pass around the object between schemes and add diagnostic fields to it (and store values for those fields in buffers at a specific time during model execution)

Solution

1. An object (extending the ccpp_hashable_char_t type like the constituents object) that would live in $CCPP-framework/src and contain necessary information for a diagnostic field, including:

   • diagnostic name
   • long name and/or standard name
   • units
   • dimensions
   • possibly an averaging flag (although that might be handled by the host model)
   • buffer containing the data captured at the chosen point
     • could also include additional buffers to keep track of minimum, maximum, average, standard deviation (depends on whether we want the host to be responsible for that kind of thing since the types of output likely vary between models)

   It would have (at least) the following methods:

   • INITIALIZE: add the metadata for a field that can be output
   • POPULATE BUFFER: populate the buffer for that field

2. An instance of the ccpp_hash_table_t type, managed by the host cap, that contains hashable field objects described in (1). It would at least contain the following methods:

   • ADD FIELD: initializes a field's metadata and buffers and adds it to the hash table (done at init time)
   • CAPTURE FIELD: find the field in the hash table and call the POPULATE BUFFER method of the object in (1) (done outside of init time)
   • GET DIAGNOSTIC FIELD: search the hash table given a diagnostic name and, if it's there, return the field metadata and buffer(s)

Alternatives (optional)

@gold2718 also proposed auto-generating the calls to add fields and the calls to out fields by specifying in the metadata that a specific variable is one that we wish to be captured.

[peverwhee]

After talking to @climbfuji and @gold2718 ... Another possibility:

• Diagnostic object/hash table still exists (mostly) as described
• The framework handles all the adding/capturing of fields based on a new metadata field that will specify whether to capture the field before or after the scheme
• Long-er term, we'll want to have a switch that will turn off diagnostics for performance
  • switch will be "all", "off", or "" (can configure subset fields to output)

This doesn't solve the problem of outputting a variable's state in the middle of a scheme. That problem can wait.

• Note: the ccpp-physics has a mechanism for grabbing variables for output in the middle of a scheme - see here

Any thoughts?