Add regridding method as a per-variable attribute to History output?

[mathomp4]

In looking at the new-ish regrid_method for History (see GEOS-ESM/GEOSgcm_App#344) I thought of something. We can put in HISTORY.rc that collection foo is regridded conservatively or bilinear or whatever, but as far as I can see, we have no way of knowing that in the history output itself.

ETA: This was rewritten after consulting @tclune and @bena-nasa to say we should instead maybe add it to the variable attributes as we could eventually regrid each variable in a collection in a different way.

So now we have, say:

        float T(time, lev, lat, lon) ;
                T:_FillValue = 1.e+15f ;
                T:add_offset = 0.f ;
                T:fmissing_value = 1.e+15f ;
                T:long_name = "air_temperature" ;
                T:missing_value = 1.e+15f ;
                T:scale_factor = 1.f ;
                T:standard_name = "air_temperature" ;
                T:units = "K" ;
                T:valid_range = -1.e+15f, 1.e+15f ;
                T:vmax = 1.e+15f ;
                T:vmin = -1.e+15f ;

and then we could add:

                T:regrid_method = "bilinear" ;

or whatever. (This does seem legal per the CF Conventions for "extra" attributes:

This standard describes many attributes (some mandatory, others optional), but a file may also contain non-standard attributes. Such attributes do not represent a violation of this standard. Application programs should ignore attributes that they do not recognise or which are irrelevant for their purposes.

I guess the question is: would this be desirable? I mean, in a way it isn't needed if the HISTORY.rc that made the collection is available or if the File Spec notes it. Or maybe it doesn't actually matter? I mean, we've decided how to regrid the collection that we'll present to the users, the end user I suppose shouldn't care since it's been regridded for them.

Of course, it's also not hard for someone to do this after the fact with ncatted, say, either. But if it would be desired, it would be simple for MAPL to do this.

I suppose I now summon @tclune and @bena-nasa for their thoughts.

[mathomp4]

Another thought: Should this be MAPL2 or MAPL3? I mean, it is "zero-diff" in that it doesn't change the output, but it does change the metadata of variables. Well, it adds to the metadata of the variables.

And I suppose I should invoke the name of @sdrabenh and get his opinions on this. In a way it's a sort of "sister" PR to GEOS-ESM/GEOSgcm_App#344

[tclune]

Not really a MAPL 2 vs 3 type of issue. More of a History vs History NG type of thing. But need @bena-nasa and or @atrayanov to comment on whether there might be some fundamental reasons why this is difficult or undesirable. We certainly want all fields in a collection to be on the same grid, so maybe we need constant regrid method for some similar reason.

[sdrabenh]

And I suppose I should invoke the name of @sdrabenh and get his opinions on this. In a way it's a sort of "sister" PR to GEOS-ESM/GEOSgcm_App#344

I would be in favor of adding a regrid_method attribute to the variables. I can't think of any downsides to this.

[mathomp4]

Well, it seems to work. I fiddled around with HISTORY.rc to change the methods and:

                H:regrid_method = "bilinear_monotonic" ;
...
                DMDTPHY:regrid_method = "conserve_monotonic" ;
...
                BCDP001:regrid_method = "conserve_2nd" ;
...

Now I suppose we get into stylistic choices. I did a pretty simple cut-paste-sed sort of change as can be seen in #1643, but it could be "more descriptive". I mean, instead of conserve_2nd we could do second-order conservative? I don't know. 🤷🏼

[mathomp4]

I suppose as well I should invoke the name of @lizziel and see if our GCHP colleagues would be opposed to this. Perhaps they have strict thoughts on variable metadata.

And then of course there is Ops...

[tclune]

This is just the tip of the proverbial iceberg in terms of providing provenance in our meta data. I'd err on the side of a more verbose string. And not sure the underscores are good.

Of course, if ESMF has names for these, we should probably just use those.

[mathomp4]

Of course, if ESMF has names for these, we should probably just use those.

Hmm. Good idea. Okay. Let us see in MAPL we have:

Regrid Constant	Description
REGRID_METHOD_IDENTITY
REGRID_METHOD_BILINEAR	bilinear
REGRID_METHOD_BILINEAR_ROTATE
REGRID_METHOD_CONSERVE	first-order conservative
REGRID_METHOD_VOTE
REGRID_METHOD_FRACTION
REGRID_METHOD_CONSERVE_2ND	second-order conservative
REGRID_METHOD_PATCH	higher-order patch
REGRID_METHOD_NEAREST_STOD	nearest source to destination
REGRID_METHOD_CONSERVE_HFLUX
REGRID_METHOD_BILINEAR_MONOTONIC	bilinear with monotonic something???
REGRID_METHOD_CONSERVE_MONOTONIC	first-order conservative with monotonic something???

Now of these 5 seem to be in ESMF (see https://earthsystemmodeling.org/docs/nightly/develop/ESMF_refdoc/node5.html#sec:regrid). Probably need @bena-nasa or @atrayano to speak up on the other ones.

I suppose if we want to go full-bore, we could even have:

                H:regrid_method = "bilinear_monotonic" ;
                H:regrid_method_constant = "REGRID_METHOD_BILINEAR_MONOTONIC" ;

though that might be a bit much.

[tclune]

Do not laugh. We may well find ourselves wanting to provide significantly more provenance:

• What grid did the data come from( native; cubed sphere; c720; ...)
• What is the regrid method
• What were the regrid options

In theory, the provenance would tell someone how to recreate the quantity (presuming that they had the native field to start with)

[lizziel]

I don't see any downsides to this update either. I tend to want more rather than less in the attributes.

[mathomp4]

I don't see any downsides to this update either. I tend to want more rather than less in the attributes.

Well, it's in MAPL 2.25! As @tclune says, more attributes will be coming no doubt, so if you have any suggestions...suggest away! :)