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

handle updated TEOS-10 formulae #12

Closed
dankelley opened this issue May 23, 2015 · 6 comments
Closed

handle updated TEOS-10 formulae #12

dankelley opened this issue May 23, 2015 · 6 comments
Assignees

Comments

@dankelley
Copy link
Contributor

TEOS-10 has been updated. So far, the code is only available in matlab, but when it becomes available in C, it would make sense to incorporate this into the gsw R package.

At the moment, the gsw help pages that link to the TEOS-10 function webpages are still working (based on R CMD check --as-cran gsw_1.0-4.tar.gz with newly-build tarball). It seems that no URLs were made obsolete. However, the contents have changed. I don't think this is a huge problem because the TEOS-10 webpages clearly designate the order of the polynomial used, and so do the gsw help pages.

To satisfy my curiosity, I did a somewhat random and very isolated test. The results, shown below, suggest that (again, in this particular test) the new formula for density will yield changes that are swamped by density variations resulting from altering salinity at the limit of measurement.

First,

gsw_sigma0(34.7118, 28.8099) # 21.798411276610750

(where the comment is the value stated in the old TEOS-10 docs) yields

[1] 21.79841

yielding fractional change in density with change in formulation:

2*(21.79841-21.798411276610750)/(21.79841+ 21.798411276610750)

being

[1] -5.85644e-08

which seems quite small. To get some context, lets add a tiny bit to SA (smaller than experimental uncertainty, I think)

gsw_sigma0(34.7118+0.0005, 28.8099) # 21.798411276610750

from which we get

[1] 21.79878

Expressed as fractional change

0.5*(21.79878-21.798411276610750)/(21.79878+ 21.798411276610750)

this data-perturbation yields density fractional change

[1] 4.228752e-06

which is about 80 times the fractional change associated with the algorithmic improvement.

@dankelley dankelley self-assigned this May 23, 2015
@dankelley
Copy link
Contributor Author

More refined calculation.

For further context on this, I looked up the SBE 911 ctd specs. They state an accuracy for conductivity of plus/minus 0.0003 S/m. To get an idea of the change in salinity, I did as follows.

> library(gsw)
> swSCTp(4,15,100,conductivityUnit="S/m")
[1] 32.31857
> swSCTp(4+0.0003,15,100,conductivityUnit="S/m")
[1] 32.32127

Thus, it looks as though the error in Practical Salinity is

> 32.32127 - 32.31857
[1] 0.0027

Rounding this value yields fractional density error associated with errors in salinity measurement

> A<-gsw_sigma0(34.7118, 28.8099)
> B<-gsw_sigma0(34.7118+0.003, 28.8099)
> 2*(A-B)/(A+B)
[1] -0.0001009117

which is to be compared with the fractional change for switching to the new formula

> 2*(21.79841-21.798411276610750)/(21.79841+ 21.798411276610750)
[1] -5.85644e-08

Thus, the ratio of error from data to improvement via new formula is

> 0.0001009117 / 5.85644e-08
[1] 1723.089

@richardsc
Copy link
Contributor

Note that version 3.05 of the GSW-C has been pushed, so we could start work any time merging the new C functions into GSW-R.

I'd sort of like to wait a while (weeks, maybe months) for things to settle on the C end. It seems inevitable that there will be a fair bit of work for us. And CRAN won't want us releasing something and then re-releasing in a few weeks. I'd like to see the C project go without updates for a reasonable time before starting to upgrade. Otherwise we'll need to keep tracking the C project daily, deciding whether to tweak things. Another factor is that I think (could be wrong!) that the change for practical work is going to be minimal, in the sense that some of our previous tests have shown that the changes in calculated results will likely be smaller than the changes in altering the final digit in typical data files.

@fdelahoyde
Copy link

SeaBird conductivity sensors are calibrated by comparing salinities calculated
from conductivity measurements to salinities measured by a laboratory
salinometer (typically a Guildline Autosal which has an accuracy of +/- 0.002
PSU). The precision of the SBE sensor is about an order of magnitude better
than the reported accuracy.

Frank

            Frank Delahoyde | Phone: 858.534.9562
    Shipboard Technical Support | Computing Resources

Scripps Institution of Oceanography | Nimitz Marine Facility
297 Rosecrans Street |
San Diego, Ca. 92106 | fdelahoyde@ucsd.edu

On 5/25/15 4:25 AM, Dan Kelley wrote:

For further context on this, I looked up the SBE 911 ctd specs
http://www.seabird.com/sbe911plus-ctd. They state an accuracy for conductivity
of plus/minus 0.0003 S/m. To get an idea of the change in salinity, I did as
follows.

library(gsw)
swSCTp(4,15,100,conductivityUnit="S/m")
[1] 32.31857
swSCTp(4+0.0003,15,100,conductivityUnit="S/m")
[1] 32.32127

Thus, it looks as though the error in Practical Salinity is about 0.003. This is
10X the uncertainty assumed above. This suggests that -- at least for this
example -- the density change associated with the switch in gsw formula will be
4000 times smaller than the uncertainty in density value for measured data.


Reply to this email directly or view it on GitHub
#12 (comment).

@dankelley
Copy link
Contributor Author

Hi Frank. Any advice on when we should incorporate the new C code for the R version? As noted in these github comments, there's a fair bit of inertia at CRAN, the repository for R packages, so we'd want to be fairly sure things are stable before making a release. My teaching starts in 2 days, so I'd be pretty happy to wait a few weeks until that settles a little.

Actually, the largest part of the work will be redoing all the documentation and test code. R is really big on that. The way we did that was by cut/paste from the GSW webpages, with manual alterations to change matlab to R. That is a bit slow, but these self-tests are one of the best things about R packaging.

@fdelahoyde
Copy link

Hi Dan,

I believe the code is stable, or at least having the same bugs as the Fortran 90
version. Paul Barker has yet to put it on teos-10.org though, so you might want
to wait for that to happen.

Frank

On 9/9/15 11:41 AM, Dan Kelley wrote:

Hi Frank. Any advice on when we should incorporate the new C code for the R
version? As noted in these github comments, there's a fair bit of inertia at
CRAN, the repository for R packages, so we'd want to be fairly sure things are
stable before making a release. My teaching starts in 2 days, so I'd be pretty
happy to wait a few weeks until that settles a little.

Actually, the largest part of the work will be redoing all the documentation and
test code. R is really big on that. The way we did that was by cut/paste from
the GSW webpages, with manual alterations to change matlab to R. That is a bit
slow, but these self-tests are one of the best things about R packaging.


Reply to this email directly or view it on GitHub
#12 (comment).

@dankelley
Copy link
Contributor Author

I'm opening a new, better-titled issue for the transition, and closing this one.

@dankelley dankelley mentioned this issue Sep 10, 2015
61 tasks
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

No branches or pull requests

3 participants