National Park Service

U.S. Department of the Interior

Natural Resource Program Center

Glacier Bay National Park and Preserve

Oceanographic Monitoring Protocol 

Version OC–2010.1

Natural Resource Report NPS/SEAN/NRR—2010/265
ON THE COVER

Lewis Sharman, Ecologist at Glacier Bay National Park and Preserve, prepares to deploy the CTD sampler during a fall 

cruise. NPS Photo by: B. Moynahan.
Glacier Bay National Park and Preserve

Oceanographic Monitoring Protocol 

Version OC–2010.1

Natural Resource Report NPS/SEAN/NRR—2010/265

Seth Danielson

University of Alaska Fairbanks

School of Fisheries and Ocean Sciences, Institute of Marine Science

PO Box 757220

Fairbanks, AK 99775

William Johnson

National Park Service

Inventory & Monitoring Program, Southeast Alaska Network

3100 National Park Road

Juneau, AK 99801

Lewis Sharman

National Park Service 

Glacier Bay National Park and Preserve, Resources Management and Research

PO Box 140

Gustavus, AK 99826

Ginny Eckert

University of Alaska Fairbanks

Fisheries Division

17101 Pt. Lena Loop Rd.

Juneau, AK 99801 

Brendan Moynahan

National Park Service

Inventory & Monitoring Program, Southeast Alaska Network

3100 National Park Road

Juneau, AK 99801

November 2010

U.S. Department of the Interior

National Park Service

Natural Resource Program Center

Fort Collins, Colorado
ii

The National Park Service, Natural Resource Program Center publishes a range of reports that 

address natural resource topics of interest and applicability to a broad audience in the National 

Park Service and others in natural resource management, including scientists, conservation and 

environmental constituencies, and the public. 

The Natural Resource Report Series is used to disseminate high-priority, current natural resource 

management information with managerial application. The series targets a general, diverse 

audience, and may contain NPS policy considerations or address sensitive issues of management 

applicability.

All manuscripts in the series receive the appropriate level of peer review to ensure that the 

information is scientifically credible, technically accurate, appropriately written for the intended 

audience, and designed and published in a professional manner. 

This report received formal peer review by subject-matter experts who were not directly 

involved in the collection, analysis, or reporting of the data, and whose background and expertise 

put them on par technically and scientifically with the authors of the information.

Views, statements, findings, conclusions, recommendations, and data in this report do not

necessarily reflect views and policies of the National Park Service, U.S. Department of the

Interior. Mention of trade names or commercial products does not constitute endorsement or

recommendation for use by the U.S. Government.

This report is available from the Southeast Alaska Network Inventory & Management website 

(http://science.nature.nps.gov/im/units/sean/OC_Main.aspx) and the Natural Resource 

Publications Management website (http://www.nature.nps.gov/publications/NRPM).

Please cite this publication as:

Danielson, S., W. Johnson, L. Sharman, G. Eckert, and B. Moynahan. 2010. Glacier Bay 

National Park and Preserve oceanographic monitoring protocol: Version OC–2010.1. Natural 

Resource Report NPS/SEAN/NRR—2010/265. National Park Service, Fort Collins, Colorado.

NPS 132/106029, November 2010
iii

Revision History

This Oceanographic Monitoring protocol (OC) is labeled with the year of acceptance of formal 

peer review. The first protocol version of a particular year is given sequence number 1.Version 

numbers will be incremented by a whole number (e.g., 1.3 to 2.0) when a change is made that 

significantly affects requirements or procedures. Version numbers will be incremented by 

decimals (e.g., 1.6 to 1.7) when there are minor modifications that do not affect requirements or 

procedures included in the plan. 

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

Initial version OC-2010.1

v

Contents

Page

Figures........................................................................................................................................... vii

Standard Operating Procedures.................................................................................................... viii

Appendices..................................................................................................................................... ix

Abstract.......................................................................................................................................... xi

Acknowledgements....................................................................................................................... xii

1.0 Background and Objectives.......................................................................................................1

1.1 Protocol Synopsis.......................................................................................................... 1

1.2 Historical and Biophysical Background ....................................................................... 1

1.3 Purpose of Oceanographic Sampling............................................................................ 4

1.4 Overview of Prior Oceanographic Sampling................................................................ 5

1.5 Rationale for Selecting This Resource to Monitor ....................................................... 6

1.6 Measurable Objectives.................................................................................................. 7

2.0 Sampling Design........................................................................................................................9

2.1 Rationale for Selecting This Sampling Design over Others......................................... 9

2.2 Site Selection .............................................................................................................. 12

2.3 Sampling Frequency and Replication ......................................................................... 12

2.4 Level of Change Detectable for The Amount/Type of Sampling Being Instituted .... 13

3.0 Hydrographic Survey...............................................................................................................15

3.1 Field Season Preparations and Equipment Setup........................................................ 15

3.2 Field Operations.......................................................................................................... 15

3.3 Post-cruise Operations................................................................................................ 16

4.0 Data Handling, Analysis, and Reporting .................................................................................17

4.1 Overview of Information Architecture ....................................................................... 17
vi

4.2 Overview of Data Products......................................................................................... 18

4.3 Dissemination: Accessing the Data Deliverables....................................................... 21

4.4 Repository: Data Archiving ........................................................................................ 23

4.5 Deliverable Validation and Certification.................................................................... 23

4.6 Data Acquisition: Scheduling Deliverable Production............................................... 24

4.7 Managing the Production Environment...................................................................... 24

4.8 Metadata Maintenance ................................................................................................ 24

4.9 Pre-certification Data Delivery................................................................................... 25

5.0 Personnel Requirements and Training.....................................................................................27

5.1 Roles and Responsibilities.......................................................................................... 27

5.2 Qualifications.............................................................................................................. 28

5.3 Training Procedures.................................................................................................... 28

6.0 Operational Requirements .......................................................................................................29

6.1 Annual Workload and Field Schedule ........................................................................ 29

6.2 Facility and Equipment Needs.................................................................................... 30

6.3 Startup Costs and Budget Considerations................................................................... 30

6.4 Protocol Revision Process........................................................................................... 31

7.0 Oceanography of Glacier Bay: Other Considerations .............................................................33

8.0 References................................................................................................................................35

8.1 References Cited and Publications Utilizing GLBA Oceanography Data.................. 35

8.2 GLBA Oceanography Program Reviews and Reports................................................ 37
vii

Figures

Page

Figure 1.1. Map of the northeast Gulf of Alaska locating Glacier Bay and GLBA 

(light shading) with respect to the nearby major bodies of water....................................................2

Figure 2.1. Oceanographic sampling station locations in Glacier Bay, Alaska............................10

Figure 4.1. The SEAN Core Functional Model overview. ...........................................................17

Figure 4.2 Deliverable references located on the oceanographic monitoring 

program’s main page......................................................................................................................22

Figure 4.3 Example content for a deliverable’s subordinate web page. This 

specific illustration is appropriate for deliverable OC_B (raw HEX files). ..................................23

Figure 4.4 Sequence of tasks and staff responsibilities used in the SEAN 

certification process. ......................................................................................................................25

Figure 4.5. Calibration files and documents (OG_A and OC_G) created at the end 

of the prior cycle must be available for the current season............................................................26
viii

Standard Operating Procedures

Page

SOP 1: CTD Maintenance, Storage and Calibration .....................................................................39

SOP 2: Calibration Certificates (OC_G Creation).........................................................................41

SOP 3: CON Calibration files (OC_A Creation)...........................................................................45

SOP 4: Hydrographic Survey.........................................................................................................51

SOP 5: CTD Data Download and Transfer to Network ................................................................57

SOP 6: Raw HEX Files (OC_B Creation).....................................................................................61

SOP 7: Post-cruise Quality Assurance: Raw Data Plots................................................................65

SOP 8: Processed CNV Files (OC_C Creation) ............................................................................71

SOP 9: Post-season Quality Assurance: Calibration Evaluation ...................................................77

SOP 10: Cumulative Database (OC_D Creation)..........................................................................79

SOP 11: Data Quality Assignment (OC_M Creation)...................................................................81

SOP 12: Field Log Sheets (OC_H Creation).................................................................................85

SOP 13: Data Availability Matrix (OC_J Creation)......................................................................87

SOP 14: Annual Data Report (OC_K Creation)............................................................................89

SOP 15: 5-Year Report (OC_L Creation)......................................................................................95

SOP 16: AOOS Data Submission (OC_E Creation)....................................................................101

SOP 17: NODC Data Submission (OC_F Creation) ...................................................................103

SOP 18: Protocol Revision (OC_I Creation)...............................................................................105

SOP 19: Managing the Production Environment.........................................................................109
ix

Appendices

Page

Appendix A. Oceanographic station locations.............................................................................113

Appendix B. Standard form templates.........................................................................................115

Appendix C. Oceanographic survey equipment list. ...................................................................119

Appendix D. List of acronyms.....................................................................................................121

Appendix E. Summary of 2009 protocol development working group discussion. ....................123

Appendix F. CTD instruments employed in program. ................................................................127

Appendix G. Data file standard header........................................................................................129

Appendix H. Typical computer directory structures....................................................................131

Appendix I. Sea-Bird software detailed configuration. ...............................................................135

Appendix J. Deliverable definitions. ...........................................................................................143

xi

Abstract

Initiated in 1993, the Glacier Bay hydrographic survey archives represent one of the longest 

running oceanographic datasets in Alaskan waters. This document describes the field methods 

and data handling procedures required to ensure an uninterrupted and consistent sampling 

program in the future collection, quality assurance and archiving procedures. The dataset will 

enable future analyses to better interpret observed changes in the physical environment and 

better understand how the marine physical environment impacts the abundant marine life found 

within Glacier Bay.

Nine field surveys are scheduled for each year: comprehensive surveys in mid-winter and midsummer with occupation of all standard stations, and seven monthly surveys between March and 

October with occupations of representative core stations. Water column profiles of the following 

parameters constitute the measurements for all surveys: water temperature, salinity, 

photosynthetically active radiation (PAR), optical backscatterance (OBS – turbidity), dissolved 

oxygen, and chlorophyll a fluorescence.
xii

Acknowledgements

The authors would like to extend their deepest appreciation to all of the people who have been 

responsible for carrying the Glacier Bay oceanographic sampling to the point it is at today. 

Oceanographic time series of this extent and quality are rare anywhere and particularly rare in 

Alaskan waters. The science field crews, vessel operators, and principal investigators all have 

dedicated untold time and resources toward creating this dataset and these efforts have resulted 

in what will be an enduring legacy through the implementation of this oceanographic monitoring 

program. We thank the authors of Hooge et al. (2003) for providing a sound foundation for the 

subsequent generation of this protocol. We thank our collaborators and reviewers who provided 

valuable and defining input to the process that led to the sample design selection, the final 

protocol document, and implementation of the program. In particular, Lisa Etherington, Mayumi 

Arimitsu, David Hill, Dean Tucker, Tom Royer and Tom Weingartner all provided valuable 

insights and comments.
1

1.0 Background and Objectives

1.1 Protocol Synopsis

This protocol is an update of and supersedes the Hooge et al. (2003) Fjord Oceanography 

Handbook. The National Park Service (NPS) Southeast Alaska Network (SEAN) entered into an

agreement with the University of Alaska-Fairbanks (UAF) to cooperatively update and revise 

Hooge et al. (2003), following NPS standards for protocol content as described in Oakley et al. 

(2003). Some relevant material herein remains unchanged from Hooge et al. (2003), including 

the majority of the fundamental data processing algorithm settings. Significant changes and 

additions have been made to the protocol for the sampling design and for visualization, reporting, 

and archiving data. Much of section 1.2 is reproduced from the executive summary of Eckert et 

al. (2006), “Assessment of coastal water resources and watershed conditions at Glacier Bay 

National Park and Preserve, Alaska.” Readers are encouraged to consult this original source for

additional references and more detailed background information.

The body of this protocol is structured to provide an overall description of steps, processes, and 

staff responsibilities for conducting the monitoring program. Standard Operating Procedures 

(SOPs) provide detailed, step-wise procedures for conducting each step or process. SOPs are 

referenced in each section, as appropriate.

This protocol was designed for application to Glacier Bay proper. Throughout this document, we 

use “GLBA” to refer to the entirety of the NPS administrative unit of Glacier Bay National Park 

and Preserve, and “Glacier Bay” to refer to Glacier Bay proper.

1.2 Historical and Biophysical Background

Glacier Bay has been used by aboriginal Alaskans for millennia (Schroeder 1993), including use 

by ancestors of the modern Tlingit. European and Russian explorers and hunters “discovered”

Glacier Bay in the 18th and 19th centuries, culminating with John Muir’s visit with the Harriman 

Alaska Expedition in 1899 (Goetzmann and Sloan 1982). Following the suggestion of William S. 

Cooper and with the backing of the Ecological Society of America, on February 26, 1925

President Calvin Coolidge created Glacier Bay National Monument to preserve the majestic 

beauty and scientific opportunities. The area of the Monument doubled in size in 1936, and the 

boundaries were modified in 1955, excluding Gustavus and the east side of Excursion Inlet. Gold 

mining was permitted from 1936 until 1976. Glacier Bay became a National Park through the 

Alaska National Interest Lands Conservation Act (ANILCA) of 1980, which extended the park 

boundary to the Alsek River and Dry Bay for a total area of over 1.33 million ha (3.28 million 

acres) including 23,426 ha (57,884 acre) in the preserve (Eckert et al. 2006). GLBA was 

designated an International Biosphere Reserve in 1986 and a World Heritage Site in 1992. In a 

2005 US Supreme Court case filed by the State of Alaska, the NPS was granted jurisdiction over 

submerged lands and tidelands within GLBA boundaries. This decision made GLBA one of the 

few protected areas in the world that includes submerged marine habitat within its jurisdiction. 

Bartlett Cove is the single major site of terrestrial human presence in GLBA and the only 

location in the park that is human-occupied year-round.

GLBA is located in Southeast Alaska and is bordered by the Gulf of Alaska to the west, Icy 

Strait to the south, Tongass National Forest to the west and northwest, Tatshenshini-Alsek 
2

Provincial Park (Canada) to the north, and Tongass National Forest to the northeast (Figure 1.1 

and Figure 1.2). GLBA encompasses marine areas along the outer coast, Cross Sound, Icy Strait, 

Glacier Bay proper, and smaller bays including Dundas Bay, Lituya Bay, Torch Bay and Dry 

Bay. 

Figure 1.1. Map of the northeast Gulf of Alaska locating Glacier Bay and GLBA (light shading) with 

respect to the nearby major bodies of water. Color shading represents the bathymetric topography, with 

depths of greater than 500m colored dark blue. The entrance to Glacier Bay resides at the crest of a 

shallow sill (~50m) in Icy Strait, separating northern Chatham Strait from Cross Sound.

GLBA is well known as a natural laboratory, and starting with John Muir and William S. 

Cooper, studies of ecological succession began in the late 1800s and early 1900s. Vegetation 

changes along the gradient of glacier recession within GLBA are classic examples of ecological 

succession (Cooper 1923, Lawrence 1958). In streams, the successional development of plant 

and animal communities is closely connected with the growth and maturation of adjacent 

terrestrial plant communities. Stream invertebrates colonize streams after dissolved organic 

carbon inputs by colonizing stream bank vegetation reach adequate levels. As plant succession 

continues, woody debris may accumulate in streams, providing shelter for fish and promoting 

colonization by anadromous salmonids (Milner 1987).
3

Figure 1.2 Location of GLBA with respect to nearby federal, state and provincial parks and forests.
4

Glaciers have been carving the region for millions of years and today approximately 27%

(356,136 ha [880,000 acres]) of GLBA is covered by glacial ice. In 1794, Captain George 

Vancouver documented that Glacier Bay was only 5 miles long due to a massive glacier 

occupying the bay with its terminus located just south of Sitakaday Narrows. At that time, this 

large glacier, which is now called the Grand Pacific Glacier, measured more than 1,200 m (4,000 

ft) thick, 32 km (20 mi) wide, and more than 161 km (100 mi) long. By 1916, the Grand Pacific 

Glacier had retreated 100 km (60 mi) to the present Tarr Inlet. This dramatic glacial retreat 

provides an outstanding opportunity to study glacial retreat, ecological succession, the effects of 

climate change, and other physical and biological dynamics of the area. Glacial retreat has 

caused and is continuing to cause tremendous physical changes to GLBA, and as a result, its 

freshwater and marine ecosystems are dynamic and challenging to understand. 

Fall, winter, and spring months are dominated by the strong Aleutian Low in the northeastern

Gulf of Alaska; weak high pressure systems prevail in the summer (Brower et al. 1988). As a 

result, GLBA experiences a wet and moderate marine climate. Records from the Bartlett Cove 

weather station (the only permanent station located with GLBA) has records going back to 1966 

and shows an average temperature of 4.9oC (40.9oF), average rainfall of 92 cm (36 in), and 

average snowfall of 132 cm (52 in). July is the warmest month with an average temperature of 

12.8oC (55oF), and the coolest conditions occur in January, when the average temperature is 

−2.8oC (27oF). Given the geographic and topographic heterogeneity within GLBA, however, data 

from this weather station does not represent the diversity of conditions within GLBA. 

Biological marine resources include a rich diversity and high abundance of marine mammals, 

including humpback whales (Megaptera novaeangliae), killer whales (Orcinus orca), harbor 

seals (Phoca vitulina), Steller sea lions (Eumetopias jubatus), sea otters (Enhydra lutris), harbor 

porpoises (Phocoena phocoena), minke whales (Balaenoptera acutorostrata), and rarely Dall’s 

porpoises (Phocoenoides dalli). Humpback whale monitoring in Glacier Bay proper, begun in 

the mid-1980s, indicates an increasing population. Harbor seals, however, have undergone a 

drastic decline of over 75% from 1992–2008, at an average annual rate of approximately 10%. 

Sea otters have undergone a dramatic increase since they began recolonizing Glacier Bay in 

1993, with approximately 2,800 individuals recorded in 2006. 

Fish and bird diversity in GLBA are very high. Glacier Bay is an important nursery area for 

fishes and is probably a spawning location for many species. Glacier Bay provides important 

habitat for many marine birds, with species composition shifting from predominantly seabirds in 

the summer to predominantly waterfowl in the winter. Some species of marine birds have been 

declining in Glacier Bay, including Kittlitz’s and marbled murrelets, which have been declining 

throughout Alaska. Glacier Bay supports the largest breeding-season population of Kittlitz’s 

murrelets in the world. Marine invertebrate resources are diverse and abundant and include 

Tanner (Chionoecetes bairdi), Dungeness (Cancer magister), and king crabs (Paralithodes spp.). 

1.3 Purpose of Oceanographic Sampling

Oceanographic measurements collected on the hydrographic survey enable a set of first-order

perspectives into local ecosystem relationships (Mann and Lazier 2006). Physical measurements 

include temperature, salinity, light, oxygen and suspended sediment. These measurements 

characterize the environment that directly impacts both lower trophic (e.g., phytoplankton) and 
5

upper trophic (e.g., crabs, fishes, marine mammals and birds) organisms through their influence 

on metabolic rates, ability to support carbon fixation through production of chlorophyll, or the 

propensity for organisms to be retained within/exported from the euphotic layer. Fluorescence 

measurements provide an index of the phytoplankton standing stock, which in turn forms the 

food base for primary consumers (zooplankton) and the subsequent cascade of carbon through 

trophic levels to apex predators (e.g., fishes, marine mammals and birds). Thus, observations 

made within this monitoring program form a foundation upon which other (e.g., chemical 

hydrography, habitat, population) aspects of the marine ecosystem within Glacier Bay can be 

evaluated. Because this dataset comprises one of the longest running oceanographic time series 

in coastal Alaskan waters, it also provides a valuable perspective of the regional oceanography: 

similar length datasets of comparable quality and measured parameters are found only hundreds 

of kilometers up- and down-coast.

1.4 Overview of Prior Oceanographic Sampling

Multiple sills, embayments, tidewater glaciers, islands and other topographic features 

characterize Glacier Bay’s complex bathymetry. Previous oceanographic studies with focus upon 

Glacier Bay are limited in number; most of our understanding comes from Matthews and 

Quinlan (1975), Matthews (1981), Hooge and Hooge (2002), Etherington et al. (2004), Madison 

and Etherington (2005), Etherington et al. (2007) and Hill et al. (2009). 

Bottom water renewal can occur in any month (Matthews 1981, Hooge and Hooge 2002) while 

solar heating, snow melt, and ice melt stratify the upper water column between spring and 

summer (Matthews 1981, Etherington 2007). The strength and relative importance of tidal 

mixing varies throughout the bay (Matthews 1981, Etherington et al. 2007); Glacier Bay has 

mixed semi-diurnal tides and a large tidal range, averaging 3.7 m (12 ft) near the mouth to 

greater than 4.2 m (14 ft) at the heads. In 2008, the National Oceanic and Atmospheric 

Administration (NOAA) National Ocean Service (NOS) Center for Operational Oceanographic 

Products and Services (CO-OPS) deployed 51 current meters in southeast Alaska, 9 of which 

were within GLBA waters. The resulting data has not been published, but a project report was 

submitted to the NPS that documents average current speeds at each mooring site (Burke 2008). 

Preliminary results indicate that near-surface currents are highly variable depending upon 

location and can attain speeds as high as 220 cm/s (Burke 2008).

Thirteen cruises collected oceanographic data between 1964 and 1967 (Matthews et al. 1975,

Matthews 1981) but cruises after this time were not common until 1993. In the years since 1993, 

the NPS and the US Geological Survey (USGS) have conducted CTD (conductivity-temperaturedepth) monitoring of physical conditions, including temperature, salinity, turbidity, 

photosynthetically active radiation (PAR), and in situ fluorometric measurements at 24 stations 

distributed throughout the Bay. Annual data reports, peer review publications, and program 

evaluations that describe these measurements are listed in the Reference section of this 

document. Data from these and other field efforts are archived locally at the SEAN 

oceanography web page (http://science.nature.nps.gov/im/units/sean/).

This oceanographic monitoring program has documented salinity values ranging from less than 

10 to greater than 32 with least saline waters found in narrow surface lenses near tidewater 

glaciers, and the most saline waters at depth in the lower Bay. Density fluctuations are primarily 
6

driven by salinity, which is the driving dynamic parameter for most coastal Alaskan waters. Sea 

water temperatures range from −1 to 15oC (30 to 59oF), with the coldest temperatures found at 

the heads of the two arms in late winter and the warmest waters observed in surface stratified 

waters during summer. Light penetration is reduced by sedimentation resulting from glacial 

runoff and by increases in phytoplankton biomass. The factors driving reductions in light 

penetration are important to understand because the amount of light available impacts 

phytoplankton production. Zooplankton surveys indicate rich productivity in a variety of 

locations within Glacier Bay, particularly in upper inlets with and without tidewater glaciers and 

near river and stream outlets. 

1.5 Rationale for Selecting This Resource to Monitor

GLBA is quintessentially a marine park. Along with weather, glaciers, and landform, the ocean 

waters drive the park’s ecosystems and dominate the dynamics of many biological communities, 

from primary producers to apex predators. A number of the SEAN Vital Signs applicable to 

GLBA (e.g., Marine Predators, Intertidal Invertebrate Communities, Kittlitz’s Murrelets) are 

themselves directly or indirectly influenced by oceanography. By monitoring select parameters, 

managers can detect oceanographic changes that are likely to influence the condition of many 

resources throughout the park and region. Oceanographic monitoring is important to 

understanding the Southeast Alaska marine ecosystem, the linkages between atmospheric and 

oceanic systems, and the implications of climate change in high-latitude systems. 

Standard oceanographic data are universally recognized among marine scientists as essential to 

understanding how ocean waters influence marine communities in a “bottom-up” fashion

(McLeod and Leslie 2009). The cascade of energy to higher trophic levels begins with the water 

column conditions (e.g., temperature, stability) which are reflected in the data collected by this 

program. Along with water column stability and nutrient availability, the availability of light 

drives primary productivity which then controls the dynamics of secondary productivity and 

indeed the entire marine trophic web. Light and light limitations in high suspended sediment 

waters have been identified as critical factors impacting phytoplankton production within Glacier 

Bay (Hooge and Hooge 2002).

Petroleum spills in particular present an environmental risk to coastal water resources in GLBA. 

Currently, Geographic Response Strategies (GRS), which are spill response plans tailored by 

ADEC and other agencies, protect specific sensitive areas from oil impacts following a spill. 

Specific areas within the park for which GRS exist include Point Carolus, Bartlett Cove, Berg 

Bay, Hugh Miller Inlet, North Beardslee Island, South Marble Island, and Sandy Cove. In 2007, 

SEAN initiated a marine contaminants monitoring program (using blue mussel tissue assays) to 

track long-term trends and to maintain a moving baseline that would be exceptionally valuable in 

the event of an acute local impact (e.g., a vessel grounding or spill). In the event that a significant 

spill calls for the services of the NOAA Office of Response and Restoration (OR&R), the data 

collected by the oceanography monitoring program can be used to help initialize and drive the 

General NOAA Operational Modeling Environment (GNOME) spill trajectory model.

Climate change is an important natural resource issue for national parks, and recent research 

suggests that changes in climate may dramatically impact water resources in Alaskan parks. 

Striking effects of climate change on hydrologic resources in Alaska include changes in the 
7

extent of permafrost and glaciers and the timing of annual sea ice onset and retreat. A direct 

result of increased glacier melt is an increase in coastal runoff (Arendt et al. 2002), and an

alteration of coastal sediment discharge. Both inputs can have downstream consequences for the 

marine ecosystem. Possible effects include increased levels of stratification (with implications 

for phytoplankton growth timing and magnitude) and increased cross-frontal density gradients 

(with implications for along-shore transport and cross-frontal mixing processes). Reports from 

the Intergovernmental Panel on Climate Change (e.g., IPCC 2007) predict high probabilities of 

increased global mean temperatures over the coming decades. The cryosphere is known to be 

sensitive to fluctuations in temperature; many ice fields in Alaska are now experiencing net 

ablation and many tidewater glaciers are retreating. Currently, glaciers in coastal GLBA are 

thinning at rates as high as 4 m (13 ft) per year and glacial retreat over the last two centuries has 

moved the leading edge of the tidewater glaciers in Glacier Bay up the fjord more than 100 km. 

The isostatic rebound associated with retreating ice (Larsen et al. 2004) can strongly impact the 

ecosystem near the water’s edge (both on land and in the water). Glacial systems are dynamic 

balances between accumulation and ablation; continued glacial retreat as well as probable 

periods of glacial advance will modify both the terrestrial and marine environments and 

ecosystems in the future. Monitoring the accompanying oceanographic changes is critical to 

understanding the causes and implications of such impacts. 

Eckert et al. (2006) identified four factors that could contribute to impairment of GLBA marine 

water resources: contaminants, harmful algal blooms, invasive aquatic species, and climate 

change. Biological populations will respond to impacts realized, and the oceanographic 

monitoring program will enable us to better understand and/or mitigate resultant changes and 

effects. Within GLBA, nearly all other resource and research issues are related to the marine 

ecosystem. Therefore, a better understanding of the many interconnected subsystems comprised 

by GLBA is dependent upon improved knowledge of underlying oceanographic processes. 

1.6 Measurable Objectives

The adopted objectives for the GLBA oceanographic monitoring program were refined through 

discussion during the 2006 Program Evaluation (Etherington 2006) and are re-worded here for 

clarity. 

The purpose of this sampling is to compile a dataset of oceanographic conditions from Glacier 

Bay that can be used to 1) better understand seasonal and interannual changes in the local and 

regional oceanographic dynamics and 2) better understand spatial and temporal variation in the 

abundance patterns of marine organisms including phytoplankton, zooplankton, marine 

invertebrates, fishes, mammals and seabirds. Measured and derived parameters that comprise this

dataset include temperature, salinity, stratification, photosynthetically active radiation (PAR), 

optical backscatterance (OBS; turbidity), chlorophyll fluorescence, and dissolved oxygen.

9

2.0 Sampling Design

Between 1993 and 2008, oceanographic sampling was targeted at the majority of 24 stations on a 

nominally quarterly basis. In designing the selected sampling scheme, we worked to incorporate 

results from prior monitoring program reviews (see section 8.2), evaluations of our proposed 

modifications and peer-review publications that employ these data so that the selected program 

maintains coherence with past sampling and also forms the basis for the strongest possible 

sampling program from this point forward. We took the 10- to 100-year view: in ten years, this 

dataset will span a quarter century and the bulk of observations will still be from collections 

made prior to 2009. In 100 years, however, collections made prior to 2009 will comprise fewer 

than 15% of the total observations. To gain maximum utility, we have strived for a balance 

between continuity between samples taken before and after 2009 and what we feel is the most 

useful dataset in the long run. 

We were fortunate to have this considerable data set and several corresponding analyses to 

inform our development of a long-term protocol. In considering existing data, we found that past 

quarterly sampling adequately resolved inter-annual signals, but was not of sufficient resolution 

to permit characterization of seasonal signals. Achieving both scales of resolution are inherent to 

meeting our specified monitoring objectives. 

This SEAN protocol, therefore, modifies the sampling design to achieve a balance between 

spatial and temporal resolution: semi-annual sampling at the “full” complement of 23 stations 

and monthly sampling from March to October at 7 “core” stations. Samples are taken in the 

months of March, April, May, June, July, August, September, October and once in winter 

(December or January), see Figure 2.1.

Water column CTD profiles include direct measurements of pressure, temperature, conductivity, 

fluorescence, dissolved oxygen, PAR, and OBS. Derived values from these measurements 

include depth, salinity, density, chlorophyll a concentration, and turbidity. 

2.1 Rationale for Selecting This Sampling Design over Others

The selected sampling design achieves moderate spatial resolution of the selected parameters at 

the “full” complement of 23 stations (Figure 2.1) so that annual and longer timescale signals can 

be resolved at all historical CTD stations. Also, monthly sampling (but with coarser spatial 

resolution) is achieved at the “core” 7 stations during the spring, summer and fall seasons when 

the ecosystem undergoes its largest dynamical range excursions and the physical properties 

exhibit their largest temporal and spatial gradients The greatest range in densities spans the 

spring (cold and salty) to fall (warm and fresh) time period. This design, therefore, achieves a 

balance between an intensive spatial sampling at two times per year to resolve annual signals and 

an intensive temporal sampling at a smaller suite of stations to resolve seasonal signals during 

the time that heat and fresh water accumulate in the system. This spatial/temporal balance 

addresses logistical, weather and budget realities associated with limited numbers of ship days, 

labor, and funds that the NPS can dedicate to this particular sampling effort and sustain over the 

long-term.
10

Figure 2.1. Oceanographic sampling station locations in Glacier Bay, Alaska. Stations comprised by the 

“core” station set are shown on a blue square background. Stations 00-14, 16-21 and 24 comprise the 

“full” station set. Stations 00-23 were historically sampled.
11

The protocol requires three days of ship time each in July and mid-winter, and two days each for 

cruises monthly during March-June and August-October. This reduction in the number days 

necessary to complete most cruises requires a smaller window of good weather to complete the 

minimum sampling and will result in a more complete dataset. By staging adequate fuel onboard, it is possible that some of the monthly sampling field trips may be achieved with only one 

day of field work, thereby potentially reducing the total number of ship days per year.

In addition to the selected design, three alternative designs were considered. The following 

subsections (2.1.1 – 2.1.3) present brief summaries of these alternative designs; appendix E

provides an overview of the protocol development focus group meeting that led to selection of 

the sampling design.

2.1.1 Alternative Design 1: Quarterly Sampling at Historical Station Locations

Alternative Design 1 represented a continuation of the 23 historic stations on a quarterly basis. 

Although this option would maintain the highest degree of continuity between historical and 

future efforts, this design was not attractive because it would not be able to resolve seasonal 

signals and thus would not fulfill the program objectives stated in section 1.3. 

2.1.2 Alternative Design 2: Oceanographic Moorings 

We considered subsurface taut-wire oceanographic moorings in Alternative 2. Advantages of a 

monitoring program built upon mooring technology include high frequency temporal sampling 

(~1 hour, year-round) and the need of only one ship day per year for mooring servicing. 

Disadvantages include potential loss of an entire years worth of data if the mooring should

catastrophically fail; inability to reliably sample the uppermost 10m of the water column, where 

many important physical and biological processes take place; problems associated with 

biofouling, which can degrade measurement accuracy; the considerable initial outlay of funds to 

purchase all needed equipment is considerable (estimated at $50,000–$100,000 per mooring, 

depending on configuration). The single most important disadvantage is that a mooring system 

would yield lower-resolution spatial sampling (both in the horizontal and vertical dimensions), 

thereby precluding achievement of our monitoring objectives. For these reasons, we determined 

that this alternative was not an acceptable replacement for the existing monitoring program. A 

mooring would be a very useful addition if additional funds become available, to add a high 

frequency temporal sampling.

2.1.3 Alternative Design 3: Incorporation of Ocean Acidification Measurements

Due to the recognized risk of ocean acidification to marine ecosystems, we also considered

monitoring the carbonate cycle as part of the hydrographic cruises. A number of factors made 

this effort unrealistic at the present time. Primary among them is that to measure oceanic pH, the 

commercially available pH probes for deployment with a CTD do not achieve the required 

resolution; they achieve an accuracy of about 0.1 whereas 0.001–0.010 is required in an ocean 

acidification study. To achieve the required accuracy, water column samples must be obtained 

and processed in an analytical laboratory. For the purposes of this monitoring program, the costs 

and additional effort are impractical; however SEAN and GLBA will work to identify external 

funding sources and partnerships that would allow us to add this important component to our 

selected design.
12

2.2 Site Selection

The “full” station set includes stations 00-14, 16-21 and 24; see Figure 2.1 for a map of station 

locations and the delineation of stations into the four primary domains. Appendix A provides

geographic coordinates of the stations. Station 24 (North Passage) is now being added in 

response to recommendations of the 2006 Program Evaluation (Etherington 2006) and comments 

made by reviewers of the proposed protocol modification. Specifically, the 2006 Program 

Evaluation identified the most important candidate for an additional station as “one west of the 

Bay mouth in deeper water NW of Lemesuier Island” (Etherington 2006:10). The location for 

Station 24 was chosen to coincide with the deepest point in the passage cross-section and within 

a reasonable distance to the mouth to Glacier Bay so that vessel transit time to the station is not 

impractical. The full station set comprises the majority of the historically sampled CTD stations

from the years 1993–2008. Stations 22 and 23 in Geikie Inlet were not included within this 

program because Etherington (2006) recommended their elimination due to the need to reduce 

the time required to attain all samples. Station 15 was sampled historically, but was dropped 

from the program in 2005 after confirmation of a high degree of redundancy of that station with 

Station 14.

The “core” station set includes stations 01, 04, 07, 12, 13, 16 and 20. These stations are chosen to 

achieve one (Lower Bay) or two (all other domains) representative samples in each of the 

primary oceanographic domains at a higher temporal sample rate during the spring, summer, and 

fall months. 

In aggregate, previously published annual reports, peer-reviewed journal articles and program 

reviews (see Reference section below) form the basis for the selection of the core and full 

stations sets. The core stations are selected to capture one or two samples within each of four

oceanographic domains within Glacier Bay. These domains (Lower Bay, Central Bay, West 

Arm, and East Arm) reflect different — though not independent — biophysical settings that give 

each domain its own characteristics. These domains are not exhaustive of all possible marine 

settings within Glacier Bay, but they do represent a wide variety of the major habitat types. 

Etherington et al. (2007) address the breakout of stations and show that variability within

domains is generally small compared to variability across domains. 

Station 12 (rather than 21) was selected for inclusion within the core station set because the 

historical database contains more occupations of Station 12 and in months of thick ice cover, 

Station 12 is more reliably accessible. Stations 12 and 20 add considerable time to the field work 

due to the long transits required to access the stations, but due to the proximity of these stations 

to the fjord heads, they are situated within habitat types not found farther down the fjords. These 

stations are important to help keep attention upon the shallow buoyant ice melt/coastal runoff 

plume observed at the head of each fjord and the associated biological responses (e.g., Kittlitz’s 

Murrelets habitat and those documented in Etherington et al. [2007]).

2.3 Sampling Frequency and Replication

Sampling includes vertical CTD profiles at

1) the “full” station set twice per year: summer (July) and winter (December or January) 

2) the “core” station set in March, April, May, June, August, September, and October
13

One vertical profile is required at each of the sample sites. The CTD samples at a rate of 2 

measurements per second. These raw scans are subsequently averaged into 1-m bins. At a typical 

lowering rate of 1 m/s, this achieves approximately 2 samples per 1 m average depth level in the 

final data file. This final data product thus achieves a medium-resolution depiction of all 

variables throughout the measured water column. 

2.4 Level of Change Detectable for the Amount/Type of Sampling Being Instituted

Monthly sampling of the core station set between March and October will allow resolution of 

seasonal variability during the period of times that exhibit the greatest biological production and 

the physical system is typically undergoing its most rapid thermal and fresh water fluctuations. 

Semi-annual sampling of the full station dataset will achieve a higher resolution depiction on an 

annual basis at the highest feasible spatial resolution. This dataset will be appropriate for 

evaluating interannual variability associated with climate-scale processes such as the El Nino 

Southern Oscillation (ENSO) cycle, the Pacific Decadal Oscillation (PDO), or the North Pacific 

Index (NPI). 

The sample design does not resolve nearshore oceanographic properties or sub-monthly time 

scales, including the fortnightly (2 week), synoptic (2–6 day), tidal (12–24 hour), or supertidal (< 

12 hr) signals. Tidal fluctuations are regular and predictable, however, and measurements can be 

interpreted with respect to the tidal phase and amplitude of the major constituents.

15

3.0 Hydrographic Survey

The field work component of this monitoring program results directly in the long-term dataset 

that is needed in order to form robust assessments about the state of the Glacier Bay marine 

system. This dataset will enable NPS the ability to observe, assess, and understand changes (both 

natural and anthropogenic). 

Looking ahead to the generation of annual data reports (SOP 14) and five-year reports (SOP 15), 

steps taken during the survey will assist in the generation of these documents. In particular, 

entries made in the “Comments” and “Notes” sections on the CTD station Field Log will assist 

the Project Leader in assembling the cruise operations summary for the reports. Selected

photographs of unusual (or even typical) events and conditions can also be incorporated into the 

reports.

3.1 Field Season Preparations and Equipment Setup

Instrumentation at the start of the sampling year (December/January cruise) should be in good 

working order, having been previously calibrated at the manufacturer in the time since the 

previous (October) cruise. A test cast off the dock in Bartlett Cove and subsequent data 

download and inspection will ensure proper equipment functionality and setup before heading 

out to the sampling stations. Instructions for assembling equipment required for the survey are 

given in SOP 4, section 1, with the following subsections:

SOP 4: 1.0 Field Preparations

 Supplies to have on hand (see also Appendix C)

 Check computer to CTD communications

 Check battery voltage

 Memory check and clear

 Check date and time

 Test cast, download test data, verify

3.2 Field Operations

Each survey is nominally scheduled to occur within the first full week of the designated month. 

Vessel availability, vessel operator availability, and weather forecasts all will influence the actual 

timing of each cruise. 

Details of the at-sea portion of the sampling program and the order of operations are listed in 

SOP 4, section 2:

SOP 4: 2.0 Field Operations

 Selection of sampling sequence

 Navigate to station

 Fill out CTD station log 

 Initiate data logging

 Equilibrate the CTD just below the surface

 Lower CTD to target depth

 Haul CTD back to surface 
16

 Terminate data logging

 Complete CTD station log 

 Fresh water rinse

 Stow CTD for transit

3.3 Post-cruise Operations

Post-cruise operations are detailed in SOP 4, section 3. Additional instructions detailing file 

download from the CTD are found in SOP 5. Instructions for file verification and plotting, done 

to ensure proper operation of the instrumentation and capture of data, are in SOP 7.

SOP 4: 3.0 Post-cruise Operations 

 Storage of the CTD and associated hardware

 Transfer data to network

 Data file verification and plotting

Once the data have been archived on the network servers, initial data verification steps are taken 

to ensure proper operation of the instrumentation and capture of data. 

Evaluation of post-season calibration results (SOP 9), creation of data deliverables (SOPs 6, 8, 

10, 11, 12, 13, 16, and 17) and annual report generation (SOP 14) are performed using all cruises 

at the end of the sampling year after post-season calibrations have been received from Sea-Bird.
17

4.0 Data Handling, Analysis, and Reporting

This chapter describes the general approaches to generating, maintaining, and disseminating 

products of this monitoring protocol. Detailed procedures are provided in product-specific SOPs. 

Detailed product definitions may be found in Appendix J. 

4.1 Overview of Information Architecture

Data in the oceanography program are managed according to the standard methods used by all 

SEAN programs, as described in the SEAN Data Management Plan (Johnson and Moynahan 

2008). The model from which these methods were derived is illustrated in Figure 4.1.

Dissemination of all data is done electronically from SEAN and partner web sites. Certain 

reports are also published by NPS under the Natural Resource Technical Report (NRTR) and 

Natural Resource Report (NRR) series. No other dissemination methods are supported.

Figure 4.1. The SEAN Core Functional Model overview. Dissemination services (red) provide all 

deliverables to all customers using Internet web servers. Repositories (yellow) store the certified inventory 

and monitoring products called for in the protocols. Certification processes (green) assure repositories 

have the highest quality data and that sensitive items are restricted to authorized users. Data acquisition 

processes (blue) led by park staff and cooperators include a wide array of tasks, ranging from collecting 

raw data to producing reports on long-term trends.
18

4.2 Overview of Data Products

The oceanography program creates and maintains thirteen specific data products for customers, 

also referred to in this document as deliverables. Each deliverable is disseminated from SEAN 

and, in selected cases, partner web sites. The SEAN web site is the single authoritative source for 

these deliverables. In the event that an oceanography data product distributed by a partner ever 

diverges from the values disseminated by SEAN, the SEAN version should be used.

The deliverables are summarized in Table 4.1 and each deliverable is fully defined in Appendix 

J. Accompanying each definition is a data flow diagram illustrating where underlying data come 

from, what processes are applied to them, where they are stored, and who is responsible for 

managing each of them (Figures J.1 – J.13).

SOPs present the detailed, stepwise process for creating each deliverable. Table 4.1 includes a 

column referencing the appropriate SOP to use in building each one.
Table 4.1. The SEAN data deliverables provided by this monitoring program.

Deliverable 

Title Description Provided to Customers as Frequency Produced Responsibility SOP

OC_A:

CON 

calibration 

files

The collection of calibration files used to adjust 

raw CTD data to standard levels based on the 

particular sensitivity of each sensor in the 

instrument array.

Windows files in the 

proprietary CON format of 

vendor Sea-Bird 

Electronics.

Typically, once per year after the 

annual instrument calibration has been 

performed. May be done more 

frequently if CTD is recalibrated due to 

sensor failure. 

Project 

Leader 3

OC_B:

Raw HEX 

files

The collection of raw CTD data taken in one 

cast. One HEX file is created per cast. Values 

represent relative voltages or frequencies 

sampled from sensors.

Windows files in vendor’s 

ASCII “HEX” format, 

wrapped into a single ZIP 

file.

One ZIP file per year. Project 

Leader 6

OC_C:

Processed 

CNV files

The collection of raw data processed against 

calibration factors, binned into one meter 

segments, and expressed in engineering units. 

One CNV file is created for each cast.

Windows files in vendor’s 

ASCII “CNV” format, 

wrapped into a single ZIP 

file.

One ZIP file per year. Project 

Leader 8

OC_D:

Cumulative 

database

A single cumulative database of all certified 

OC_C data. Customers extract data onto their 

workstations after specifying filter parameters 

such as year, depth range, etc.

ASCII CSV files 

downloaded from web and 

saved onto local 

workstations.

Continuously available. Data 

Manager 10

OC_E:

AOOS data

submission

The data in OC_D are delivered by SEAN to 

partner AOOS (Alaska Ocean Observing 

System), who provide various data visualization 

and reporting tools.

Various forms, as defined 

by partner.

Data are updated periodically from the 

SEAN database as they become 

certified; typically once per year.

Data 

Manager 16

OC_F:

NODC data 

submission

The data in OC_D are delivered by SEAN to 

partner NODC (National Ocean Data Center), 

who combine incoming data with other holdings

and redistribute them to the public and 

researchers.

Various forms, as defined 

by partner.

Data are updated periodically from the 

SEAN database as they become 

certified; typically once per year.

Data 

Manager 17

OC_G:

Calibration 

certificates

Scanned images of certificates provided by 

instrument servicers that document sensor 

sensitivity factors at the time of each calibration.

Individual PDF files, one 

for each certificate.

Typically, one per year per sensor 

after the annual instrument calibration 

has been performed. May be done 

more frequently if an individual sensor 

is recalibrated due to its being repaired 

or replaced.

Project 

Leader 2

OC_H: 

Field log 

sheets

Two-sided color scans of the original field log 

sheets

One PDF file containing 

one November – October 

year.

Once per year. Project 

Leader 12
Table 4.1. The SEAN data deliverables provided by this monitoring program (continued).

20

Deliverable 

Title Description Provided to Customers as Frequency Produced Responsibility SOP

OC_I:

Protocol

This protocol document, explaining the 

complete details of the monitoring program as 

currently implemented.

One PDF file. As required. Program 

Manager 18

OC_J: 

Data 

availability

matrix

Data availability matrix documenting which data 

are available in the OC_D database by month 

and year.

One cumulative PDF file 

covering all years.

Typically once per year after 

certification of the latest OC_D.

Data 

Manager 13

OC_K:

Annual data 

report

Annual report summarizing operations and 

data. One PDF file. Once per year after certification of the 

corresponding OC_D.

Project 

Leader 14

OC_L: 

Five-year 

report

Five-year analysis reviewing trends in the 

collected parameters One PDF file.

Once every fifth year after completion 

of the most recent OC_K annual 

report.

Ecologist 15

OC_M:

Data quality 

assignment

Data quality adjustment report used to flag 

database rows judged to be anomalous for 

various reasons.

Incorporated into the 

OC_D downloadable 

database.

Once per year after certification of the 

latest OC_D.

Project 

Leader 11
21

4.3 Dissemination: Accessing the Data Deliverables

In keeping with SEAN’s data management policies, customers access all of the oceanographic 

program’s deliverables directly from SEAN’s public web site. The web site also contains useful 

ancillary information and references to relevant published and gray literature. Figure 4.2 

illustrates main page content. Most example links in Figure 4.2 are top-level and refer to

subordinate web pages that offer customers the ability to select information covering specific 

years or filtered by specific parameters. Subordinate pages also provide access to formal 

metadata in XML format for the specific deliverable type.

Figure 4.3 illustrates example content for a subordinate page, in this case one that may be used 

for deliverable OC_B (raw HEX files).

Figures 4.2 and 4.3 are intended to illustrate content only. The actual layout, graphics, and 

cosmetics used will follow the guidance of the national Inventory and Monitoring program. All 

SEAN web pages exhibit a consistent style.

While the dissemination services are publicly available to the world, the target audiences include 

NPS managers and resource specialists, and the broader scientific community.

Copies of certified cast data are distributed to the AOOS for further dissemination. The AOOS 

system is rapidly evolving, offers useful analysis tools, and serves an established audience. 

AOOS’s current capabilities and features are documented at http://ak.aoos.org/aoos/index.html. 

SEAN does not control program data once AOOS assimilates it into their operations. Should 

discrepancies be found between AOOS and SEAN data, SEAN is the authoritative source.

Copies of final certified data are also distributed to NODC for further dissemination. NODC is a 

branch of the National Oceanic and Atmospheric Administration (NOAA) that has served as an 

oceanographic data repository since 1961. The NODC archive is the largest collection of 

publicly accessible oceanographic data in the world (see http://www.nodc.noaa.gov/). SEAN 

does not control program data once NODC assimilates it into their operations, nor does SEAN 

manage NODC data’s currency or update schedules. Should discrepancies be found between 

NODC and SEAN data, SEAN is the authoritative source.

Selected certified deliverables and their metadata are also distributed to NPS Data Store for 

further dissemination (http://science.nature.nps.gov/nrdata/). Should discrepancies be found 

between NPS Data Store deliverable copies and original SEAN web site products, SEAN is the 

authoritative source.

In the SEAN model, as depicted in Figure 4.1, a Project Leader is also a customer. When 

creating a product based on earlier deliverables (e.g., annual or five-year reports), the Project 

Leader uses as source material the certified SEAN deliverables from the web; the Project 

Leader’s local work files are not used. This process assures that deliverable creation processes 

only use authoritative data and, thereby, are reproducible. For example, OC_C (processed CNV 

files) is created using OC_B (raw HEX files) and OC_A (CON calibration files). To create 

OC_C, the leader first downloads the certified OC_B and OC_A deliverables to a local 

workstation. The Project Leader’s locally retained files originally used in submitting OC_B and 
22

OC_A are ignored, as it is possible they could have become locally altered copies that diverge 

from certified products.

No deliverables of the oceanographic monitoring program are currently considered sensitive. 

Should a future policy revision make something sensitive, it will be sequestered at SEAN and 

will not be available for general dissemination. Questions regarding existence of sequestered 

products should be directed to the Data Manager through the “Contact Information” link of the 

web site.

Figure 4.2 Deliverable references located on the oceanographic monitoring program’s main page.
23

Figure 4.3 Example content for a deliverable’s subordinate web page. This specific illustration is 

appropriate for deliverable OC_B (raw HEX files).

4.4 Repository: Data Archiving

Oceanographic program data are maintained in SEAN’s Auxiliary Repository on equipment 

located in the SEAN office in Juneau, Alaska. Parts of the SEAN Data Management Plan detail 

the Juneau backup and restore mechanism (Johnson and Moynahan 2008: SOP 204 – Backup 

and Restore Routines; SOP 1101: Network Archiving Process). That same document in Chapter 

11 covers the philosophy of records management at SEAN.

Content of the Auxiliary Repository is also mirrored at the production web site and database 

facilities of the NPS Natural Resource Program Center (NRPC) in Fort Collins, Colorado, from 

which it is publicly disseminated. The NRPC uses enterprise-level business continuity processes 

to maintain their mirror of SEAN’s repository.

Original copies of submissions to outside repositories (OC_E [AOOS] and OC_F [NODC]) are 

retained in a safekeeping area of the Juneau network. Doing so permits reconstruction of failed 

partner repositories. Similarly, NODC archives permit reconstruction of SEAN databases in the 

event of disaster.

4.5 Deliverable Validation and Certification

Each deliverable goes through rigorous validation processes to ensure it meets mandatory quality 

control criteria. After a submitted product meets all mandatory criteria, the originator reviews the 

final version and, if completely satisfied, certifies it. Once certified, the Data Manager installs it 
24

in the repository and ensures it is properly accessible from the dissemination web site. The 

SEAN Data Management Plan describes the approach to validation and certification (Johnson 

and Moynahan 2008: section 6.4 and SOP 601 – Procedures for Certifying Project Data). 

This protocol explicitly defines in Appendix J the set of mandatory and optional validation 

criteria for every deliverable in the oceanographic monitoring program.

Certification requires orchestrating a set of tasks between the Project Leader and Data Manager 

(generically depicted in Figure 4.4). For each deliverable, these tasks are detailed in their 

respective SOPs. Specific interactions between Project Leader and Data Manager are graphically 

illustrated for each deliverable in the data flow diagrams in Appendix J. 

4.6 Data Acquisition: Scheduling Deliverable Production

A set of prerequisites must be completed before most deliverables can be generated. That is, 

creating some deliverables may be dependent on prior certification of other deliverables, which, 

in turn, may have their own dependencies. Figure 4.5 illustrates the typical order used in creating 

the products. Besides formal deliverables, key intermediate processes are also noted in the proper 

sequence. Due to the numerous circumstances and exceptions one may encounter while 

operating the monitoring program, it may be necessary to revise the order of execution ad hoc. 

Figure 4.5 is only an example; the Project Leader may identify acceptable variations. Substantial 

permanent variations will be formalized in future protocol revisions (SOP 18).

4.7 Managing the Production Environment

In order for users of the Internet to have access to I&M products, the content is required to be 

housed on what are called “production” file servers, database servers, and web servers. These are 

currently physically housed in Ft. Collins, Colorado. Only fully-vetted, permanent items are 

allowed in the production environment. The SEAN maintains its own environments in order to 

prepare content for production. These are known as the Development, Test, and Staging 

environments. They reside on their own servers located at the SEAN offices.

The technical details to observe in preparing program data products and installing them in 

production are addressed in SOP 19.

4.8 Metadata Maintenance

The Data Manager is responsible for maintaining FGDC-compliant metadata for each tabular 

deliverable. SEAN stores metadata as XML files and serves them on the SEAN webpage, 

alongside the deliverables they describe. SEAN uses NPS Metadata Editor and the 

NPS_Basic_Edit stylesheet for basic entry. Where data fields exist, SEAN extends the basic 

metadata by providing the Entity_and_Attribute_Information section. Metadata considerations 

are further addressed in Chapter 8 of the SEAN Data Management Plan (Johnson and Moynahan 

2008).
25

Figure 4.4 Sequence of tasks and staff responsibilities used in the SEAN certification process.

4.9 Pre-certification Data Delivery

At times, users may benefit from having access to the data soon or immediately after a cruise, 

rather than waiting for the year-end certification process to complete. For example, a researcher 

who is planning an early summer expedition to Glacier Bay could benefit from seeing the late 

spring vertical profiles. For these time-sensitive cases, the Project Manager can be contacted 

directly and will arrange on an ad hoc basis to deliver the requisite .HEX and .CON files. The 

post-cruise raw in-season data plots can be disseminated in the same fashion. The intent is to 

provide useful (but raw and lower quality) data to those with immediate need. Also see Chapter 7 

for suggested future improvements to the dissemination of near real-time data.
26

PRE-SEASON

Deliverable Comment

OC_G: CTD calibration certificate images Generally available as previous year’s post-season

OC_A: CON calibration file Generally available as previous year’s post-season

IN-SEASON

Cruise 1...n

Post cruise

Copy laptop files to network storage

QA raw data by plotting

File field log sheets for post-season use

Day 1...n

Cast 1...n

Fill in sample log sheet

Have CTD collect readings

Dump CTD to laptop files and backup hard drive

QA files visually

Clear data from CTD

POST-SEASON

Deliverable Comment

OC_H: log sheet images One PDF for whole season

OC_B: raw HEX files One ZIP for whole season

OC_C: processed CNV files One ZIP for whole season

OC_D: database rows Generated from OC_C by Data Manager

OC_G’: calibration certificate images Available after CTD returns from annual calibration

OC_A’: CON calibration file Available after CTD returns from annual calibration

OC_M: data quality report Applied to OC_D by Data Manager

OC_J: data availability matrix OC_C must be certified before updating OC_J

OC_E: AOOS submission Generated from OC_D by Data Manager

OC_F: NODC submission Generated from OC_D by Data Manager

OC_K: annual report Generated from OC_D by Project Leader

OC_L: 5-year report Generated every fifth year from OC_D and outside sources

OC_I: revised protocol No fixed schedule; implement at start of a season.

Send CTD out for annual recalibration

Figure 4.5. Calibration files and documents (OG_A and OC_G) created at the end of the prior cycle must 

be available for the current season. During field work a number of tasks must be performed in the 

depicted sequences. At the end of the season new calibration products must be obtained (OC_A’ and 

OC_G’) in order help flag data exceptions. Following the order depicted for post-season deliverable 

creation will assure prerequisites are met in generating the cycle’s full set of products.
27

5.0 Personnel Requirements and Training

5.1 Roles and Responsibilities

Field efforts, comprising the hydrographic survey and undertaken by the Project Leader and 

Vessel Operator, are detailed in SOP 4. CTD care and maintenance, data download, data 

processing and plot generation are done by the Project Leader, following details given in SOPs 1 

– 3 and 5 – 7. The validation process is the joint responsibility of the Project Leader and the Data 

Manager (SOPs 2 – 3, 6, 8, 10–18). The resulting certified deliverables are installed in the NPS 

repository archive, hooked into web dissemination links, and transmitted to external facilities

(SOPs 16 – 17) by the Data Manager.

5.1.1 Project Leader (presently Lewis Sharman, Ecologist, GLBA): 

 Work with the Vessel Operator to schedule and execute a safe cruise that accomplishes all 

sampling requirements

 Initiate or discontinue sampling as dictated by weather conditions or the general safety of 

personnel and equipment

 Complete pre-cruise confirmation of the CTD instrumentation, power, memory, and 

configuration for proper operation

 Complete CTD Field Log at each station

 Deploy CTD at each station

 Ensure proper storage and maintenance of the CTD instrumentation and hardware

 Ensure CTD is sent to manufacturer for annual calibrations

 Verify proper data collection and overall quality at the end of each day’s sampling, 

including entering CTD Field Log information into a station summary spreadsheet

 Plot vertical profiles at the end of each cruise to demonstrate data quality

 Process collected data files to 1-m averaged values 

 Ensure post-season calibrations have been checked and applied if needed

 Complete and submit the data deliverables defined in Appendix J to the Data Manager

 Correct deliverables as needed to meet mandatory validation criteria

 Assemble metadata entries that document exceptions and notable observations recorded in 

field notes

5.1.2 Vessel Operator (varies; presently GLBA operators of the Capelin, Arete, Talus, and 

on occasion, Sharman and Moynahan on the Sigma-t or Boomer): 

 Vessel operations, fueling, and maintenance

 Work with the Project Leader to schedule and execute a safe cruise that accomplishes all 

sampling requirements

 Initiate or discontinue sampling as dictated by weather conditions or the general safety of 

personnel and equipment

 Assist the Project Leader as needed to execute the CTD cast

5.1.3 Data Manager (presently Bill Johnson, SEAN): 

 Validate quality of deliverables against formal criteria

 Build facilities to disseminate products over the web

 Maintain and disseminate metadata, create metadata files

 Track project progress and adherence to schedules

 Archive data at: 
28

• The NPS internal database

• The regional AOOS database

• The national NODC database

 Coordinate corrections so that AOOS and NODC continue to represent the best consistent 

project data

5.2 Qualifications

5.2.1 Project Leader:

 Knowledge of at-sea field sampling operations, protocol, and safety

 Familiarity with CTD instrumentation, data collection, and deployments

 Ability to download data file to a computer, process, plot, and evaluate profile quality

 Expertise in correcting errors detected in data deliverables

 Project management skills

5.2.2 Vessel Operator:

 Basic seamanship skills

 Small boat operations 

 Small engine operation and maintenance 

 Operation of marine communication and navigation electronics

 Use of marine hydraulics

 Local area knowledge

5.2.3 Data Manager: 

 Expertise in database management

 Expertise in web programming

 Data processing, validation, reporting and archiving skills

 Project management skills

5.3 Training Procedures

5.3.1 Project Leader:

 CTD operations and maintenance

 Field Log recordkeeping procedures

 Post-cruise data quality check and visualization techniques

 Sea-Bird CTD data processing techniques

5.3.2 Vessel Operator:

 DOI Motorboat Operator Certification Course or appropriate USCG license

 Marine navigation 

 Marine weather forecasting

5.3.3 Data Manager: 

 Technical database management

 Technical web development

 CTD operations

 CTD data processing
29

6.0 Operational Requirements

6.1 Annual Workload and Field Schedule

The field season begins with the mid-winter cruise of December/January, having received a 

freshly calibrated instrument back from the manufacturer following the October cruise. Each 

field year thus may span two calendar years, beginning with a December or January cruise and 

ending with the October cruise. Approximately 19 field days each per year are required for a 

Vessel Operator and CTD Operator to complete this sampling, distributed over the following 

schedule:

December/January: 3 days to sample stations 00-14, 16-21 and 24

March: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

April: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

May: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

June: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

July: 2 days to sample stations 00-14, 16-21 and 24 (feasible in good weather & extended 

daylight)

August: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

September: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

October: 2 days to sample stations 01, 04, 07, 12, 13, 16, and 20

The target date range of sampling for each “core station” cruise (March – June and August –

October) is the first full week of the sample month. This ensures buffer time when weather 

constraints prohibit sampling during the target week. One exception is the June sampling cruise, 

for which the target date range centers as closely as possible around May 31 (the area containing 

Station 20 is inaccessible during the June 1 – July 15 closure to motorized vessels). Similarly, the 

target date range of the July “all-stations” cruise centers as closely as possible around July 16 

when stations 19 and 20 in upper Muir Inlet become accessible following the same closure. The 

60-day (December – January) target date range of the winter “all-stations” cruise is intentionally 

broad in order to provide for shorter days and challenging winter weather. Sampling all stations 

with less ship time could be accomplished by first examining ways to run a vessel with extra 

range or fuel storage on-board so that in months of long daylight and reduced station coverage, it 

might be possible to occupy all stations in one extended day for a savings of three ship days per 

year. Use of a vessel that can operate well in darkness or low light conditions could result in a 

savings of up to seven ship days per year. 

In addition to the field efforts described above, approximately four hours will be required to set 

up/stow sampling equipment before and after each cruise for a total of nine days per year. 

Approximately one-half person-day per cruise is required for the CTD operator to download 

data, transfer data to the archive and make initial QC plots so that if instrumental problems are 

detected in the data, they can be corrected before the next field effort (4.5 days per year). 

Processing data to the final OC_D level takes place annually after manufacturer calibration 

results are received; this will require five days in December or January. Approximately two 

weeks time (ten days) are required to assemble the annual final report in January or February. 
30

We strongly recommend development of full redundancy in capabilities for field sampling (CTD 

operation). Doing so would reduce the burden on any one individual and ensure operational 

continuity in the inevitable instance of Project Leader schedule conflict, absence, or turnover. 

Data manager duties will require approximately 15 days per year.

In aggregate, personnel resources dedicated to this program include the following tasks and 

estimated time requirements:

Vessel operator 19 days per year

CTD operator 27 days per year

Data verification & processing 5–10 days per year

Annual report generation 10 days per year

Five-year report generation 20 days every 5 years

Data management 15 days per year

6.2 Facility and Equipment Needs

 Vessel for conducting research equipped with

o Fuel

o GPS system

o Depth sounder 

o Davit/boom and hydraulics for hauling line or equivalent

o Survival suits

o Float coats

o Communications (satellite phone and marine radio)

o Emergency beacon (EPIRB - Emergency Position Indicating Radio Beacons)

o General emergency supplies on board the vessel

 Redundant CTD system with ancillary sensors and associated hardware and spares as 

described in section 6.3 below.

 Heated storage facility and shop area for CTD instrumentation, line, miscellaneous 

hardware and spares.

 Data processing and archive facilities

 Laptop computer

 Backup hard drive

6.3 Startup Costs and Budget Considerations

The continued success of the program depends to a considerable extent upon certain direct 

support from GLBA. This support is principally in-kind (rather than outright funding) and takes 

the form of the following: 

 Provision of a park vessel as oceanographic sampling platform, with operator (see section 

5.1.2) and associated maintenance, fuel, etc. (approximately 19 days per year, see sections 

6.1-2);

 Provision of a park employee (Project Leader, see section 5.1.1 and section 6.1) capable of 

conducting field surveys, maintaining the instruments/equipment, and downloading, 

processing, and periodically reporting out the data (approximately 50 days per year). 
31

 Occasionally the Project Leader will require an assistant (in addition to the Vessel 

Operator) capable of assisting with the field surveys (estimated requirement 10 days per 

year). This assistant may be park or SEAN staff. 

To ensure uninterrupted sampling, SEAN will need to procure a new set of instrumentation 

approximately every 10 years, with the first set to be purchased as soon as possible after 

implementation of this protocol (Spring 2009). In 2009, the cost of a complete CTD system with 

all ancillary sensors is approximately $25,000. A backup system will achieve multiple benefits: 

1) allow annual recalibrations to take place without impeding field efforts if the calibration 

facility is not able to effect a rapid turnaround for any reason; 2) allow the sampling program to 

keep pace with state of the art instrumentation advances on an appropriate time scale; 3) allow 

SEAN to plan and budget for gradual instrumentation replacement over time and 4) provide 

instrumental redundancy in case of failure. Examples of failure include moderately common 

field problems (corroded connector pins, cracked conductivity cell or damaged interface cabling 

ancillary sensors) as well as uncommon problems (flooded pressure housing, battery leakage, or 

total instrumental loss due to lowering line failure).

Calibration costs of $2500/year are required to ensure overall reliability of the collected data. 

Funds (< $500/year) for miscellaneous operations and field supplies (see Appendix C) are also 

needed on an ongoing basis. `

Access to a dedicated vessel that is not dependent upon scheduling constraints of an operator 

from GLBA could allow the SEAN personnel to more efficiently plan and execute field work. 

Key considerations in deciding whether to acquire a dedicated vessel include: predictability of 

support from existing GLBA divisions and vessels (i.e., Resource Management and Law 

Enforcement Rangers), cost of acquisition, operation, and maintenance, and extent to which the 

vessel would be utilized by other Vital Signs that call for boat-based monitoring (e.g., Marine 

Predators, Kittlitz’s Murrelets, Marine Contaminants, Weather and Climate, Airborne 

Contaminants). Partnering with other sampling efforts could possibly improve efficiency and 

reduce overall vessel time.

Depending on the expertise in-house at SEAN, both annual data reporting and the five-year

summaries may benefit from contracting an external oceanographer to help in the analysis, 

presentation and interpretation of the collected dataset. 

6.4 Protocol Revision Process

This protocol may be updated or revised as new knowledge, technologies, equipment, and 

methods become available. Revisions will balance the advantages of new techniques with 

possible disadvantages associated with disrupting data continuity. 

All revisions require review for clarity and technical soundness. Small changes to the existing 

protocol documents — for example formatting, simple clarification of existing content, small 

changes in the task schedule or project budget, or general updates to information management 

handling SOPs—may be reviewed in-house by project cooperators and SEAN staff. Changes to 

data collection, analysis techniques, or sampling design will trigger an external peer review to be 

coordinated by the Alaska Region Inventory and Monitoring Coordinator. 
32

The SEAN Program Manager will periodically poll the Project Leader and Data Manager on the 

need to initiate a protocol revision cycle. Every effort will be made to ensure that complete, 

certified protocol revisions are applied at the start of a new sampling year (i.e., after the October 

cruise and before the winter cruise). Exceptions include revisions that would remedy an 

identified safety deficiency or a significant issue of data quality or continuity of operations.

The protocol document is defined as data deliverable OC_I. Technical details of its construction 

are specified in SOP 18.

The protocol revision process will be cooperatively managed by the Project Leader, SEAN

Program Manager, and SEAN Data Manager. In the course of a revision cycle, proposed 

revisions may originate from any of those three individuals. One of these three people shall agree 

to be “revision coordinator” and be responsible for the actual drafting of the document. Proposed 

contributions and internal tracked-change reviews will be resolved by the revision coordinator 

until consensus is reached on a final draft document. If an external peer review is required, the 

coordinator will resolve review comments in consultation with the other two participants.

A revised protocol must be given a new protocol identifier, using the form detailed in the SEAN 

Data Management Plan (Johnson and Moynahan 2008: SOP 602: Version Control). The Project 

Leader will include a summary and justification of the revision in the first post-revision Annual 

Report, under an appropriately titled section. The new protocol will be disseminated and 

archived through standard SEAN practices and will be submitted to appropriate NPS repositories 

outside SEAN.
33

7.0 Oceanography of Glacier Bay: Other Considerations

The basic set of deliverable plots and data summaries outlined within the protocol for reporting 

and archive purposes will ensure attainment of the monitoring objectives, but as the Glacier Bay 

and the greater northeast Pacific ecosystems both change over time, new or different methods of 

analyzing and reporting the data will be developed. Technological advances will allow for more 

detailed measurements of more parameters. It is important that NPS maintain the observations

currently specified within this protocol, but NPS should also remain open to future generation 

technologies that may improve measurement and description of the oceanographic ecosystem.

Some improvements to the program can be realized relatively inexpensively by the addition of 

two person-days per cruise (18 days per year total) to generate intermediate (not formally 

validated with post-season calibrations) data files, plots and tables (profiles, anomaly plots, 

cross-sections, statistical analyses) that can be distributed via the web page immediately after the 

cruise. Of these two person-days, one day would be allocated for compiling the data and 

generating the plots and tables; the second day would be designated for uploading the data files 

and plots into the I & M web page. Some time to spin up this effort so that it could be done 

efficiently and repeatedly would be required. Implementing this service would increase the 

overall value of the collected data because it would enhance the ability for users to reliably 

incorporate the data into time-sensitive applications. Such applications include support of inseason field research, support of real-time nowcast/forecast models, support of near real-time 

oceanographic reanalysis programs and possible support of in-season resource management 

issues that impact the greater Gulf of Alaska marine system.

Another item to consider in the future is what response the I&M program should undertake if a 

set of highly unusual events were to be observed. Presently, the program does not have a 

procedure in place identify (in a timely fashion) or meaningfully follow up on such occurrences. 

Having the ability to more closely investigate anomalous observations would 1) provide a reverification of the initial observation and 2) provide the ability to opportunistically sample and 

better understand such events and their greater implications.

The monitoring program outlined herein has been designed to document oceanographic 

conditions from representative domains within Glacier Bay. This program provides a solid 

foundation for understanding the oceanographic environment, but there remain many gaps that 

need to be acknowledged and addressed if opportunities present themselves. For the physical 

fields, limited spatial and temporal coverage of selected parameters lead to incomplete snapshots 

of the physical system. While the ancillary sensors on the CTD make a cost-effective attempt to 

go beyond the basic physics, this oceanographic program is incomplete with respect to the lack 

of monitoring of chemical properties and the bacterial, phytoplankton, microzooplankton, and 

zooplankton communities. 

GLBA and, more broadly, the NPS can help ameliorate the data gaps by supporting processoriented studies that focus on better describing the dynamics and community makeup of the 

portions of the ecosystem currently not sampled. Such studies would make the monitoring 

dataset collected under this protocol more valuable because these investigations would place the 
34

monitoring results within a more complete ecological context. Examples of such process studies 

include those outlined below.

Physics:

 Tides:

o Twenty-four hour to one month tidal cycle hydrography and current studies at various 

locations along and across the bay will put individual stations into a high-resolution 

temporal frame of reference

 The nearshore environment:

o Describe physical conditions and transport processes in biological “hot-spots” to 

better predict and understand regions of high biological densities and productivity

o Freshwater dynamics studies, from coastal discharge to mixing processes, to help link 

terrestrial, glacial and marine processes

 Mooring, Autonomous Underwater Vehicle (AUV) and surface radar deployments:

o Provide descriptions of both low-frequency and high-frequency modes of system 

change, including tidal processes, deep water renewal and the phasing of system 

changes throughout the water column

 Oceanographic linkages:

o Determine the level of connectivity and influence of waters outside Glacier Bay upon 

those inside the Bay and vice-versa

o Determine relationships with oceanographic and meteorological patterns on larger 

scales

Chemistry:

 Nutrient budgets:

o Document the nutrient dynamics and nutrient transfer pathways within Glacier Bay in 

order to better understand this productive ecosystem

 Ocean acidification:

o Glacier Bay as a high-latitude early-warning system for ocean acidification

Primary Production:

 Phytoplankton bloom dynamics:

o Document the in situ phytoplankton species composition

o Investigate spring bloom and episodic production events through the summer: to 

determine relative importance to overall productivity

o Determine the role of tidal mixing in maintaining primary production.

o Explore limitations to production through the summer and how they affect the 

phytoplankton community structure

o Investigate the role of tidewater glaciers in patterns of primary productivity and 

document changes as glaciers recede/advance

Secondary Production:

 Zooplankton communities: 

o Document the structure and dynamics of the dominant zooplankton communities that 

feed the fish and marine mammal populations

o Investigate spatial and temporal abundance of meroplankton (larvae) of commercially 

and ecologically important species (e.g., crabs, clams, mussels)
35

8.0 References

8.1 References Cited and Publications Utilizing GLBA Oceanography Data

Brower, W. A., Jr., R. G. Baldwin, C. N. Williams, Jr., J. L. Wise, and L. D. Leslie. 1988. 

Climate atlas of the outer continental shelf waters and coastal regions of Alaska, vol. I. Gulf 

of Alaska, National Climate Data Center, Asheville, NC. 519 pp.

Burke, P. 2008. Southeast Alaska current survey in Glacier Bay National Park, project report. 

NOAA/NOS/COOPS, Silver Spring, MD. 6 pp.

Cokelet, E., A. Jenkins, and L. Etherington. 2007. A transect of Glacier Bay ocean currents

measured by acoustic doppler current profiler (ADCP). Pages 80–83 in J. Piatt and S. Gende, 

editors. Proceedings of the 4th Glacier Bay Science Symposium, October 26–28, 2004. USGS 

Scientific Investigations Report 2007-5047.

Cooper, W. S. 1923. The recent ecological history of Glacier Bay, Alaska: II. The present 

vegetation cycle. Ecology 4:223–246.

Eckert, G., E. Hood, S. Nagorski, and C. Talus. 2006. Assessment of coastal water resources and 

watershed conditions at Glacier Bay National Park and Preserve, Alaska. Natural Resource 

Technical Report NPS/NRWRD/NRTR—2006/353, Juneau, AK. 129 pp.

Etherington, L. L. 2004. Monitoring of oceanographic properties of Glacier Bay, Alaska. 2003 

Annual Report. U.S. Geological Survey, Alaska Science Center, Anchorage, AK. 37 pp.

Etherington, L. L., P. N. Hooge, and E. R. Hooge. 2004. Factors affecting seasonal and regional 

patterns of surface water oceanographic properties within a fjord estuarine system: Glacier 

Bay, AK. U.S. Geological Survey, Alaska Science Center, Anchorage, AK. 79 pp.

Etherington, L., P. N. Hooge, E. Hooge, and D. Hill. 2007. Oceanography of Glacier Bay,

Alaska: implications for biological patterns in a glacial fjord estuary. Estuaries and Coasts 

30(6):927–944.

Fisher, J. 2006. Seasonal timing and duration of brachyuran larvae in a high-latitude fjord. 

Marine Ecological Progress Series 323:213–222.

Goetzmann, W. H., and K. Sloan. 1982. Looking far north: The Harriman expedition to Alaska, 

1899. Viking Press, NY.

Hill, D. F., S. J. Ciavola, L. Etherington, and M. J. Klaar. 2009. Estimation of freshwater runoff 

into Glacier Bay, Alaska and incorporation into a tidal circulation model. Estuarine, Coastal 

and Shelf Science 82(1):95–107.

Hooge, P. N., E. R. Hooge, E. K. Solomon, C. L. Dezan, C. A. Dick, J. Mondragon, H. Rieden,

and L. Etherington. 2003. Fjord oceanography monitoring handbook: Glacier Bay, AK. U.S. 

Geological Survey, Alaska Science Center, Anchorage, AK. 21 pp.
36

Hooge, P. N. and E. R. Hooge. 2002. Fjord oceanographic processes in Glacier Bay, Alaska. 

U.S. Geological Survey, Alaska Science Center, Anchorage, AK. 142 pp.

IPCC. 2007. Climate Change 2007: Synthesis report. Contribution of working groups I, II and III 

to the fourth assessment report of the Intergovernmental Panel on Climate Change (core 

writing team, Pachauri, R. K, and A. Reisinger, editors). IPCC, Geneva, Switzerland. 104 pp.

Johnson, W. F., and B. J. Moynahan. 2008. Data management plan: Southeast Alaska network. 

Natural Resource Report NPS/SEAN/NRR—2008/058. National Park Service, Fort Collins, 

CO.

Lawrence, D. B. 1958. Glaciers and vegetation in southeast Alaska. American Scientist 46:89–

122.

Madison, E., and L. L. Etherington. 2005. Monitoring of oceanographic properties of Glacier 

Bay, Alaska. 2004 annual report. U.S. Geological Survey, Alaska Science Center, Anchorage, 

AK. 21 pp.

Mann, K. H., and J. R. N. Lazier. 1996. Dynamics of marine ecosystems: biological–physical 

interactions in the oceans. Blackwell Science, Cambridge, MA.

Matthews, J. B., and A. V. Quinlan. 1975. Seasonal characteristics of water masses in Muir Inlet, 

a fjord with tidewater glaciers. Journal of the Fisheries Research Board of Canada 32:1693–

1703.

Matthews, J. B. 1981. The seasonal circulation of the Glacier Bay, Alaska fjord system.

Estuarine, Coastal and Shelf Science 12(6):679–700.

McLeod, K. L., and H. M. Leslie (editors). 2009. Ecosystem-based management for the oceans. 

Island Press, Washington, DC.

Milner, A. M. 1987. Colonization and ecological development of new streams in Glacier Bay 

National Park, Alaska. Freshwater Biology 18:53–70.

Oakley, K. L., L. P. Thomas, and S. G. Fancy. 2003. Guidelines for long-term monitoring 

protocols. Wildlife Society Bulletin 31(4):1000–1003.

Schroeder, R. F. 1995. Historic and contemporary Tlingit use of Glacier Bay. Pages 278–293 in 

D. Engstrom, editor. Proceedings of the Third Glacier Bay Science Symposium, 1993. 

National Park Service, Gustavus, AK.

Taggart, S. J., P. N. Hooge, J. Mondragon, E. R. Hooge, and A. G. Andrews. 2003. Living on the

edge: distribution of Dungeness crab Cancer magister in a recently deglaciated fjord. Marine 

Ecology Progress Series 246:241–252. 
37

8.2 GLBA Oceanography Program Reviews and Reports

Drew, G. 2002. Review of Hooge and Hooge report (2002). U.S. Geological Survey, Alaska 

Science Center, Anchorage, AK.

Etherington, L. 2006. Program Evaluation Report. U.S. Geological Survey, Alaska Science 

Center, Anchorage, AK.

Knudsen, E. 2001. Review of oceanographic monitoring study plan. U.S. Geological Survey,

Alaska Science Center, Anchorage, AK.

Knudsen, E. 2001. Review of Hooge and Hooge report (2002). U.S. Geological Survey, Alaska 

Science Center, Anchorage, AK.

Mondragon, J. 2003. Review of Etherington et al. report (2003). U.S. Geological Survey, Alaska 

Science Center, Anchorage, AK.

Sharman, L. 2003. Review of Etherington et al. report (2004). National Park Service, Glacier 

Bay National Park, Bartlett Cove, AK.

Weingartner, T. 2002. Review of Hooge and Hooge report (2002). University of Alaska, 

Fairbanks, Fairbanks, AK.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

39

SOP 1: CTD Maintenance, Storage and Calibration

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

1.0 CTD Maintenance, Supplies and General Handling Procedures 

1.1 General CTD Handling, Care, and Use Instructions

The Sea-Bird SBE-19 and SBE-19plus operators’ manuals (available on the SEAN and Sea-Bird 

websites) document all recommended practices for cleaning the CTD, accessing the battery 

compartment, care and installation of o-rings, instrument operation, instrument setup and CTDcomputer communications. The Project Leader will read and become comfortable with all 

aspects of the manual.

Within a cruise and between casts (assuming no more than a day between casts), the plumbed 

line connecting the pump and sensors should be flushed with 0.1% Triton X-100 solution, 

followed by distilled water, as described in SBE Application Notes 34, 2D, and 64 

(http://www.seabird.com/application_notes). (Note: Triton X-100 is a non-ionic biogenic 

detergent; be careful not to get the solution in your eyes or on your skin.) Normally the 

conductivity cell is kept wetted by keeping the syringe/Tygon tubing assembly attached to the 

temperature/conductivity intake duct fitting between casts. In very cold conditions, however, 

special care must be taken to protect the instrument from freezing, and one precaution is to 

disconnect the tubing assembly after flushing to allow drainage (then reconnect “dry”). This is 

particularly important during the winter (December–January) cruise when one or more nights 

may be spent in the field. The instrument should be stored in a heated space aboard the survey 

vessel overnight (in which case the tubing assembly can remain connected). For longer-term 

storage between cruises, see section 2 below.

1.2 Supplies

On an ongoing basis, all field gear should be assessed and repaired or replaced as needed. 

Necessary equipment and supplies include but are not limited to the CTD lowering line, spare 

CTD and GPS batteries, the computer-to-CTD interface cable, spare o-rings, electrical silicone 

grease, distilled water, Triton X-100 solution, and bleach solution. A supply of KimWipes or 

other similar non abrasive lint-free wiping towel is necessary for proper o-ring handling.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

40

2.0 Long-term Storage

2.1 Instrument Cleaning

Cleaning the CTD after each cruise is important to maintain sensor viability and reduce the 

potential for the negative effects of biofouling, contamination by oil, and buildup of salt crystals 

on the sensors, especially the relatively sensitive and delicate conductivity cell and oxygen 

sensor. Again, refer to SBE Application Notes 34, 2D, and 64 

(http://www.seabird.com/application_notes) for detailed long-term cleaning/storage instructions. 

Rinse the entire instrument thoroughly with fresh water. 

Disconnect the tubing connecting the DO sensor so that it is not exposed to the conductivity cell 

cleaning procedure. Flush the conductivity cell with a 0.1% solution of Triton X-100. Wash the 

solution back and forth with the syringe. Allow the cell to soak in the solution for 60 minutes. 

Drain the cell and tubing. Thoroughly rinse the unit with clean water for 5 minutes; any residual 

salt crystals can damage the cell. Sea-Bird cautions not to use a brush or Q-tip to clean the flow 

tube on the conductivity cell, as this can alter the calibration or damage the sensor.

After treating the conductivity cell as above, implement the following procedure to prepare the 

(now disconnected) DO sensor for long-term storage between cruises. Using the syringe, flush 

the sensor for 1 minute with a 1% (vs. 0.1%) Triton X-100 solution preferably warmed to 30°C 

(86°F). Drain and flush with warm (not hot) fresh water for 5 minutes. Soak the sensor for 1 

minute in a 500–1000 ppm solution of bleach; after the soak drain and flush with warm (not hot) 

fresh water for 5 minutes. Assuming there is no danger of freezing, connect the sensor inlet and 

outlet with a short loop of Tygon tubing. Place a small piece of clean sponge — slightly 

dampened with fresh, clean water — in the center of the tubing (not near the sensor membrane).

2.2 Storage

After the conductivity cell is thoroughly dry from its last cleaning, store by re-attaching the 

syringe assembly to seal the dry cell. For long-term storage, keep the DO sensor isolated with its 

closed tubing loop. Remember, however, to remove the loop and reconnect the DO sensor to the 

in-line tubing train on the CTD just before redeploying the instrument on the first cast of the next 

cruise!

3.0 Factory Calibrations

Immediately after each October cruise, send the entire CTD instrument to Sea-Bird Electronics 

for calibration of all sensors. Sea-Bird will ensure the third-party ancillary sensors are also 

calibrated at the originator’s factory and returned in a timely fashion. Be sure to get an RMA

number from Sea-Bird before shipping the CTD to them. Include a completed Sea-Bird Service 

Request Form in the shipping crate. Ship the CTD via FedEx, and make sure the RMA number is 

written on the address label somewhere. Email the serial number of the instrument to Sea-Bird in 

advance. Sea-Bird shipping information is as follows.

SEA-BIRD ELECTRONICS, INC.

1808 136th Place NE

Bellevue, WA 98005, USA

Phone: (425) 643-9866

Fax: (425) 643-9554

E-mail: Seabird@seabird.com

Contacts: Mike Handewith, 

Dave Armstrong, Andy Heard

Sea-Bird's website also has return information at: www.seabird.com
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

41

SOP 2: Calibration Certificates (OC_G Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

Two cases are possible. First, the sensor servicing company may have provided one or more 

paper certificates attesting to the calibration parameters determined on a particular date. In this

case, the Project Leader must generate one PDF file for each document using a document 

scanner and appropriate software. Second, the sensor servicing company may have provided a 

CD or DVD already containing PDF files of the certificates. 

Once the PDFs are available, they are copied to a park network drive, renamed following a 

consistent convention, and run through the validation/quality assurance iterations until certified

and disseminated.

SOP 2 requires users to work in the internal NPS network under valid Active Directory accounts. 

Access questions should be directed to the Data Manager.

Detailed Steps

1. Certificates on paper received

1. Project Leader tasks

1. Extract from packet only those forms that list sensor parameters and attest to their 

accuracy.

2. Scan each one into a separate PDF file using park scanner and associated software. 

Save on park network at 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\Certificate\ where yyyy is 

the year on the certificate, e.g., 2010.

3. Name each file with a reference to its local CTD number, followed by an underscore, 

followed by sensor type, followed by underscore, followed by the sensor serial 

number, followed by underscore, followed by calibration date as YYMM.

1. Local CTD number is 1, 2, etc. It is not the Sea-Bird serial number.

2. Sensor types: TEM, CON, PAR, OBS, FLU, DOX, PRE.

3. Sensor serial number may always be found inside the PDF.

4. Example CTD#1 Fluorometer calibration certificate of March 2009 would be 

named 1_FLU_ WS3S-652P_0903.PDF.

4. Submit these files via email attachment to the Data Manager for validation, 

specifying in the message body it is deliverable OC_G, as defined in protocol OC2010.1. Multiple files are permitted in one submission email.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

42

2. PDFs on CD received

1. Project Leader tasks

1. Copy each PDF that contains a certificate from the CD into 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\Certificate\ where yyyy is 

the year on the certificate, e.g., 2010.

2. Rename each file with a reference to its local CTD number, followed by an 

underscore, followed by sensor type, followed by underscore, followed by the sensor 

serial number, followed by underscore, followed by calibration date as YYMM.

1. Local CTD number is 1, 2, etc. It is not the Sea-Bird serial number.

2. Sensor types: TEM, CON, PAR, OBS, FLU, DOX, PRE.

3. Sensor serial number may always be found inside the PDF.

4. Example CTD#2 Pressure strain gauge calibration certificate of February 2009 

would be named 2_PRE_ 0436_0902.PDF.

3. Submit these files via email attachment to the Data Manager for validation, 

specifying in the message body it is deliverable OC_G, as defined in protocol OC2010.1. Multiple files are permitted in one submission email.

3. Regardless of whether paper or CD files

1. Data Manager tasks

1. On receipt of the submission, assign the next formal Submission Number to this file, 

as found in the master Submission_Log table.

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

1. Due to the nature of this deliverable, there is no submission unit scope. The filename 

is sufficient to distinguish it.

2. Save the file in the staging area for validation

1. Be sure the filename matches the required form listed above.

2. The staging location is INPGLBAFS03\DATA:\SEAN_Data\Staging\OC\OC_G .

3. Validate the submission according to current criteria.

4. Record validation summary data in the Submission_Log.

1. Set status code to V if mandatory validation passed.

2. Set status code to F if mandatory validation failed

5. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed

6. If submission passes mandatory criteria, reply with a “success email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

2. Project Leader tasks

1. On receipt of a failure email:

1. Rescan the PDF to ensure it is in the proper format OR contact the vendor to 

obtain a valid PDF with proper parameters.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

43

2. Restart the process from the beginning.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. Store log sheets in an annual paper file kept by the Project Leader.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

3. Data Manager tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool. 

2. Clean submission files out of staging area.

3. Terminate the process.

2. On receipt of a certification email:

1. Verify no sensitive information is in the deliverable. Products containing sensitive 

information cannot be disseminated. (Sensitivity is highly unlikely for this 

deliverable.)

2. Copy the submitted file to test environment at AUXREP\OC\OC_G\ .

3. Propagate from test to production environment.

4. Verify deliverable is accessible from production web site.

5. Mark the certification in the Status column in Submission_Log using the web tool.

6. Clean submission files out of staging area.

7. Update the deliverable tracking spreadsheet with the date of completion for 

OC_G.

8. Terminate the process.

3. Update the scope of the formal metadata so it includes this new date range.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

45

SOP 3: CON Calibration Files (OC_A Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

OC_A is built in one of two ways, depending on circumstances. Case 1 occurs when the Project 

Leader receives a vendor-supplied CD containing a CON file, typically after the annual 

recalibration. In this case, the CON file is submitted to the Data Manager for the validation / 

quality assurance process and is eventually certified.

Case 2 occurs when a single sensor undergoes calibration (or initial installation). The sensor is 

shipped with paper documentation that must be used along with vendor software to create a new 

CON file. The new file undergoes standard validation and certification.

SOP 3 requires users to work in the internal NPS network under valid Active Directory accounts. 

Access questions should be directed to the Data Manager.

Detailed steps

1. Case 1: Full calibration file set is received

1. Project Leader tasks

1. Receive CD supplied by vendor with recalibrated CTD.

2. Verify that the CON file calibration coefficients exactly match those given on the 

paper or .pdf file versions. If discrepancies are found, follow the instructions to use 

the SBEDataProcessing.exe file under “Case 2” below to correct the CON file.

3. Copy the CON file from CD to 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CON_calibration, where 

yyyy is the year of calibration, e.g., 2009. The file will be named on the CD using the 

format YYMM.CON, where Y stands for year and M is month. In order to distinguish 

this calibration from those of any other CTDs employed, the filename must be 

changed. Rename the local copy to the form C_YYMM.CON, where C stands for 

CTD number. For example, a calibration file from March 2005 for CTD #1 would be 

called 1_0503.CON.

4. Submit the file via email attachment to the Data Manager for validation, specifying in 

the message body it is deliverable OC_A, as defined in protocol OC-2010.1.

2. Data Manager tasks

1. On receipt of the submission, assign the next formal Submission Number to this file, 

as found in the master Submission_Log table.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

46

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

1. Due to the nature of this deliverable, there is no submission unit scope. The filename 

is sufficient to distinguish it.

2. Save the file in the staging area for validation, ensuring its name meets the standards 

defined in Appendix J.

3. Validate the submission according to current criteria.

1. Criteria are minimal because this deliverable’s form is proprietary to the CTD 

vendor.

2. Record validation summary data in the Submission_Log using the web tool.

4. If submission fails mandatory criteria, reply to the original submission with a “failure 

email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed

5. If submission passes mandatory criteria, reply to the original submission with a 

“success email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader tasks

1. On receipt of failure email:

1. Contact the vendor to obtain a valid con file.

2. Restart the process from the beginning.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable, reply with a “certification email” stating the deliverable 

is certified and may be disseminated.

2. If these are unacceptable:

1. Reply with a “withdrawal email” stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool. 

2. Terminate the process.

2. On receipt of a certification email:

1. Verify no sensitive information is in the deliverable. Products containing sensitive 

information cannot be disseminated.

2. Copy the submitted file to test environment as AUXREP\OC\OC_A\yyyy\ where 

yyyy is the numeric year the vendor created the file.

3. Propagate from test to production environment

4. Verify deliverable is accessible from production web site.

5. Mark the certification in the Status column in Submission_Log using the web tool.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

47

6. Update the deliverable tracking spreadsheet with the date of completion for 

OC_A.

7. Terminate the process.

3. Update the scope of the formal metadata so it includes this addition.

2. Case 2: Paper addendum to calibration is received

1. Project Leader tasks

1. Receive revised calibration parameters on paper or email.

2. Make a new copy of the CON file that directly preceded this recalibration effort. 

Calibration files are located on 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CON_calibration\ where 

yyyy is the year of calibration, e.g., 2009. Name the file C_YYMMx.CON where ‘x’ 

is a letter used to distinguish this latest update from its predecessor. Begin the 

sequence with ‘a’ and use sequential letters for additional updates. For example, the 

first revision to calibration file 1_0903.CON would be 1_0903a.CON. The next 

revision (which must be based on 1_0903a.CON) would be 1_0903b.CON.

3. Using the Sea-Bird program SBEDataProc.exe, revise the calibration parameters in 

the new CON file. Be careful to exactly enter the new information, while not 

changing items that define other aspects of the CTD. Errors in the CON file will 

produce erroneous results in the other deliverables; and the fact that results are 

defective may not be obvious.

1. Start the SBEDataProc.exe program. It should be on the Project Leader’s 

computer under the “Start” button.

2. Select Configure from the top menu. On the dropdown menu, click on “SBE 19 

Seacat CTD.” A Windows form will appear on screen.

3. Press the OPEN button on the form. Navigate to the new copy of the CON file 

made in the preceding step. Open it. The Windows form will now list the sensors 

defined in the latest CON file. 

4. Double click the name of the first sensor to adjust. A dialog box will be displayed 

showing the latest calibration entry for that particular sensor. Each sensor takes 

different types of values. The calibration document should have values that match 

the dialog box entries for a particular sensor.

5. Revise the screen entries so they match the document.

6. Press the OK button when the sensor has been fully defined.

7. Back on the Windows form, press the SAVE button to permanently write the new 

information to the CON file.

8. If there are additional sensor calibrations to enter, go back to the section on 

double-clicking the sensor name on the form.

9. When done, press the EXIT button and then close the SBEDataproc.exe

application.

4. Submit the new file via email attachment to the Data Manager for validation, 

specifying in the message body it is deliverable OC_A, as defined in protocol OC2010.1.

2. Data Manager tasks

1. On receipt of the submission, assign the next formal Submission Number to this file, 

as found in the master Submission_Log table.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

48

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

1. Due to the nature of this deliverable, there is no submission unit scope. The filename 

is sufficient to distinguish it.

2. Save the file in the staging area for validation, ensuring its name meets the standards 

defined in Appendix J.

3. Validate the submission according to current criteria.

1. Criteria are minimal because this deliverable’s form is proprietary to the CTD 

vendor.

2. Record validation summary data in the Submission_Log using the web tool.

1. Set status code to V if mandatory validation passed.

2. Set status code to F if mandatory validation failed

4. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed

5. If submission passes mandatory criteria, reply with a “success email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader tasks

1. On receipt of a failure email:

1. Re-edit the file so it is correct OR contact the vendor to obtain proper 

parameters.

2. Restart the process from the beginning.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. Remember to generate a PDF of the CTD document and build a new deliverable 

OC_G – CTD Calibration Certificates.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using 

http://165.83.57.239/0_submission_update.aspx. 

2. Terminate the process.

2. On receipt of a certification email:

1. Verify no sensitive information is in the deliverable. Products containing sensitive 

information cannot be disseminated.

2. Copy the submitted file to test environment as AUXREP\OC\OC_A\.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

49

3. Propagate from test to production environment.

4. Verify deliverable is accessible from production web site.

5. Mark the certification in the Status column in Submission_Log using 

http://165.83.57.239/0_submission_update.aspx.

6. Update the deliverable tracking spreadsheet with the date of completion for 

OC_A.

3. Update the scope of the formal metadata so it includes this new date range.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

51

SOP 4: Hydrographic Survey

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

1.0 Field Preparations

1.1 Supplies to Have Available

Assemble CTD and general field gear (see Appendix C), lowering line and hardware, distilled

water and Triton X-100 solution containers/squirt bottles for cleaning/rinsing the CTD, field 

logs, GPS and spares kit. Appendix C also outlines equipment needed to complete oceanographic

surveys. Use the CTD’s wooden box for transportation, particularly on unpaved roads in a car. 

Vibrations due to transportation result in broken connections or sensors. Please treat the 

instrument carefully (it is very expensive!). After the instrument is loaded onto the vessel, be 

sure to secure the end of the ground line to the CTD using 2 metal carabiners and the other end to 

the vessel. The CTD communications, battery, memory and date/time checks can be done on 

board at the dock or in a lab. 

1.2 Check Computer to CTD Communications 

Before deployment of the CTD in the field, check the “status” of the instrument using the Seasoft 

software module seaterm.exe. A test CTD cast off the dock in Bartlett Cove would help to verify 

proper CTD operation. See details of communication and operation in SOP 5 and/or the SBE-19 

operator’s manual for help.

1.3 Check Battery Voltage

Check battery status within the SeaTerm program. If the Vmain is less than 10V, replace the 9 

D-cell batteries.

1.4 Memory Check and Clear

Ensure that the CTD memory is empty (info was cleared after the last cruise). In the SeaTerm 

window, press F3 or click on the Connect button. The display should read >10V Vmain for the 9 

alkaline D-Cell batteries and cleared memory (nsamples = 0, memory = 0). To clear memory, 

enter the InitLog command in SeaTerm.

1.5 Check Date and Time

Next, check to see that the time and date are current for GMT time. Note that GMT is either 8 or 

9 hours away from Alaska Local time depending on whether or not Daylight Savings is in effect

(8 hours when DST is in effect and 9 hours when it is not). If the CTD is not synchronized to 

GMT, enter the ST command in SeaTerm. The program will prompt you to type in the correct 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

52

date, then the correct time. Synchronizing your watch with CTD time can help avoid mistakes 

when entering information in the Field Log. It is important that GMT time be employed so that 

future analyses can accurately relate the timing of the tidal signal to the timing of the CTD cast. 

Tidal analyses are carried out with respect to GMT, so avoiding the use of local time will help 

avoid errors introduced by switching in and out of Daylight Savings.

1.6 Soak the Dry Conductivity Cell

When removed from dry storage, the conductivity cell needs to soak before being deployed. Fill 

the cell with a 0.1% Triton X-100 for at least one hour. When ready to use, drain the Triton X100 solution; there is no need to rinse the cell. Do not allow Triton X-100 to flow through to the

dissolved oxygen sensor, which may be adversely affected.

1.7. Test Cast, Download Test Data and Verify Proper Operation

Perform a test cast off the Bartlett Cove Dock before heading to the field to ensure proper CTD 

operation before beginning valuable ship time. Data can be downloaded and viewed as described 

below.

2.0 Field Operations

2.1 Selection of Sampling Sequence

The Vessel Operator and Project Leader will work together to determine the order with which to 

occupy stations. Consideration for personnel, vessel and equipment safety should be taken into 

account when assessing weather conditions and the short-term forecast. It is desirable to occupy 

stations south of Station 04 on the incoming tide for data collection consistency purposes, but it 

is more important that all target stations are occupied. 

2.2 Navigate to Station

The Vessel Operator will navigate to each station in turn using GPS navigation and ensure that 

the CTD cast is initiated within 200 m of the nominal station location. 

2.3 Complete CTD Station Log 

See Appendix B for a copy of the log form. See Appendix A for a listing of the nominal station 

locations and depths. At the start of a new Field Log form, fill out the top header information, 

including:

1. Vessel name

2. Cruise identifier

3. The CTD number employed (CTD number is local to the NPS SEAN system and 

defined in Appendix F).

4. The Data Dump Number (sequential number for download. Check previous data 

dump log for current number to use, see also Appendix B).

5. The names of observers responsible for conducting the CTD cast.

At the beginning of the CTD cast, record on the Field Log form: 

1. The sequential cast number (1, 2, 3, 4...)

2. The station name (01, 04, 07, ...)
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

53

3. The latitude and longitude of the cast location, using decimal degrees in WGS 84 

Alaska datum (Or mark a waypoint on the GPS and record the waypoint number in 

the logbook. See section 2.9, below.)

4. The waypoint number for future reference on the cruise.

5. The station date and time. Record time as GMT date and time; note there are different 

offsets for Alaska Standard Time (add 9 hours) and Alaska Daylight Savings Time 

(add 8 hours).

6. The bottom depth as measured by the fathometer.

7. The target depth for the CTD (i.e., the amount of line to pay out).

8. Comments documenting any item of note associated with this cast. Use extra room on 

the bottom or the back of the Field Log form if needed.

2.4 Initiate Data Logging

Slide the magnetic switch to the “ON” position. Record the time “on” in the field notebook. See 

Figure SOP 4.1 for details of the CTD sensor layout and on/off switch location. 

2.5 Equilibrate the CTD Just Below the Surface

Lower the CTD into the water, just below the surface, to equilibrate for a minimum of two 

minutes. (Have you first removed to syringe assembly from the temperature/salinity intake duct 

fitting? Have you removed the DO sensor closed tubing loop and reconnected the sensor to the 

in-line CTD tubing?) Employ a stopwatch with timer alarm to ensure a full 120-second soak 

period is observed. This equilibration time will allow 45 seconds for the pump to turn on, 

provide time for the instrument to adjust to ambient temperature, and for the conductivity cell to 

flush. Also, it allows the data processing program the ability to remove the first 90 seconds of 

data collected, resulting in improved measurements over the uppermost few meters of the water 

column. 

Figure SOP 4.1. Typical location of SBE-19 CTD sensors and on/off switch. CTD #1 is illustrated. Other 

CTDs may have somewhat different physical configurations.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

54

2.6 Lower CTD to Target Depth

Lower the CTD at using 3/8” nylon, 3-braid line marked at 10-m intervals (timed as 10 meters 

per 10 seconds). The lowering speed should be 30 meters per minute (1/2 meter per second) 

for the uppermost 50 m and can be increased to 60 meters per minute (1 meter per second) 

below 50 m depth. Blue tape markers indicate 10-m intervals, red tape indicates 50-m intervals, 

and green tape indicates 100-m intervals. The instrument should be dropped no more than 90% 

of the depth at the station and never more than the maximum depth of 600 m. The CTD is 

usually dropped to no more than 550 m as a safety precaution. 

2.7 Haul CTD Back to Surface 

Retrieve the CTD with a power block/davit or a long-line drum. Note that data are collected by 

the CTD on both the down- and up-casts; however, the up-cast data are not typically used for

analysis (down-cast data are more accurate because the sensors are receiving and measuring a 

nearly-undisturbed water column on the way down) — so there is no need to go slowly on the 

way up. Be careful, however, as the instrument nears the surface, and be sure to control the 

power block so the CTD is not jerked up out of the water and into the davit block or against the 

side of the boat. Be careful when bringing CTD back onto boat.

2.8 Terminate Data Logging

Turn the instrument off with the magnetic switch.

2.9 Complete CTD Station Log 

Record any irregularities about the cast on the data sheet. Include comments about such events 

as, e.g., the magnetic switch arriving at the surface in the “off” position, forcing a duplication of 

that station’s cast. If you marked a GPS waypoint for the cast’s location, enter the coordinates 

onto the data sheet now to prevent loss of the waypoint when others use the GPS later. 

2.10 Freshwater Rinse

Rinse entire instrument with distilled water, poured from jug or by using a squirt bottle. In 

particular, make sure to douse all of the optical sensors with the fresh water. Rinse the irradiance 

meter with distilled water and replace the cover. Flush the conductivity cell with syringe of

Triton X-100 solution (preferred) or distilled fresh water. Syringe and Tygon tubing should be 

left attached to cell to avoid drying out between usages.

2.11 Stow CTD for Transit

With air temperatures greater than 5oC above freezing, the CTD may remain on deck. In freezing 

and near-freezing conditions, bring the CTD into the cabin between stations and during transit to 

avoid freezing and breaking the conductivity cell. 

2.12 Data Download

At the end of the day, download the CTD cast data to a local computer according to SOP 5, 

which includes basic quality assurance steps.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

55

3.0 Post-cruise Operations 

3.1 Storage of the CTD and Associated Hardware and Spares

Stow CTD until next field effort. For long-term storage procedures, see SOP 1. 

For overnight short-term storage, the CTD may be left on board the survey vessel. Bring the 

CTD into the cabin to avoid freezing and breaking the conductivity cell. 

3.2 Data Transfer to Network

After each cruise, transfer data to network according to details of SOP 5.

3.3 Plot Data

Once cruise data has been transferred to the network, plot each cast for QA purposes using SOP 

7.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

57

SOP 5: CTD Data Download and Transfer to Network

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

During a cruise, typically at the end of each day, the contents of the CTD are downloaded to a 

laptop computer and given quality assurance tests. If significant problems are found during the 

quality assurance review, some stations may need to be re-occupied the following day to avoid 

loss of data. After the data is transferred to the computer and a backup hard drive, the CTD 

memory is then erased to make room for additional data.

At the end of each cruise, the laptop files are copied to the park’s network file server. These files 

are the basis for many other deliverables.

This process is the responsibility of the Project Leader.

Detailed steps

1. Before a cruise

1. Ensure the laptop has working copies of SEATERM software.

1. If not found on laptop, seek Data Manager’s assistance.

2. Ensure the serial data cable is packed for the field.

3. If this is the first cruise of the year, create a “c:\oceanography\yyyy\Downloaded 

HEX files\” folder on the laptop to hold the season’s cruise data, where yyyy is the 

4-digit year.

4. Create a subdirectory for this cruise as “c:\oceanography\yyyy\Downloaded HEX 

files\yymm\” where yy is the 2-digit year, and mm the 2-digit month.

5. Determine the starting dump number for the cruise by incrementing the last dump 

number used by the OC survey program.

1. It may be found on the most recently completed survey field log sheet.

Only one sequential dump number is maintained, regardless of how many CTDs 

are employed at various times.

2. For each cruise day

1. Capture casts using the method described in SOP 4.

2. Retrieve daily data from CTD.

1. Connect laptop serial port to CTD using special cable.

2. Invoke SEATERM software.

3. Be sure SEATERM is set to download one specified cast at a time.

4. Press “connect” software icon.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

58

1. If it doesn’t connect, take remedial action such as tightening cables and replacing 

batteries.

2. If it does connect, the number of casts and the record numbers for each cast will 

be displayed.

1. Complete a CTD Download Checklist from the displayed information; for date, use 

the local date transferred rather than the GMT collection date.

2. If no processing is done on the CTD for 90 seconds, the connection is dropped to 

conserve battery power.

5. Invoke a transfer using the “upload” button.

6. Specify the next cast to save, as tracked on the checklist.

7. You will be prompted for “header” information.

1. Enter it from the correct row of the field log sheet.

2. Be mindful of the 90-second disconnect timeout.

8. Specify the destination file on the laptop as c:\oceanography\yyyy \Downloaded HEX 

files \yymm\yymm_C_dddd_cc.hex, where yy is year of cast, mm is month of cast, C 

is local ctd number, dddd is dump number, and cc is cast number. Zero fill any name 

component to ensure the filename is exactly 18 characters.

9. Watch screen progress to be sure the correct sample numbers are reflected for that 

cast.

1. If the wrong records appear listed, delete the file using Windows explorer and 

redo the download.

10. Mark the completed download on the paper checklist.

11. Repeat for each cast until the list is completely checked off.

3. Visually check basic quality of each HEX file.

1. Locate each downloaded file with Windows explorer and open it in NOTEPAD.

2. The cast number should match the log sheet entry and the filename – this is VERY 

IMPORTANT.

3. The header text should match the corresponding log sheet values.

4. Beyond the header, every line should be exactly the same length. Scan down to the 

end of the file for short or long lines. For the CTD/sensor configuration currently 

employed in the GLBA sampling, the line length is 24 characters, but the exact 

number of characters in the data line varies by the number and type of sensors on the 

CTD at the time it is used.

4. If any file does not meet the QA requirements, then delete it with Windows 

explorer and recreate it with SEATERM.

1. A file cannot be deleted if it is still open in NOTEPAD – close the file.

2. The new file must go through this QA as well.

3. If a second attempt at downloading the cast also results in data lines that are not 

exactly 24 characters in length:

1. Use the NOTEPAD session to delete the invalid lines.

2. Save the file and close NOTEPAD.

3. Add a comment to the field log sheet specifying the number of invalid rows 

deleted due to length errors.

4. If, from a particular point in time, files begin exhibiting consistent short or long 

lines, this suggests the CTD is faulty and must be serviced immediately.

5. Back up the hex files in laptop folder “yymm” to a USB thumb drive.

1. Plug in thumb drive and wait for it to be recognized.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

59

2. Use Windows Explorer to copy files.

3. Use the “Safely remove hardware” function in the system tray to ensure the copy is 

complete.

4. Physically remove the drive

6. Clear data from CTD.

1. Verify that all casts have been downloaded to the laptop and backed up on the USB 

drive.

2. Using SEATERM, enter the command “IL” and confirm the operation by entering 

“IL” a second time when prompted.

1. This permanently erases the CTD memory.

2. Do not use the “Init Log” button on the SEATERM screen: it does not function 

properly with every CTD used by the program.

7. Disconnect.

1. Exit the SEATERM program.

2. Disconnect the cable from CTD and laptop.

3. Cap the CTD data socket.

3. At end of each cruise:

1. Copy the HEX files from laptop to network server folder at 

\\nps\akrdfs\GLBA\Science\ Data\Oceanography\Data\yyyy\HEX_raw\ where ‘yyyy’ 

is the survey year.

1. Files for a particular year are comingled and are not segregated by cruise.

2. Subsequent data processing will fail unless this specific folder holds all files for the 

season.

2. Store log sheets in an annual paper file kept by the Project Leader.

1. They will be required post-season to generate OC_H field log images.

2. They will also be required before the next cruise to determine the next starting dump 

number.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

61

SOP 6: Raw HEX Files (OC_B Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

During the survey year cruises are made. At the end of each cruise day, data from each cast 

recorded on the CTD must be moved to a laptop computer file. The files undergo basic quality 

assurance. When the laptop files are complete, the CTD memory is erased to make room for the 

next day’s collection.

At the end of each cruise, the laptop files are copied to the park’s network file server.

At the end of each season, the network file copies are zipped into one file for the year. The 

Project Leader submits the one file to the Data Manager as OC_B. Validation / quality assurance 

iterations are performed until the Project Leader is satisfied the data are as accurate and complete 

as is practical. The Project Leader certifies the deliverable and the Data Manager arranges for 

repository and dissemination.

SOP 6 requires users to work in the internal NPS network under valid Active Directory accounts.

Access questions should be directed to the Data Manager.

Detailed steps

1. In-season component

1. Project Leader tasks

1. During the field season, the oceanographic survey procedures described in SOP 4

must be successfully performed. They provide the required basis for performing this 

SOP.

2. Post-season component

1. Project Leader tasks

1. Verify all of the year’s cruises are present as hex files in 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\HEX_raw\ .

1. If any hex files are missing and cannot be located, this should be marked on the 

original field log sheet before it is scanned and preserved. The information will be 

needed when building the OC_M quality assessment and OC_K annual report at 

the end of the cruise season.

2. Zip all the hex files in into a single file stored in the same folder.

1. Bring up the HEX_raw folder in Windows explorer
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

62

1. Select all files.

1. Left click one of the HEX files to select it.

2. Press Control-A to select the remaining.

3. If any non-HEX files were in the folder, deselect them by holding down 

the control key and left clicking each one.

2. Create a single ZIP file containing all HEX files using WinZip

1. In Windows explorer, right click one of the selected files and hold right button until a 

menu appears – this may take awhile, be patient.

2. From the menu that appears, point to WinZip.

1. If WinZip is not on the menu, contact IT support for help.

3. On the sub-menu that appears, select “Add to Zip File...”

4. On the “Add” dialog box that appears, append the final product’s filename to the 

existing path.

1. The default path shown should be the folder containing the HEX files.

2. Name the archive file HEX_yyyy_a.zip .

1. ‘yyyy’ is the calendar year.

2. Sequence letter ‘a’ is A for first attempt, B for second, etc.

3. For example, the third attempt at creating a valid 2011 OC_B 

deliverable would use filename HEX_2011_C.ZIP.

5. Press the “Add” button and the new file will be created from all selected HEX files.

3. Submit the deliverable file via email notification to the Data Manager for 

validation.

1. Specify in the message body it is deliverable OC_B, as defined in protocol OC2010.1.

2. Specify the fully qualified filename that the ZIP resides in.

3. Do not attach the ZIP file to the email, as it may be too large to be delivered.

1. Do not alter the deliverable file after the submission email has been 

sent; that could break the validation process.

2. Data Manager tasks

1. On receipt of the submission, assign the next formal Submission Number to this file 

using the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx.

2. Complete Submission_Log details up through the Submission_Date column.

3. Copy the file into the staging area for validation at 

\\inpglbafs03\data\SEAN_Data\Staging\OC\OC_B. 

1. Put it in its own subdirectory whose name is the same as the submission number.

2. Ensure its name meets the standards defined in Appendix J.

4. Unzip the file into its component HEX files in the staging area.

5. Invoke validation of the HEX files according to current criteria by using the web 

program at http://165.83.57.239/OC_DM_validate_OCB.aspx (See also Appendix J).

1. Validation summary results automatically are recorded in the Submission_Log.

6. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. A specific list of all the mandatory criteria failed

1. Copy and paste the “findings” panel of OC_DM_validate_OCB.aspx into the email 

message.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

63

2. Alternatively, attach the “findings.htm” file that was automatically created in the 

staging subdirectory.

7. If submission passes mandatory criteria, reply with a “success email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader tasks

1. On receipt of a failure email:

1. Make corrections so the deliverable meets mandatory criteria.

1. Print out the findings from the email if desired for ready reference.

2. It may be convenient to have the scanned field log forms (OC_H) accessible in order 

to help resolve exceptions.

3. Edit each original file using WordPad.

1. Be aware these are the original source records and editing must be done 

with care to avoid introducing new errors.

2. When a file is corrected, save it on top of the existing file.

2. In case of accident, files may be restored to original state by obtaining copy of 

previous submission from Data Manager

3. Restart the process from the beginning of the post-season component process.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool. 

2. Terminate the process.

2. On receipt of a certification email:

1. If sensitive information is in the unzipped deliverable:

1. Products containing sensitive information cannot be disseminated.

2. Mark the Submission_Log’s Status column as Sensitive using the web tool.

3. Copy the submitted single zip file to test environment as 

AUXREP\OC\OC_B\SENSITIVE\ HEX_yyyy.zip (no version letter in name).

2. If NO sensitive information is in the unzipped deliverable:

1. Copy the submitted single zip file to test environment at AUXREP\OC\OC_B\

HEX_yyyy.zip.

2. Create web page links to the new file.

3. Mark the certification status and date in Submission_Log using the web tool.

3. Propagate from test to production environment.

4. Verify non-sensitive deliverable is accessible from production web site.

5. Update the annual deliverable tracking spreadsheet with the date of completion 

for OC_B.

6. RETAIN the individual files from the staging area.

1. This will serve as the original CTD file backup.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

64

2. The original CTD files on the park server are typically directly edited in the validation 

process, so the staging backup is necessary.

3. Using NPS Metadata Editor software, update the scope of the formal metadata so it 

includes this new date range.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

65

SOP 7: Post-cruise Quality Assurance: Raw Data Plots

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

As soon as cruise data become available on the park network after completion of SOP 5, the 

performance of the CTD is reviewed by generating a set of profile plots from all of the HEX 

files. Sea-Bird SBEDataproc.exe software is used. Due to the number of parameters recorded, 

each cast requires two JPEG file plots in order to display all values.

It is important to perform this procedure immediately after each cruise, so the leader can detect 

faulty performance of individual sensors in time to complete repairs before the next cruise. (This 

quality check does not, however, replace the visual file inspections performed in SOP 5. 

Incorrect length data lines detected in SOP 5 typically indicate defects in the CTD hardware, 

firmware, and/or configuration but not in individual sensors.)

This process is the responsibility of the Project Leader. The plots are intermediate products local 

to the park and are not a formal SEAN deliverable. They are, however, required so the Project 

Leader may create the OC_M data quality evaluation deliverable at season’s end.

Note: before executing this procedure, it may be helpful to review Appendix H regarding 

standard directory structures and Appendix I regarding Sea-Bird software layout.

SOP 7 requires users to work in the internal NPS network under valid Active Directory accounts. 

Access questions should be directed to the Data Manager.

Detailed steps

1. Be aware of limitations inherent in software.

1. This process may be performed at the park or at any location physically 

connected to the NPS network.

1. If executed outside the immediate park, it may take a great deal of time to complete.

2. Be aware execution from outside could slow Internet response to all park staff.

2. The workstation used must have special SBEDATAPROC.EXE software and 

custom scripts installed.

1. If not found on desktop, seek Data Manager’s assistance.

2. The custom scripts are required to automate a set of complex data processing steps.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

66

3. The software may present message boxes and halt until the operator issues 

commands to continue.

1. Sometimes these messages do not appear in the foreground of the desktop, but are 

hidden behind other windows.

2. To limit hidden windows, it is advisable not to work with other software, such as web 

browsers, while this process is being performed.

4. The vendor software does not permit rigorous exception recovery.

1. The applications may fail due to a number of circumstances.

2. Familiarity with the Sea-Bird data processing applications will aid in diagnosing and 

overcoming problems.

3. The authoritative manual may be found at 

http://www.seabird.com/pdf_documents/manuals/SBEDataProcessing_7.18c.pdf.

4. The Data Manager is available to assist in resolving software issues.

2. Generate plots from all HEX files

1. Be sure there are no empty HEX files in the directory, which will halt the 

automated processing.

1. Use Windows Explorer to find any files that are too small to contain data points.

Navigate to \\nps\akrdfs\glba\science\data\oceanography\data\yyyy\hex_raw, where 

yyyy is the year of interest.

Locate any file whose size is 2KB or smaller.

2. Open each small file with NOTEPAD.EXE or similar program to verify whether rows 

of hex data follow the line containing *END*.

3. For each file with no data, use Windows Explorer to rename it by appending a “.bad” 

extension, which will remove it from the processing path. (E.g., rename a file called 

0903_1_0178_00.hex to 0903_1_0178_00.hex.bad.

2. Invoke the automation scripts by double-clicking the provided desktop icon or, if 

no icon is available, double-clicking its BAT file in Windows explorer.

1. Each CTD has its own version of the script. For example, CTD #1 uses C:\Program 

Files\Sea-Bird\#1HEX_Plot.bat. CTD #5 uses C:\Program Files\SeaBird\#5HEX_Plot.bat.

2. Details of program configuration are provided in Appendix I.

3. A “DOS command window” will appear and prompt the user for parameters.

1. Provide the 4-digit year in response to the prompt.

2. Enter the name of the calibration file to use.

1. Generally, this is the file most current at the beginning of the survey year.

2. Enter the filename and extension only.

1. For example, 1_0436a.con

2. Do not attempt to specify any directory information. The locations of calibration files 

for each year are pre-defined.

3. The process may appear unresponsive, with no visible indication of activity, but it is 

running. Be patient.

4. A Windows dialog box will appear titled “Data Conversion”

1. It shows parameters used and provides the status of file processing.

2. As long as file processing progress is shown, nothing should be touched in the dialog 

box.

3. Message boxes indicating errors in a particular file may appear.

1. The messages are terse but do explain the nature of problems.

2. Generally, they can be dismissed by pressing the OK button.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

67

3. If presented a message box asking “Do you want to process the next file?”, one 

may generally press YES.

1. A few defective files should not be grounds for cancelling all plots.

4. If presented with the message “Output file already exists,” click on the “Yes to 

all” button.

4. It will be over when the dialog box disappears.

5. Nothing will appear for awhile, but the first set of plots, the “A” group, is being 

assembled.

1. Once the software has looked at every file for the year, it may display a message box 

warning of errors in certain files.

1. Errored files will not be plotted.

2. Press the OK button on the message box to continue.

3. Be aware this box may be hidden beneath other Windows, and that processing 

will not resume until OK is pressed.

2. A Windows form titled “Sea Plot” will eventually appear.

1. It should display a progress bar as it plots each file.

One may monitor the creation of JPG plot files by watching the ...yyyy\plot\hex\

directory (Figure SOP 7.1):

Figure SOP 7.1. Using Windows Explorer to monitor plotting progress.

2. When complete, the software may display a temporary plot viewing window, 

which should be dismissed.

3. Once the A plot files are complete, the dialog box will disappear.

6. Nothing will appear for awhile, but the second set of plots, the “B” group, is being 

assembled.

1. The considerations and actions are the same as those in the previous step.

2. After the B plots complete the original command box should automatically disappear 

as well. If it doesn’t, type EXIT in that box.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

68

7. The plots should be reviewed for indications of problems.

1. They may typically be viewed in Windows explorer by double-clicking. The 

application that pops up showing the first file typically supports scrolling through the 

other files in the directory. Figure SOP 7.2 illustrates this.

2. The plot files follow the same file naming convention as the HEX files, but have an 

_A or _B appended, indicating which parameter set they show.

3. Missing plot files are usually the result of damaged HEX files – which should be 

investigated.

4. Erratic plots of only one parameter suggest a faulty sensor in need of correction.

1. However, outlier values only at the top of the cast are to be expected, as the CTD 

may start recording before being fully submerged and acclimated.

5. Erratic plots of multiple parameters, if they are repeated from a particular time 

forward, suggest a systemic CTD failure (Figure SOP 7.3).

Figure SOP 7.2. Example vertical profile plot of density, OBS, 

Fluorescence and PAR.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

69

Figure SOP 7.3. Raw data profile plot illustrating an example of a bad 

cast. In this case, the CTD was not lowered to depth. Data show the 

measurements “settling” as the pump comes on and the data values 

approach steady readings during the soak period.

3. Retain the plot files for year end.

1. They will be required for determining data quality when deliverable OC_M is built 

at the end of the year.

2. If accidentally deleted, they will be recreated the next time this process is run. The 

automated process always plots all files for the year.

3. The ...yyyy/PLOT/HEX/TEMP directory is used to store intermediate CNV files 

integral to this process. These files are not to be used for any other purpose as 

they are not managed as formal deliverables. 

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

71

SOP 8: Processed CNV Files (OC_C Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

At the end of the survey year, the certified HEX files along with the latest CON file are retrieved 

from SEAN and copied to the park file server. Sea-Bird SBEDataproc.exe software is executed 

under script control, creating the CNV files. 

Once created, the individual CNV files are zipped into one file for the year. The Project Leader 

submits the one file to the Data Manager as OC_C. Validation / quality assurance iterations are 

performed until the Project Leader is satisfied the data are as accurate and complete as is 

practical. The Project Leader certifies the deliverable and the Data Manager arranges for 

repository, dissemination, and metadata update.

Two profile plots of each fully processed CNV file are also generated by the SBEDataproc 

script. The plots are retained by the Project Leader for later creation of deliverable OC_M - Data 

Evaluation.

Note: before executing this procedure, it may be helpful to review protocol Appendix H 

regarding standard directory structures and Appendix I regarding Sea-Bird software layout.

SOP 8 requires users to work in the internal NPS network under valid Active Directory accounts. 

Access questions should be directed to the Data Manager.

Detailed Steps

1. Project Leader Tasks

1. Obtain the latest certified HEX files.

1. Delete all data files in 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\HEX_raw\ .

2. Download the certified OC_B deliverable from web site 

http://science.nature.nps.gov/im/units/sean/OC_Main.aspx to file server directory 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\HEX_raw\ .

3. Unzip its files using Windows explorer

1. Double-click the downloaded zip file.

2. A pane showing all the HEX files will open – select them with the mouse and drag 

to the main folder of 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\HEX_raw\ .
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

72

3. It could take awhile to extract the typical number of files.

2. Obtain the most recent certified CON file for the season.

1. Delete all files in 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CON_Calibration\ .

2. Download the most recent certified OC_A deliverable for the year to 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CON_Calibration\ . The 

appropriate file is the most recent one for the CTD in use which internally contains 

sensor calibration records all dated prior to the start of the cruise.

3. Using Windows Explorer, create a folder for the CNV output at 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CNV_processed where 

yyyy is the year surveyed.

1. Within that folder, create a subdirectory named “temp”.

2. If the CNV_Processed folder already exists from an earlier attempt, delete all its 

existing files, including those in the temp directory, using Windows Explorer.

4. Use SBEDataproc.exe to generate one CNV file from each HEX file.

1. Be aware of inherent software limitations as detailed in SOP 7.

2. The final output CNV files will be directed to 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CNV_processed\. 

1. The file will be named yymm_C_dddd_cc_suffix.CNV

1. yy is year, mm is month, C is CTD#, dddd is dump#, and cc is cast number.

2. Suffix refers to a set of single letters separated by underscores that get generated as 

a byproduct of the software process. A typical suffix is “c_f_a_m_l_d_b”.

3. Invoke the automation scripts by double-clicking the provided desktop icon or, if no 

icon is available, double-clicking this entry in Windows explorer: C:\Program 

Files\Sea-Bird\CNV_Create.bat. A “DOS command box” will appear.

4. Invoke the automation scripts by double-clicking the provided desktop icon or, if no 

icon is available, double-clicking its BAT file in Windows explorer.

1. Each CTD has its own version of the script. For example, CTD #1 uses

C:\Program Files\Sea-Bird\#1CNV_Create.bat. CTD #5 uses C:\Program 

Files\Sea-Bird\#5CNV_Create.bat.

2. Details of program configuration are provided in Appendix I.

5. A “DOS command window” will appear and prompt the user for parameters.

1. Provide the 4-digit year in response to the prompt.

2. Enter the name of the calibration file to use.

1. Generally, this is the file most current at the beginning of the survey year.

2. Enter the filename and extension only.

1. For example, 1_0436a.con

2. Do not attempt to specify any directory information. The locations of 

calibration files for each year are pre-defined.

6. While nothing may appear to be happening, processes are starting in the background. 

Each one may take several minutes to appear on the screen. Be patient.

7. A Windows dialog box will appear titled “Data Conversion”

1. It shows parameters used and provides the status of file processing.

2. As long as file processing progress is shown, nothing should be touched in the

dialog box.

3. Message boxes indicating errors in a particular file may appear.

1. The messages are terse but do explain the nature of problems.

2. Generally, they can be dismissed by pressing the OK button.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

73

3. If presented a message box asking “Do you want to process the next file?”, one may 

generally press YES.

1. A few defective files should not be grounds for cancelling the deliverable.

4. This subprocess will be over when the “Data Conversion” dialog box disappears.

8. Dialog boxes will similarly appear and disappear as the following additional 

processes execute: Filter, Align CTD, Cell Thermal Mass, Loop Edit, Derive, Bin 

Average, Sea Plot ‘A’ series, Sea Plot ‘B’ series.

1. Note and dismiss any warning messages as they appear.

2. Errors serious enough to halt the process are possible.

1. Appendix I provides details helpful in diagnosis.

2. The latest Sea-Bird software manual may explain how to recover.

3. The Data Manager may be able to assist.

9. Once the whole process completes, several sets of files will be created.

1. \\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CNV_processed\ will 

contain the final CNV files to be used in assembling OC_C.

2. \\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\Plot\CNV\ will 

contain a pair of plots for each cast.

1. These are based on the fully processed CNV files.

2. They should be similar but not identical to the QA plots in the ...\Plot\HEX\

subdirectory.

3. \\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CNV_processed\temp\

will contain the intermediate files left by each subprocess.

1. These are left behind for diagnostic purposes.

2. They are not to be reported to SEAN.

3. They should be deleted once OC_C is successfully certified.

5. Zip all the CNV files in 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\CNV_processed\ into a 

single file stored in the same folder.

1. Bring up the CNV_processed folder in Windows explorer

2. Select all files.

1. Left click one of the CNV files to select it.

2. Press Control-A to select the remaining.

3. If any files other than types CNV were in the folder, deselect them by holding 

down the control key and left clicking each one. Be certain to deselect the “temp” 

directory.

3. Create a single ZIP file containing all final CNV files using WinZip or similar 

software

1. In Windows explorer, right click one of the selected files.

2. From the menu that appears, point to WinZip.

1. If WinZip is not on the menu, contact IT support for help.

3. On the sub-menu that appears, select “Add to Zip File...”

4. On the “Add” dialog box that appears, add the final product’s filename to the 

existing path.

1. The default path shown should be the folder containing the CNV files.

2. Name the archive file CNV_yyyy_a.zip .

1. ‘yyyy’ is the calendar year.

2. Sequence letter ‘a’ is A for first attempt, B for second, etc.

3. For example, the second attempt at creating a valid 2012 OC_C 

deliverable would use filename CNV_2012_B.ZIP.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

74

5. Press the “Add” button and the new file will be created from all selected files.

4. Submit the deliverable file via email notification to the Data Manager for validation.

1. Specify in the message body it is deliverable OC_C, as defined in protocol OC2010.1.

2. Specify the fully qualified filename that the ZIP resides in.

3. Do not attach the ZIP file to the email, as it may be too large to be delivered.

4. Do not alter the deliverable file after the submission email has been sent; that could 

break the validation process.

2. Data Manager Tasks

1. On receipt of the submission, assign the next formal Submission Number to this 

file, as found in the master Submission_Log table.

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

1. The submission status must be P for pending.

2. Network copy the file into the staging area for validation at

\\inpglbafs03\data\SEAN_Data\Staging\OC\OC_C. 

3. Ensure its name meets the standards defined in Appendix J.

1. Put it in its own subdirectory whose name is the same as the submission number.

4. Unzip the file into its component CNV files in the staging area.

5. Invoke validation of the CNV files according to current criteria by using the web 

program at http://165.83.57.239/OC_DM_validate_OCC.aspx.

1. Select the pending OC_C submission from among those shown.

2. Validation summary results automatically are recorded in the Submission_Log.

6. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. A specific list of all the mandatory criteria failed

1. Copy and paste the “findings” panel of OC_DM_validate_OCC.aspx into the 

email message.

2. Alternatively, attach the “findings.htm” file that was automatically created in the 

staging subdirectory.

7. If submission passes mandatory criteria, reply with a “success email” that 

includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader Tasks

1. On receipt of a failure email:

1. Make corrections so the deliverable meets mandatory criteria.

2. Restart the process from the beginning of the post-season component section.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

75

2. Delete the obsolete intermediate files contained in ...\CNV_Processed\temp\.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager Tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool. 

2. Terminate the process.

2. On receipt of a certification email:

1. If sensitive information is in the unzipped deliverable:

1. Products containing sensitive information cannot be disseminated.

2. Mark the Submission_Log’s Status column as Sensitive using the web tool.

3. Copy the submitted single zip file to test environment as 

AUXREP\OC\OC_C\SENSITIVE\ CNV_yyyy.zip (no version letter in name).

2. If NO sensitive information is in the unzipped deliverable:

1. Copy the submitted single zip file to test environment at AUXREP\OC\OC_C\

CNV_yyyy.zip.

2. Create web page links to the new file.

3. Mark the certification in the Status column in Submission_Log using the web tool.

3. Propagate from test to production environment.

4. Verify any non-sensitive deliverable is accessible from production web site.

5. Update the annual deliverable tracking spreadsheet with the date of completion for 

OC_C.

6. Do not delete the individual CNV files from the staging area. They will be 

immediately needed for generating OC_D.

3. Update the scope of the formal metadata so it includes the new date coverage.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

77

SOP 9: Post-season Quality Assurance: Calibration 

Evaluation

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

1.0Summary

After the October cruise, the CTD is returned to Sea-Bird for calibration of the sensors. If 

multiple CTDs were employed during the season, all must undergo calibration. All sensors on a 

CTD are to be calibrated. Because no water samples are taken for mid-season calibrations of the 

conductivity, fluorometers or OBS sensors, the annual calibrations provide the only means for 

the program to independently assess sensor operations. The “Temperature Calibration Report” 

and “Conductivity Calibration Report” will detail sensor drift between the current and previous 

instrument calibrations. Use the “As Received” calibration values for purposes of determining 

drift during the period of instrument use.

For Glacier Bay measurements, which describe a dynamic coastal domain, sufficient accuracy of 

temperature (oC) and salinity (PSU) data are achieved at the 0.01 and 0.03 levels respectively; 

however typical measurements will perform better than this, on the order of 0.002–0.005 for the 

temperature measurements and 0.01–0.02 for the salinity measurements. Water samples are not 

taken during the Glacier Bay cruises, so the monitoring program has only limited ability to assess 

and correct deviant readings. After the calibration sheets have been inspected, a data quality flag 

will be assigned (see OC_M) to each CTD cast, according to the criteria listed below.

2.0 Temperature Sensor Drift

Sea-Bird specifies typical drift of the temperature probes to be less than 0.002oC per year. 

Presuming no major problems are noted with the temperature sensor, no calibration adjustments 

to the temperature measurements should ever be required. Check the “drift since last cal” value 

and ensure this value is below 0.01oC.

If the sensor offset is greater than 0.01, the cause of this should be determined through 

examination of the comments on the calibration report and/or in consultation with Sea-Bird. For 

offsets less than or equal to 0.01oC, the data quality flag should be marked as “Good.” For offsets 

between 0.01oC and 0.02oC, the data quality flag should be set to “Questionable” and for offset 

greater than 0.02oC, the data quality flag should be set to “Bad”. In the rare case where the 

temperature calibration indicates a total drift of more than 0.01oC, the cause of such a large offset 

are to be documented in the comments field of OC_M.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

78

3.0 Conductivity Sensor Drift

Particular care must be taken when assessing the conductivity calibration values, because drift 

and complete cell failure can be caused by many different sources. Biofouling of the 

conductivity cell causes measurable changes in accuracy; a crack in the glass cell can cause 

partial (minimal) or near complete sensor failure. Typical drift of a conductivity cell with one 

year between calibrations should be in the range of 0.001–0.0025 PSU/month. 

If the calibration report indicates a total conductivity cell drift of greater than 0.03 (≈0.0025

PSU/month for a year-long calibration cycle), then document this large drift in the metadata 

notes and adjust the data quality flag accordingly. The data quality flag is marked as “Good” if 

the total conductivity cell offset is less than or equal to 0.03 PSU. The data quality flag is marked 

as “Questionable” if the total offset is between 0.03 and 0.1 PSU and the data quality flag is 

marked as “Bad” if the total offset is greater than or equal to 0.1 PSU.

For the purposes of the GLBA program, no post-calibration salinity adjustments are made. 

Without in situ water samples, it is generally not possible to determine when the offset (of even 

if only one) was generated or if the offset occurred as a slowly drifting change in sensor 

characteristics. Researchers who would care to make the assumption that the drift occurred 

linearly with time can access the archived calibration sheets and spread the drift evenly (in time), 

as detailed in Sea-Bird Application Note #31, which can be downloaded from the Sea-Bird web 

site. 

In the rare case where the salinity calibrations exhibit a total drift of more than 0.1 PSU, the 

cause of such a large drift is probably catastrophic sensor failure and the Sea-Bird sensor 

calibration report may note some significant problem; this is to be noted in the comments field of 

OC_M. If no single event stands out as the likely cause of failure, none of the salinity data 

should be certified as “Good.” If a likely cause for failure can be identified, the Project Manager 

will have the option of 1) certifying only data collected before this point in time with a 

“Questionable” data quality flag and data collected after this point in time with a “Bad” data 

quality flag set or 2) denoting all data collected as “Bad”. Employing comparisons of 

measurements collected in previous years along with measurements collected in the year of 

sensor failure can help diagnose when such a failure may have taken place. The deepest 

measurements in the water column would be most appropriate for such comparisons because the 

dynamic range of salinity values is smaller away from the surface waters.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

79

SOP 10: Cumulative Database (OC_D Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

Immediately after certification of an OC_C submission, the individual CNV validation files are 

still available in the staging area. Data in these files are loaded into the test database, deleting 

anything previously submitted for the stated year. Once that is done successfully, the process is 

repeated for the production database. Certification is attested by the Data Manager, on the basis 

of the Project Leader’s OC_C certification.

All steps are performed by the Data Manager.

Detailed Steps

1. Data Manager Tasks

1. Upon certification of OC_C, verify the year’s unzipped CNV file set is still complete 

in the staging area. 

2. OC_C has already been validated and needs no further quality control measures.

3. If the OC_C deliverable for the submission unit was marked sensitive in its 

Submission_Log entry:

1. Create a Submission_Log entry for this OC_D using the web tool, marking the status

as sensitive. 

2. Update the annual deliverable tracking spreadsheet with the date of completion for 

OC_D.

3. Propagate only the tracking spreadsheet to production.

4. The process is complete.

4. Otherwise use web application http://165.83.57.239/OC_DM_create_OC_D.aspx to 

create and validate the OC_D

1. Indicate to the program which certified OC_C submission from the offered choices to 

use as the basis for the OC_D.

2. The submission log entry will be automatically created and updated as progress is 

made.

3. The OC_C components are revalidated

1. If a mandatory criterion is violated, the OC_D will not be created and the process 

ends.

2. Failure suggests a previously undetected flaw in the predecessor OC_C and, 

possibly, OC_B components: this must be investigated and corrected before an 

O_D can be created.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

80

4. If this submission unit has previously been stored in the database, then the new data 

will totally replace the older submission

1. The web application will only erase/replace the earlier data if the operator 

confirms this with the “overwrite” button on the screen.

2. Should loading of the new data fail later in the process, any erased prior data will 

remain erased. Remedial action will be needed to recreate it.

5. When complete, the web application updates the submission status.

1. If it is not Certified, check the screen execution log to determine the nature of the 

problem, correct the issue, and resubmit.

5. Using SQL Server management studio, update the production database rows and 

submission log entry for the submission unit from the staging server.

6. Update the annual deliverable tracking spreadsheet with the date of completion 

for OC_D.

7. Update the scope of the formal metadata so it includes the new date range
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

81

SOP 11: Data Quality Assignment (OC_M Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct.

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

At the end of the survey year, a review is done to determine if recalibration data indicate sensor 

errors over the season are significant. The original log sheet images are reviewed for annotations 

regarding exceptions. The raw and processed vertical profile data plots are reviewed both 

separately and jointly for data errors.

The Project Leader notes questionable and unusable casts for the year on the data quality report 

spreadsheets. The Data Manager, after validating the spreadsheet forms, updates appropriate 

columns in the cumulate database to reflect exceptions to quality.

Detailed Steps

1. Project Leader Tasks

1. Obtain a blank Data Quality Report form from the “toolbox” link on the SEAN web 

site.

1. Its form is an XLSX spreadsheet.

2. Ensure there are nine tabs, one for each cruise of the year.

3. Head the top of each form with cruise-specific information.

4. Record results of the following analyses on the appropriate sheet.

1. Use the order shown.

2. If a cast/station is marked BAD at a point in the process for any reason, no 

further quality review for that cast is performed.

3. If a cast/station is marked QUESTIONABLE, review continues in order to 

determine if it should be further marked down to BAD.

2. Review the latest certified calibration certificates.

1. Examine the certified images on the SEAN website of the pre- and post-season 

calibration documents (deliverable OC_G).

2. Following the guidance in SOP 9, note any data quality exceptions on the data quality 

report sheets.

3. The scope of this finding may cover the entire season if a serious drift was present.

3. Review all certified field log sheet images for the year on the web site (deliverable 

OC_H).

1. Individual cast exceptions may be noted in the COMMENTS field.

2. Overall cruise exceptions and problems may be noted in the NOTES field.

3. Be sure to check the backside image of each sheet for further details.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

82

4. Mark technically flawed casts as BAD on the quality spreadsheet.

1. Use the codes listed at the bottom of the sheet, which follow the standard used by 

the Ocean Data View system.

2. Include a brief explanatory comment. Each comment will be embedded in the 

historic database to guide future researchers when they select data to work with.

5. Mark/comment casts as questionable if one or two sensors appear faulty for some or 

all of a cast. 

1. It isn’t possible to provide a quality rating at the CTD/dump/cast/individualsensor level, so any problem has to be recorded for the cast as a whole. 

6. Check appropriate boxes on the Data Quality Sheet to mark any failed or 

disconnected sensors for particular casts or for the dump as a whole.

1. This will cause the OC_D database to be null in the corresponding cells, 

removing the wild readings typical of broken sensors.

4. Review the raw in-season profile plots made for individual casts made for QA 

purposes during the season (SOP 7).

1. Mark/comment as questionable casts having one or two improbable plot lines.

2. Mark/comment as bad casts displaying three or more improbable plot lines.

5. Review the processed post-season profile plots made for individual casts made 

for QA purposes during the season (SOP 8).

1. Mark/comment as bad casts for which nothing is plotted

1. The data processing tasks discard observations that are widely outside acceptable 

limits – in a seriously failed cast it is possible all points get deleted.

2. Compare processed post-season plots against raw in-season plots.

1. If strong discrepancies appear, investigate possible causes.

2. The Project Leader’s judgment, following currently accepted practices in the 

field, will determine whether to mark casts as questionable or bad.

6. Submit the deliverable file via email attachment to the Data Manager for validation.

7. Specify in the message body it is deliverable OC_M, as defined in protocol 

OC-2010.1.

2. Data Manager Tasks

1. On receipt of the submission, assign the next formal Submission Number to this 

file, as found in the master Submission_Log table.

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

2. Copy the file into the staging area for validation at 

\\inpglbafs03\data\SEAN_Data\Staging\OC\OC_M. 

1. Ensure its name meets the standards defined in Appendix J.

3. Validate the XLSX file according to current criteria. 

4. Record validation summary data in the Submission_Log using the web tool.

5. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

83

6. If submission passes mandatory criteria, reply with a “success email” that

includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader Tasks

1. On receipt of a failure email:

1. Make corrections so the deliverable meets mandatory criteria.

2. Make another submission with the corrected deliverable candidate.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. Store log sheets in an annual paper file kept by the Project Leader.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager Tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column with the web tool.

2. Terminate the process.

2. On receipt of a certification email:

1. Due to the nature of these data NO sensitive information is in the deliverable.

2. Copy the submitted single spreadsheet file to test environment at 

AUXREP\OC\OC_M\yyyy.XLSX.

3. Create web page links to the new file.

4. Update the test database contents.

1. Use the OC_M update tool on the Data Management web site at 

http://165.83.57.239/OC_DM_update_OCM.aspx .

5. Mark the certification in the Status column in Submission_Log using the web tool

6. Propagate from test to production environment.

3. Update the annual deliverable tracking spreadsheet with the date of completion 

for OC_M.

4. Update the scope of the formal metadata so it includes the new date coverage.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

85

SOP 12: Field Log Sheets (OC_H Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

The complete sets of paper field log sheets that have been accumulating over the survey year are 

collected. They are double-side scanned into a single PDF for the year. The PDF is submitted 

through the validation / quality assurance iterations until certified.

SOP 12 requires users to work in the internal NPS network under valid Active Directory 

accounts. Access questions should be directed to the Data Manager.

Detailed Steps

1. Project Leader Tasks

1. Retrieve from paper files the field log sheets that have been recorded during the 

survey season.

2. Arrange them in dump number order.

3. Verify the set is complete. The dump number should continuously increment with 

no gaps. If a sheet is discovered missing for a dump, insert a page of paper in the 

stack listing the dump number and stating “No Field Log Sheet.”

4. Scan the entire packet into a single PDF file using park scanner and associated 

software. 

1. Be sure the scanner is set for two-sided scanning, or be prepared to duplex them by 

hand.

2. Save the PDF on park network at 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\yyyy\Field_Log_Sheets\ where 

yyyy is the survey year covered, e.g., 2011. Name the file LOG_yyyy.PDF, once

again substituting the year for yyyy.

5. Submit the single PDF file via email attachment to the Data Manager for validation, 

specifying in the message body it is deliverable OC_H, for year yyyy, as defined in 

protocol OC-2010.1.

2. Data Manager Tasks

1. On receipt of the submission, assign the next formal Submission Number to this 

file, as found in the master Submission_Log table.

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

86

2. Save the file into the staging area for validation at 

\\inpglbafs03\data\SEAN_Data\Staging\OC\OC_H. 

3. Validate the submission according to current criteria.

4. Record validation summary data in the Submission_Log using the web tool.

5. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed

6. If submission passes mandatory criteria, reply with a “success email” that 

includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

3. Project Leader Tasks

1. On receipt of a failure email:

1. Review the paper stack is in order.

2. Rescan the PDF to ensure it is in the proper form.

3. Resubmit

4. If failure cannot be resolved, email the Data Manager that the submission is 

withdrawn.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

4. Data Manager Tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool.

2. Terminate the process.

2. On receipt of a certification email:

1. Verify no sensitive information is in the deliverable. Products containing sensitive 

information cannot be disseminated. (Sensitivity is highly unlikely for this 

deliverable.)

2. Copy the submitted file to test environment at AUXREP\OC\OC_H\ .

3. Propagate from test to production environment.

4. Verify deliverable is accessible from production web site.

5. Mark the certification in the Status column in Submission_Log using the web tool.

6. Update the deliverable tracking spreadsheet with the date of completion for OC_H.

3. Update the scope of the formal metadata so it includes this new date range.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

87

SOP 13: Data Availability Matrix (OC_J Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

Once the OC_D database update has been certified for the year, this must be publicly 

documented in OC_J. The Data Manager retrieves the most recent OC_J version as an Excel 

spreadsheet. A database query is executed for the year to show by month by CTD the presence of 

readings for salinity, PAR, OBS, fluorometry and DO. The spreadsheet is updated to reflect this 

and saved. A PDF is made of the new spreadsheet. It is installed in the repository for 

dissemination.

All tasks are performed by the Data Manager.

Detailed steps

1. Retrieve the latest Excel spreadsheet version of deliverable OC_J from 

AUXREP\OC\OC_J\current.xls.

2. Resave it as AUXREP\OC\OC_J\yyyymmdd.xls.

1. Filename is date of creation, (i.e., today).

2. yyyy is 4-digit year.

3. mm is 2-digit month with leading zero if needed.

4. dd is 2-digit day with leading zero if needed.

3. Query the detailed database for a count of parameters recorded over the 

scope of deliverable OC_D, grouped by year, month, CTD, and sensor type.

1. Open a SQL data query tool such as Microsoft SQL Server Management Studio.

2. Execute the query stored in K:\SEAN_Data\Staging\OC\OC_J\OC_J-basis.sql.

3. Update yyyymmdd.xls cell icons so they reflect the scope of data found by the query.

4. If this is the first deliverable reported for the latest survey year, an additional row must be 

added to the sheet and populated. If it is the result of a resubmission / recertification to 

the original OC_D, then the original row should be directly altered.

4. Exhaustively compare results against one year prior.

1. Any changes to the CTD capabilities should be reflected.

2. If expected changes do not appear, suspend the process until the nature of the fault is 

determined and remediation steps are identified and performed.

5. Spot check older sheet cells against the comprehensive database query.

1. Exhaustive comparison is not required because these are not likely to change.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

88

2. If the query does not appear consistent with the existing history, investigate cause to 

determine whether it is the result of normal operations or of an error.

3. If the result appears caused by a failure that requires remediation, then launch an ad hoc 

effort to repair damage.

6. If no inconsistencies were detected above, update the sheet to reflect new 

values.

7. Save the new components of OC_J.

1. Resave the updated yyyymmdd.xls.

2. Also save yyyymmdd.xls as a PDF file named yyyymmdd.pdf.

3. Copy yyyymmdd.xls over file current.xls, which will be the basis for the next deliverable 

cycle.

4. Copy yyyymmdd.pdf over file current.pdf, which is the information disseminated by the 

main web site.

8. Verify the new OC_J is being properly served by the web site.

9. Update the deliverable tracking spreadsheet with the date of completion for 

this OC_J.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

89

SOP 14: Annual Data Report (OC_K Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

The annual report will summarize the field efforts of the previous sampling year, provide 

graphical and tabular summaries of collected data and place these data within historical context 

so that unusual observations can be identified. The sampling year ends after the October cruise, 

so the final certified data will not be available until after the instrument returns from the Sea-Bird

calibration facility, typically in November or early December. The December oceanographic 

cruise will take place in December or January; the Annual Data Report will normally be 

generated in January or February.

Because water column samples of phytoplankton, suspended sediment, and dissolved oxygen are 

not taken and analyzed, the ancillary data sensors cannot be quantitatively compared on an intercruise or inter-annual basis, nor even within the same cruise (it is acceptable to compare 

measurements within the same cast, however). For example, different phytoplankton species 

have different responses as measured by the fluorometers. Consequently, even within a single 

cruise, data are not directly comparable because phytoplankton communities within a fjord near a

glacier may well have different species compositions from communities more closely connected 

to the Gulf of Alaska. Similarly, field personnel have no way to calibrate the OBS sensor in situ

to particle size distribution, shape, color, reflectivity, etc., so turbidity measurements among 

casts and cruises must be interpreted with considerable caution. Nonetheless, it is important to 

examine these data (on a relative scale) in order to note possible changes in the character of these 

parameters over time. 

1.0 Annual Report Format and Content

The Annual Data Report will follow the NPS Natural Resource Data Series report format 

(http://www.nature.nps.gov/publications/NRPM/index.cfm) and will contain the following 

subsections and content:

1. Introduction: Overview of the monitoring program and its history; personnel 

involved.

2. Methods: Summary of the sampling methodology, timing of field work.

3. Coverage: Chart showing what stations were occupied in what months

4. Synopsis of operations: Overview of the year; what went well; what problems 

cropped up; what needs particular attention in the coming year. Summary of 

observation comments and notes recorded on the Field Log sheets.

5. Results: 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

90

i. Tables summarizing basic measurement and statistics. Provide the mean, 

maximum, minimum and standard deviation (as appropriate) of designated 

parameters in the upper 50m of the water column from all cruises (for each 

core station). Parameters will include: temperature, salinity, density, vertical 

density gradient, fluorescence, oxygen, OBS and PAR. (See example in 

section 2.0 following.) A second table will depict water column conditions 

from near the bottom at each station.

ii. Analysis of Station 04 with respect to historical data. Vertical profile plots or 

tables of the temperature and salinity measurements from Station 04 in all 

cruises along with historical mean and +/- one standard deviation.

iii. Horizontal cross-sections. Horizontal cross-sections of temperature, salinity, 

density, fluorescence, oxygen, and OBS from the July and December/January

cruises. For each of the cruises with cross-section plots, one set of crosssections should show the data extending from Icy Strait to the head of the 

West Arm, and a second set should show the data from Icy Strait to the head 

of the East Arm fjord.

6. Discussion: Summary of observations based on tables and figures presented in the 

Results section. Note in particular anomalous conditions that persist through multiple 

sampling periods, multiple years and/or across domains.

2.0 Content of Results Section (i): Tables Summarizing Basic Measurements and 

Associated Statistics

In order to assess the measurements made within each cruise, standard statistical summary tables 

(Table SOP 14.1) and/or plots will be created by the Project Leader with help from the Data 

Manager in accessing values stored within the database. 

These tables will be useful to other researchers conducting marine related studies in the park. 

Such data tables can be incorporated directly into their analyses, and the Annual Data Report will 

provide sufficient context for interpretation of these measurements.

Rows of each table will describe each field effort conducted through the year and at each core 

station. Columns of the data tables will contain the 0–50m depth level mean, maximum, 

minimum and standard deviation for all of the following parameters: Temperature, Salinity, 

Density (Sigma-t), Vertical density gradient, Fluorescence, Oxygen, OBS, and PAR. Exceptions 

to the reported statistics are for 1) the density gradient parameter which requires reporting of the 

mean, maximum and depth of maximum only, and 2) the PAR measurement which requires the 

mean, minimum and maximum values only. For purposes of this report, vertical density gradient 

is calculated as [(density at next lower bin) – (density at next higher bin)] * 0.5. The top and 

bottom depth bins of each cast have no vertical density gradient. Table SOP 14.1 shows example 

table setups for reporting these statistics.

The 0–50 m depth level captures the portion of the water column where the majority of primary 

production, macronutrient utilization, phytoplankton standing stock, thermal stratification, and 

low-salinity lenses all occur. Thus, summarizing this portion of the water column will provide a 

broad perspective on the physical, chemical and phytoplankton components of the system.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

91

The near-bottom summary table will provide information about 1) bottom water renewal rates 

and timing within the fjord; 2) to the nutrient budget cycle dynamics; and 3) connectivity of the 

fjords with the outside waters.

Table SOP 14.1. Example data summary tables for reporting the basic measurement and statistics 

collected at the core station set. 

3.0 Content of Results Section (ii): Analysis of Station 04 with Respect to 

Historical Data

Using data from Station 04 only, vertical profiles (temperature vs. depth and salinity vs. depth) 

are to be plotted along with the climatologic mean profile in order to assess the relation of the 

current data to the long-term mean (Figure SOP 14.1). The data should also be tabulated so that 

the values shown in the plots are easily accessible to managers and other researchers (Table SOP

14.2). Station 04 is selected for this analysis because it represents a deep station inside the main 

sill of the fjord and with close connection (proximity) to the West Arm, East Arm and Lower 

Bay domains. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

92

Figure SOP 14.1. Example vertical profiles of temperature (left) and salinity (right) shown along with 

historical data. Data is taken from oceanographic station GAK1 in the northern Gulf of Alaska near 

Resurrection Bay. Plotted are the current data (May 2007, red with dots) and historical mean values 

(blue, with dots) along with +/- bounds of 1 standard deviation to either side of the historical mean (blue, 

without dots). Only a subset of the full vertical profile has been employed here: the 0, 10, 20, 30, 50, 75, 

100, 150, 200 and 250 m depth levels. From this plot, we see that waters in May 2007 are anomalously 

cold over nearly the whole water column whereas the waters are anomalously salty between 10 and 100

m depth and anomalously fresh at 250 m depth.

Error bounds of one standard deviation plotted to either side of the monthly climatology will 

allow the profile of interest to be assessed as to whether or not the monthly values’ deviations 

(from the monthly climatology) are considered “normal” or “anomalous.” An anomalous value is 

defined as one with observations that fall beyond one standard deviation of the mean of that 

month’s measurements. Therefore, by definition of 1 standard deviation and the assumption of a 

normal distribution, 68% of all years will be considered “normal” and 32% will be considered 

“anomalous”. Anomalous measurements are to be noted in the discussion section of the report. 

Observations that fall outside of two standard deviations (~95% of normally distributed 

observations) represent very unusual occurrences and deserve particular attention within the 

annual report. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

93

Table SOP 14.2. Example data table: tablature display of the same data presented in Figure SOP 14.1. 

To help draw attention to anomalous measurements, observations made in May 2007 that lie outside one 

standard deviation of the long-term mean are emphasized in bold, italic type.

Station GAK1 Temperature Station GAK1 Salinity

Depth

(m)

1972–

2008 May 

Mean

Mean - 1 

Standard 

Deviation

May 

2007

Mean + 1 

Standard 

Deviation

1972–

2008 May 

Mean

Mean - 1 

Standard 

Deviation

May 2007

Mean + 1 

Standard 

Deviation

0 6.69 5.66 6.59 7.72 30.63 30.02 31.10 31.24

10 6.03 5.10 4.86 6.95 31.08 30.73 31.60 31.43

20 5.56 4.73 4.36 6.40 31.25 30.98 31.69 31.53

30 5.35 4.58 4.23 6.12 31.36 31.11 31.79 31.60

50 5.20 4.42 4.10 5.98 31.49 31.29 31.84 31.70

75 5.01 4.18 3.97 5.83 31.67 31.52 31.93 31.83

100 5.01 4.23 3.85 5.80 31.85 31.71 32.05 31.99

150 5.15 4.46 3.93 5.84 32.20 32.00 32.16 32.40

200 5.33 4.82 4.17 5.83 32.54 32.32 32.34 32.76

250 5.46 5.05 4.25 5.87 32.75 32.53 32.44 32.96

These tables and vertical profile plots are to be generated at a select subset, the “standard 

oceanographic” depths: 0, 10, 20, 30, 40, 50, 75, 100, 150, 200, 250, 300, 400, and 500 m depth 

levels. 

4.0 Content of Results Section (iii): Horizontal cross-sections

Horizontal cross-section plots can be generated with the Ocean Data View (ODV) software

(http://odv.awi.de/). An ASCII data table provided by the Data Manager that contains the full 

“flattened” dataset can be imported directly into ODV. Parameters to plot include temperature, 

salinity, fluorescence, oxygen and OBS and should cover stations from Icy Strait to the head of 

West Arm. An example of a horizontal cross-section figure along Glacier Bay is presented in 

Figure SOP 14.2.

These figures provide a visual depiction of the data collected with the highest spatial resolution. 

Features within the figures will lend themselves to discussion of biophysical processes that are 

important to the marine ecosystem.

5.0 Validation and submission of the deliverable

The final version of OC_K is generated as a PDF file by the Project Leader. It is passed to the 

Data Manager for the defined validation checks and eventually is confirmed certified through the 

workflow used for all deliverable certifications. The Data Manager installs the final PDF in the 

auxiliary repository, creates a web link for it, updates the Deliverable Product Tracking grid, and 

forwards the final OC_K to NPS’s NRInfo Portal (formerly NPS Data Store).
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

94

Figure SOP 14.2. Example ODV-generated cross-section contour plots using Glacier Bay CTD data 

collected in July 2009. Station locations are plotted with blue dots in the map in the lower left-hand corner, 

the transect is outlined in red. On the contour plots, the mouth of Glacier Bay (station 00) is located at 0 

km on the horizontal axis.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

95

SOP 15: Five-Year Report (OC_L Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Beginning in 2012 and every five years thereafter, the Project Leader, with appropriate SEANfunded external technical assistance, will undertake trend analyses and comparison of the 

monitoring program dataset to other regional datasets for the purpose of placing observed signals 

into broader temporal and regional contexts. 

1.0 Five-Year Report Format and Content

The five-year report will contain the following subsections and content:

1. Introduction: Overview of the monitoring program and its history

2. Methods: summary of the sampling methodology 

3. Coverage: Chart showing what stations were occupied in what months and years

4. Results: Analyses are driven mainly by observed features noted within the Glacier 

Bay dataset. The five-year report will include the following four components:

i. Analysis of spatial extent of observed anomalies

ii. Trend analysis

iii. Time series analysis

iv. Comparisons to other surface and profile data

5. Discussion: Summary of observations based on tables and figures presented in the 

Results section. 

2.0 Content of Results Section (i): Analysis of Spatial Extent of Observed 

Anomalies 

For the same reasons as for the annual report, Station 04 is given particular attention in the fiveyear data reports. Show in the five-year report to what extent Station 04 anomalies are 

representative of anomalies observed at the other core stations through use of basic statistics: 

mean, standard deviation, and cross-correlation computations will suffice. This analysis will help 

place interpretation of the Station 04 results into a broader spatial context.

3.0 Content of Results Section (ii): Trend Analysis

The five-year report will present monthly anomaly time series, which includes station-by-station 

plots of the difference between observed and long-term mean monthly values. This manipulation

removes the mean annual signal (represented by the monthly climatology) from the time series 

and allows for straightforward interpretation of different signals. Examples of such analyses are 

available at the GAK1 time series web page: www.ims.uaf.edu/gak1 and in Figure SOP 15.1
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

96

below. Analyses will be performed at a selection of depth levels that provide a representative 

depiction of the water column. Employ the “standard” oceanographic depth levels: the 0, 10, 20, 

30, 40, 50, 75, 100, 150, 200, 250 and 300 m depth levels.

Figure SOP 15.1. Example anomaly plots of temperature (top) and salinity (bottom) along with the leastsquares best fit linear trend (red) to each time series for oceanographic station GAK1. In these plots, the 

mean annual signal (monthly climatology) has been subtracted from the present month’s measurements, 

resulting in a zero mean anomaly time series. The plots show that the mean 250m temperature has 

increased by nearly 1oC over the last 35 years whereas the salinity has remained essentially unchanged. 

The most recent two years (2007 & 2008) show temperatures well below the long-term trend line, 

indicated a recent prolonged cold spell. Temperatures through most of the 1980s, however, were mostly 

higher than normal.

4.0 Content of Results Section (iii): Time Series Analysis

When the GLBA dataset is sufficiently long, spectral analysis techniques (e.g., Fourier analysis) 

will be appropriate for evaluating cyclic and quasi-cyclic phenomena. To ensure statistically 

robust interpretations, Fourier analysis requires a time series to be about 10 times the length of 

the period for the signal of interest. Thus, to well resolve the (approximately) three-year El Nino 

(Southern Oscillation Index) signal, a time series approaching 30 years will be required. 

The GLBA oceanographic time series trends and anomalies should also be compared to other 

regional data sets collected in the northeast Pacific. These comparisons should include 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

97

investigations of regime shifts (e.g., step or state changes) and periodic or quasi-periodic 

phenomena. 

Oceanographic data sets for comparison include (but are not necessarily limited to):

1. The GAK1 time series

Oceanographic measurements from the mouth of Resurrection Bay, Alaska. Dataset 

maintained by the University of Alaska – www.ims.uaf.edu/gak1/.

2. The Line P and Ocean Station PAPA time series 

Oceanographic measurements from 50N, 140W. Dataset maintained by the Canadian 

Department of Fisheries and Ocean Sciences (DFO) at the Institute of Ocean Sciences

(IOS). www-sci.pac.dfo-mpo.gc.ca/osap/projects/linepdata/default_e.htm

3. Canadian “lighthouse” time series 

Sea surface temperature and salinity measurements from lighthouses located along the 

Canadian Pacific coast. Dataset maintained by DFO-IOS. www-sci.pac.dfompo.gc.ca/osap/data/default_e.htm

4. National Data Buoy Center (NDBC) moorings and coastal station datasets

Oceanographic and meteorologic data sets located throughout Southeast Alaska. 

www.ndbc.noaa.gov/.

Companion plots of environmental and climate time series can be employed to help interpret the 

oceanographic findings within a broader context. Cross-correlation techniques can help identify 

possible linkages between the local Glacier Bay system and the companion time series. 

Data sets for comparison include:

1. Local atmospheric variables

Wind, temperature and precipitation datasets available from the National Climate Data 

Center (NCDC; www.ncdc.noaa.gov and the NDBC www.ndbc.noaa.gov). The Bakun 

Upwelling index available from the Pacific Fisheries Environmental Laboratory: 

(http://www.pfeg.noaa.gov/products/PFEL/modeled/indices/upwelling/NA/upwell_menu_

NA.html). Variables computed by atmospheric reanalysis models such as the National 

Center for Environmental Prediction/National Center for Atmospheric Research 

(NCEP/NCAR) Reanalysis: 

(http://www.esrl.noaa.gov/psd/data/gridded/data.ncep.reanalysis.html)

2. Local sea level/tide stations

Data available from the NOAA Tides and Currents web page 

(http://tidesandcurrents.noaa.gov/)

3. Local streamflow data 

Dataset available from the United States Geological Survey 

(http://waterdata.usgs.gov/ak/nwis/)

4. Large-scale climate system indices

Pacific Decadal Oscillation (PDO,http://jisao.washington.edu/pdo/PDO.latest),

Southern Oscillation Index (www.cgd.ucar.edu/cas/catalog/climind/index.html)

North Pacific Index (NPI, www.cgd.ucar.edu/cas/catalog/climind/index.html)

Pacific-North American Index (PNA, http://jisao.washington.edu/data/pna/)
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

98

5.0 Content of Results Section (iv): Comparison of Glacier Bay Measurements to 

Other Surface and Profile Data

Evaluation of the Glacier Bay CTD data within a broader spatial context can be accomplished by 

utilizing historical CTD casts from the greater Southeast Alaska region. Data can be downloaded 

from the NODC World Ocean Database (WOD), (www.nodc.noaa.gov/) and the AOOS-AMIS 

database (www.aoos.org/). The plot shown in Figure SOP 15.2 is an example of using this WOD 

historical dataset. The WOD should be polled for each five-year report to determine if new casts 

for the region of interest have been incorporated. Transects that are coincident or nearly 

coincident with the timing of the Glacier Bay CTD transects should be focused on and will 

provide the greatest benefit for analysis.

Figure SOP 15.2. Horizontal cross-sections (upper panels) and a T-S plot (lower right panel) employing 

historical CTD data from the NODC World Ocean Database, plotted with the Ocean Data View (ODV)

software package. Station locations are plotted on the map in the lower left panel and span from the 

central Gulf of Alaska (located at 0 km on the left of the upper two panels) into Cross Sound (at 

approximately 110 km) to the mouth of Glacier Bay (at approximately 150km), to the mouth of Lynn Canal 

(at approximately 220 km) and down into Chatham Strait. In this case, the data is averaged from between 

the months of August and October. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

99

Other spatially explicit datasets that can lead to useful insight include satellite measurements of:

 Sea Surface Temperature (Advanced Very High Resolution Radiometer satellite)

 Winds 

 Sea Surface Elevation (from the Topex/Poseidon satellites) 

 Ocean Color (SeaWifs and MODIS satellites). 

These datasets can all be accessed online (http://seawifs.gsfc.nasa.gov/ and 

http://podaac.jpl.nasa.gov/DATA_CATALOG/index.html). Most of these datasets can also be 

retrieved directly from the AOOS data server.

6.0 Validation and Submission of the Deliverable

The final version of OC_L is generated as a PDF file by the Project Leader. It is passed to the 

Data Manager for the defined validation checks and eventually is confirmed certified through the 

workflow used for all deliverable certifications. The Data Manager installs the final PDF in the 

auxiliary repository, creates a web link for it, updates the Deliverable Product Tracking grid, and 

forwards the final OC_L to NPS’s NRInfo Portal (formerly NPS Data Store).

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

101

SOP 16: AOOS Data Submission (OC_E Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

At the end of each season, once the OC_D database updates have been certified, the year’s data 

are submitted to the Alaska Ocean Observing System for secondary archiving and dissemination.

As of the current writing (October 2010), the AOOS data management program is in a 

transitional phase and is not accepting or disseminating data. We look forward to working with 

them when they have achieved a functional level of service ability.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

103

SOP 17: NODC Data Submission (OC_F Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

At the end of each season, once the OC_D database updates have been certified, the year’s data 

are submitted to the National Oceanographic Data Center (NODC, http://www.nodc.noaa.gov/)

for archiving and dissemination. This same submission will also be forwarded to the NRInfo 

Portal.

1.0 NODC Data Submission:

1. Select data for submission.

2. Assemble metadata in an FGDC-compatible metadata file or employ the NODC 

Electronic Data Description Form, available at: 

http://www.nodc.noaa.gov/General/NODC-Submit/dirsubmit_eddf.html.

3. Assemble the metadata and data for submission. 

Compile the files within one compressed archive file (e.g., .zip, .gz).

4. Browse to http://www.nodc.noaa.gov/.

5. Click on the “Submit Data” hyperlink for FTP data submission instructions.

6. Upload data file and metadata file via FTP:

i. Open an ftp communications program.

ii. Enter "ftp ftp.nodc.noaa.gov"

iii. When prompted for name, enter "anonymous" (use lower case). 

iv. When prompted for password, enter your e-mail address. 

v. When logged on, change directory to "incoming" by entering:

"cd pub/incoming". 

vi. Check that you are in the correct directory (pub/incoming) by entering the 

command "pwd" (print working directory)

vii. Make sure the transfer type is binary by entering "bin". 

viii. Use "put filename", where "filename" is the name of your file, or for 

multiple files use "mput *.*" or "mput *" to transmit the data. When 

transferring multiple files you can turn off the prompt for each filename by 

typing "prompt" before you type the "mput" command. 

ix. After completion of file transmission, enter "ls" to obtain a list of files 

that were sent, both by you and other recent data submitters. 

x. Enter "bye" to log off. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

104

xi. Send an e-mail message to: NODC.DataOfficer@noaa.gov to let us know 

that data was submitted. Please describe your exact submission procedures 

and anything else you would like us to know about the data. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

105

SOP 18: Protocol Revision (OC_I Creation)

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

Summary

Periodically, material changes must be made to the protocol to take advantage of new or different 

technologies, supply manufacturers, equipment, and methods. Changes may also be made to 

correct significant errors in the document or to refine and update the data reports.

The Program Manager, Project Leader, and Data Manager jointly build a list of desired changes. 

They review the issues, accept some or all of them by consensus, and draft new language to 

affect the accepted changes. One person shall be chosen to coordinate the new document and be 

responsible for the new draft. Changes to key items will trigger an external review of the draft 

document. Reviews will consider impacts including but not limited to those caused by changes in 

equipment, data collection methods and data processing methods.

After satisfying both internal and external reviewers, the updated protocol will go through formal 

validation and certification by the Program Manager and Data Manager. The certified protocol 

will be widely disseminated.

Detailed Steps

1. Program Manager (PM) Tasks

1. Periodically poll Project Leader (PL) and Data Manager (DM) on the need for a 

protocol revision cycle.

2. Schedule a revision cycle when called for by consensus.

3. Obtain a new formal protocol ID number from Data Manager.

1. Method for assigning a protocol ID is formally set in SEAN’s Data Management Plan 

SOP-602 Version Control.

2. A new ID is required for each revision because most data collected are tagged with 

the specific protocol they were created under: the mechanism is rigid.

4. Solicit agenda of issues to address.

5. Initiate kick-off meeting.

2. Program Manager, Project Leader, and Data Manager Tasks

1. Prepare issues lists.

2. Agree on overall scope of revision.

1. “Minor” will have internal review.

2. “Major” will have peer review.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

106

3. Agree on a “coordinator” who is responsible for managing assembly of the 

revised document.

4. Obtain the most recent Word version of the current protocol from the DM to serve 

as the basis for the new document.

1. The original DOCX file is copied to an editable destination file.

2. The document is set for tracked changes.

3. A global search and replace is done to change all existing references to the protocol 

ID to the new designator.

4. The DM provides a link allowing access of the DOCX file by the three team members 

through a browser.

5. The actual final product will be made available on the web only as read-only PDF in 

order to minimize the chance of multiple conflicting documents being built.

5. Draft possible revisions.

1. Each team member should take responsibility for sections within their realm of 

expertise.

2. If a particular section needs to be addressed to meet multiple needs, it should be 

worked on serially.

1. Get team agreement on the order of attack for issues.

2. Assign person to do first revision covering first issue.

3. Obtain consensus on the first revision.

4. Assign person to do second revision covering second issue, etc.

3. “Coordinator” Tasks

1. Assemble revision drafts into a coherent document.

2. Maintain a document change table in the SOP document to track internal 

versioning.

3. Distribute to PM, PL, and DM for internal review.

4. Update document to satisfy internal review.

5. Obtain consensus of PM, PL, and DM.

6. Format the document.

7. If scope is major, coordinate external review.

1. Pass document to Regional I&M Coordinator for consideration.

2. Distribute resulting review comments to PM, PL, and DM.

3. Revise protocol in light of review comments.

4. Coordinate revisions among team.

8. Assemble document.

9. Obtain final team approval.

10. Format document as a Natural Resource Report (NRR).

1. Coordinate technical/formatting NRR review

2. Obtain a “TIC” document number from NRPC.

3. Make final technical revisions.

11. Notify team of completion.

4. Program Manager Tasks

1. Generate a PDF file off the original Word document.

2. Submit both the PDF and DOCX files via email attachment to the Data Manager for 

validation.

1. Specify in the message body it is deliverable OC_I, as defined in protocol 

OC_2010.1.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

107

5. Data Manager Tasks

1. On receipt of the submission, assign the next formal Submission Number to this 

file, as found in the master Submission_Log table.

1. Use the “Update Submission Log” web tool at 

http://165.83.57.239/0_submission_update.aspx .

2. Complete Submission_Log details up through the Submission_Date column.

2. Save the attached file into the staging area for validation at 

\\inpglbafs03\data\SEAN_Data\Staging\OC\OC_I. 

3. Validate the two files according to current criteria. 

4. Record validation summary data in the Submission_Log using the web tool.

5. If submission fails mandatory criteria, reply with a “failure email” that includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing all the specific mandatory criteria failed

6. If submission passes mandatory criteria, reply with a “success email” that 

includes:

1. The submission number assigned

2. The deliverable ID

3. The protocol ID

4. Documentation listing any specific optional criteria failed

5. Request to certify deliverable as complete

6. Program Manager Tasks

1. On receipt of a failure email:

1. Make corrections so the deliverable meets mandatory criteria.

2. Make another submission with the corrected deliverable candidate.

2. On receipt of a success email, review any failed optional criteria:

1. If these are acceptable to PM, PL, and DM:

1. Reply with a “certification email” stating the deliverable is certified and may be 

disseminated.

2. If these are unacceptable:

1. Reply with a “withdrawal email”, stating the deliverable is withdrawn.

2. Take remedial action to obtain a corrected deliverable.

3. Restart the process from the beginning.

7. Data Manager Tasks

1. On receipt of a withdrawal email:

1. Mark the withdrawal in the Submission_Log’s Status column using the web tool. 

2. Terminate the process.

2. On receipt of a certification email:

1. Due to the nature of these data NO sensitive information is in the deliverable.

2. Copy the two submitted files to test environment at AUXREP\OC\OC_N\.

1. Name them <protocol_ID>.PDF and <protocol_ID>.DOCX.

3. Create web page link to the new PDF but not the .DOCX, which remains hidden.

4. Retire the old protocol so it becomes accessible from the Historical Protocol link.

5. Mark the certification in the Status column in Submission_Log using the web tool.

6. Propagate from test to production environment.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

108

7. Update the annual deliverable tracking spreadsheet showing date of completion for 

OC_I.

1. Record in the tracking spreadsheet for the year reflected in the protocol_ID, 

which may not be the current year.

2. An entirely new row will need to be added to the sheet, as this is not a scheduled 

deliverable already accounted for.

3. Submit the final document to NRInfo Portal.

4. Update the I&M protocol database to reference the new protocol.

5. Revise web sites to accommodate any altered information structure set in the new 

protocol.

6. Update the scope of the formal metadata so it includes the new date and 

versioning information.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

109

SOP 19: Managing the Production Environment

Version 1.0

Revision History Log:

Prev. 

Version #

Revision 

Date Author Changes Made Reason for Change New Version #

Oct. 

2010

S. Danielson, W.

Johnson, L. Sharman, G. 

Eckert, B. Moynahan

1.0

1.0 Summary

In order for most SEAN deliverables to be disseminated to the public, they must be installed in

the NPS production environment at I&M in Ft. Collins, Colorado. Certain of the deliverables 

must also be installed in production repositories, such as the NODC and the NPS Data Store. In 

order for this production content to be generated, various steps must be performed in SEAN’s 

staging environment. Once content is built and verified in the staging environment, it gets copied 

to production for permanent storage and dissemination.

Most of the detailed SOPs in this protocol end with a reference to propagating the final 

deliverable into production. This is an implicit reference to this SOP. Not all deliverables are 

handled in the exact same manner, so methods for installing them into production vary.

2.0 Schematic of the Environments

Figure SOP 19.1 illustrates the major components in the SEAN staging and WASO production 

environments. (References are also made to SEAN’s development and test environments. Details 

of their operation are not germane to moving deliverables from staging to production, and will 

not be discussed here.)

3.0 Components of the Environments

Major components of the staging environment include the Staging Directory, the Data 

Management Web Server, the Staging Database, and the Master Auxiliary Repository. The 

staging directory is a folder on SEAN’s local file server used to collect submitted productions 

and feed them into validation and certification processes. The data management web server is an 

internal-only website holding applications used to: validate some deliverables; create certain 

deliverables; report information used as the basis for other deliverables; and actively track the 

status of all deliverables in process. The staging database is a SQL database used to hold the 

OC_D product and the status tables. The master auxiliary repository is a set of folders and files 

housed on the local SEAN file server. It contains all certified deliverables except for OC_D,

which can only live on a database server.

The production environment consists of the Production Database, the Replica Auxiliary 

Repository, and the Production Web Server. The production database houses all final OC_D 

data. The replica auxiliary repository is a mirror of the staging auxiliary repository. (This is done 

because NPS security technicians do not permit the production environment to directly access 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

110

the staging auxiliary repository.) The production web server houses the public dissemination 

point. It draws content from the other two components.

Three additional production environments, which receive copies of certain items from the 

auxiliary repository, are AOOS, NODC, and the NPS Data Store. Delivering content to these 

repositories is SEAN’s only role and responsibility in their management. 

Figure SOP 19.1. Components of the staging and production environments are illustrated in schematic 

form. Coloring indicates the functional realm of each component, as defined in the SEAN data 

management plan. Rectangles depict the data management tasks required to move a product from one 

component to the next. Internal functions provided by the data management web server related to 

oceanography are also listed.

4.0 Management Tasks to Perform

Figure SOP 19.1 shows in rectangles specific tasks needed to move a deliverable from the 

submission-to-staging through the production-dissemination states. These are primarily data 

copying steps achieved either by file transfer or by SQL database synchronization. No attempt 

will be made to detail specific commands and IT processes to accomplish these particular tasks. 

They are inherently complex and are dependent on the current complement of equipment 

components, software versions, security policies, and NRPC operating procedures. Most of the 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

111

tasks are also performed on the order of only once per year. Data management staff is expected 

to determine the best method to use at each particular invocation.

The data management web site also supports a number of necessary tasks required in 

accomplishing the staging to production process. These are depicted in Figure SOP 19.1 as 

lozenges within the data management web server object. Their use is covered in the various 

SOPs covering detailed production of data deliverables.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

113

Appendix A. Oceanographic station locations.

A.1 Currently sampled stations

Core stations are highlighted in bold type.

Station Latitude 

(WGS84)

Longitude 

(WGS84) Description Nominal Depth (m)

00 58.326735 -135.875108 Icy Strait 53

01 58.412562 -135.99511 Mouth of Glacier Bay 62

02 58.490056 -136.05178 Sitakaday Narrows 93

03 58.571715 -136.065116 SE of Willoughby Island 112

04 58.650872 -136.115113 N of Drake I. and N of Marble I. 288

05 58.704199 -136.233473 Between N Drake and SW Tlingit PT 366

06 58.759193 -136.341762 E of Hugh Miller Inlet 288

07 58.8111687 -136.474331 N of Blue Mouse, W of Tidal Inlet 435

08 58.865018 -136.593433 S of Rendu Inlet 426

09 58.897515 -136.736769 SE of Russell Island 377

10 58.899179 -136.840103 N of Reid Inlet 361

11 58.972079 -136.916778 Tarr Inlet 338

12 59.033341 -137.018446 Head of Tarr Inlet 288

13 58.73253 -136.113453 SE of Tlingit PT, NW of Sturgess 146

14 58.79169 -136.108456 Muir Sill 81

16 58.895845 -136.093461 E of Hunter Cove 313

17 58.975001 -136.136797 E of Westdahl Pt 212

18 59.0500003 -136.18513 S of Riggs, NW of McBride 214

19 59.07168 -136.336789 Muir Inlet 225

20 59.086017 -136.370953 Head of Muir Inlet 179

21 59.047695 -137.057739 Marjorie/Grand Pacific 195

24 58.333333 -136.116667 North Passage 150
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

114

A.2 Historical stations not currently sampled

Station Latitude 

(WGS84)

Longitude 

(WGS84) Description Nominal Depth (m)

15 58.815021 -136.105123 W of Muir Pt. 116

22 58.657692 -136.36543 Entrance to Geikie 155

23 58.598125 -136.506455 Head of Geikie 66
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

115

Appendix B. Standard form templates.

Electronic copies of all templates are available at the following web site:

http://science.nature.nps.gov/im/units/sean/OC_Main.aspx.

B.1 Field Log Form
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

116

B.2 CTD Download Checklist

Cast 

# Starting record Ending record File name

Downloaded 



Visual 

Inspection 



o o

o o

o o

o o

o o

o o

o o

o o

o o

o o

o o

o o

o o

o o

File name is 18 characters of the form yymm_C_dddd_cc.HEX where:

 yy is year, mm is month, C is CTD#, dddd is dump#, cc is cast#

 (use leading zeroes where necessary to meet length requirements)

Oceanographic Survey CTD Download Checklist

Glacier Bay National Park and Preserve

Date: _________________ CTD #: ____ Data Dump # ________ 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

117

B.3 Data Quality Report

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

119

Appendix C. Oceanographic survey equipment list.

C.1 Research Vessel and support equipment

 R/V Capelin, Arete (Lewis) 

 Power Block/Davit (on boat)

 Hydraulics (on boat)

C.2 CTD sampling equipment

 SEACAT SBE 19-03 Conductivity-Temperature-Depth (CTD) Recorder 

 Ground line (marked every 10m) and plastic tub

 2 stainless steel locking carabineers (on CTD)

 CTD equipment box 

o Distilled water squirt bottle

o Triton –X* detergent and squirt bottle with diluted solution and MSDS

o Silicone Grease (Dow Corning 4 Electrical Insulating Compound)

o Rubbing Alcohol and Q-Tips (for cleaning conductivity cell and data cable pins)

o Lint-free cloth and lint-free papers (KimWipes)

o Data Cable, including RS232 to DB9 connector 

o Copy of protocol

o Spare pens and pencils

o Paper towels

o Spare Batteries

 9 D-cell batteries (per CTD)

 12 AA-cell batteries (4 per GPS, 8 per PLGR)

 Distilled Water (1gallon)

 Portable Computer 

 Empty USB flash memory drive for data backups

 Office Box (containing general office equipment)

 GPS unit and manual (Be sure to download station locations into GPS before use.)

 Extra power/antenna cables and external antennas

 Stopwatch with timer alarm

* Triton X-100 is non-ionic detergent, which is used as a 1% solution in distilled water. One 

source is VWR Scientific Products in Seattle, WA at 800-932-5000, or www.vwrsp.com.

C.3 Manuals and documentation

 Seacat SBE 19-03, SeaSave, SeaPlot and SBEDataProcessing operating manuals

 GPS operating manual

 Last CTD dump 

 Waterproof field notebook with blank Rite-in-the-rain or Duracopy paper 

 Oceanography notebook (contains protocol, station locations, maintenance info, etc.)

 CTD datasheets copied onto waterproof paper 

C.4 General field gear

 Rite-in-the-Rain waterproof or DuraCopy plastic paper
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

120

 Several black Ultra Fine Point Sharpie pens and/or pencils.

 Personal Flotation Devices (one per person on board)

 Immersion (survival) suits (one per person on board)

 Handheld (waterproof) radio with ParkNet frequencies and extra radio batteries

 Groceries – order beforehand 

 Rain gear

 Waterproof gloves (insulated ideal)

 Waterproof boots

 Binoculars

 Personal gear

 Topographical map and nautical charts of Glacier Bay

 Digital camera

C.5 Computer equipment and software

 On-board Windows Laptop with appropriate ports for connection to CTD

 SeaTerm.exe CTD data acquisition software

 WordPad, Notepad, or other text editor software

 Storage media for data backup (e.g., recordable compact disc; thumb drive)
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

121

Appendix D. List of acronyms.

Acronym Definition

AOOS Alaska Ocean Observing System

CTD Conductivity-temperature-depth instrument for recording oceanographic 

parameters

CO-OPS Center for Operational Oceanographic Products and Services

FGDC Federal Geographic Data Committee

GLBA Glacier Bay National Park and Preserve

GMT Greenwich mean time

GPS Global positioning system

NCAR National Center for Atmospheric Research 

NCEP National Center for Environmental Prediction

NOAA National Oceanic and Atmospheric Administration

NODC National Oceanographic Data Center

NOS National Ocean Service

NPS National Park Service

NRPC Natural Resource Program Center

OBS Optical backscatterance, a measure of turbidity

ODV Ocean Data View, visualization software

PAR Photosynthetically active radiation

QA Quality assurance

SEAN Southeast Alaska Network of NPS Inventory & Monitoring Division

SOP Standard operating procedure

USGS United States Geological Survey

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

123

Appendix E. Summary of 2009 protocol development working 

group discussion.

The following paragraphs summarize a February 2009 discussion of the SEAN oceanography 

monitoring program, held at the Glacier Bay Field Office at Indian Point in Juneau. We worked 

to incorporate results from prior monitoring program reviews (see section 8.2) and evaluations of 

our proposed modifications so that the selected program maintains coherence with past sampling 

and also forms the basis for the strongest possible sampling program from this point forward. 

The group tried to take the 10- to 100-year view: in ten years, this dataset will span a quarter 

century and the bulk of the holdings will still be from collections made prior to 2009. In 100 

years, however, collections made prior to 2009 will comprise fewer than 15% of the total 

observations. To gain maximum utility, we have strived for a balance between continuity 

between samples taken before and after 2009 and what we feel is the most useful dataset in the 

long run. 

A number of researchers with past and present interest in Glacier Bay oceanography (including 

Lisa Etherington, Mayumi Arimitsu, and David Hill) were sent this summary and solicited for 

feedback. Overall response to the recommended changes was positive, though we did make some 

adjustments to the protocol based on this feedback. Most important, one new station in North 

Passage was added for sampling with the full station set in July and mid-winter.

E.1 Proposed Modifications to the Glacier Bay Oceanographic Monitoring 

Protocol

The Southeast Alaska Network (SEAN) of the National Park Service (NPS) has committed to 

long-term continuation of oceanographic monitoring within Glacier Bay proper. NPS entered 

into a cooperative agreement with the University of Alaska Fairbanks (UAF) to review and 

update the GLBA monitoring protocol (Hooge et al. 2003), including program objectives, 

rationale, field methods, schedules for calibrating instruments and sensor replacement, data 

processing and archiving procedures, metadata and data formats, and recommended data 

summaries. The historical database contains 16 consecutive years of sampling (1993–2008), 

primarily carried out by United States Geological Survey (USGS) personnel. To date, sampling 

has resulted in a number of annual reports and peer-reviewed publications that provide 

considerable detail summarizing the various domains, their mean annual cycles, and the monthly

variability across and within domains. 

The 2006 Glacier Bay Oceanographic Program Evaluation Report (Etherington 2006) is based on 

a 2005 Glacier Bay Oceanographic Program Review Workshop attended by a number of NPS, 

USGS and NOAA personnel. The workshop attendees refined the objectives of the monitoring 

program as follows:

1) To provide a dataset on physical oceanographic conditions in Glacier Bay (salinity, 

temperature, stratification, photosynthetically available radiation (PAR), optical 

backscatterance (OBS, turbidity) that can be used to understand seasonal and interannual 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

124

changes in the estuarine dynamics of Glacier Bay as well as the Southeast Alaska oceanographic 

system.

2) To provide a baseline oceanographic dataset (salinity, temperature, stratification, 

photosynthetically available radiation (PAR), optical backscatterance (OBS, turbidity), and 

chlorophyll a fluorescence) that can be used by a variety of biologists to understand spatial and 

temporal variation in the abundance patterns of a variety of organisms. 

These objectives remain in place today. At the outset of the SEAN protocol development 

process, the initial NPS proposal was to continue with sampling historic CTD stations 

numbers 00-211 within GLBA on a quarterly basis (March, July, October and December).

On February 4, 2009, a focus group (Brendan Moynahan, Lewis Sharman, Bill Johnson, Yumi 

Arimitsu, Lisa Etherington (by phone), Ginny Eckert and Seth Danielson) discussed the 

background behind the present GLBA dataset, monitoring objectives, rationale, and ways we 

might modify the present sampling design to ensure the monitoring dataset best fulfills the 

objectives stated above and other anticipated needs of user groups. The group recognized the rare 

luxury of having adequate historical data to critically consider modifications. Much discussion 

revolved around the realization that the proposed quarterly sampling resolves annual cycles but 

not seasonal; in order to ensure the resolution of seasonal fluctuations, it is necessary to increase 

the temporal rate of sampling.

The group agreed that more frequent temporal sampling would be greatly beneficial, particularly 

during the spring, summer, and fall months when most other user groups are in GLBA and when 

both the physical and biological systems undergo their greatest annual changes. Applying results 

from Etherington et al. (2007), which summarized spatial/temporal variability patterns within 

GLBA and found that adjacent stations are highly correlated, we concluded that a reduced set of 

monitoring stations representative of the four primary domains (Lower Bay, Central Bay, West 

Arm, and East Arm) could reduce the number of days at sea from 3–4 days to 2 days per cruise, 

yet still capture the bulk of the oceanographic spatially-dependent signals. We discussed many 

alternatives that, though appealing, do not fit within the available budget (e.g., maintaining longterm oceanographic moorings). While a single station within each of the four primary domains 

would capture the majority of the spatial variability, the data set would be significantly improved 

by inclusion of stations near the head of each arm (i.e., in Tarr and Muir inlets) and at Station 13 

in the Central Bay (which USGS identified as exhibiting unique biophysical characteristics).

We therefore propose modifications to the present sampling scheme: 1) Occupy all standard 

CTD stations (#’s 00-21) once in July and once in mid-winter (December or January as 

conditions permit) and 2) occupy Stations 01, 04, 07, 12, 13, 16, and 20 on a monthly basis from 

March to June and August to October. This scheme resulted from lengthy discussion over the 

cost-benefit balance between spatial and temporal resolution and the number of ship days 

available per year. This effort ensures two samples in each domain except for the Lower Bay, 

where strong tidal currents lead to enhanced mixing and reduced gradients. Additional benefits 

from the proposed sampling scheme include 1) fewer consecutive days of good weather are 

 1 Under any sampling scheme, present stations 22 and 23 (both in Geikie Inlet), would be discontinued per 

recommendations of the 2006 oceanography program review. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

125

required to complete most months sampling and 2) this scheme will eventually lead to robust 

monthly climatologies for select stations in all major oceanographic domains in 9 calendar 

months and climatologies at all stations near the extremes of both summer and winter (July and 

December/January).

Sampling per the revised scheme would begin in April 2009. The draft protocol will be delivered 

to NPS on April 1, 2009. It will undergo internal and external peer review and will be finalized 

by May 1, 2009.

E.2 Literature Cited

Etherington, L. 2006. Program Evaluation Report, U.S. Geological Survey, Alaska Science 

Center, Anchorage, AK

Etherington, L., P. N. Hooge, E. Hooge, and D. Hill. 2007. Oceanography of Glacier Bay,

Alaska: implications for biological patterns in a glacial fjord estuary. Estuaries and Coasts 

30(6):927–944.

Hooge, P. N., E. R. Hooge, E. K. Solomon, C. L. Dezan, C. A. Dick, J. Mondragon, H. Rieden,

and L. Etherington. 2003. Fjord oceanography monitoring handbook: Glacier Bay, AK. U.S. 

Geological Survey, Alaska Science Center, Anchorage, AK.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

127

Appendix F. CTD instruments employed in program.

Deliverables associated with instrument calibration details are specific to each individual CTD. 

The filenames for these deliverables have a CTD# embedded in them. The following table 

identifies the individual physical device associated with each CTD#.

Table F.1. CTD instruments employed in the program.

CTD# Model Serial # Started 

Service

Ended 

Service

1 Sea-Bird SBE19-03 193353-0436 4/1994 -

2 Sea-Bird SBE19-03 194652-0775 7/1993 1/2005

3 Sea-Bird SBE 19-03 194690-0819 6/1999 7/2000

4 Sea-Bird SBE 25 43 5/1994 7/2000

5 Sea-Bird SBE19-plus V2 19P55083-6353 2/2010 -

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

129

Appendix G. Data file standard header.

The header strings, illustrated in Figure G.1, are required to be defined to the SeaTerm program 

on any computer used to download CTD data into HEX files. The strings must be one to one 

matches of the characters in the illustration. Mandatory validation of HEX and CNV files will 

always fail unless this exact header is defined.

This header is normally maintained on Windows computers in the file 

C:\WINDOWS\SeaTerm.ini .

Figure G.1. Required header prompts to be used with SeaTerm software.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

131

Appendix H. Typical computer directory structures

Operating this program requires using a field laptop, a networked park computer, and the SEAN 

auxiliary repository. The data are normally stored in standard structures.

1.0 Laptop used to capture shipboard data from CTD.

Responsible person: Project Leader.

Figure H.1. Standard directory structure for field laptops used in data capture.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

132

2.0 GLBA network file server used for building deliverables.

Responsible person: Project Leader.

Figure H.2. Standard directory structure for park network file server.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

133

3.0 SEAN auxiliary repository.

Responsible person: Data Manager.

Figure H.3. Standard directory structure for oceanography section of SEAN auxiliary repository.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

135

Appendix I. Sea-Bird software detailed configuration.

A software layout has been designed that supports the specific operations described in certain 

SOPs. An understanding of it may be helpful in troubleshooting processing exceptions.

Sea-Bird SeaTerm software must be available on the Project Leader’s laptop for uploading the 

CTD. Sea-Bird SBEDataProcessing-Win32 needs to be available on the park network in order to 

perform post-cruise QA as well as to create deliverable OC_C.

1.0 SeaTerm on the laptop

Sea-Bird software is provided on annual calibration CDs. It is also available as a download 

described at http://www.seabird.com/software/FTPsiteinfo.htm . The product to install is in the 

Seasoft-Win32 package. Installation is straightforward, but local administrator rights are 

required, so IT support may need to assist. The installation puts all software in C:\Program 

Files\Sea-Bird\ . Our laptop requires only SeaTerm software (NOT SeaTermV2 software). The 

additional software products that are installed will not be used on the laptop.

All data reside in C:\Oceanography. Each year is given its own directory. A CON directory holds 

the current calibration file. A HEX directory holds all the cast data downloaded from the CTD. 

This is illustrated in Appendix H.

2.0 SBEDataProcessing accessible on the park network

Sea-Bird software must be installed, as described above, where the Project Leader may use it 

when connected to the park network. It is possible to use the laptop, but this is not desirable since 

that could result in accidental storage of the data files on the laptop instead of on the secure, 

backed up network. If terminal server is employed by the Project Leader, the IT staff will need to 

do the installation. There are a number of programs in the SBEDataProcessing suite, all of which 

must be accessible.

The manual named SEASOFT-Win32: SBE Data Processing is also available on the same web 

site as the software. It explains the details of processing that are briefly outlined below.

Several additional files must be added to C:\Program Files\Sea-Bird\ to support the automation 

the SOPs rely on. The file names are illustrated in Figure I.1. Those names referencing HEX are 

used to support the regular QA described in SOP 7. Those referencing CNV are needed to 

generate OC_C in SOP 8 and OC_M in SOP 11. 

The following documentation references generic filenames such as “HEX_Plot_A.psa.” In 

actuality, files are CTD specific so they may accommodate unique sensor configurations among 

the various devices. They bear names like “#5_HEX_Plot_A.psa” for use with CTD #5 and 

“#1_HEX_Plot_A.psa” for use with CTD #1.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

136

Figure I.1. Layout of Sea-Bird software directory showing special files created to support SOPs 7, 8, and

11.

3.0 SOP 7 Raw data plot software

Hex_Plot.bat drives the process. A shortcut on the user’s desktop would be helpful, as this is 

performed after every cruise. It collects the year and calibration file name from the Project 

Leader’s input and then invokes the Sea-Bird processes.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

137

Figure I.2. “HEX_Plot.bat” - batch program that generates raw in-season quality assurance plots for a 

particular year.

The batch file then invokes synchronous operation of all the needed Sea-Bird software processes 

using the SBEBATCH.EXE program. The instructions for running the processes are in file 

Hex_Plot.txt. It does three tasks, one for each line in Figure I.3. First all HEX files are converted 

to basic CNV files and stored in a “temp” directory – as per specifications set in 

“HEX_to_CNV_for_plotting.psa”. Second, for each CNV file “temp”, the set of A parameters is 

plotted according to “HEX_Plot_A.psa”. Third, a profile plot is also generated showing the B 

parameters according to “HEX_Plot_B.psa”.. Two plots are required due to the large number of 

parameters recorded by the CTD. 

Figure I.3. File “Hex_Plot.txt” contains instructions for sequencing the data processing sub-processes to 

generate profile plots based on HEX files.

4.0 SOP 8 CNV file creation 

Once a year the Project Leader uses “CNV_Create.bat” (Figure I.4) to run this operation 

automatically. It may be performed repeatedly until the resulting deliverables are acceptable.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

138

Figure I.4. “CNV_Create.bat” file contents.

The batch file invokes synchronous operation of all the needed Sea-Bird software processes. The 

instructions performed are in file “CNV_Create.txt”, Figure I.5. Each task uses its own “.psa” 

file to specify options to use in certain processing steps.

Figure I.5. Sequence of processes to run in order to produce final CNV files as well as associated profile 

plots.

First the raw HEX files are pulled from folder ..\HEX_Raw\ and converted into basic CNV files, 

as adjusted by the named calibration file. This, and subsequent, CNV files are stored in the 

..\CNV_Processed\temp\ folder. The original filename has a “_c” suffixed to it to indicate the file 

was the result on data conversion.

Second the “_c” files are run through a filter to smooth the pressure, temperature, and 

conductivity readings. The resulting files are suffixed further with “_f” and written to the temp 

folder.

Next the “_f” files are aligned so that temperature and conductivity coincide with the pressure. 

These go into temp as “_a” files.

Then the “_a” files have conductivity cell thermal mass effects removed from the measured 

conductivity. The resulting temp files are suffixed “_m”.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

139

The “_m” files then have readings during pressure slowdowns and reversals (typically the result 

of ship heave) flagged as bad. The output is suffixed “_L”.

Using measured pressure, temperature, and conductivity, the “_L” files have calculated on them 

sigma-t, salt water depth, and salinity. The resulting files are marked “_d”.

Finally, the “_d” files have their values averaged into 1-meter bins. The final “_b” files are 

stored directly in ..\CNV_Processed\. They are NOT written to ..\CNV_Processed\temp\.

The “_b” files are the basis for the two sets of post-processing profile plots. Plots are stored in 

the ..\Plot\CNV\ folder. There is an A suffixed to the filename of the first profile plots, and B to 

the second set. A pair of plots is required for each cast due to the number of parameters 

measured by the CTD.

The final CNV files begin with a preamble that documents the particular data processing steps 

that were performed to generate the values in the file. Figure I.6 illustrates a typical preamble.

* Sea-Bird SBE19 Data File:

* FileName = C:\Oceanography\2009\Downloaded HEX file\0907_1_0184_03.hex

* Software Version 1.59

* Temperature SN = 0436

* Conductivity SN = 0436

* System UpLoad Time = Jul 16 2009 15:04:02

** Vessel:Sigma-t

** CTD#:1

** Dump#:0184

** Observer:Sharman

** Cast#:03

** Station:10

** Latitude:58.89903

** Longitude:-136.83978

** Date GMT:2009/07/16

** Time GMT:19:42

** Fathometer depth:361

** Cast target depth:330

** Moderate line angle.

* ds

* SEACAT PROFILER V2.1e SN 0436 07/16/09 23:02:22.158

* pressure sensor: serial no = 2852184, range = 870 psia, tc = -24

* clk = 32767.703 iop = 135 vmain = 9.9 vlith = 5.2

* ncasts = 6 samples = 9970 free = 11687 lwait = 0 msec

* sample rate = 1 scan every 0.5 seconds

* minimum raw conductivity frequency for pump turn on = 3000 hertz

* pump delay = 45 seconds

* battery cutoff = 7.2 volts

* number of voltages sampled = 4 

* S>

* dh

* cast 3 07/16 19:42:07 samples 5897 to 7557 stop = switch off

* S> 

# nquan = 12

# nvalues = 319 

# units = specified
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

140

# name 0 = wetStar: Fluorescence, Wetlab Wetstar [mg/m^3]

# name 1 = obs: OBS, Backscatterance (D & A) [NTU]

# name 2 = par: PAR/Irradiance, Biospherical/Licor

# name 3 = t090C: Temperature [ITS-90, deg C]

# name 4 = prSM: Pressure, Strain Gauge [db]

# name 5 = c0S/m: Conductivity [S/m]

# name 6 = sbeox0V: Oxygen Voltage, SBE 43

# name 7 = sigma-t00: Density [sigma-t, Kg/m^3 ]

# name 8 = sal00: Salinity [PSU]

# name 9 = depSM: Depth [salt water, m], lat = 58.5

# name 10 = sbeox0ML/L: Oxygen, SBE 43 [ml/l], WS = 2

# name 11 = flag: flag

# span 0 = 0.3639, 16.3122 

# span 1 = 13.7855, 23.6942 

# span 2 = 3.3050e-02, 1.5638e+02 

# span 3 = 3.7964, 7.0704 

# span 4 = 1.009, 322.248 

# span 5 = 1.597253, 3.115554 

# span 6 = 2.6009, 3.5767 

# span 7 = 11.4476, 24.9448 

# span 8 = 14.6693, 31.4214 

# span 9 = 1.000, 319.000 

# span 10 = 5.78148, 8.49310 

# span 11 = 0.0000e+00, 0.0000e+00 

# interval = meters: 1 

# start_time = Jul 16 2009 19:42:07

# bad_flag = -9.990e-29

# sensor 0 = Frequency 0 temperature, 0436, 03-Mar-09

# sensor 1 = Frequency 1 conductivity, 436, 03-Mar-09, cpcor = -9.5700e08

# sensor 2 = Extrnl Volt 0 irradiance (PAR), primary, 6011, 26-Feb-09

# sensor 3 = Extrnl Volt 1 backscatterance, primary, 1591, 08-Mar-09

# sensor 4 = Extrnl Volt 2 WET Labs, WETStar fluorometer, WS3S-0652P, 

10-Mar-09

# sensor 5 = Extrnl Volt 3 Oxygen, SBE, primary, 1628, 07-Apr-09p

# sensor 6 = Pressure Voltage, 195991, 27-Feb-09

# datcnv_date = Jan 13 2010 16:46:36, 7.18c

# datcnv_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\hex_raw\0907_1_0184

_03.hex 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CON_calibration\1_0

903.con

# datcnv_skipover = 180

# datcnv_ox_hysteresis_correction = yes

# filter_date = Jan 13 2010 16:50:23, 7.18c

# filter_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c.cnv

# filter_low_pass_tc_A = 0.500

# filter_low_pass_tc_B = 1.000

# filter_low_pass_A_vars = t090C c0S/m

# filter_low_pass_B_vars = prSM

# alignctd_date = Jan 13 2010 16:54:17, 7.18c

# alignctd_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c_f.cnv

# alignctd_adv = t090C 0.500, sbeox0V 5.500 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

141

# celltm_date = Jan 13 2010 16:58:41, 7.18c

# celltm_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c_f_a.cnv

# celltm_alpha = 0.0400, 0.0000

# celltm_tau = 8.0000, 0.0000

# celltm_temp_sensor_use_for_cond = primary, 

# loopedit_date = Jan 13 2010 17:03:11, 7.18c

# loopedit_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c_f_a_m.cnv

# loopedit_minVelocity = 0.100 

# loopedit_surfaceSoak: do not remove 

# loopedit_excl_bad_scans = yes

# Derive_date = Jan 13 2010 17:08:35, 7.18c

# Derive_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c_f_a_m_l.cnv 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\TEST\CON_calibration\1_0

436.con

# derive_time_window_docdt = seconds: 2

# derive_ox_tau_correction = yes

# binavg_date = Jan 13 2010 17:14:32, 7.18c

# binavg_in = 

\\nps\akrdfs\GLBA\Science\Data\Oceanography\Data\2009\CNV_Processed\temp\

0907_1_0184_03_c_f_a_m_l_d.cnv

# binavg_bintype = meters

# binavg_binsize = 1

# binavg_excl_bad_scans = yes

# binavg_skipover = 0

# binavg_surface_bin = yes, min = 0.200, max = 0.800, value = 0.000

# file_type = ascii

*END*

Figure I.6. Example of a documentary preamble stored at the head of all CNV files.

Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

143

Appendix J. Deliverable definitions

Deliverables are the data and information products that are validated, certified, archived, and 

disseminated through the Southeast Alaska Network. Scientific deliverables are typically built by 

the Project Leader and submitted to the Data Manager. A few technical deliverables, which are 

of an information-management rather than scientific nature, are built by the Data Manager. 

Regardless of the source, every deliverable is formally validated by the Data Manager and 

certified by the originator before it is made available.

In order to carry out these processes, it is necessary to define in full detail the content, nature, 

and domain of each deliverable. Complete definitions also support subsequent interpretation of 

the products by removing ambiguity.

Appendix J defines every deliverable supported by the SEAN oceanographic program. It follows 

policies set in the SEAN Data Management Plan (Johnson and Moynahan 2008: SOP 302 – Data 

Management Considerations in Protocol Development). Using that method, the top level 

description of a deliverable is explained using a single form named either A, B, C, or D. The 

specific form used for a particular deliverable depends on the nature of the deliverable’s 

contents. Deliverables of a tabular type are further defined with a form X, where the structure of 

the table is described. Each individual attribute (i.e., column, field) of a table is then defined in 

detail using a form Y. Using this set of six forms, all data and information involved in the SEAN 

oceanographic program (and other SEAN programs) are consistently, precisely, and fully 

defined.

Each deliverable is also documented with a data flow diagram. These explain exactly where 

underlying data come from, what processes are applied to them, where they are stored, and who 

is responsible for managing each of them.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

144

Contents

Page

J.1 OC_A: CON Calibration Files...............................................................................................146

J.2 OC_B: Raw HEX Files ..........................................................................................................148

J.3 OC_C: Processed CNV Files .................................................................................................152

J.4 OC_D: Cumulative Database .................................................................................................161

J.5 OC_E: AOOS Repository Submission...................................................................................179

J.6 OC_F: NODC Repository Submission...................................................................................183

J.7 OC_G: Calibration Certificate Images...................................................................................187

J.8 OC_H: Field Log Sheet Images .............................................................................................188

J.9 OC_I: Protocol .......................................................................................................................191

J.10 OC_J: Data Availability Matrix ...........................................................................................193

J.11 OC_K: Annual Report..........................................................................................................195

J.12 OC_L: Five-Year Report......................................................................................................197

J.13 OC_M: Data Quality Evaluation..........................................................................................199
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

145

Figures

Page

Figure J.1. Data flow required to generate deliverable OC_A – CON file. ...............................146

Figure J.2. Data flow required to generate deliverable OC_B – HEX files. ..............................148

Figure J.3. Data flow required to generate deliverable OC_C – CNV files. ..............................152

Figure J.4. Data flow required to generate deliverable OC_D – cumulative 

database........................................................................................................................................161

Figure J.5. Data flow required to generate deliverable OC_E – AOOS 

submission....................................................................................................................................179

Figure J.6. Data flow required to generate deliverable OC_F – NODC 

submission....................................................................................................................................183

Figure J.7. Data flow required to generate deliverable OC_G – calibration 

certificate images. ........................................................................................................................187

Figure J.8. Data flow required to generate deliverable OC_H – field log sheet 

images. .........................................................................................................................................189

Figure J.9. Data flow required to generate deliverable OC_I – protocol. ..................................191

Figure J.10. Data flow required to generate deliverable OC_J – data availability 

matrix. ..........................................................................................................................................193

Figure J.11. Data flow required to generate deliverable OC_K – annual report........................195

Figure J.12. Data flow required to generate deliverable OC_L – five-year report.....................197

Figure J.13. Data flow required to generate deliverable OC_M – data quality 

evaluation.....................................................................................................................................199
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

146

J.1 OC_A: CON Calibration Files

Purpose of deliverable: CTD sensors are periodically calibrated. The unit as a whole is 

generally calibrated annually, though special circumstances may cause individual sensors to be 

recalibrated and reported ad hoc. Calibration results in a report for each sensor that provides 

numeric factors used to adjust actual field readings to a standardized level. A full CTD 

calibration typically results in the vendor providing a CON computer file covering multiple 

sensors. When ad hoc calibration of just one particular sensor is performed, results are typically 

provided on paper. These paper factors must then be added to the latest CON file using 

proprietary software. The ultimate deliverable, a calibration file, is used by subsequent processes 

to normalize field data. Providing this deliverable allows customers to generate processed 

“CNV” data from raw readings, replicate our program results, and investigate new methods of 

processing raw CTD data.

Frequency produced: A new calibration file must be created after the result of any sensor 

recalibration is reported to the Project Leader. Note there are different process steps for handling 

a file provided for the CTD than there are for handling a paper report on an individual sensor.

Prerequisites: Validation cannot be performed until the corresponding OC_G calibration 

certificate images have been certified.

Data flow:

Figure J.1. Data flow required to generate deliverable OC_A – CON file.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

147

Deliverable definition forms:

Form C: Non-Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_A

Deliverable Title:

CON calibration files

File format:

CON

Associated software and version:

SBEDataProc.exe 7.18

Revision Date / protocol version:

08-17-2010 / OC-2010.1

Expected frequency:

1/ctd/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

CTD#+Year+Month

What purpose does this deliverable serve?

Documents the calibration parameters for all sensors on the CTD. Needed to convert raw HEX 

data into binned engineering-unit CNV data (using the SBEDataProc program).

Summary of content:

This file uses a proprietary format. Each type of sensor requires different kinds and numbers of 

calibration parameters. The file contains a section for each sensor, as identified by sensor serial 

number. Within each section are the particular parameters appropriate to that sensor. There is 

also a general CTD configuration section that defines such items as the number of channels 

installed. 

The file is named using the convention C_yymm.CON where C is the single-digit CTD 

identifier, yy are the last two digits of the highest calendar year in the file in which any sensor 

was calibrated, and mm are the two-digit month of the most recent sensor calibration in the file.

Mandatory validation criteria:

1. Must be able to be opened, updated, and resaved using the Config function of 

SBEDataproc.exe 7.18 or later.

2. Values must match those in corresponding OC_G images from the same time period.

Optional validation criteria:

 - None -

Deliverable ID of any other SEAN data products required to create this product:

OC_G CTD calibrations certificate images

Description and source of any outside data required to create this product:

Periodic calibration is managed by Sea-Bird Electronics, typically at the end of each season. They supply 

a new CON file after each service event. Some sensors may be revised during the season. In this case, 

documentation is provided to permit the Project Leader to update the latest CON file at the park.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

148

J.2 OC_B: Raw HEX Files

Purpose of deliverable: CTD devices collect sensor data in memory, grouped by cast. These 

raw “hex” data are downloaded from the CTD into ASCII files containing header information 

and hexadecimal representations of sensor voltages/frequencies taken at a preset time interval. 

Each cast is recorded in one and only one hex file. Typically, OC_B hex files are later processed 

into advanced products that are binned by depth with voltages converted to appropriate 

engineering units (see deliverable OC_C). However, the raw OC_B deliverables are made 

available to the community in order to support custom analyses that require raw sensor data.

Frequency produced: Hex data are produced for every cast, as delineated by the cycling of the 

CTD’s on/off switch. The data are unloaded into hex files at the end of each cruise day. Hex files 

are accumulated during the season. OC_B is created at the end of each season by packaging all 

component hex files into a single deliverable.

Prerequisites: Production of this deliverable is dependent on capturing the daily CTD data

stream into intermediate hex files throughout the season. The final deliverable, itself, is created 

post-season from the saved in-season data files.

Data flow:

Figure J.2. Data flow required to generate deliverable OC_B – HEX files.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

149

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_B

Deliverable Title:

Raw HEX files

File format:

ZIP

Associated software and 

version:

PKUNZIP, WINRAR, etc.

Revision Date / protocol 

version:

04-08-2009 / 2010.1

Expected frequency:

1 zip holding about 120 hex 

files/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

YEAR

What purpose does this deliverable serve?

Provides raw CTD “hex” data as the basis for customer analyses.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or files that 

provide information which may be represented in a grid format. Each relation listed must be 

fully defined in its own accompanying Form X.):

HEX_yyyy.ZIP is a zip archive of individual cast files named “yymm_C_dddd_cc.hex”, where 

yy is year of cast, mm is month of cast, C is local ctd number, dddd is dump number, and cc is 

cast number. Leading zeroes are used to make every filename exactly 18 characters. The cast 

files are treated as a relation for data management purposes.

Deliverable ID of any other SEAN data products required to create this product:

- None -

Description and source of any outside data required to create this product:

Individual cast data from CTD downloads. Field log sheets recording cast particulars. 

SeaTerm.ini program configuration file containing the header prompt definitions explained in 

Appendix G.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

150

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

yymm_C_dddd_cc.hex

Used by deliverable ID:

OC_B

Revision date / protocol 

version:

04-08-2009 / 2010.1

Type of relation:

Database table Data file

Estimated rows:

1,200

Primary key for this relation:

- none -

Purpose:

Oceanographic cast raw “hex” data downloaded from CTD.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. Each 

attribute must be defined in an accompanying Form Y.):

LINE

Mandatory validation criteria involving multiple attributes:

- none -

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

151

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

LINE

Used by deliverable ID:

OC_B

Revision date / protocol 

version:

04-08-2009 / 2010.1

Default report heading:

-noneRelation (from Form X):yymm_C_dddd_cc.hex

Purpose:

One proprietary data line from the CTD device during a cast.

Data type: varchar()

Maximum length 200

Required: no

Measurement units: n/a

Format: Character string

Foreign key to (relation+attribute): n/a

Case: Upper only

Mandatory validation rules for this attribute

(in order of application):

1. Null LINE is always valid.

2. LINE having first character of ‘*’ is 

always valid.

3. LINE must be composed of characters 

from the set {A-Z} + {0-9}. Lower case is 

not permitted.

4. Every LINE in the file, other than those 

beginning with ‘*”, must be exactly the 

same number of characters long. For 

example, all must be 24 characters in a 

particular file.

5. Within the relation as a whole, each of the 

following strings must be present in at 

least one LINE beginning ‘**’: ‘Vessel:’, 

‘CTD#:’, ‘Dump#:’, ‘Observer:’, ‘Cast#:’, 

‘Station:’, ‘Latitude:’, ‘Longitude:’, ‘Date 

GMT:’, ‘Time GMT:’, ‘Fathometer 

depth:’, ‘Cast target depth:’

Optional validation rules for this attribute: • Count the number of lines following the 

delimiter line ‘*END*’. This should match 

the number of samples determined by 

parsing the line beginning ‘* cast’ and 

locating starting and ending record 

number.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

152

J.3 OC_C: Processed CNV Files

Purpose of deliverable: CNV files show the recorded parameters for each cast in a manner 

useful for analysis. Each processed CNV is derived from a HEX file, but differs in three ways. 

First, the CNV data shows one row for every meter of depth; while HEX data typically show 

multiple rows for every meter, as HEX readings are taken at periodic times instead of periodic 

depths. Second, CNV values have been normalized using the calibration factors. Third, CNV 

values are in terms of engineering units instead of voltage/frequency levels.

Frequency produced: OC_C is created at the end of each season by generating a CNV file for 

each HEX file and then packaging all CNV files into a single deliverable.

Prerequisites: Production of this deliverable is dependent on having certified OC_A and OC_B 

products for the season.

Data flow:

Figure J.3. Data flow required to generate deliverable OC_C – CNV files.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

153

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_C

Deliverable Title:

Processed CNV files

File format:

ZIP

Associated software and 

version:

PKUNZIP, WINRAR, etc.

Revision Date / protocol 

version:

04-09-2009 / 2010.1

Expected frequency:

1 zip holding about 120 hex 

files/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

YEAR

What purpose does this deliverable serve?

Provides binned, calibrated CNV data for customer analyses.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or files that 

provide information which may be represented in a grid format. Each relation listed must be 

fully defined in its own accompanying Form X.):

CNV_yyyy.ZIP is a zip archive of individual cast files named “yymm_C_dddd_cc.cnv”, where 

yy is year of cast, mm is month of cast, C is local ctd number, dddd is dump number, and cc is 

cast number. Leading zeroes are used to make every filename exactly 18 characters. The CNV 

files are considered a relation for purposes of data management.

Deliverable ID of any other SEAN data products required to create this product:

1. OC_B HEX files for the year of interest.

2. The most recent OC_A CON file whose latest individual sensor calibrations fall before 

the earliest cast represented in the OC_B files. That is, say, if OC_B covers 1/15/2006 

through 9/22/2006 then the OC_A CON file to use must have no individual sensor 

calibration date exceeding 1/15/2006. The OC_A naming convention usually allows 

ascertaining the correct file to use at a glance.

Description and source of any outside data required to create this product:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

154

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

yymm_C_dddd_cc.cnv

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Type of relation:

Database table Data file

Estimated rows:

180

Primary key for this relation:

- none -

Purpose:

Oceanographic cast CNV data for customer analysis. The file consists of a preamble defining 

parameters involved in the cast such as station and dump number. This is followed by a second 

preamble that documents the processing performed to create this cast data. The final section is a 

grid of attributes with each row representing a meter in the downcast.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. Each 

attribute must be defined in an accompanying Form Y.):

PRESSURE FLUORESCENCE

DEPTH OBS

TEMPERATURE OXYGEN

CONDUCTIVITY PAR

SALINITY SBE_DATA_FLAG

SIGMA_T

Mandatory validation criteria involving multiple attributes:

Any record whose first character is either ‘*’ or ‘#’ is preamble data that is always valid, no 

validation of individual attributes applies to such rows.

Within the relation as a whole, each of the following strings must be present in at least one row 

beginning with the ‘*’ character:

‘Vessel:’, ‘CTD#:’, ‘Dump#:’, ‘Observer:’, ‘Cast#:’, ‘Station:’, ‘Latitude:’, ‘Longitude:’, 

‘Date GMT:’, ‘Time GMT:’, ‘Fathometer depth:’, ‘Cast target depth:’

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

155

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

PRESSURE

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Pressure (dbar)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Pressure in decibars.

Data type: real

Maximum length 8

Required: yes

Measurement units: Decibars

Format: 9999.9999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between -0.002 and 9999.9999

Optional validation rules for this attribute: Should be between 1 and 800

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DEPTH

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Depth (m)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Depth in meters.

Data type: integer

Maximum length 4

Required: yes

Measurement units: meters

Format: 9999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be an integer.

2. Must be between 0 and 9999.

3. Must be unique within a file.

Optional validation rules for this attribute: • Should be between 0 and 800.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

156

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

TEMPERATURE

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Temperature (C)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Temperature in Celsius.

Data type: real

Maximum length 6

Required: no

Measurement units: Degrees C

Format: 99.9999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between -5.0 and 20.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 0.0 and 20.0

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CONDUCTIVITY

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Conductivity (S/m)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Conductivity in Siemens per meter.

Data type: real

Maximum length 8

Required: no

Measurement units: Siemens/meter

Format: 9.999999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 10.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: Should be between 0.0 and 5.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

157

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SALINITY

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Salinity (PSU)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Salinity in practical salinity units.

Data type: real

Maximum length 6

Required: no

Measurement units: PSU

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 40.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 0.0 and 34.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SIGMA_T

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Density (kg/m3)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Density differential in kg/m3.

Data type: real

Maximum length 7

Required: no

Measurement units: kg/m3

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 30.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 15.0 and 27.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

158

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

FLUORESCENCE

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Fluorescence (mg/m**3)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Fluorescence.

Data type: real

Maximum length 6

Required: no

Measurement units: mg/m3

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 99.999.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 0.0 and 70.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

OBS

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Backscatterance (in NTU)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Turbidity detected by OBS backscatter sensor.

Data type: real

Maximum length 7

Required: no

Measurement units: NTU

Format: 999.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 800.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 0.0 and 500.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

159

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

OXYGEN

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Dissolved Oxygen (ml/l)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Dissolved oxygen content.

Data type: real

Maximum length 6

Required: no

Measurement units: ml/l

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 20.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 2.0 and 14.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

PAR

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

PAR (uE/m^2 * sec)

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Photosynthetically active radiation.

Data type: real

Maximum length 8

Required: no

Measurement units: μEinsteins/m2·sec

Format: 9999.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 3000.0.

3. Special allowed case of SBE error flag 

value: -9.990e-29.

Optional validation rules for this attribute: • Should be between 0.0 and 1600.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

160

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SBE_DATA_FLAG

Used by deliverable ID:

OC_C

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

DP Quality

Relation (from Form X):

yymm_C_dddd_cc.cnv

Purpose:

Indicates bins with suspect data due to pressure slowdown or reversal as drop progresses. Set 

appropriately by SBE data processing “loopedit” function. A non-zero value indicates suspect 

data, which will not be loaded into the OC_D database.

Data type: real

Maximum length 9

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

-noneOptional validation rules for this attribute:
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

161

J.4 OC_D: Cumulative Database

Purpose of deliverable: Working with large groups of OC_C processed CNV files can be 

cumbersome and difficult. An oceanography database is maintained that contains all the CNV 

values for all surveys done in the program. These rows may differ slightly from OC_C data in 

having data quality information, outlier corrections, etc. Through the web, the database may be 

queried to produce a single file on the customer’s workstation containing final data, filtered to 

meet the customer’s exact area of interest. Deliverable OC_D is an incremental update used to 

revise the cumulative database.

Frequency produced: OC_D is generated at the end of each season directly after certification 

of OC_C processed CNV files. It is created from OC_C’s intermediate validation files.

Prerequisites: Production of this deliverable is dependent on having a certified OC_C product 

for the year.

Data flow:

Figure J.4. Data flow required to generate deliverable OC_D – cumulative database.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

162

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_D

Deliverable Title:

Searchable database rows

File format:

n/a

Associated software and 

version:

n/a

Revision Date / protocol 

version:

04-10-2009 / 2010.1

Expected frequency:

1 submission/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

YEAR

What purpose does this deliverable serve?

Provides binned, calibrated CNV data filtered by parameters directly to customer workstations.

This is basically deliverable OC_C recast in a database structure. Sensor data in the source CNV 

file that have negative values (typically due to faulty sensor or SBE data error flag) are treated as 

NULL in the database.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or files that 

provide information which may be represented in a grid format. Each relation listed must be 

fully defined in its own accompanying Form X.):

tbl_oc_cast

Deliverable ID of any other SEAN data products required to create this product:

OC_C

Description and source of any outside data required to create this product:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

163

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

tbl_oc_cast

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Type of relation:

Database Table 

Estimated rows:

300,000+

Primary key for this relation:

ctd + dump + cast + depth

Purpose:

Oceanographic calibrated cast data binned to 1 meter levels and expressed in engineering units, 

to serve as a basis for customer analysis. The table appears totally denormalized to facilitate web 

downloading and direct use by Excel and MS Access.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. Each 

attribute must be defined in an accompanying Form Y.):

CTD CONDUCTIVITY

DUMP SALINITY

OBSERVER SIGMA_T

CAST FLUORESCENCE

VESSEL OBS

STATION OXYGEN

LATITUDE PAR

LOGITUDE SBE_DATA_FLAG

DATE_GMT COMMENTS

TIME_GMT DATA_QUALITY

FATHOMETER_DEPTH QUALITY_COMMENT

TARGET_DEPTH TIME_STAMP

PRESSURE PROTOCOL_ID

DEPTH USERID

TEMPERATURE SUBMISSION_NUMBER

CRUISE_YEAR

Mandatory validation criteria involving multiple attributes:

- none -

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

164

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CTD

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

CTD# 

Relation (from Form X):

tbl_oc_cast

Purpose:

Local identification of the CTD device. Initially, units 1 and 2 were defined.

Data type: Varchar(1)

Maximum length 1

Required: yes

Measurement units: n/a

Format: 9

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must be between 1 and 9.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DUMP

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

DUMP# 

Relation (from Form X):

tbl_oc_cast

Purpose:

The sequential number that is incremented each time any CTD memory is cleared. It tracks 

distinct uses of the CTD to gather a set of consecutive casts.

Data type: Varchar(4)

Maximum length 4

Required: yes

Measurement units: n/a

Format: 0000

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent a whole number, zero 

filled.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

165

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

OBSERVER

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

OBSERVER

Relation (from Form X):

tbl_oc_cast

Purpose:

The last names of those making the cast.

Data type: Varchar(50)

Maximum length 50

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: any

Mandatory validation rules for this attribute (in 

order of application):

- none -

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CAST

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Cast# 

Relation (from Form X):

tbl_oc_cast

Purpose:

Sequential cast number within a particular dump. Casts are integers beginning with zero. They 

are generated by the CTDs themselves. Because of memory limits in existing equipment, it is 

rare CAST will ever exceed 15.

Cast is part of the primary key, making its representation critical. If its value is below 10, it must 

be stored only as two digits, employing a leading zero if needed..

Data type: Varchar(2)

Maximum length 2

Required: yes

Measurement units: n/a

Format: n0

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent an integer between 0 

and 99.

Optional validation rules for this attribute: • should be between 0 and 15
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

166

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

VESSEL

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Vessel 

Relation (from Form X):

tbl_oc_cast

Purpose:

Name of the vessel used to conduct the survey.

Data type: Varchar(24)

Maximum length 24

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: Proper

Mandatory validation rules for this attribute (in 

order of application):

- none -

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

STATION

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Station 

Relation (from Form X):

tbl_oc_cast

Purpose:

Identification number for a unique sampling location. Over time station numbers may be retired. 

The numbers are never recycled. Stations are always exactly two digits in length, using a leading 

zero if needed to meet that constraint.

Data type: Varchar(2)

Maximum length 2

Required: yes

Measurement units: n/a

Format: 00

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent a zero-filled integer 

between 00 and 24.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

167

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

LATITUDE

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Latitude 

Relation (from Form X):

tbl_oc_cast

Purpose:

Decimal latitude in WGS84 datum.

Data type: real

Maximum length 8

Required: no

Measurement units: degrees

Format: 99.99999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must be a real number.

2. Must be between 58.0 and 61.0.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

LONGITUDE

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Longitude 

Relation (from Form X):

tbl_oc_cast

Purpose:

Decimal longitude using the WGS84 datum.

Data type: real

Maximum length 10

Required: no

Measurement units: n/a

Format: -999.99999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must be a real number.

2. Must be between -135.0 and -142.0.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

168

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DATE_GMT

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Date

Relation (from Form X):

tbl_oc_cast

Purpose:

Date the cast was taken; in the GMT time zone.

Data type: date

Maximum length n/a

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must be a valid a date.

2. Must not be a date beyond the current 

one at point of validation.

3. Must not be a date before 1992.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

TIME_GMT

Used by deliverable ID:

OC_D

Revision date / protocol version:

04-10-2009 / 2010.1

Default report heading:

Time 

Relation (from Form X):

tbl_oc_cast

Purpose:

Time cast was initiated, in Greenwich Mean Time.

Data type: time

Maximum length n/a

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must resolve to a valid time.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

169

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

FATHOMETER_DEPTH

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Bottom (m)

Relation (from Form X):

tbl_oc_cast

Purpose:

Depth to the sea floor of this station in meters, expressed as a positive integer.

Data type: integer

Maximum length 4

Required: no

Measurement units: meters

Format: 9999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be an integer between 0 and 9999.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

PRESSURE

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Pressure (dbar)

Relation (from Form X):

tbl_oc_cast

Purpose:

Pressure in decibars.

Data type: real

Maximum length 8

Required: no

Measurement units: Decibars

Format: 9999.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 1 and 9999.999.

Optional validation rules for this attribute: Should be between 1 and 800
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

170

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DEPTH

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

05-12-2010 / 2010.1

Default report heading:

Depth (m)

Relation (from Form X):

tbl_oc_cast

Purpose:

Depth of this bin in meters, expressed as a positive integer. The first bin is labeled as meter zero. 

NOTE: sampling mechanics sometimes prevents the first meter (or more) from being recorded. 

In such cases the missing surface bins are imputed by replicating the readings of the first valid 

bin up through bin 0 (provided there is a valid bin within 4 meters of the surface). A comment 

explaining this is included on every imputed row. If no valid bin is present for a cast within the 

first 4 meters, no rows are generated and the missing bins in OC_C remain missing in OC_D.

Data type: integer

Maximum length 4

Required: yes

Measurement units: meters

Format: 9999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be an integer.

2. Must be between 0 and 9999.

Optional validation rules for this attribute: • Should be less than 800.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

TEMPERATURE

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Temperature (C)

Relation (from Form X):

tbl_oc_cast

Purpose:

Water temperature in degrees Celsius.

Data type: Real

Maximum length 6

Required: no

Measurement units: Degrees C

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between -5.0 and 20.0.

Optional validation rules for this attribute: • Should be between 0.0 and 20.0
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

171

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CONDUCTIVITY

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Conductivity (S/m)

Relation (from Form X):

tbl_oc_cast

Purpose:

Conductivity in Siemens per meter.

Data type: real

Maximum length 8

Required: no

Measurement units: Siemens/meter

Format: 9.999999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 10.0. 

Optional validation rules for this attribute: Should be between 0.0 and 5.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SALINITY

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Salinity (PSU)

Relation (from Form X):

tbl_oc_cast

Purpose:

Salinity in practical salinity units.

Data type: real

Maximum length 6

Required: no

Measurement units: PSU

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 40.0.

Optional validation rules for this attribute: • Should be between 0.0 and 34.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

172

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SIGMA_T

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Density (kg/m3)

Relation (from Form X):

tbl_oc_cast

Purpose:

Density differential in kg/m3.

Data type: real

Maximum length 7

Required: no

Measurement units: kg/m3

Format: nn.nnn

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 30.0

Optional validation rules for this attribute: • Should be between 15.0 and 27.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

FLUORESCENCE

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Fluorescence (mg/m3)

Relation (from Form X):

tbl_oc_cast

Purpose:

Fluorescence. Negative values may be recorded when sensor is disconnected.

Data type: real

Maximum length 6

Required: no

Measurement units: mg/m3

Format: 99.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must not exceed 100.0.

Optional validation rules for this attribute: • Should be between 0.0 and 70.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

173

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

OBS

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Backscatterance (NTU)

Relation (from Form X):

tbl_oc_cast

Purpose:

Turbidity detected by OBS backscatter sensor.

Data type: real

Maximum length 7

Required: no

Measurement units: NTU

Format: 999.999

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 800.0.

Optional validation rules for this attribute: • Should be between 0.0 and 500.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

OXYGEN

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

Dissolved Oxygen (ml/l)

Relation (from Form X):

tbl_oc_cast

Purpose:

Dissolved oxygen content. Negative values may appear when CTD is used without the DO 

sensor connected.

Data type: real

Maximum length 6

Required: no

Measurement units: ml/l

Format: nn.nnn

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must not exceed 20.0.

Optional validation rules for this attribute: • Should be between 2.0 and 14.0.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

174

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

PAR

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-09-2009 / 2010.1

Default report heading:

PAR (uE/m^2 * sec)

Relation (from Form X):

tbl_oc_cast

Purpose:

Photosynthetically active radiation.

Data type: real

Maximum length 8

Required: no

Measurement units: μEinsteins/m2·sec

Format: nnnn.nnn

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must be a real number.

2. Must be between 0.0 and 3000.0.

Optional validation rules for this attribute: • Should be between 0.0 and 1600.0.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SBE_DATA_FLAG

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

DP Error Flag

Relation (from Form X):

tbl_oc_cast

Purpose:

Indicates bins with suspect data due to pressure slowdown or reversal as the cast progresses. A 

non-zero value indicates suspect data.

Data type: real

Maximum length 9

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

- none -

Optional validation rules for this attribute:
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

175

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

COMMENTS

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Comments

Relation (from Form X):

tbl_oc_cast

Purpose:

Recorded comments regarding circumstances of this particular cast.

Data type: Varchar(512)

Maximum length 512

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

- none -

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DATA_QUALITY

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Data Quality

Relation (from Form X):

tbl_oc_cast

Purpose:

Indicator of the quality of the observation, for determining whether to include it in analyses. The 

Ocean Data View coding system is observed. This is not recorded in the database during OC_D 

processing. Instead, it is entered upon subsequent certification of deliverable OC_M: Data 

Quality.

Data type: Varchar(1)

Maximum length 1

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): tbl_data_quality

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. If present, must match 0, 1, 4, or 8.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

176

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DATA_QUALITY_COMMENT

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

05-12-2009 / 2010.1

Default report heading:

Quality Comment

Relation (from Form X):

tbl_oc_cast

Purpose:

Explanation of why data quality was not considered “good.” Source is certified OC_M 

spreadsheet for a particular year.

Data type: Varchar(512)

Maximum length 512

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

- none -

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

TIME_STAMP

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Last Updated

Relation (from Form X):

tbl_oc_cast

Purpose:

The date and time this row was most recently inserted or updated in the table. It is used for 

auditing purposes.

Data type: datetime

Maximum length n/a

Required: yes

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

- none -

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

177

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

PROTOCOL_ID

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Protocol

Relation (from Form X):

tbl_oc_cast

Purpose:

The formal version of the protocol under which this row was created.

Data type: Varchar(10)

Maximum length 10

Required: yes

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): Tbl_protocol

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must match a protocol in tbl_protocol.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

USERID

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Updated by

Relation (from Form X):

tbl_oc_cast

Purpose:

The login name used to authorize the process that created/updated this row in the cumulative 

database. It is restricted to those userids stored in the database table called tbl_submitter. It is 

used for auditing purposes.

Data type: Varchar(20)

Maximum length 20

Required: yes

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): tbl_submitter

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must match a protocol in tbl_submitter.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

178

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

SUBMISSION_NUMBER

Used by deliverable ID:

OC_D

Revision date / protocol 

version:

04-10-2009 / 2010.1

Default report heading:

Submission#

Relation (from Form X):

tbl_oc_cast

Purpose:

The submission number used to transmit to the network the files from which this particular row 

came. It is used for several data management purposes, including auditing.

Data type: int

Maximum length n/a

Required: yes

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): tbl_submission_log

Case: n/a

Mandatory validation rules for this attribute

(in order of application):

1. Must match a submission_number in 

tbl_submission_number.

Optional validation rules for this attribute: - none -

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CRUISE_YEAR

Used by deliverable ID:

OC_D

Revision date / protocol version:

12-30-2009 / 2010.1

Default report heading:

Cruise Year 

Relation (from Form X):

tbl_oc_cast

Purpose:

Cruises are aggregated by year defined as the period December through November. For example, 

casts made in December 2008 and those from April 2009 are all in cruise year 2009. Casts made 

in October 2008 are in cruise year 2008. Cruise year is derived from DATE_GMT.

Data type: Varchar(4)

Maximum length 4

Required: yes

Measurement units: n/a

Format: 0000

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent an integer between 

1993 and the current year.

Optional validation rules for this attribute: - none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

179

J.5 OC_E: AOOS Repository Submission

Purpose of deliverable: Copies of final certified detailed data are delivered to the Alaska 

Ocean Observing System (AOOS) for further dissemination. Their web system offers useful 

analysis tools and serves an established audience. 

Frequency produced: This is generally created once per field season. In the event incorrect 

data appear in the AOOS system, OC_E may be recreated to make it whole.

Prerequisites: Production of this deliverable is built using the certified OC_D database for a 

particular year.

Data flow:

Figure J.5. Data flow required to generate deliverable OC_E – AOOS submission.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

180

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_E

Deliverable Title:

AOOS submission

File format:

CSV for data

XML for metadata

Associated software and version:

Custom for data

Metavist 5.0 for metadata

Revision Date / 

protocol version:

05-04-2009 / 2010.1

Expected frequency:

Once per year

Likely dissemination partners:

AOOS

Submission unit:

YEAR

What purpose does this deliverable serve?

Populates secondary repository.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or 

files that provide information which may be represented in a grid format. Each 

relation listed must be fully defined in its own accompanying Form X.):

AOOS_yyyy.CSV where ‘yyyy’ is the four-digit year represented.

Deliverable ID of any other SEAN data products required to create this product:

OC_D

Description and source of any outside data required to create this product:

Format rules must be supplied by AOOS as a basis for generating the CSV.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

181

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

AOOS_yyyy.CSV

Used by deliverable ID:

OC_E

Revision date / protocol version:

05-04-2009 / 2010.1

Type of relation:

Windows file

Estimated rows:

20,000

Primary key for this relation:

- none -

Purpose:

Oceanographic calibrated cast data binned to 1 meter buckets, expressed in engineering 

units.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. 

Each attribute must be defined in an accompanying Form Y.):

CTD TEMPERATURE

DUMP CONDUCTIVITY

CAST SALINITY

VESSEL SIGMA_T

STATION FLUORESCENCE

LATITUDE OBS

LOGITUDE OXYGEN

DATE_GMT PAR

TIME_GMT SBE_DATA_FLAG

FATHOMETER_DEPTH COMMENTS

PRESSURE DATA_QUALITY

DEPTH PROTOCOL_ID

CRUISE_YEAR

Mandatory validation criteria involving multiple attributes:

- none -

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

182

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier: Used by deliverable ID:

OC_E

Revision date / protocol version:

2010.1

Default report heading: Relation (from Form X):

AOOS_yyyy.CSV

Purpose:

All attributes used for OC_E are copies of those with the same name from OC_D. Refer to the 

definition of deliverable OC_D for details.

Data type:

Maximum length

Required:

Measurement units:

Format:

Foreign key to (relation+attribute):

Case:

Mandatory validation rules for this attribute (in 

order of application):

Optional validation rules for this attribute:
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

183

J.6 OC_F: NODC Repository Submission

Purpose of deliverable: Copies of final certified detailed data are delivered to the National 

Oceanographic Data Center (NODC) for further dissemination. This repository is accessed by 

the worldwide research community to obtain detailed data. Its excellent archive also serves as 

backup in case SEAN experiences a disaster.

Frequency produced: This is generally created once per field season. In the event incorrect 

data appear in the NODC system, OC_F may be recreated to make it whole.

Prerequisites: Production of this deliverable is built using the certified OC_D database for a 

particular year.

Data flow:

Figure J.6. Data flow required to generate deliverable OC_F – NODC submission.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

184

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_F

Deliverable Title:

NODC submission

File format:

CSV for data

XML for metadata

Associated software and version:

Custom for data

Metavist 5.0 for metadata

Revision Date / 

protocol version:

05-04-2009 / 2010.1

Expected frequency:

Once per year

Likely dissemination partners:

NODC/NOAA

Submission unit:

YEAR

What purpose does this deliverable serve?

Populates secondary repository.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or 

files that provide information which may be represented in a grid format. Each 

relation listed must be fully defined in its own accompanying Form X.):

NODC_yyyy.CSV where ‘yyyy’ is the four-digit year represented.

Deliverable ID of any other SEAN data products required to create this product:

OC_D

Description and source of any outside data required to create this product:

Format rules must be negotiated developed in consultation with NODC as a basis for 

generating the CSV.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

185

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

NODC_yyyy.CSV

Used by deliverable ID:

OC_F

Revision date / protocol version:

05-04-2009 / 2010.1

Type of relation:

Windows file

Estimated rows:

20,000

Primary key for this relation:

- none -

Purpose:

Oceanographic calibrated cast data binned to 1 meter buckets, expressed in engineering 

units.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. 

Each attribute must be defined in an accompanying Form Y.):

CTD TEMPERATURE

DUMP CONDUCTIVITY

CAST SALINITY

VESSEL SIGMA_T

STATION FLUORESCENCE

LATITUDE OBS

LOGITUDE OXYGEN

DATE_GMT PAR

TIME_GMT SBE_DATA_FLAG

FATHOMETER_DEPTH COMMENTS

PRESSURE DATA_QUALITY

DEPTH PROTOCOL_ID

CRUISE_YEAR

Mandatory validation criteria involving multiple attributes:

- none -

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

186

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier: Used by deliverable ID:

OC_F

Revision date / protocol version:

2010.1

Default report heading: Relation (from Form X):

NODC_yyyy.CSV

Purpose:

All attributes used for OC_F are copies of those with the same name from OC_D. Refer to the 

definition of deliverable OC_D for details.

Data type:

Maximum length

Required:

Measurement units:

Format:

Foreign key to (relation+attribute):

Case:

Mandatory validation rules for this attribute (in 

order of application):

Optional validation rules for this attribute:
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

187

J.7 OC_G: Calibration Certificate Images

Purpose of deliverable: CTD sensors are periodically calibrated. The whole unit is generally 

calibrated annually, though special circumstances may cause individual sensors to be recalibrated 

and reported ad hoc. When a unit is returned to the Project Leader from calibration, it is 

accompanied by certificates specifying the latest calibration parameter values and attesting to 

their accuracy. Researchers need to find these in order to verify accurate calibration figures have 

been properly applied to other oceanographic data products.

Frequency produced: Whenever the result of any sensor recalibration is reported to the Project 

Leader. Certificates may be provided as paper forms, which must be scanned into PDFs. They 

may also be supplied as PDF files on CD, which may be used directly.

Prerequisites: None.

Data flow:

Figure J.7. Data flow required to generate deliverable OC_G – calibration certificate images.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

188

Deliverable definition forms:

Form C: Non-Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_G

Deliverable Title:

Calibration certificate images

File format:

PDF

Associated software and version:

Adobe Acrobat 9 pro

Revision Date / protocol version:

04-07-2009 / OC-2010.1

Expected frequency:

5/ctd/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

CTD# + Sensor s/n + Year + 

Month

What purpose does this deliverable serve?

Documents the calibration parameters for all sensors on the CTD. Needed to validate revisions to 

OC_A calibration CON files.

Summary of content:

Scanned images of calibration certificates saved as PDFs. Certificates are provided by CTD and 

sensor vendors after periodic recalibration and after obtaining new sensors. 

Mandatory validation criteria:

1. Must successfully open using Adobe Reader 7.0 or greater.

2. Filename must conform to submission unit pattern described in detailed steps in SOP 2

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products required to create this product:

- None -

Description and source of any outside data required to create this product:

Paper and/or PDF calibration certificates from manufacturers.

J.8 OC_H: Field Log Sheet Images

Purpose of deliverable: These are scanned images of the original sampling log sheets used to 

record the header information for each cast of a cruise. They are made available to allow 

discovery and correction of erroneous header information in OC_B hex files. Notes on the 

images may also be viewed to explain exceptional data encountered in other products derived 

from OC_B. Both front and back of each form are recorded, unless completely blank.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

189

Frequency produced: These should be created annually, typically after completion of the field 

season.

Prerequisites: Availability of the complete set of log sheets for the survey year. 

Data flow:

Figure J.8. Data flow required to generate deliverable OC_H – field log sheet images.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

190

Deliverable definition forms:

Form C: Non-Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_H

Deliverable Title:

Log sheet images

File format:

PDF

Associated software and version:

Adobe Acrobat 9 pro

Revision Date / protocol version:

04-07-2009 / OC-2010.1

Expected frequency:

20/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

Year

What purpose does this deliverable serve?

Source documents may be used for researching data errors and individual exceptions.

Summary of content:

Scanned images of field log sheets. 

Mandatory validation criteria:

1. Must successfully open using Adobe Reader 7.0 or greater.

2. Filename must conform to submission unit pattern described in detailed steps.

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products required to create this product

- None -

Description and source of any outside data required to create this product:

Paper log sheets from field crews.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

191

J.9 OC_I: Protocol

Purpose of deliverable: The protocol document defines in detail the technical methodology 

employed in the SEAN oceanography program.

Frequency produced: Created as needed, using the processes in SOP 18.

Prerequisites: Protocol deliverables are always created from the most-recent DOCX form of the 

latest OC_I protocol document. 

Data flow:

Figure J.9. Data flow required to generate deliverable OC_I – protocol.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

192

Deliverable definition forms:

Form A: Non-Tabular Information Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_I

Deliverable Title:

Protocol

File format:

DOCX and PDF

Associated software and version:

Word 2007 + Adobe Acrobat 9 pro

Revision Date / protocol version:

05-12-2009 / OC-2010.1

Expected frequency:

unknown

Likely dissemination partners:

None – served by SEAN

Submission unit:

Single unit to supplant the 

existing OC_I.

What purpose does this deliverable serve?

Defines the technical methodology employed in the SEAN oceanography program.

Summary of content:

Narrative, detailed appendices, standard operating procedures for conducting program. A PDF 

copy is kept for dissemination purposes. A DOCX copy is kept as the basis for the next version 

update.

Mandatory validation criteria:

1. PDF must successfully open using Adobe Reader 7.0 or greater.

2. DOCX must successfully open using Microsoft Word 2007.

3. Must consistently reference a correct version number, as defined in SEAN Data 

Management Plan (Johnson and Moynahan 2008: SOP 602 – Version Control).

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products required to create this product

Prior OC_I.

Description and source of any outside data required to create this product:

No specific sources can be named in advance. Editors will have to draw on a number of areas 

of technical expertise and guidance to complete this deliverable. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

193

J.10 OC_J: Data Availability Matrix

Purpose of deliverable: Researchers need to be informed of the availability of specific data by 

month and year. Specific data collected varies depending on factors such as the type of detectors 

installed at the time, weather conditions, and field circumstances. The availability depicted here 

is derived from the presence of time and type entries existing in the database based in deliverable 

OC_D cumulative database. “Type” granularity refers to the type of physical parameter 

measured: temperature, PAR, etc. If the data management procedures are strictly observed, then 

the matrix will inherently reflect availability of OC_D’s precursors: OC_A, OC_B, OC_C, and 

OC_G. 

Frequency produced: This must always be performed directly after completing a deliverable 

OC_D cumulative database, which is normally done annually. The actual deliverable 

disseminated for OC_J is a PDF file. However, an Excel spreadsheet is also part of this 

deliverable, though not served on the web site. The spreadsheet serves as the source for the PDF 

and the basis for the next update.

Prerequisites: OC_D cumulative database.

Data flow:

Figure J.10. Data flow required to generate deliverable OC_J – data availability matrix.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

194

Deliverable definition forms:

Form A: Non-Tabular Information Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_J

Deliverable Title:

Data availability matrix

File format:

.XLS and .PDF

Associated software and version:

Excel 2008 and Adobe Acrobat 9

Revision Date / protocol version:

10-19-2009 / 2010.1

Expected frequency:

1/year

Likely dissemination partners

None – served by SEAN

Submission unit:

None: does not get merged into a 

time series

What purpose does this deliverable serve?

Explains to customers the availability of time and type entries existing in deliverable OC_D and 

its precursors. “Time” granularity is year/month. “Type” granularity refers to the kind of 

physical parameter measured: temperature, PAR, etc.

Summary of content:

A PDF rendering of an Excel spreadsheet similar in form and content to the following:

Mandatory validation criteria:

 1. Spreadsheet must be able to be opened with full functionality using Microsoft Excel 2008 or 

more recent version.

 2. PDF must be able to be opened and properly rendered under Adobe Reader 9.

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products prerequisite to this product:

OC_D database update.

Description and source of any outside data required to create this product:

- None -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

195

J.11 OC_K: Annual Report

Purpose of deliverable: This is a report that summarizes the operations and outcomes of a 

season. Content includes station coverage, tables and plots illustrating current conditions, 

operation exceptions, and notification of any changes to the protocol. The content is appropriate 

for its audience of management as well as the public.

Frequency produced: These are typically created annually, after completion of each field 

season.

Prerequisites: Certified database deliverable OC_D for the season. Certified data quality 

evaluation OC_M for the season. The OC_M data quality evaluation is typically not available 

until after the CTD returns from annual factory calibration with new calibration factors.

Data flow:

Figure J.11. Data flow required to generate deliverable OC_K – annual report.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

196

Deliverable definition forms:

Form A: Non-Tabular Information Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_K

Deliverable Title:

Annual report

File format:

PDF

Associated software and version:

Adobe Acrobat 9 pro

Revision Date / protocol version:

04-17-2009 / OC-2010.1

Expected frequency:

1/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

Year

What purpose does this deliverable serve?

Summarizes the operations and outcomes of a season to inform managers and the public as well 

as professional oceanographers.

Summary of content:

Synopsis of operations, temporal/spatial coverage for this season, representative data tables, 

representative vertical profile plots, representative data visualizations, discussion summarizing 

observations. 

Mandatory validation criteria:

1. Must successfully open using Adobe Reader 7.0 or greater.

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products required to create this product

OC_D CNV database rows. OC_M data quality evaluation.

Description and source of any outside data required to create this product:

- None -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

197

J.12 OC_L: Five-Year Report

Purpose of deliverable: This report discusses trends that are evident from the historic data 

series. It does not cover operations, which is done in the annual report. The content is appropriate 

for an audience of management and the public, as well as scientists.

Frequency produced: These are created every five years, typically sometime after completion of the 

OC_K annual report for the most recent season.

Prerequisites: Certified database deliverable OC_D cumulative database for all seasons in the scope. 

Certified data quality report OC_M for all seasons in the scope. 

Data flow:

Figure J.12. Data flow required to generate deliverable OC_L – five-year report.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

198

Deliverable definition forms:

Form A: Non-Tabular Information Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_L

Deliverable Title:

Five-year report

File format:

PDF

Associated software and version:

Adobe Acrobat 9 pro

Revision Date / protocol version:

04-17-2009 / OC-2010.1

Expected frequency:

1 every 5 years

Likely dissemination partners:

None – served by SEAN

Submission unit:

5-year contiguous set of survey 

years

What purpose does this deliverable serve?

Analysis of physical oceanographic trends for each station is provided to inform customers and 

facilitate decision making. Time series analysis for evaluating cyclic phenomena is also 

presented.

Summary of content:

Introduction, methods, coverage, results, and discussion. 

Mandatory validation criteria:

1. Must successfully open using Adobe Reader 7.0 or greater.

Optional validation criteria:

- None -

Deliverable ID of any other SEAN data products required to create this product

OC_D CNV database rows and OC_M data quality evaluation for the years covered must be 

certified before this report may be composed.

Description and source of any outside data required to create this product:

Oceanographic time series useful for comparison include GAK1, Line P and Ocean Station 

PAPA, Canadian “lighthouse, and National Data Buoy Center moorings and coastal stations. 

Cross correlation analysis uses climate data from NCDC and NDBC, streamflow from USGS, 

and large-scale climate system indices such as those available from http://jisao.washington.edu

and http://www.cgd.ucar.edu/cas/catalog/climind. 
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

199

J.13 OC_M: Data Quality Evaluation

Purpose of deliverable: This form identifies the quality of data taken during each cast of the 

season. Once certified it is not disseminated as a stand-alone data product. Instead, the values in 

OC_M are applied to columns in the cumulative database originally populated by OC_D.

Frequency produced: OC_M may be created piecemeal in-season with one spreadsheet per 

CTD + Dump. However, due to prerequisite scheduling, OC_M is submitted and certified once 

per year.

Prerequisites: Certified database deliverable OC_D cumulative database, original AND postseason calibration reports OC_G, quality-assurance plots generated for both HEX and CNV files 

by Project Leader (not a deliverable). 

Data flow:

Figure J.13. Data flow required to generate deliverable OC_M – data quality evaluation.
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

200

Deliverable definition forms:

Form D: Tabular Data Deliverable

Vital Sign:

OC Oceanography

Deliverable ID:

OC_M

Deliverable Title:

Data quality report

File format:

XLS

Associated software and 

version:

Excel 2007

Revision Date / protocol 

version:

05-01-2009 / 2010.1

Expected frequency:

20/year

Likely dissemination partners:

None – served by SEAN

Submission unit:

CTD# + dump#

What purpose does this deliverable serve?

Provides data quality column values for cumulative database.

Identifiers of relations that compose the tabular deliverable (“Relations” are tables or files that 

provide information which may be represented in a grid format. Each relation listed must be 

fully defined in its own accompanying Form X.):

OC_M_C_dddd.XLS, where “C” is the CTD unit number and “dddd” is the dump number.

Deliverable ID of any other SEAN data products required to create this product:

OC_D, OC_G

Description and source of any outside data required to create this product:

- None -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

201

Form X: Relation Definition

Vital Sign:

OC Oceanography

Relation identifier:

OC_M_C_dddd.XLS

Used by deliverable ID:

OC_M

Revision date / protocol version:

05-01-2009 / 2010.1

Type of relation:

File

Estimated rows:

25

Primary key for this relation:

ctd + dump 

Purpose:

Roster of casts made during a dump cycle of a particular CTD, with data quality exceptions 

identified.

Identifiers of attributes defined over this relation (“Attributes” are columns of the grid. Each 

attribute must be defined in an accompanying Form Y.):

CTD

DUMP

CAST

QUALITY_CODE

COMMENT

Mandatory validation criteria involving multiple attributes:

If COMMENT is not null, then QUALITY_CODE must not be null.

Optional validation criteria involving multiple attributes:

- none -
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

202

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CTD

Used by deliverable ID:

OC_M

Revision date / protocol version:

05-01-2009 / 2010.1

Default report heading:

CTD# 

Relation (from Form X):

OC_M_C_dddd.XLS

Purpose:

Local identification of the CTD device. Initially, units 1 and 2 were defined.

Data type: Varchar(10)

Maximum length 1

Required: yes

Measurement units: n/a

Format: 9

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must be between 1 and 9.

Optional validation rules for this attribute: • Should be between 1 and 3.

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

DUMP

Used by deliverable ID:

OC_M

Revision date / protocol version:

05-01-2009 / 2010.1

Default report heading:

Dump# 

Relation (from Form X):

OC_M_C_dddd.XLS

Purpose:

The sequential dump number covered by this data.

Data type: Varchar(4)

Maximum length 4

Required: yes

Measurement units: n/a

Format: 0009

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent an integer between 1 

and 9999.

Optional validation rules for this attribute:
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

203

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

CAST

Used by deliverable ID:

OC_D

Revision date / protocol version:

05-01-2009 / 2010.1

Default report heading:

CAST# 

Relation (from Form X):

OC_M_C_dddd.XLS

Purpose:

Sequential cast number within a particular dump. Casts are integers beginning with zero. They 

are generated by the CTDs themselves. Because of memory limits in existing equipment, it is 

rare CAST will ever exceed 15.

Data type: Varchar(2)

Maximum length 2

Required: yes

Measurement units: n/a

Format: 00

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent an integer between 0 

and 99.

Optional validation rules for this attribute: • should be between 0 and 15

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

QUALITY_CODE

Used by deliverable ID:

OC_M

Revision date / protocol version:

05-01-2009 / 2010.1

Default report heading:

Quality 

Relation (from Form X):

OC_M_C_dddd.XLS

Purpose:

The numeric quality code used to flag individual casts. Codes used are those defined natively to 

Ocean Data View software. 0=good, 1=unknown, 2=questionable, 8=bad.

Data type: Varchar(1)

Maximum length 1

Required: no

Measurement units: n/a

Format: 9

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

1. Must represent an integer between 0 

and 9.

Optional validation rules for this attribute: • should be one of {0, 1, 2, 8}
Glacier Bay National Park and Preserve Oceanographic Monitoring Protocol

204

Form Y: Attribute Definition

Vital Sign:

OC Oceanography

Attribute identifier:

COMMENT

Used by deliverable ID:

OC_M

Revision date / protocol version:

05-01-2009 / 2010.1

Default report heading:

Quality Comment 

Relation (from Form X):

OC_M_C_dddd.XLS

Purpose:

A brief explanation of why the quality was assigned. If COMMENT is entered, then 

QUALITY_CODE must not be null.

Data type: Varchar(512)

Maximum length 512

Required: no

Measurement units: n/a

Format: n/a

Foreign key to (relation+attribute): n/a

Case: n/a

Mandatory validation rules for this attribute (in 

order of application):

- None -

Optional validation rules for this attribute: - None -
The Department of the Interior protects and manages the nation’s natural resources and cultural heritage; provides scientific and

other information about those resources; and honors its special responsibilities to American Indians, Alaska Natives, and affiliated

Island Communities.

NPS 132/106029, November 2010
National Park Service

U.S. Department of the Interior

Natural Resource Program Center

1201 Oakridge Drive, Suite 150

Fort Collins, CO 80525

www.nature.nps.gov

EXPERIENCE YOUR AMERICA TM