EAMxx: long_name attribute missing in output using _horiz_avg reducer

[bogensch]

I noticed that long_name attribute (in addition to standard_name) is missing from variables with the _horiz_avg reducer. Below is header output for the same variable at full resolution and using horiz_avg :

        float surface_upward_latent_heat_flux_horiz_avg(time) ;
                surface_upward_latent_heat_flux_horiz_avg:units = "W/m2" ;
                surface_upward_latent_heat_flux_horiz_avg:_FillValue = 3.402824e+33f ;
                surface_upward_latent_heat_flux_horiz_avg:averaging_count_tracker = "avg_count" ;
                surface_upward_latent_heat_flux_horiz_avg:long_name = "MISSING" ;
                surface_upward_latent_heat_flux_horiz_avg:standard_name = "MISSING" ;
                surface_upward_latent_heat_flux_horiz_avg:cell_methods = "time: mean" 

        float surface_upward_latent_heat_flux(time, ncol) ;
                surface_upward_latent_heat_flux:units = "W/m2" ;
                surface_upward_latent_heat_flux:_FillValue = 3.402824e+33f ;
                surface_upward_latent_heat_flux:averaging_count_tracker = "avg_count_ncol" ;
                surface_upward_latent_heat_flux:long_name = "upward latent heat flux at the surface" ;
                surface_upward_latent_heat_flux:standard_name = "surface_upward_latent_heat_flux" ;
                surface_upward_latent_heat_flux:cell_methods = "time: mean" ;
                surface_upward_latent_heat_flux:coordinates = "lat lon" ;

It would be helpful for diagnostics if this was fixed.

[AaronDonahue]

I'm not sure how easy it would be, but we should probably have conditional diagnostics use the metadata associated with the variable they are based on, if possible. That is a tricky one though, because what metadata would be use for our more complicated conditional diagnostics that involve vertical averaging?

[bartgol]

That's a good question: for certain diags we prob should store a valid standard/lon name, as there is one readily avail (e.g., potential temperature, exner, rad fluxes, etc). But for "reduction" type diags, what should the std/long name be? I suppose the best choice would be ${field_name}_${reduction} (so in this case, for field blahblah, it would be blahblah_horiz_avg), but is that a "standard" name? Maybe it works for long name though.

[mahf708]

Two orthogonal thoughts:

1. I think the farthest we can go here is to simply pipe info by having some sort of a sophisticated regex, and this will have lots of limitations
2. To my disappointment, I think our "with-code" solution to IO metadata is no longer good enough. We can keep it as-is, but I propose we allow the user to bring their metadata as well. Just like we now allow users to alias IO names and all that, we could allow users to specify their choice of metadata.

A meta point: I think the old way of doing metadata and standards and all that is going to be hard to keep in our model because we have decided to go all out for flexibility and online diagnostics (something I fully support). I thus am thinking, from a dev standpoint, we can punt this to users even further by making a copy of this metadata available (and editable) in the case directory