Python implementation of TEOS-10: comparison, strategy

[DamienIrving]

I was talking to the authors of TEOS-10 (McDougall and Barker) and they were saying that there are errors in the Python implementation of TEOS-10 contained in this repo. They say that the only trustworthy versions of TEOS-10 code (for any language) are found at the TEOS-10 website (i.e. and not on GitHub at the TEOS-10 organisation page).

Since they have a C version of the code available at the TEOS-10 website, I'm wondering if anyone is planning to write a python wrapper for it?

In the meantime, should this repo be taken down? I know people (including myself) who install gsw as follows, completely unaware of any errors with the code:

conda config --add channels conda-forge
conda install gsw 

[durack1]

@DamienIrving do you have some more specifics about the "errors"?

[DamienIrving]

@PaulMBarker - Are you able to help out with @durack1's question. Do all the functions have errors, or just some of them?

[efiring]

The C version is a scalar translation of the Fortran-90 version, so I don't think it forms a good basis for Python wrappers. I have no confidence that it will even be maintained.
The python version is based on earlier versions of the matlab code, and is incomplete compared to the matlab code. I am not aware of actual errors in the python version, however, other than those I documented in #10--which reflect differences between versions of the matlab code.
The python version needs considerable work, but not deletion from github.

Edit: as noted below, I have changed my mind about wrapping the C version; we may end up doing this in the Python version for a large subset of the functions, including all of the core polynomial evaluations.

[PaulMBarker]

We are looking for someone to maintain the C version, even if it requires us to pay them.
I have had reports that the C version works with Python and it passes gsw_check_functions,
I have no idea if that is true for python.

I received this a few months ago:
"Among the differences between the python and the C gsw, for instance, I realized that the python code still uses a 48 polynomial to derive specific volume (versus the 75 one in the C code) resulting in density differences of ~5e-4."

When a package passes check_functions I am more than willing to add a zipped version of it to the TEOS-10 website for distribution.

The ONLY place where software should be downloaded from is the TEOS-10 website. We have a responsibility that any software we distribute is correct. (R is the exception to this and I know I need to add a link to the R version but I have been flat out.)

Paul.

[castelao]

I agree with @efiring that it's not a reason to delete the repository. Python-GSW is classified as beta, right? We should be able to handle this in the traditional way, opening issues and PRs.

What are the confirmed errors? Do we have an issue opened for each of those known errors with details?

@efiring , how can I help you? I can figure out some time to help with this.

[efiring]

@castelao The fundamental problem is that TEOS-10 is an enormous conglomeration of code and documentation, that has gone through several versions via massive changes. The Python implementation has not kept up. There is some discussion of this, including identification of failing checks, in #10. To date, neither @ocefpaf nor I have had the rather large chunk of time that would be required to bring everything up to version 3.05. In addition, there is probably still some work needed on tools for automatically translating the documentation from the Matlab to the Python--ideally.
In the spirit of patching things up rather than trying for a complete and clean solution, it seems we need to identify exactly which functions need to be replaced entirely because they use newer algorithms, and then which ones need to be modified to use these new versions. The core information may already be in the discussion on #10. The starting point is an existing PR, #7, which is a first crack at translating the new core algorithm, but which needs quite a bit of work before it will be ready.

[PaulMBarker]

Being that it is a beta, until this work is done, how do we stop users downloading it and using it as though it is "blessed" code?

[efiring]

Building a python version via wrappers around the C or Fortran is always an option. Of the two, the C is easier to deal with, especially if one wants to be able to compile on Windows. A reasonable approach would be to come up with an engine for generating vectorized cython wrappers to the scalar C functions that are needed by users. This should not be terribly difficult, because there are only a few signatures that need to be supported. But it is still an almost total restart--a new project--and it has the disadvantage of being harder to build and install than the present pure-Python approach.

[efiring]

@PaulMBarker we don't. That is just not the way things work, and not the way to make progress. Really, how much damage is being done by people using the 48 polynomial that used to be "blessed"? If you really think this is a crisis, and you want to take action, you could ask @ocefpaf to stop packaging it for conda.

[durack1]

@efiring @castelao just FYI I have been keeping track of the versioning of the GSW-Matlab releases in my personal repo https://github.com/durack1/GSW-Matlab/releases. This should provide a way of determining changes dating back to v1.0 and most importantly all the incremental changes within the v3.05 release (there have been 8 updates to date)

[ocefpaf]

Apologies for not addressing the concerns here earlier. (I am moving to another city and I am out for a few weeks.)

Like @efiring mention I do not have time for this project due to my day job. I would love to work on python-gsw again as this has a special place in my heart. (gsw was my first Python project back when I was learning Python from awesome expert developers like @efiring and Bjørn Ådlandsvik.)

I failed to bring more developers to this project and the development is halted for many years now.
However, even incomplete and outdated, there are many projects out there that rely on this library, and I am reluctant to remove it. I would love to find funds to move this project forward though.

So my suggestion is to keep the unofficial status, maybe add a caveat note until I can find funds or extra time to bring tis library up to date with latest Matlab gsw.

PS: For those interested in the c wrapper I suggest you contact @lukecampbell and ask about his goals for that library. Maybe he can take up on the offer to updated it.

[durack1]

@PaulMBarker if I was to vote, I believe that if any funds are available to update the TEOS-10 libraries, python (and not the C or fortran) is the language that is prioritized.. Removing the need for compilation (in the case of C or fortran) and also having a platform independent (and open source, rather than matlab licensed) version is a far superior solution

[richardsc]

I realize this is probably not the appropriate place for this discussion (i.e. we've gone off topic, which I tend to discourage in Github issues for repos that I myself maintain ...), but I think this is a great discussion.

If priority was being assigned to a particular TEOS-10 language implementation, I'd disagree with @durack1 that python should be prioritized, but rather believe that maintaining and fully implementing the TEOS work in C would be the most beneficial to the entire community. This is not because I dislike python (python is great!) or because I mainly use R (I also love R!) but because each of those languages provide the facility for including C code (to my understanding Matlab can do this too, but I do agree with @durack1 about the license issue).

Yes, compilation is potentially a barrier, but only for developers and testers, and shouldn't affect downstream users. E.g. for R, installing packages that include C code through the regular package distribution system (CRAN) enables access to pre-compiled binaries for each platform (this is the case for the GSW-R library). My understanding of python package managers is limited, but I understood that conda and the like do the same (please correct me if I'm wrong).

Another reason that I understood for supporting "lower level" implementations is that they are then available to be included directly in primitive equation models (not likely to be coded in python or another interpreted language). Of course, many commonly used models are in Fortran, which complicates that argument ...

[durack1]

@richardsc interesting perspective, which I have trouble disagreeing with.. I do note however that there are 4045 noted downloads for the conda-forge gsw implementation which is a pretty decent number (and 10/11 repo forks versus 2 each for fortran, c and R, and 1 for JS).. So it certainly does appear to be the highest volume language variant. I'd be curious about the total download count for the other package flavours.. I wonder if @PaulMBarker has these stats from the TEOS-10 homepage to interrogate?