Closed efiring closed 7 years ago
PaulMBarker
commented
7 years ago the codes that appear in C only are subroutines that probably are at the end of one of the functions. eg. pt_from_pot_enthalpy_ice_poly_dh is a subroutine in pt_from_pot_enthalpy_ice
PaulMBarker
commented
7 years ago we added the extra inputs to z_from_p in a more recent version of the programme, adding dynamic height improves the accuracy of the calculation.
efiring
commented
7 years ago @PaulMBarker Thanks for the info. I completely forgot to check for subroutines.
hylandg
commented
7 years ago The 2 temperature freezing functions
are Fortran specific (as per https://github.com/TEOS-10/GSW-Fortran/issues/4) and within the C-code could be renamed to
without loss of functionality.
efiring
commented
7 years ago Closed by #10.
I am working on an automated wrapping of the C code in Python, in the course of which I find some C functions that could be updated in various ways to better match the matlab, and some functions that I suspect are left over from earlier versions; they have no matching m-files. The functions I have encountered so far are:
In C only? Obsolete? Delete?
Extra (optional) arguments in matlab:
I could make PRs for such changes to bring the C closer to the current matlab; would they be welcome? (I would probably not do anything about optional output arguments; in the one case that comes to mind, it is a nearly-useless validity flag that can be obtained separately.) The method to be used for handling optional arguments is open to discussion. Options include using separate functions for each signature, or using a single variadic signature.
My priority is in the basic functionality, especially the simple scalar functions; for some of the more complex functions, including most that operate on profiles, I think that re-implementation in Python will be adequate for my purposes.