Add Var.are_compatible for FlatVar and Metadata

[ph-kev]

This functionality is needed in ClimaCalibrate for comparing two different FlatVar or Metadata and determining whether they are compatible on physical space and the values dropped are on the same coordinates. The function arecompatible for FlatVar and Metadata is needed to avoid accessing drop_mask from the Metadata which is internal to ClimaAnalysis.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.50%. Comparing base (db0b943) to head (471b642).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #409   +/-   ##
=======================================
  Coverage   99.49%   99.50%           
=======================================
  Files          19       19           
  Lines        2181     2201   +20     
=======================================
+ Hits         2170     2190   +20     
  Misses         11       11           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[nefrathenrici]

This looks good. I'm a bit confused about how ignore_dims is meant to be used, since there are three checks and it only blocks one. For example, if vars differ in the flatten order or the drop mask, arecompatible will return false even though the specific dimension has been "ignored". The docstring is precisely worded, but it would be good to add a single line that differing flatten orders or drop masks will make the vars incompatible.

[ph-kev]

This looks good. I'm a bit confused about how ignore_dims is meant to be used, since there are three checks and it only blocks one. For example, if vars differ in the flatten order or the drop mask, arecompatible will return false even though the specific dimension has been "ignored". The docstring is precisely worded, but it would be good to add a single line that differing flatten orders or drop masks will make the vars incompatible.

I am confused on what three checks you are referring to. One way of thinking about what it means for two FlatVars to be arecompatible is that it makes sense to do operations (addition) with them. I don't think it makes sense to ignore the dimensions in the flatten order since it wouldn't really make sense to do operations between them. Similarly, if values are on different coordinates, it also doesn't make sense to do operations with them. So, the only purpose of ignore_dims is to give people an out when ignoring coordinate values of the dimensions (and since the check is in for loop, also ignoring the dimension units).

[nefrathenrici]

I am confused on what three checks you are referring to. One way of thinking about what it means for two FlatVars to be arecompatible is that it makes sense to do operations (addition) with them. I don't think it makes sense to ignore the dimensions in the flatten order since it wouldn't really make sense to do operations between them. Similarly, if values are on different coordinates, it also doesn't make sense to do operations with them. So, the only purpose of ignore_dims is to give people an out when ignoring coordinate values of the dimensions (and since the check is in for loop, also ignoring the dimension units).

Ok, thanks for the explanation, the behavior makes sense. The three checks I meant are: flatten order, per-dimension coordinate values + units, and the drop mask. A differing flatten order or drop mask would make the vars incompatible so we shouldn't ignore them.

[ph-kev]

Note that this PR haven't been merged since CliMA/ClimaCalibrate.jl#334 isn't merged in. Once that PR is ready to be merged, this PR can be merged in.