teos-10 / gsw-r Goto Github PK

CF TEOS-10/GSW-Matlab#7.

Snipped from a developer email:

In the C library, file gsw_oceanographic_toolbox.c, the function gsw_ipv_vs_fnsquared_ratio() is using a value of p_ref that is neither defined in the function argument list nor in the code below it. I’ve put below a snippet. I think the behaviour in this case will be undefined. Some compilers might use 0 for the value of p_ref, but others might use some junk value that was in the system memory at the pointed-to address.
Note that p_ref is not defined before use.

void
gsw_ipv_vs_fnsquared_ratio(double *sa, double *ct, double *p, int nz,
double *ipv_vs_fnsquared_ratio, double *p_mid)
{
int k;

double dsa, sa_mid, dct, ct_mid, dp, p_ref;
double alpha_mid, beta_mid;
double alpha_pref, beta_pref, numerator, denominator;

for (k = 0; k < nz-1; k++) {
   dsa = (sa[k+1] - sa[k]);
   sa_mid = 0.5*(sa[k] + sa[k+1]);
   dct = (ct[k+1] - ct[k]);
   ct_mid = 0.5*(ct[k] + ct[k+1]);
   dp = (p[k+1] - p[k]);
   p_mid[k] = 0.5*(p[k] + p[k+1]);

   alpha_mid = gsw_alpha(sa_mid,ct_mid,p_mid[k]);
   beta_mid = gsw_beta(sa_mid,ct_mid,p_mid[k]);
   alpha_pref = gsw_alpha(sa_mid,ct_mid,p_ref);

Build fails on vignette building:

$ make gsw
rm gsw_*.tar.gz
R CMD build GSW-R
* checking for file ‘GSW-R/DESCRIPTION’ ... OK
* preparing ‘gsw’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
Loading required package: mapproj
Loading required package: maps
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  Running 'texi2dvi' on 'gsw.tex' failed.
BibTeX errors:
The top-level auxiliary file: gsw.aux
The style file: gsw.bst
I couldn't open database file gsw.bib
---line 29 of file gsw.aux
 : \bibdata{gsw
 :             }
I'm skipping whatever remains of this command
I found no database files---while reading file gsw.aux
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
make: *** [gsw] Error 1

Sample code

library(gsw)
print(gsw_SA_from_SP(SP=c(35, 35), p=c(100,100), longitude=c(-30,NA), latitude=c(45,30)))
print(gsw_CT_from_pt(c(35, NA), pt=c(10,11)))

yields

 *** caught segfault ***
address 0x7fefdc33c4e8, cause 'memory not mapped'

Traceback:
 1: .C("wrap_gsw_SA_from_SP", SP = as.double(l$SP), p = as.double(l$p),     longitude = as.double(l$longitude), latitude = as.double(l$latitude),     n = n, rval = double(n), NAOK = TRUE, package = "gsw")
 2: gsw_SA_from_SP(SP = c(35, 35), p = c(100, 100), longitude = c(-30,     NA), latitude = c(45, 30))
 3: print(gsw_SA_from_SP(SP = c(35, 35), p = c(100, 100), longitude = c(-30,     NA), latitude = c(45, 30)))
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault: 11

I am using R version 3.3.2 (2016-10-31)

When I have an NA value in my data I noticed:

gsw_SA_from_SP returns NA
gsw_CT_from_pt returns NaN

This seems inconsistent. Assume they should both return NA?

Great to have gsw in R! Thankyou!

I am new to Github. Hope I have done this right.

Regards
Abe

There should be an R interface to the calculation of seawater spiciness. The matrial below shows that it is there in the C code, but that no direct connection has been made to the R code.

src/GSW-R[master]$ git grep spic
src/gsw_oceanographic_toolbox.c:function gsw_spiciness0(sa,ct)  
src/gsw_oceanographic_toolbox.c:!  Calculates spiciness from Absolute Salinity and Conservative 
src/gsw_oceanographic_toolbox.c:!  spiciness0  =  spiciness referenced to a pressure of 0 dbar, 
src/gsw_oceanographic_toolbox.c:gsw_spiciness0(double sa, double ct)
src/gsw_oceanographic_toolbox.c:        double  xs, ys, spiciness0;
src/gsw_oceanographic_toolbox.c:        spiciness0= s01+ys*(s02+ys*(s03+ys*(s04+ys*(s05+ys*(s06+s07*ys)))))
src/gsw_oceanographic_toolbox.c:        return (spiciness0);
src/gsw_oceanographic_toolbox.c:function gsw_spiciness1(sa,ct)  
src/gsw_oceanographic_toolbox.c:!  Calculates spiciness from Absolute Salinity and Conservative 
src/gsw_oceanographic_toolbox.c:!  spiciness1  =  spiciness referenced to a pressure of 1000 dbar [ kg/m^3 ]
src/gsw_oceanographic_toolbox.c:gsw_spiciness1(double sa, double ct)
src/gsw_oceanographic_toolbox.c:        double  xs, ys, spiciness1;
src/gsw_oceanographic_toolbox.c:        spiciness1= s01+ys*(s02+ys*(s03+ys*(s04+ys*(s05+ys*(s06+s07*ys)))))
src/gsw_oceanographic_toolbox.c:        return (spiciness1);
src/gsw_oceanographic_toolbox.c:function gsw_spiciness2(sa,ct)  
src/gsw_oceanographic_toolbox.c:!  Calculates spiciness from Absolute Salinity and Conservative 
src/gsw_oceanographic_toolbox.c:!  spiciness2  =  spiciness referenced to a pressure of 2000 dbar [ kg/m^3 ]
src/gsw_oceanographic_toolbox.c:gsw_spiciness2(double sa, double ct)
src/gsw_oceanographic_toolbox.c:        double  xs, ys, spiciness2;
src/gsw_oceanographic_toolbox.c:        spiciness2= s01+ys*(s02+ys*(s03+ys*(s04+ys*(s05+ys*(s06+s07*ys)))))
src/gsw_oceanographic_toolbox.c:        return (spiciness2);
src/gswteos-10.h:extern double gsw_spiciness0(double sa, double ct);
src/gswteos-10.h:extern double gsw_spiciness1(double sa, double ct);
src/gswteos-10.h:extern double gsw_spiciness2(double sa, double ct);

I tried submitting the present version to CRAN, but got complaints as follows. The CRAN maintainers are quite stringent about such problems, and have asked me to address this "ASAP". (I was surprised that the complaint was not also about qsort_s, additionally, since that doesn't seem to be POSIX, either.) CRAN is quite stringent about these things.

qsort_r is not a standard C (nor POSIX) function: §1.6.4 of the manual told you to test for non-C functions. And your platform-specific code in the C file using this is not in the spirit of the CRAN policy:

'Package authors should make all reasonable efforts to provide cross-platform portable code.'

You cannot know what future versions of the OSes you pick out will provide!

Similarly, you should not be including a guessed prototype but using the system header: that seems to be stdlib.h, but glibc require _GNU_SOURCE (or perhaps similar for older versions) to be defined.

Issue #20 has a checklist that lists all the TEOS-10 functions, and that is not suitable, given the title of that issue. Therefore, I intend to break some things out to separate issues; here, that means ice-related functions. I developed the checklist based on http://www.teos-10.org/pubs/gsw/html/gsw_contents.html

• gsw_adiabatic_lapse_rate_ice
• gsw_alpha_wrt_t_ice
• gsw_cp_ice
• gsw_chem_potential_water_ice
• gsw_enthalpy_ice
• gsw_entropy_ice
• gsw_frazil_ratios_adiabatic
• gsw_frazil_ratios_adiabatic_poly
• gsw_frazil_properties
• gsw_frazil_properties_potential
• gsw_frazil_properties_potential_poly
• gsw_gibbs_ice
• gsw_helmholtz_energy_ice (note lower-case on name, as for Gibbs)
• gsw_ice_fraction_to_freeze_seawater
• gsw_internal_energy_ice
• gsw_kappa_ice
• gsw_kappa_const_t_ice
• gsw_melting_ice_equilibrium_SA_CT_ratio
• gsw_melting_ice_equilibrium_SA_CT_ratio_poly
• gsw_melting_ice_into_seawater
• gsw_melting_ice_SA_CT_ratio
• gsw_melting_ice_SA_CT_ratio_poly
• gsw_pot_enthalpy_from_pt_ice
• gsw_pot_enthalpy_from_pt_ice_poly
• gsw_pressure_coefficient_ice
• gsw_pt0_from_t_ice
• gsw_pt_from_pot_enthalpy_ice
• gsw_pt_from_pot_enthalpy_ice_poly
• gsw_pt_from_t_ice
• gsw_rho_ice
• gsw_sound_speed_ice
• gsw_specvol_ice
• gsw_t_from_pt0_ice

The HTML documentation suggests that this function returns 3 values, but there are only 2 returned values in the C code used here (and the matlab code on which that is based). Also, the d/dSA check values given the HTML are not reproduced by the present function. This was reported on Mar 18, 2017; see TEOS-10/GSW-Matlab#7.

For example (something I was trying for the vignette):

library(gsw)
data(levitus, package="ocedata)
SA <- gsw_SA_from_SP(levitus$SSS, 0, levitus$longitude, levitus$latitude)

yields

Error in gsw_SA_from_SP(levitus$SSS, 0, levitus$longitude, levitus$latitude) : 
  NA/NaN/Inf in foreign function call (arg 1)

I guess I'll copy what we do in oce, since that's not making this error.

As pointed out by @paleolimbot, this dependency can cause problems for some users. And, apart from the test suite (which is handled without Depending on testthat), there is no real need for this, because documentation entries of the form

expect_equal(A, B)

are just as clear to the user if written as

all.equal(A, B)

Goal. The C and Fortran codes for GSW-3.05 are now available on the TEOS-10 website, so it makes sense to start migration of GSW-R to 3.05. I made a new branch named 305 for this. Below is a list of the functions in gsw (from a grep in the file R/gsw.R), with a checkmark indicating that the function and its documentation have been updated, and that the check values match the published ones (but see the notes on some functions).

• argfix
• gsw_adiabatic_lapse_rate_from_CT
• gsw_alpha
• gsw_alpha_on_beta
• gsw_alpha_wrt_t_exact
• gsw_beta
• gsw_beta_const_t_exact
• gsw_cabbeling
• gsw_C_from_SP
• gsw_cp_t_exact
• gsw_CT_freezing
• gsw_CT_from_pt
• gsw_CT_from_t
• gsw_deltaSA_from_SP
• gsw_dynamic_enthalpy
• gsw_enthalpy
• gsw_enthalpy_t_exact
• gsw_entropy_from_t
• gsw_grav
• gsw_internal_energy
• gsw_IPV_vs_fNsquared_ratio
• gsw_kappa
• gsw_kappa_t_exact
• gsw_latentheat_evap_CT
• gsw_latentheat_evap_t
• gsw_latentheat_melting
• gsw_Nsquared
• gsw_p_from_z
• gsw_pot_rho_t_exact
• gsw_pt0_from_t
• gsw_pt_from_CT
• gsw_pt_from_t
• gsw_rho
• gsw_rho_first_derivatives
• gsw_rho_t_exact
• gsw_SA_from_rho
• gsw_SA_from_SP
• gsw_SA_from_Sstar
• gsw_sigma0
• gsw_sigma1
• gsw_sigma2
• gsw_sigma3
• gsw_sigma4
• gsw_sound_speed
• gsw_sound_speed_t_exact
• gsw_specvol
• gsw_specvol_anom_standard Note that previously we provided gsw_specvol_anom, but things seem to be changed in the matlab/C. The matlab version of gsw_specvol_anom has two additional arguments. Nothing corresponding was found in the C library, so I deleted gsw_specvol_anom and provided gsw_specvol_anom_standard, which is in both matlab and C, and which has check values that work with the new R function of the same name.
• gsw_specvol_t_exact
• gsw_SP_from_C
• gsw_SP_from_SA
• gsw_SP_from_SK
• gsw_SP_from_SR
• gsw_SP_from_Sstar
• gsw_SR_from_SP
• gsw_Sstar_from_SA
• gsw_Sstar_from_SP
• gsw_t_freezing Note: This uses the C function named gsw_t_freezing_exact, because the
  C function named gsw_t_freezing does not produce check values that match the Matlab function called gsw_t_freezing.
• gsw_t_from_CT
• gsw_thermobaric
• gsw_Turner_Rsubrho
• gsw_z_from_p

@PaulMBarker -- I suspect the check values listed at

http://www.teos-10.org/pubs/gsw/html/gsw_specvol_second_derivatives_wrt_enthalpy.html

are incorrect. In R I get as follows. Clark is getting the same things in Matlab; neither matches the values on the above-named website.

> library(testthat)
> SA <- c(34.7118, 34.8915, 35.0256, 34.8472, 34.7366, 34.7324)
> CT <- c(28.8099, 28.4392, 22.7862, 10.2262,  6.8272,  4.3236)
> p <- c(      10,      50,     125,     250,     600,    1000)
> r <- gsw_specvol_second_derivatives_wrt_enthalpy(SA, CT, p)
> data.frame(SA,CT,p,r)
       SA      CT    p        specvol_SA_SA         specvol_SA_h          specvol_h_h
1 34.7118 28.8099   10 8.09000289962637e-10 3.25437133570796e-13 4.47949998681476e-16
2 34.8915 28.4392   50 8.09379996750000e-10 3.27060462851431e-13 4.49121446914278e-16
3 35.0256 22.7862  125 8.46630656471014e-10 3.75273569184178e-13 4.85998151346315e-16
4 34.8472 10.2262  250 9.69733649853835e-10 5.45188833073084e-13 5.98480711660961e-16
5 34.7366  6.8272  600 9.97274534322934e-10 5.89424881889351e-13 6.28708349875318e-16
6 34.7324  4.3236 1000 1.01353037979356e-09 6.16101548209175e-13 6.47433212216398e-16

(This follows some direct emails between coauthors. I'm marking the assignee as CR since he noticed some problems with build warnings, related to the license. I don't see such problems when I build, so it will be easier for CR to see if any new problems arise when we remove the LICENSE file.)

I just read in the R docs the following. So we cannot include the LICENSE file.

The optional file LICENSE/LICENCE contains a copy of the license of the package. To avoid
any confusion only include such a file if it is referred to in the ‘License’ field of the 
DESCRIPTION file.

@PaulMBarker -- I suspect the check values listed at

http://www.teos-10.org/pubs/gsw/html/gsw_rho_second_derivatives_wrt_enthalpy.html for

are incorrect. In R I get as follows. Clark is getting the same things in Matlab; neither matches the values on teos-10.org

> library(gsw) # must be installed from github to get latest version
> SA <- c(34.7118, 34.8915, 35.0256, 34.8472, 34.7366, 34.7324)
> CT <- c(28.8099, 28.4392, 22.7862, 10.2262,  6.8272,  4.3236)
> p <- c(      10,      50,     125,     250,     600,    1000)
> r <- gsw_rho_second_derivatives_wrt_enthalpy(SA, CT, p)
> data.frame(CT,SA,p,r)
       CT      SA    p            rho_SA_SA              rho_SA_h               rho_h_h
1 28.8099 34.7118   10 0.000207312267114544 -4.59053080088382e-07 -4.54213854637790e-10
2 28.4392 34.8915   50 0.000207065033523473 -4.60370569872258e-07 -4.55984900239309e-10
3 22.7862 35.0256  125 0.000191848346945039 -4.98605615416296e-07 -4.99870030989387e-10
4 10.2262 34.8472  250 0.000133182862881598 -6.42833108550132e-07 -6.28337767293403e-10
5  6.8272 34.7366  600 0.000116049034622904 -6.82091962941161e-07 -6.64021595759308e-10
6  4.3236 34.7324 1000 0.000102745309429078 -7.06793055445909e-07 -6.87367088752173e-10

The current CRAN version of GSW is 3.03 (from January 2015). I think it is time to start implementing the version 3.05 files for a new release.

This issue can be used to track issues/progress towards this goal. Any sense of a timeline @dankelley ? I'm thinking it would be nice to have an updated package by the end of 2016. This might also coincide with an updated oce.

DK edit: I am putting a checklist below, which I originally had within a separate comment. I moved it here so that an overall summary of issues would then tell us how far we are along in the conversion process, by counting checked and unchecked boxes. NOTE: the case in the function names given in the checklist is not always right.

• gsw_add_barrier (a utility function, not wrapped to R)
• gsw_add_mean (a utility function, not wrapped to R)
• gsw_adiabatic_lapse_rate_from_ct
• gsw_adiabatic_lapse_rate_ice
• gsw_alpha
• gsw_alpha_on_beta
• gsw_alpha_wrt_t_exact
• gsw_alpha_wrt_t_ice
• gsw_beta
• gsw_beta_const_t_exact
• gsw_C_from_SP
• gsw_cabbeling
• gsw_chem_potential_water_ice
• gsw_chem_potential_water_t_exact
• gsw_cp_ice
• gsw_cp_t_exact
• gsw_CT_first_derivatives
• gsw_CT_first_derivatives_wrt_t_exact
• gsw_CT_freezing
• gsw_CT_freezing_first_derivatives
• gsw_CT_freezing_first_derivatives_poly
• gsw_CT_freezing_poly
• gsw_CT_from_enthalpy
• gsw_CT_from_enthalpy_t_exact
• gsw_CT_from_enthalpy_ice
• gsw_CT_from_entropy
• gsw_CT_from_pt
• gsw_CT_from_rho
• gsw_CT_from_t
• gsw_CT_maxdensity
• gsw_CT_second_derivatives
• gsw_deltaSA_from_SP
• gsw_dilution_coefficient_t_exact
• gsw_dynamic_enthalpy
• gsw_enthalpy
• gsw_enthalpy_CT_exact
• gsw_enthalpy_diff
• gsw_enthalpy_first_derivatives Problem with HTML docs and therefore check values
• gsw_enthalpy_first_derivatives_CT_exact
• gsw_enthalpy_ice
• gsw_enthalpy_second_derivatives
• gsw_enthalpy_second_derivatives_CT_exact
• gsw_enthalpy_t_exact
• gsw_entropy_first_derivatives
• gsw_entropy_from_pt
• gsw_entropy_from_t
• gsw_entropy_ice (see issue #25)
• gsw_entropy_second_derivatives
• gsw_fdelta
• gsw_frazil_properties
• gsw_frazil_properties_potential
• gsw_frazil_properties_potential_poly
• gsw_frazil_ratios_adiabatic
• gsw_frazil_ratios_adiabatic_poly
• gsw_geo_strf_dyn_height
• gsw_geo_strf_dyn_height_pc
• gsw_gibbs
• gsw_gibbs_ice
• gsw_grav
• gsw_helmholtz_energy_ice
• gsw_ice_fraction_to_freeze_seawater
• gsw_internal_energy
• gsw_internal_energy_ice
• gsw_ipv_vs_fnsquared_ratio
• gsw_kappa
• gsw_kappa_const_t_ice
• gsw_kappa_ice
• gsw_kappa_t_exact
• gsw_latentheat_evap_ct
• gsw_latentheat_evap_t
• gsw_latentheat_melting
• gsw_melting_ice_equilibrium_SA_CT_ratio
• gsw_melting_ice_equilibrium_SA_CT_ratio_poly
• gsw_melting_ice_into_seawater
• gsw_melting_ice_SA_CT_ratio
• gsw_melting_ice_SA_CT_ratio_poly
• gsw_melting_seaice_equilibrium_SA_CT_ratio
• gsw_melting_seaice_equilibrium_SA_CT_ratio_poly
• gsw_melting_seaice_into_seawater
• gsw_nsquared
• gsw_pot_enthalpy_from_pt_ice
• gsw_pot_enthalpy_from_pt_ice_poly
• gsw_pot_enthalpy_ice_freezing
• gsw_pot_enthalpy_ice_freezing_first_derivatives
• gsw_pot_enthalpy_ice_freezing_first_derivatives_poly
• gsw_pot_enthalpy_ice_freezing_poly
• gsw_pot_rho_t_exact
• gsw_pressure_coefficient_ice
• gsw_pressure_freezing_ct
• gsw_pt0_from_t
• gsw_pt0_from_t_ice
• gsw_pt_first_derivatives
• gsw_pt_from_CT
• gsw_pt_from_entropy
• gsw_pt_from_pot_enthalpy_ice
• gsw_pt_from_pot_enthalpy_ice_poly
• gsw_pt_from_t
• gsw_pt_from_t_ice
• gsw_pt_second_derivatives
• gsw_rho
• gsw_rho_alpha_beta
• gsw_rho_first_derivatives
• gsw_rho_first_derivatives_wrt_enthalpy
• gsw_rho_ice
• gsw_rho_second_derivatives
• gsw_rho_second_derivatives_wrt_enthalpy
• gsw_rho_t_exact
• gsw_SAAR (but note that in_ocean is broken)
• gsw_SA_freezing_from_CT
• gsw_SA_freezing_from_CT_poly
• gsw_SA_freezing_from_t
• gsw_SA_freezing_from_t_poly
• gsw_SA_from_rho
• gsw_SA_from_SP
• gsw_SA_from_SP_baltic
• gsw_SA_from_SStar
• gsw_seaice_fraction_to_freeze_seawater
• gsw_sigma0
• gsw_sigma1
• gsw_sigma2
• gsw_sigma3
• gsw_sigma4
• gsw_sound_speed
• gsw_sound_speed_ice
• gsw_sound_speed_t_exact
• gsw_SP_from_C
• gsw_SP_from_SA
• gsw_SP_from_SA_baltic
• gsw_SP_from_SK
• gsw_SP_from_SR
• gsw_SP_from_SStar
• gsw_specvol
• gsw_specvol_alpha_beta
• gsw_specvol_anom_standard
• gsw_specvol_first_derivatives
• gsw_specvol_first_derivatives_wrt_enthalpy
• gsw_specvol_ice
• gsw_specvol_second_derivatives
• gsw_specvol_second_derivatives_wrt_enthalpy
• gsw_specvol_t_exact
• gsw_spiciness0
• gsw_spiciness1
• gsw_spiciness2
• gsw_SR_from_SP
• gsw_SStar_from_SA
• gsw_SStar_from_SP
• gsw_t_deriv_chem_potential_water_t_exact
• gsw_t_freezing
• gsw_t_freezing_first_derivatives coded but test values are not working
• gsw_t_freezing_first_derivatives_poly coded but only tfreezing_p test values is working
• gsw_t_freezing_poly
• gsw_t_from_ct
• gsw_t_from_pt0_ice
• gsw_thermobaric
• gsw_turner_rsubrho
• gsw_util_indx (a utility function, not wrapped to R)
• gsw_util_interp1q_int (a utility function, not wrapped to R)
• gsw_util_linear_interp (a utility function, not wrapped to R)
• gsw_util_sort_real (a utility function, not wrapped to R)
• gsw_util_xinterp1 (a utility function, not wrapped to R)
• gsw_z_from_p

The data file src/gsw_saar_data.c is 8.3M, which exceeds the limit for submission to CRAN (Comprehensive R Archive Network). Even though the resulting shared object is not excessive in size, this is still flagged as a submission-blocking problem, and so I am now working on a solution. Luckily, R packages can have "hooks" at load and unload time, and so I should be able use these to populate arrays (within malloced storage) within the C code. I will try to do this with minimal changes to the C library, because every change made to the C library is a change that will need to be remade when that library changes.

I'll put a note here when I start the work, to avoid code mixups if CR is working at the same time.

I noticed while doing some work with the python version of gsw that there are some O2 functions that appear to be included in GSW-C but that we haven't imported, e.g. gsw_o2sol and gsw_o2sol_sp_pt.

I thought that anything included in the GSW-C source was included in GSW-R, but perhaps that's not the case?

CF TEOS-10/GSW-Matlab#7.

An example (from work for the vignette)

library(oce)
library(gsw)
data(levitus, package="ocedata")
SA <- gsw_SA_from_SP(levitus$SSS, 0, levitus$longitude, levitus$latitude)
max(SA, na.rm=TRUE)
sum(SA==9e15,na.rm=T)/prod(dim(SA))

yields

[1] 9e+15
[1] 0.02222222

From https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/gsw-00check.html

using R Under development (unstable) (2016-07-11 r70891)
using platform: x86_64-pc-linux-gnu (64-bit)
using session charset: UTF-8
checking for file ‘gsw/DESCRIPTION’ ... OK
this is package ‘gsw’ version ‘1.0-3’
checking package namespace information ... OK
checking package dependencies ... OK
checking if this is a source package ... OK
checking if there is a namespace ... OK
checking for executable files ... OK
checking for hidden files and directories ... OK
checking for portable file names ... OK
checking for sufficient/correct file permissions ... OK
checking whether package ‘gsw’ can be installed ... ERROR
Installation failed.
See ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/PKGS/gsw.Rcheck/00install.out’ for details.
DONE
See https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/gsw-00install.html for details.

Details:

* installing to library ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages’
* installing *source* package ‘gsw’ ...
** package ‘gsw’ successfully unpacked and MD5 sums checked
** libs
make[1]: Entering directory '/tmp/Rtmp3o5B2Z/R.INSTALL52783215e22b/gsw/src'
gcc-6 -std=c11 -I/home/hornik/tmp/R.check/r-devel-gcc/Work/build/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O3 -Wall -Wno-unused -pedantic -mtune=native -c gsw_oceanographic_toolbox.c -o gsw_oceanographic_toolbox.o
gcc-6 -std=c11 -I/home/hornik/tmp/R.check/r-devel-gcc/Work/build/include -DNDEBUG  -I/usr/local/include    -fpic  -g -O3 -Wall -Wno-unused -pedantic -mtune=native -c gsw_p_from_z.c -o gsw_p_from_z.o
gsw_p_from_z.c: In function ‘gsw_p_from_z’:
gsw_p_from_z.c:15:22: error: ‘M_PI’ undeclared (first use in this function)
     double deg2rad = M_PI / 180.0;
                      ^~~~
gsw_p_from_z.c:15:22: note: each undeclared identifier is reported only once for each function it appears in
/home/hornik/tmp/R.check/r-devel-gcc/Work/build/etc/Makeconf:132: recipe for target 'gsw_p_from_z.o' failed
make[1]: *** [gsw_p_from_z.o] Error 1
make[1]: Leaving directory '/tmp/Rtmp3o5B2Z/R.INSTALL52783215e22b/gsw/src'
ERROR: compilation failed for package ‘gsw’
* removing ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages/gsw’

The example in the docs call it SP, but it ought to be Sstar. The documentation for the argument is correct; the problem is just a confusing naming in the example.

Kurt Hornik has written a script to check for all packages that contain this argument-name error. There are a lot of them, and gsw is one. I'll fix that. Since they want an update of all such packages, I will arrange for that also, probably before March 17.

PS. I did some branch weaving, also, to get the 3.05 code in the next CRAN release.

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.

A lot of R packages hosted on GitHub are starting to use Travis CI as a quality demonstrator in their README files. It looks quite easy and the checks in gsw are very fast, so I propose to do that. @richardsc - any objection?

The code

library(oce)
data("levitus", package="ocedata")
SA <- gsw_SA_from_SP(levitus$SSS, 0, levitus$longitude, levitus$latitude)
imagep(levitus$longitude, levitus$latitude, SA-levitus$SSS)

yields a graph like shown below. Note the problem at the dateline (and also Greenwich meridian). Also, there are some vertical bands on the figure (look e.g. at about 160E).

Hello, I am trying to use gsw_nsquared as follows:

using GibbsSeaWater

# Constants
g = 9.81
Nz = 64
Δz = 2.5
Lz = Δz*Nz
z = -((Δz/2):Δz:(Lz-Δz/2))
Stop = 34.1 
Sbot = 34.7
Ttop = -0.5
Tbot = 0
ztop = -40
zbot = -Lz
dSdz = (Sbot - Stop)/(zbot - ztop)
dTdz = (Tbot - Ttop)/(zbot - ztop)

# Profiles
S = Stop .+ dSdz*(z .< ztop).*(z .- ztop)
T = Ttop .+ dTdz*(z .< ztop).*(z .- ztop)
Pres = -rho_O*g*z*1e-4
N2 = float(Nz-1)
Pmid = float(Nz-1)
a = gsw_nsquared.(S, T, Pres, 0, Nz, N2, Pmid)

But get the following error:

 ERROR: LoadError: MethodError: no method matching unsafe_convert(::Type{Ptr{Float64}}, ::Float64)
Closest candidates are:
  unsafe_convert(::Type{T}, ::T) where T<:Ptr at essentials.jl:391
  unsafe_convert(::Type{Ptr{T}}, ::Ptr{Tuple{Vararg{T,N}}}) where {N, T} at refpointer.jl:136
  unsafe_convert(::Type{P}, ::Ptr) where P<:Ptr at essentials.jl:392
  ...
Stacktrace:
 [1] gsw_nsquared(::Float64, ::Float64, ::Float64, ::Int64, ::Int64, ::Float64, ::Float64) at /Users/guptam/.julia/packages/GibbsSeaWater/vq3GE/src/gen_gswteos10.jl:370
 [2] _broadcast_getindex_evalf at ./broadcast.jl:648 [inlined]
 [3] _broadcast_getindex at ./broadcast.jl:621 [inlined]
 [4] getindex at ./broadcast.jl:575 [inlined]
 [5] copy at ./broadcast.jl:876 [inlined]
 [6] materialize(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1},Nothing,typeof(gsw_nsquared),Tuple{Array{Float64,1},Array{Float64,1},StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}},Int64,Int64,Float64,Float64}}) at ./broadcast.jl:837
 [7] top-level scope at compare_nsquared.jl:137
 [8] include(::String) at ./client.jl:457
 [9] top-level scope at REPL[14]:1
in expression starting at compare_nsquared.jl:137

Could you advise how I should use gsw_nsquared instead?
Many thanks.

Hi

I have two questions.

1. After adding another GSW function (gsw_distance) to the repo, I hit

$ Rscript -e "roxygen2::roxygenise()"
Loading gsw
Loading required package: testthat
Warning: The existing 'NAMESPACE' file was not generated by roxygen2, and will not be overwritten.

Is this ok? git status does not mention the NAMESPACE file.

2. Then, I run this Makefile

## my makefile
mygsw: export R_LIBS_USER := ~/my/package/path/ # this is necessary to find knitr package
mygsw: 
	$(eval GSWVSN := $(shell awk '/Version/{print($$2)}' GSW-R/DESCRIPTION))
	@echo gsw version: $(GSWVSN) 
	@echo R_LIBS_USER: $(R_LIBS_USER) 
	cd GSW-R 
	echo "devtools::document(roclets=c('rd', 'collate', 'vignette'))" | R --no-save PKG_CFLAGS=--pedantic R CMD build --compact-vignettes="gs+qpdf" GSW-R R CMD CHECK --as-cran gsw_${GSWVSN}.tar.gz R CMD INSTALL gsw_${GSWVSN}.tar.gz

which gives

$ make mygsw 
gsw version: 1.0-6
R_LIBS_USER: ~/my/package/path/
cd GSW-R 
echo "devtools::document(roclets=c('rd', 'collate', 'vignette'))" | R --no-save PKG_CFLAGS=--pedantic R CMD build --compact-vignettes="gs+qpdf" GSW-R R CMD CHECK --as-cran gsw_1.0-6.tar.gz R CMD INSTALL gsw_1.0-6.tar.gz
Warning: unknown option ‘--as-cran’
* checking for file ‘GSW-R/DESCRIPTION’ ... OK
* preparing ‘gsw’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* looking to see if a ‘data/datalist’ file should be added
* building ‘gsw_1.0-6.tar.gz’

 ERROR
cannot change to directory ‘R’
make: *** [Makefile:8: mygsw] Error 1

I definitely incorporated some errors in my Makefile (note also the unknown --as-cran). However, the provided example at the end of develop/developer/README.md did not work for me.

Kind regards,
Chris

I am working on updating the software page on the TEOS10 website. I would like to add something to show that this package exists. How would you like this to appear?

Paul.

@efiring do you get the same as below, if you use the C code directly? (I've asked PB if the teos-10 website might be out-of-date, and I'll post status updates here as they come in.)

In doing updates for GSW-R/1.0-1, I am finding that I cannot reproduce the check values given at http://www.teos-10.org/pubs/gsw/html/gsw_geo_strf_dyn_height.html. Details are below, but a summary is that I am getting 12.295 for the first test, while the TEOS-10 website indicates 12.172 for that value.

@efiring do you get the same if you use the C code directly?

> library(gsw)
> SA <- c(34.7118, 34.8915, 35.0256, 34.8472, 34.7366, 34.7324)
> CT <- c(28.8099, 28.4392, 22.7862, 10.2262,  6.8272,  4.3236)
> p <- c(      10,      50,     125,     250,     600,    1000)
> p_ref <- 500
> dh <- gsw_geo_strf_dyn_height(SA, CT, p, p_ref)
> stopifnot(all.equal(dh, c(12.172172845782585, 9.797739925848624, 6.070940749148281,
+                           3.042891445395256, -1.078872239804912, -4.656953829254061)))
Error: dh and c(12.1721728457826, 9.79773992584862, 6.07094074914828, 3.04289144539526,  .... are not equal:
  Mean relative difference: 0.01048202
> 
> dh
[1] 12.295114  9.931936  6.165909  3.055219 -1.080634
[6] -4.633611

Values indicated at the TEOS-10 website

Oh, should have guessed this. Rstudio uses a makefile method to avoid recompiling things if the .c file hasn't changed. So all those (5000 or so) warnings are actually still there. I had thought they went away.

I need to figure this out, because CRAN is not going to accept a package with thousands of compilation warnings.

Below are a few of the warnings.

clang -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include   --pedantic -fPIC  -Wall -mtune=core2 -g -O2  -c gsw_oceanographic_toolbox.c -o gsw_oceanographic_toolbox.o
gsw_oceanographic_toolbox.c:84:2: warning: unused variable 'delj' [-Wunused-variable]
        GSW_SAAR_DATA;
        ^
./gsw_internal_const.h:395:26: note: expanded from macro 'GSW_SAAR_DATA'
int     deli[4] = {0,1,1,0}, delj[4] = {0,0,1,1}, npan = 6; \
                             ^
gsw_oceanographic_toolbox.c:84:2: warning: unused variable 'deli' [-Wunused-variable]
./gsw_internal_const.h:395:5: note: expanded from macro 'GSW_SAAR_DATA'
int     deli[4] = {0,1,1,0}, delj[4] = {0,0,1,1}, npan = 6; \
        ^
gsw_oceanographic_toolbox.c:242:2: warning: unused variable 'pa2db' [-Wunused-variable]
        GSW_TEOS10_CONSTANTS;
        ^
./gsw_internal_const.h:12:2: note: expanded from macro 'GSW_TEOS10_CONSTANTS'
        pa2db = 1.0e-4, \
        ^
gsw_oceanographic_toolbox.c:243:2: warning: unused variable 'h211' [-Wunused-variable]
        GSW_SPECVOL_COEFFICIENTS;
        ^
./gsw_internal_const.h:263:2: note: expanded from macro 'GSW_SPECVOL_COEFFICIENTS'
        h211 = -4.35926785610e-5, \
        ^
gsw_oceanographic_toolbox.c:243:2: warning: unused variable 'c005' [-Wunused-variable]
./gsw_internal_const.h:174:2: note: expanded from macro 'GSW_SPECVOL_COEFFICIENTS'
        c005 =  1.17681023580e-8, \
        ^

I sent a test build to the windows-test machine and it gave as follows. I'll fix it and post again with a diff, before closing this

Found the following significant warnings:
  gsw_oceanographic_toolbox.c:10645:2: warning: implicit declaration of function 'qsort_s' [-Wimplicit-function-declaration]

This is also recorded in TEOS-10/GSW-Matlab#6 and my goal in saving it as an issue also here in GSW-R is as a reminder to myself to fix up the R version when I learn more about the check values.

This is likely because the C source is not matched up with the Matlab source (e.g. note that the Matlab source has a third input argument, saturation_fraction).

Overview of all comments My guess is that this issue will be opened and closed, repeatedly. The purpose is to track modifications to the source that are required to clean it of NOTEs from the CRAN builder. The main problems are likely to be failures to open URLs stated in the documentation. Some of these will be temporary, but I propose to employ the scheme used in oce, in which we apply a cautionary principle: if I find that the link has changed, then I'll change it. But if I find that it has simply become nonfunctional (even temporarily) then I will alter the text indication from \url{} to \samp{}. (Oh, and of course I will simply remove any links that now fail, for which I cannot find a replacement.)

This issue serves to organize and document the adding of GSW functions to the package, by way of following the developer instructions. The order is alphabetical (as listed in src/gswteos-10.h), but if users have a specific need for a function that has not yet been completed they should comment here.

Functions not to be added

The following functions are listed in the src/gswteos-10.h file but they will not be added to the package because they are for internal use by those who are developing the TEOS functions:

• gsw_add_barrier
• gsw_add_mean
• gsw_xinterp1
• gsw_indx
• gsw_gibbs the TEOS-10 Gibbs function of seawater and its derivatives
• gsw_gibbs_ice the TEOS-10 Gibbs function of ice and its derivatives
• gsw_SAAR Absolute Salinity Anomaly Ratio (excluding the Baltic Sea)
• gsw_Fdelta ratio of Absolute to Preformed Salinity, minus 1
• gsw_deltaSA_atlas Absolute Salinity Anomaly atlas value (excluding the Baltic Sea)
• gsw_SA_from_SP_Baltic Calculates Absolute Salinity in the Baltic Sea
• gsw_SP_from_SA_Baltic Calculates Practical Salinity in the Baltic Sea
• gsw_infunnel "oceanographic funnel" check for the 48-term equation
• gsw_entropy_part entropy minus the terms that are a function of only SA
• gsw_entropy_part_zerop entropy_part evaluated at 0 dbar
• gsw_interp_ref_cast linearly interpolates the reference cast
• gsw_interp_SA_CT linearly interpolates (SA,CT,p) to the desired p
• gsw_gibbs_pt0_pt0 gibbs(0,2,0,SA,t,0)
• gsw_gibbs_ice_part_t part of gibbs_ice(1,0,t,p)
• gsw_gibbs_ice_pt0 part of gibbs_ice(1,0,pt0,0)
• gsw_specvol_SSO_0_p specvol_CT(35.16504,0,p)
• gsw_enthalpy_SSO_0_p enthalpy_CT(35.16504,0,p)
• gsw_Hill_ratio_at_SP2

Functions to be added

As functions are added (meaning coded, documented and tested), their tick boxes are checked off. To avoid edit conflicts, the developers can communicate by means of comments in this thread (e.g. "In the next 2 hours I intend to code such-and-such"), and these comments are erased when the code is pushed back to github. Thus, the idea is that a developer starts by reloading this webpage, picks a task that is of interest, adds a comment, and usually an hour later pushs the repository and deletes the comment.

A link providing docs for the functions is http://www.teos-10.org/pubs/gsw/html/gsw_contents.html.

• gsw_adiabatic_lapse_rate_from_ct
• gsw_alpha
• gsw_alpha_on_beta
• gsw_alpha_wrt_t_exact
• gsw_beta_const_t_exact
• gsw_beta
• gsw_c_from_sp
• gsw_cabbeling
• gsw_ct_freezing done, but yields check values from gsw_CT_freezing_poly
• gsw_ct_from_pt
• gsw_ct_from_t
• gsw_deltasa_from_sp
• gsw_dynamic_enthalpy
• gsw_enthalpy
• gsw_enthalpy_t_exact
• gsw_cp_t_exact
• gsw_entropy_from_t
• gsw_grav
• gsw_internal_energy
• gsw_ipv_vs_fnsquared_ratio
• gsw_kappa
• gsw_kappa_t_exact
• gsw_latentheat_evap_ct
• gsw_latentheat_evap_t
• gsw_latentheat_melting
• gsw_nsquared
• gsw_pot_rho_t_exact
• gsw_pt0_from_t
• gsw_pt_from_ct
• gsw_pt_from_t
• gsw_rho
• gsw_rho_first_derivatives
• gsw_rho_t_exact
• gsw_sa_from_rho
• gsw_sa_from_sp
• gsw_sa_from_sstar
• gsw_sigma0
• gsw_sigma1
• gsw_sigma2
• gsw_sigma3
• gsw_sigma4
• gsw_sound_speed
• gsw_sound_speed_t_exact
• gsw_specvol_anom
• gsw_specvol
• gsw_specvol_t_exact
• gsw_sp_from_c
• gsw_sp_from_sa
• gsw_sp_from_sk
• gsw_sp_from_sr
• gsw_sp_from_sstar
• gsw_sr_from_sp
• gsw_sstar_from_sa
• gsw_sstar_from_sp
• gsw_t_freezing done, but yields check values from gsw_t_freezing_poly
• gsw_t_from_ct
• gsw_thermobaric
• gsw_turner_rsubrho
• gsw_z_from_p

The release of 1.0-5 was on 2017-08-09, i.e. nearly 4 years ago, and GSW-C has evolved a bit in the meantime. Also, as in #46, it is now clear that reliance on testthat was a problematic choice.

Accordingly, I've been working for a few days, to get a new release ready. Some of the work was quite finicky (see the somewhat meandering discussions on #46 and #47), but I think I have it mostly done. I like to do the things that devtools::release() wants me to do, head of time, so here's a checklist to help me keep track:

• clear up some remaining loose ends in the code (recheck the GSW-C/matlab integration, and what I say about that in the docs
• check into the special-case that GSW-C is using for a particular function (see #47)
• do another editing pass on the docs (especially the templates) for clarity
• use pkgdown to redo the old, hand-edited website. (The benefit of using pkgdown is that it can be automated, and it will present a format that will be familiar to users.)
• ensure that R-CMD-check action is okay
• ensure that pkgdown action is okay
• test on winbuilder/develop check_win_devel().
• test on winbuilder/release with check_win_release()
• test on Rhub with rhub::check() answering 14 for ubuntu-gcc-devel
• test on Rhub with rhub::check() answering 5 for debian-gcc-release
• spell check with develop::spell_check()
• examine built-up tarball to ensure that there are no unnecessary files there.
• revdepcheck

df <- structure(list(SA = c(36.855503939848, 36.4971650766637, 36.4977700026719,
36.2529246997542, 36.2534270655287, 36.002043110245, 36.0002357585083,
35.8278109198182, 35.8281142727647, 35.7015734367856, 35.7006709862616,
35.7848317547004, 35.7858367750849, 35.9496877557911, 35.9520999643311,
36.0623842502388, 36.0861726265337, 36.14217237462, 36.2275535176993,
36.2408756031207, 36.2187323903269, 36.1707742062984, 36.0918852617197,
35.9813688721453), CT = c(21.4947473754157, 16.6878140953016,
16.6748589933191, 14.5354547312802, 14.5417247209637, 13.1075384801307,
13.1059005757833, 11.9533561570296, 11.9365831694816, 10.834696340731,
10.8354205711472, 10.2515778760042, 10.2534330502052, 10.1594789517675,
10.1628546551997, 10.1319944946218, 10.000801742997, 9.97602409076545,
10.0160820710144, 9.89429410566537, 9.64473876660855, 9.23710853886353,
8.83733409331888, 8.23858450492611), p = c(11, 102.1, 103.1,
202.4, 202.4, 301, 301.6, 402.1, 403.1, 559.8, 560.5, 701.3,
701.4, 790.9, 791.3, 895.3, 943.4, 1046.5, 1137.4, 1193.3, 1242.6,
1292.7, 1345.1, 1405.4)), .Names = c("SA", "CT", "p"), row.names = c(NA,
-24L), class = "data.frame")
gsw::gsw_geo_strf_dyn_height(df$SA, df$CT, df$p)

yields

 [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

although this profile (station "19" within data(section), in the oce package) seems really very similar to the stations before and after it. Here's a plot of the station ... which seems ok to me.

In a discussion of the Python (and C) versions -- see TEOS-10/GSW-C#2 (comment) -- it is seen that gsw_saar() can segfault sometimes in the C version.

I wanted to test this in the R version. It seems not to be a problem, with the develop branch commit f25c9b7. (But note: I have not decided whether to call this gsw_saar() or gsw_SAAR(). At the moment it is the latter, but I reserve the "right" to change it in the next few days.)

> library(gsw)
> str(gsw_SAAR(1000, -30, 5))
List of 2
 $ saar   : num 0.000133
 $ inocean: int 1
> str(gsw_SAAR(1000, 60, 40))
List of 2
 $ saar   : num 0
 $ inocean: int 1

These were revealed by winbuilder.

• URL: http://teos-10.github.io/GSW-R (moved to http://teos-10.github.io/GSW-R/)
  From: DESCRIPTION
  Status: 200
  Message: OK

• URL: http://teos-10.github.io/GSW-R/documentation.html
  From: man/gsw.Rd
  Status: 404
  Message: Not Found

• URL: https://dankelley.github.io/oce (moved to https://dankelley.github.io/oce/)
  From: man/gsw.Rd
  Status: 200
  Message: OK

• URL: https://doi.org/10.1175/JPO-D-11-0188.1
  From: inst/doc/gsw.html
  Status: 403
  Message: Forbidden

• URL: https://doi.org/10.1175/JTECH-D-19-0211.1
  From: man/gsw_geo_strf_dyn_height.Rd
  Status: 403
  Message: Forbidden

• URL: https://www.teos-10.org/pubs/gsw/html/gsw_enthalpy_ct_exact.html
  From: man/gsw_enthalpy_CT_exact.Rd
  Status: Error

• Message: SSL: no alternative certificate subject name matches target host name 'www.teos-10.org'
  URL: https://www.teos-10.org/pubs/gsw/html/gsw_saar.html
  From: man/gsw_SAAR.Rd
  Status: Error

• Message: SSL: no alternative certificate subject name matches target host name 'www.teos-10.org'

• Found the following URLs which should use \doi (with the DOI name only):
  File 'gsw_geo_strf_dyn_height.Rd':
  https://doi.org/10.1175/JTECH-D-19-0211.1

Prescript -- I tried emailing the below to Paul by sending to [email protected] but the email bounced, stating that [email protected] was an "Unrouteable address" and classifying that as a "Permanent error".

My questions relate to how the base routine works (in C) ... this is therefore not really a question about GSW-R, per se, because in R we just wrap the C functions according to documentation (and with test values) on the TEOS-10 website.

1. A typo: the function named gsw_geo_strf_steric_height() is defined at the URL http://www.teos-10.org/pubs/gsw/html/gsw_steric_height.html and the title on the first line of that URL says “gsw_steric_height”.

2. A question: what is the function actually calculating? The docs suggest an integral (and that’s the usual definition in the literature) but the returned value (even in the test case on the above-named URL) is a vector, so I’m not quite sure what this means. To get the integral, do I take the first value in that vector, the last, a sum, … ?

This issue is just to serve as a reminder, and, if I have the time at some point, to troll through the list and plan out which functions should be cross-referenced.

I am confused about http://www.teos-10.org/pubs/gsw/html/gsw_specvol_first_derivatives_wrt_enthalpy.html in which I see as follows (an aside: the C source uses a different name for the first variable):

    OUTPUT:

    v_SA_wrt_h  =  The first derivative of specific volume with respect to 
                Absolute Salinity at constant CT & p.   
                                             [ (m^3/kg)(g/kg)^-1 (J/kg)^-1 ]
    v_h  =  The first derivative of specific volume with respect to 
                SA and CT at constant p.               [ (m^3/kg)(J/kg)^-1 ]

The units, the wording, and even the naming all confuse me a bit. I wonder if it's just me?

Units

The unit of v_h seems OK. $d(spec vol)/d(enthalpy)$ has unit (m^3/kg) / (J/kg) because “enthalpy” (really, either “mass-specific enthalpy”, or “specific enthalpy”, but that's a small detail) has unit J/kg.

But the unit of v_SA_wrt_h suggests that we may have $d^2(spec vol)/d(SA)/d(enthalpy)$ so it’s not a “first derivative” as in the function name.

Wording

For v_h, I am drawing a blank as to what "The first derivative of specific volume with respect to SA and CT at constant p" means.

Naming

If my hypothesis on the meaning of v_SA_wrt_h is correct, should this maybe be called v_SA_h or something? I don't quite understand what "wrt" means.

I'm sorry if I'm just being dense, and I'm hoping this comment will help others.

This example came up in some work with oce, and so I'll illustrate with oce code. I see how to fix this, and have done it for the CT as a test case (i.e. below is from the OLD code; the 0.00000 will become NA in the NEW code)

library(oce)
a <- as.ctd(30:35,c(10,NA,12,13,14,15),10:15)
a[["CT"]]
[1] 10.07951  0.00000 12.05066 13.03213 14.01094 14.98715

Freezing temperatures are not agreeing with test values on the teos-10 website, since

library(gsw)
SA <- c(34.7118, 34.8915, 35.0256, 34.8472, 34.7366, 34.7324)
p <- c(      10,      50,     125,     250,     600,    1000)
saturation_fraction <- 1
tf <- gsw_t_freezing(SA, p, saturation_fraction)
options(digits=14)
print(data.frame(gsw=tf, expect=c(-1.902730710149803, -1.942908619287183, -2.006861069199743,
                                  -2.090985086875259, -2.351293130342102, -2.660498762776720)))

yields as below (look at the 4th and 5th digits after the decimal place)

               gsw           expect
1 -1.9027044342992 -1.9027307101498
2 -1.9428979454752 -1.9429086192872
3 -2.0068773645786 -2.0068610691997
4 -2.0910413915380 -2.0909850868753
5 -2.3514315601789 -2.3512931303421
6 -2.6606852376337 -2.6604987627767