Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement cf names for all gsw functions #14

Closed
rcaneill opened this issue Feb 1, 2022 · 6 comments · Fixed by #31
Closed

Implement cf names for all gsw functions #14

rcaneill opened this issue Feb 1, 2022 · 6 comments · Fixed by #31
Assignees
Milestone

Comments

@rcaneill
Copy link
Collaborator

rcaneill commented Feb 1, 2022

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 + ...
@rcaneill rcaneill added this to the Version 0.2.0 milestone Feb 1, 2022
@rcaneill rcaneill self-assigned this Feb 5, 2022
@DocOtak
Copy link
Owner

DocOtak commented Feb 5, 2022

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
Copy link
Collaborator Author

rcaneill commented Feb 5, 2022

Ok, we can keep it alphabetical then.

@DocOtak
Copy link
Owner

DocOtak commented Feb 5, 2022

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
Copy link
Collaborator Author

rcaneill commented Feb 6, 2022

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
Copy link
Collaborator Author

rcaneill commented Feb 6, 2022

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

@rcaneill
Copy link
Collaborator Author

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

@rcaneill rcaneill linked a pull request Mar 3, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants