Use MIP-compliant variable names and units by default

[billsacks]

From discussions on improving the usability of CESM output last year, one request that emerged was outputting standard MIP-compliant variable names and units by default, removing (or at least greatly reducing) the need for a separate CMORization step in post-processing model output.

Recent input from Gary Strand:

It's the translation from CESM native names/units to MIP-compliant names/units that's fraught with error and the real problem. Native MIP output would also make participating in MIPs a whole lot easier - all that would then be needed to submit data to a MIP would be to add any required metadata ("ncatted" calls will do that) and rename timeseries files. Any run anyone could choose to do would be very easy to compare to our CMIP3/CMIP5/CMIP6 runs plus all the other runs by other modeling groups. I've had requests for the scripts to convert CESM output to CMIP6-compliant format and what we have simply doesn't work anywhere other than cheyenne and is very interwoven with HPC environment here. That undercuts the community aspect of CESM.

The downsides to native MIP compliance are:
(a) Rewriting all the output calls across all the components (CICE excepted; Dave's already done that) to meet MIP-compliant names and units would be a big task. Some would be straightforward ("ts" == "TS") but others much less so - those atm fields that require vertical interpolation, for example. We do have all the necessary calculations available, so that's good.
(b) All CESM-name-specific analysis codes will no longer work. All the WG diagnostics plus CVDP (unless I'm mistaken, Adam). Packages that expect POP cgs "TEMP" won't like mks "thetao", for example.
(c) A bigger issue is that not all fields that CESM can output have MIP equivalents - ocean BGC fields and chemistry fields in particular. The process to add fields to the CF standard list isn't fast and is done by volunteers on a very part-time basis.
(d) And, of course, it's not practical to rerun the model if a MIP-compliant field comes out incorrectly and can't be fixed.

However, in my mind, (c) and (d) are not actually drawbacks: they just imply that it will hard to be perfect in this endeavor. (a) and (b) point out a significant up-front cost, but if we don't do this, we'll be stuck maintaining the CMORization scripts, which may be a similar cost over the long-term.

• For CTSM, see CMORize names and units in history fields and make units UDUNITS compliant CTSM#973

[billsacks]

This doesn't seem to be high enough priority that it will happen anytime soon. I'm going to close it as a wontfix; we can always reopen it later if it becomes wanted.