Closed rcaneill closed 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.
Ok, we can keep it alphabetical then.
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)
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.
I made a test that would solve the issue that all functions don't produce the same number of attributes in PR #22
I'll work on this using #28 as soon as #27 is merged
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.