Update (almost) to v3_06_11 compatibility #35
Conversation
efiring
commented
Sep 27, 2020
efiring
commented
- Added make_data_from_mat.py to generate new SAAR and check value files from the matfile included in the matlab release zipfiles. - Substituted the newer gsw_geo_strf_dyn_height_1 with the pchip option as the engine for the dynamic height calculation, replacing the original that dated from a much earlier version. It gets closer to the current check values than the old version, but not nearly close enough to pass the tests; since more development on this is expected, the test is left here with the failure in place. - Made small changes to 2 second derivative calculations for improved numerics. New check values are not needed.
efiring
changed the title
|
|
||
| # Edit the mat_filename as needed, but make sure there is enough path | ||
| # info to show the matlab "version" it comes from. | ||
| mat_filename = '../../gsw_matlab_v3_06_11/library/gsw_data_v3_0.mat' |
There was a problem hiding this comment.
We should work with upstream to release these data in a more friendly way. Maybe a netCDF file served/hosted somewhere that would make it easy for all projects to get it.
There was a problem hiding this comment.
What is it you want in netcdf format?
There was a problem hiding this comment.
@ocefpaf is referring to all of the data in gsw_data_v3_0.mat, which should include clear version identification both inside the file and in the file name. As it is now, there are many differing versions of that critical file, with no clarity as to what has changed from one to another, or which one is which. This is part of a larger organizational issue of how to make it less difficult to provide gsw functionality in languages other than Matlab--and even for Matlab users, of how to track what has changed from one version to another.
There was a problem hiding this comment.
I would add, though, that this is not an immediate priority; we are not asking you to spend time now to write a netcdf version from the matfile. We are directly reading the matfile, which is easy in Python.
There was a problem hiding this comment.
Hah! It turns out there is a https://github.com/TEOS-10/GSW-datafile repo. It was last updated Oct 29, 2015. Here are the global attributes of the sole file in the repo:
:version_date = "15th_May_2011" ;
:version_number = "3.05" ;
:history = "Created by Paul M. Barker on 30th October 2015 for the Gibbs-Seawater Oceanographic Toolbox" ;
:title = "Contains the global data set of Absolute Salinity Anomaly Ratio, the global data set of Absolute Salinity Anomaly Atlas, a reference cast and check values for all of the functions" ;
And here they are for the version Frank Delahoyde used for his version of GSW-C:
:version_date = "15th_May_2011" ;
:version_number = "3.05.6" ;
:history = "Created by Paul M. Barker on 8th August 2016 for the Gibbs-Seawater Oceanographic Toolbox" ;
:title = "Contains the global data set of Absolute Salinity Anomaly Ratio, the global data set of Absolute Salinity Anomaly Atlas, a reference cast and check values for all of the functions" ;
There was a problem hiding this comment.
I have the data file in netcdf format, it is made during the matlab datafile making. I will put it up on the repo.
There was a problem hiding this comment.
Can (and should) all versioning be clearly matched to the matlab releases, at least so long as they are setting the standard? So, a file name for the current latest would be, for example, "gsw_data_matlab_v3_06_12.nc". version_number could be 3.06.12; Maybe it already is. Maybe version_date should be the date of the matlab release, or maybe the date of the last time the actual data tables, as opposed to check values, were changed?
