DocOtak / gsw-xarray

Wrapper for gsw that will add CF attributes to xarray.DataArray outputs
https://gsw-xarray.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
23 stars 3 forks source link

Implement cf names for all gsw functions #14

Closed rcaneill closed 2 years ago

rcaneill commented 2 years ago

We should write the list of all functions and standard names attributes. To keep the file _cf_names.py organized, we can maybe follow the gsw organization (i.e. splitting functions into density, ice, etc), e.g.

_density = (("sigma0", "sea_water_sigma_t", "kg m-3"), ("other_density_func", "std_nme", "unit"))
_ice = (("ice_func", "std_nme", "unit"),)
_func_standard_name_units = _density + _ice + ...
DocOtak commented 2 years ago

I'm not too sure about this one. The upstream gsw docs warn against using the sub modules so I'd rather not codify it here. The C version just has everything in alphabetical order by function name.

There are not standard names for every gsw function either. Though there is a proposal process if we want to add new names.

rcaneill commented 2 years ago

Ok, we can keep it alphabetical then.

DocOtak commented 2 years ago

Your draft PR clarified what you meant by "wrap all functions" and I agree it is a good idea, especially to prevent pass through of attributes that would be incorrect for the output of some gsw function.

Do you have ideas on how we should handle the situations where the inputs to the function can change or invalidate the standard name? (e.g. if the optional parameters of the z_from_p or p_from_z are not 0)

rcaneill commented 2 years ago

Do you have ideas on how we should handle the situations where the inputs to the function can change or invalidate the standard name? (e.g. if the optional parameters of the z_from_p or p_from_z are not 0)

Good question. I think that we could start by listing the number of "weird" functions, and depending on the number of them think about either 1) hardcode these special cases (if only a small number are problematic) or 2) find another solution.

Another problem that will arise is that some functions (e.g. CT_first_derivatives) return a list of arrays. In this case, we can probably have lists of names and units in the _func_standard_name_units, and iterate through them to assign them to the proper output arrays.

rcaneill commented 2 years ago

I made a test that would solve the issue that all functions don't produce the same number of attributes in PR #22

rcaneill commented 2 years ago

I'll work on this using #28 as soon as #27 is merged