handle updated TEOS-10 formulae about gsw-r

[dankelley]

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]

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]

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: [phone]
    Shipboard Technical Support | Computing Resources

Scripps Institution of Oceanography | Nimitz Marine Facility
297 Rosecrans Street |
San Diego, Ca. 92106 | [email protected]

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]

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]

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]

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