goldy

> 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...

@climbfuji, Thanks for working on this. I like the first part but have a couple of concerns about this bit: > The CCPP Single Column Model (SCM) is designed as...

We should expand the capability of the `capgen` interface to include options for all the 'standard' CCPP physics kinds. The CCPP Framework committee hereby declares all kinds used today in...

> > Is this test supposed to pass on our test files? If I try it in capgen_test or advection_test, I get something like: > > ``` > > Unknown...

> > I agree with the sentiment, however, in this case, the DDT is defined in the metadata that is being scanned, it was just not scanned before a file...

> Another nice-to-have would be to be able to redirect these log messages to separate log files or stdout/stderr or some other method that can be informed by the host...

If output is configured, does the framework still return the error object to the host model? How does the host model know what messages have been output? This feels a...

Is this proposed interface for runtime, build time (post framework), or both?

Currently (in capgen), there is a post-framework database access for the processes, e.g., ``` /scripts/ccpp_datafile.py --process-list j/ccpp/ccpp_datatable.xml ``` should output a list of schemes tied to processes, e.g., ``` deep_convection=am,microphysics=thompson...

> 1. "non-standard" fieldnames like "T" and "state_T" (for example) introduce unwanted ambiguity I've been wondering about this, especially with names such as "state_T" which are from a very specific...