Update regridder.grid property to ensure cf compliant coordinates

[tomvothecoder]

Description

• Closes [Bug]: Getting data CF-compliant for regridding (with xesmf) #718

This pull request introduces a new feature to ensure CF-compliance of coordinate variables in the regridder module. xESMF requires coordinates to be CF-compliant in order to map to them using CF-xarray.

Key changes include:

New Feature Implementation:

• xcdat/regridder/accessor.py: Added the _ensure_cf_compliance method to ensure coordinate variables have the "axis" and "standard_name" attributes required for CF-compliance. This method is now called within _get_axis_data.

Test Enhancements:

• tests/test_regrid.py: Added a new test test_grid_adds_cf_attributes_to_non_cf_compliant_coords to verify that the regridder correctly adds CF attributes to non-compliant coordinates.

Import Adjustments:

• xcdat/regridder/accessor.py: Updated imports to include CF_ATTR_MAP for mapping CF attributes.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

If applicable:

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass with my changes (locally and CI/CD build)
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have noted that this is a breaking change for a major release (fix or feature that would cause existing functionality to not work as expected)

[tomvothecoder]

Hey @pochedls and @jasonb5, this PR fixes #718. Can you test and review?

I'd like to get this merged in the next day or two.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (8824b32) to head (69896f1).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #736   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           15        15           
  Lines         1621      1630    +9     
=========================================
+ Hits          1621      1630    +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jasonb5]

Hey @pochedls and @jasonb5, this PR fixes #718. Can you test and review?

I'd like to get this merged in the next day or two.

I will review this PR today.

[pochedls]

Things are working now, but I think there is still an issue. Take a look at the map from xcdat (this PR):

compared to calling xesmf directly:

A vague idea/possibility: In curvilinear grids lat/lon are often represented as an index (e.g., [0, 1, 2, ...]) for latitude["lat", "lon"] and longitude["lat", "lon"]. I'm wondering if the regridder is interpreting lat (the index) as the source grid points instead of the actual latitude values that are a function of lat/lon. [I might have lat/latitude reversed in this example, but something like this may be going on].

[tomvothecoder]

@pochedls Thanks Steve. It looks like we need more work on this. I'll push back the release of v0.8.0 depending on when the next E3SM Unified is released (which is probably being pushed back from 2/15)

A vague idea/possibility: In curvilinear grids lat/lon are often represented as an index (e.g., [0, 1, 2, ...]) for latitude["lat", "lon"] and longitude["lat", "lon"]. I'm wondering if the regridder is interpreting lat (the index) as the source grid points instead of the actual latitude values that are a function of lat/lon. [I might have lat/latitude reversed in this example, but something like this may be going on].

Hmm this is a good question. I'll step through the code to see which values are being used for latitude.

[tomvothecoder]

A vague idea/possibility: In curvilinear grids lat/lon are often represented as an index (e.g., [0, 1, 2, ...]) for latitude["lat", "lon"] and longitude["lat", "lon"]. I'm wondering if the regridder is interpreting lat (the index) as the source grid points instead of the actual latitude values that are a function of lat/lon. [I might have lat/latitude reversed in this example, but something like this may be going on].

I explain the issue here. You're correct, nlat and nlon are being used to represent the grid because they are considered the index/dimension coordinates. However, these coordinates contain integers representing the indices of the coordinates. lat and lon are ancillary coordinates and contain the actual values that are needed for regridding with xESMF.

This is mainly a metadata/coordinates issue rather than an issue in xCDAT's logic. We'll need to think more carefully about how we can retrieve lat and lon since they are ancillary coordinates. The regridder.grid property calls _get_axis_data() which then calls xc.get_dim_coords() (only gets dimension coordinates).

[jasonb5]

LGTM

Thanks @tomvothecoder @pochedls

[tomvothecoder]

More work needs to be done based on @jasonb5's comment here: #718 (comment)