Add 2D lat/lon vars to history

[slevis-lmwg]

Description of changes

Add 2D lat/lon vars to src/main/histFileMod.F90 Useful when running on irregular grids.

Specific notes

Contributors other than yourself, if any: @mvertens @ekluzek @billsacks

CTSM Issues Fixed (include github issue #): #1813

Are answers expected to change (and if so in what way)? No but 2D lat/lon variables will now appear in history.

Any User Interface Changes (namelist or namelist defaults changes)? No.

Testing performed, if any: Ran a case on an irregular grid. Confirmed that 2D lat/lon variables now appear in history. Their x, y coordinates are still wrong.

For the concern of filling up disk space, I could write the 2D lat/lon variables in the first time step only. It's more complicated to figure out whether the 2D variables are needed at all. We'd need to loop through lat values in a row (or lon values in a column) and confirm that there are multiple values (other than the missing value).

[ekluzek]

@slevisconsulting there is a convention that these variables (LATIXY and LONGXY) should be in caps. Most of our files that have them are in caps. From this UNIDATA report I found on a Google search it seems to be a standard as well...

https://rda.ucar.edu/thredds/uddc/files/g/ds314.3/1901_1909/clmforc.cruncep.V7.c2016.0.5d.Prec.1908-08.nc?catalog=https://rda.ucar.edu/thredds/catalog/files/g/ds314.3/1901_1909/catalog.html&dataset=files/g/ds314.3/1901_1909/clmforc.cruncep.V7.c2016.0.5d.Prec.1908-08.nc

[slevis-lmwg]

This far my code mods are simple and they work BUT I have eliminated the lat/lon coordinates because they were 1D and I haven't, yet, found a way to make them 2D. So I have kept lat/lon as dimensions and LATIXY/LONGXY as variables.

I will need to research this more, and I'm open to suggestions.

Oh, by the way, I looked in the fsurdat file and found that we have lat/lon as dimensions and LATIXY/LONGXY as variables, but no lat/lon coords.

UPDATE: From this site I get the sense that we could add a coordinates = "LONGXY LATIXY ..." attribute to history variables to solve the loss of lat/lon as coordiates:

dimensions:
    MT = UNLIMITED ; // (1 currently)
    Y = 850 ;
    X = 712 ;
    Depth = 10 ;
variables:
    double MT(MT) ;
            MT:units = "days since 1900-12-31 00:00:00" ;
    double Date(MT) ;
            Date:units = "day as %Y%m%d.%f" ;
    float Depth(Depth) ;
            Depth:units = "m" ;
            Depth:positive = "down" ;
    int Y(Y) ;
            Y:axis = "Y" ;
    int X(X) ;
            X:axis = "X" ;
    float Latitude(Y, X) ;
            Latitude:units = "degrees_north" ;
    float Longitude(Y, X) ;
            Longitude:units = "degrees_east" ;
    float temperature(MT, Depth, Y, X) ;
            temperature:coordinates = "Longitude Latitude Date" ;
            temperature:standard_name = "sea_water_potential_temperature" ;
            temperature:units = "degC" ;
    float salinity(MT, Depth, Y, X) ;
            salinity:coordinates = "Longitude Latitude Date" ;
            salinity:standard_name = "sea_water_salinity" ;
            salinity:units = "psu" ;

[ekluzek]

Here's the CF convention which gets into how these conventions work: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.9/cf-conventions.html

[billsacks]

For what it's worth, CISM uses the "coordinates" attribute on variables like you mention @slevisconsulting - e.g., see /glade/p/cesmdata/cseg/inputdata/glc/cism/Greenland/greenland_4km_epsg3413_c171126.nc (though that appears to just be on input files, not on the history output files, for whatever reason).