forked from TEOS-10/GSW-C
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME-developer
93 lines (80 loc) · 4.68 KB
/
README-developer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
This document describes the organization of TEOS-10/GSW-C on github, and
gives instructions for contributors.
Files for users
===============
README -- The README file distributed with the
teos-10.org distribution.
LICENSE -- GSW C software license.
Makefile -- makefile supplied in the teos-10.org
distribution.
gswteos-10.h -- GSW function prototype definitions
gsw_internal_const.h -- Common parameters used to compile the GSW-C
library.
gsw_oceanographic_toolbox.c
-- The distribution source code for the GSW-C
library less gsw_saar.
gsw_saar.c -- gsw_saar and gsw_deltasa_atlas (modified).
gsw_saar_data.h -- static global absolute salinity anomaly data
used by gsw_saar.c
gsw_check_data.h -- static check data used by gsw_ check functions.c
gsw_check_functions.c -- C implementation of the check functions used
to validate the correct building of the GSW-C
Oceanographic Toolbox.
TOOLS.ini -- Variable definitions used by nmake
TOOLS.gcc -- Variable definitions used by make
Files for development
=====================
README-developer -- This file.
GNUmakefile -- GNU make makefile used to manage the building
and maintenance of the gsw_c_v3.05.zip file on
teos-10.org, as well as RPMs for RedHat Linux
systems.
gsw_data_v3_0.nc -- A redundant and hopefully current version of
the netcdf file hosted on github as
TEOS-10/datafile. gsw_check_data.h and
gsw_saar_data.h are generated from this file
using the supplied utilities
make_check_data.py and make_saar_data.py.
make_check_data.py -- Utility to generate gsw_check_data.h from
gsw_data_v3_0.nc. **Do not use**
make_saar_data.py -- Utility to generate gsw_saar_data.h from
gsw_data_v3_0.nc. **Do not use**
make_data_from_mat.py -- Utility to generate check data and SAAR data from
gsw_matlab_v3_06_11/library/gsw_data_v3_0.mat.
You need to edit the file to supply the correct
path. The geostrophic streamfunction values are
patched in from geo_strf_dyn_height.npy to match
the pchip-based version being used here.
libgswteos-10.spec.proto
-- template used to create libgswteos-10.spec,
the configuration file for rpmbuild on RedHat
Linux platforms.
The file GNUmakefile is supplied for use on Linux/GNU systems. It has two
major purposes:
* To build a zip archive of the distribution suitable for TEOS-10.org; and
* To set up a versioned source distribution suitable for building source
and binary RPMs on RedHat-like Linux systems.
Please note that the current distribution on teos-10.org
(http://teos-10.org/software/gsw_c_v3.05.zip) is a subset of this github
directory and is accurately described by the supplied README file.
Notes for contributors
======================
It is anticipated that the primary use for this C library will be
to provide core functionality in the GSW-Python and GSW-R libraries.
If additional core GSW functions are added here, they should be consistent
with their GSW-Matlab versions and with the general style of functions
presently in the C library. Pull Requests for new functions should
include the corresponding tests in gsw_check_functions.c and test data in
gsw_check_data.h. The latter should be the result of re-running the
make_check_data.py utility; gsw_check_data.h should not be hand-edited.
Code style for C should be generally consistent with the existing code
with respect to brackets and indentation, with the proviso that new
code should use 4-space indentation. There should be no trailing
whitespace, and no tab characters.
Originally, gsw_oceanographic_toolbox.c was assembled by a script from
individual files for each exported function, and the files were sorted
alphabetically. When adding new exported functions, please insert them
alphabetically so as to maintain this (arbitrary) convention. Support
functions, declared as "static", should be kept together with the
exported functions in which they are used, so they typically will not
be in alphabetic order.