Closed dankelley closed 9 years ago
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
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.
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 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 https://github.com/TEOS-10/GSW-R/issues/12#issuecomment-105213803.
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.
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 https://github.com/TEOS-10/GSW-R/issues/12#issuecomment-139001958.
I'm opening a new, better-titled issue for the transition, and closing this one.
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 onR 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 thegsw
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,
(where the comment is the value stated in the old TEOS-10 docs) yields
yielding fractional change in density with change in formulation:
being
which seems quite small. To get some context, lets add a tiny bit to
SA
(smaller than experimental uncertainty, I think)from which we get
Expressed as fractional change
this data-perturbation yields density fractional change
which is about 80 times the fractional change associated with the algorithmic improvement.