Can we detect global warming in different parts of the Earth through climate sensors in the oceans? Can we study it through software to enable ocean exploration? What is the future of global warming through predictions from climate sensors in the oceans?

tional challenges for Earth science, and no one sensor can “do it all”. While many remote sensing technologies are available at present, scientific disciplines are often trained to use only a specific subset, greatly limiting scientific advancements. Here we present open- source software (icepyx) that lowers the barrier for entry for two remote platforms offering vertically- resolved information about the ocean's subsurface: ICESat- 2 (Ice, Cloud, and land Elevation Satellite 2) and Argo floats. icepyx provides object- oriented code for querying and downloading ICESat- 2 and Argo data within a single analysis workflow. icepyx natively handles ICESat- 2 data access and read- in; here we introduce the Query, Unify, Explore SpatioTemporal (QUEST) module as a framework for adapting icepyx to easily access and ingest other datasets and present Argo data as the initial use case. Seamless retrieval of coincident data from ICESat- 2 and Argo enables improved targeted and exploratory studies across the cryosphere and open ocean realms.

a specific discipline may not even be aware of other relevant data products that are publicly available for use. Although the oceanography community has made substantial progress in understanding the marine system with ocean- dedicated satellites starting with the Coastal Zone ColorScanner (Antoine et al. 1996), these platforms are limited to sunlit, cloud- free conditions, and limited information about the water column can be obtained. The benefits of purpose- built sensors

notwithstanding, more advancements are possible by combining technologies intended for ocean work with those that were initially created for different purposes, ideally enabled by an open- source framework (Hostetler et al. 2018). For example, the recent use of an atmospheric lidar sensor (the Cloud- Aerosol Lidar with Orthogonal Polarisation, CALIOP, on Cloud- Aerosol Lidar and Infrared Pathfinder Satellite Observations, CALIPSO) in ocean studies led to exciting discoveries, including observing diel vertically migrating zooplankton from space (Behrenfeld et al. 2019), as well as advances in understanding that will improve conventional technologies (i.e., a seasonal bias in NASA ocean colour data) (Bisson et al. 2021b, 2023).

Two such technologies that have apparently different purposes yet strong compatibilities and applications in oceanography are Argo floats (Argo 2024) and the Ice, Cloud, and land Elevation Satellite 2 (ICESat- 2; Markus et al. 2017) mission launched in 2018. Argo floats move vertically within the water column as they drift in a semi- lagrangian manner with the currents, primarily offering vertical profiles of temperature, salinity, and depth. The floats are programmed to collect a profile every 10 days. After drifting freely at 1 km depth, the float will descend to 2 km, collecting measurements approximately every 1–2 dbar in the upper 1 km (Wong et al. 2020). Vertical sampling resolution is typically reduced in the lower 1 km where the vertical profile is less variable. An additional group of Argo biogeochemical (BGC) floats are equipped with both biological and chemical sensors to measure chlorophyll concentration, nitrate, oxygen, the particulate backscattering coefficient at 700 nm, and in some cases, photosynthetically active radiation (PAR) and spectral downwelling irradiance. A portion of Argo floats will transit underneath sea ice (Hague and Vichi 2021), capturing precious data not possible using conventional methods, especially from satellites. The invention and deployment of Argo floats have transformed our understanding of ocean physics and biology, especially during times and in places inaccessible from ocean colour satellite observations such as wildfire events (Tang et al. 2021) and under- ice blooms (Horvat et al. 2022). Until recently, Argo floats were the only tool available to capture the structure of the upper water column on global scales. Now that ICESat- 2 has been launched, the combination of surface observations by ICESat- 2 and deep observations by Argo has great scientific potential in topics such as air- sea interactions and biogeochemistry of phytoplankton blooms.

In 2018, ICESat- 2 was launched with a primary goal of studying polar regions, but it has technical capabilities to observe terrestrial and ocean ecosystems worldwide. Compared to the original ICESat mission, ICESat- 2 boasts several advantages for use in oceanographic applications. ICESat utilised a laser altimeter known as the Geoscience Laser Altimeter System (GLAS), which transmitted a single beam over the Earth's surface at 1064 nm, a wavelength that quickly attenuates in water. In comparison, the Advanced Topographic Laser Altimeter System (ATLAS), the sole instrument onboard ICESat- 2 and the only photon- counting lidar altimeter in orbit, contains a 532 nm laser with a pulse repetition rate of 10 kHz with three pairs of beams on the ground (Markus et al. 2017). Each beam pair contains a strong beam and a weak beam, with the strong beam having four times the beam energy per pulse than the weak beam. Over the ocean, ICESat- 2 data have been used to generate vertical profiles (up to 15 m depth) of particulate backscattering and light attenuation (Lu et al. 2020, 2021), map bathymetry accurate to ~0.5 m in water up to ~40 m deep (Parrish et al. 2019), and extract sea ice thickness data for contextualising under- ice phytoplankton phenology (Bisson and Cael 2021), the latter of which was accomplished using software described herein. With CALIPSO decommissioned, the only lidar satellite available for ocean observations presently flying is ICESat- 2 (Behrenfeld et al. 2023).

Compared to ocean colour data, which are typically manageable in aggregate because they are of relatively small size (available at https:// ocean color. gsfc. nasa. gov;note each day of data is ~1 GB or less), photon data from ICESat- 2 are complex, large datasets that cannot be easily downloaded and stored for local use without substantial manipulation (e.g., just one day of ICESat- 2's ATL03 data product is ~300 GB). While other missions (e.g., MODIS- Aqua, CALIPSO) have higher- level ocean data products, ICESat- 2 ocean products are in development, and many ocean applications of ICESat- 2 rely on lower- level ATL03 photon cloud data to derive subsurface optical information about the water column. Without open- source, collaborative software programs and community resource sharing, a substantial amount of prior knowledge is needed in order to appropriately and efficiently access and use ICESat- 2 data for ocean applications. None of the recent studies using CALIOP for ocean particle and biology studies have made their code openly available or in an open- source language, limiting the degree to which satellite lidar analyses in the ocean can be reproduced and proliferated for different needs (Behrenfeld et al. 2013, 2022; Lu et al. 2020, 2021; Lacour et al. 2020; Bisson and Cael 2021; Bisson et al. 2021, 2021a, 2023). Furthermore, existing oceanographic investigations utilising ICESat- 2 data are overall limited relative to the potential, and those studies were conducted by a relatively small subset of oceanography researchers.

To enable novel studies of coupled ICESat- 2 and ocean data, we introduce an open- source Python module QUEST: Query, Unify, Explore SpatioTemporal. QUEST is housed and packaged within the icepyx library, a community and Python software library that simplifies the process of ‘querying, obtaining, analyzing, and manipulating ICESat- 2 datasets to enable scientific discovery’ (Scheick et al. 2023). The module includes testing, documentation, and a tutorial for accessing coincident Argo and ICESat- 2 data using QUEST. Our goal is to lower the access barrier to combining multiple datasets to advance our understanding of ocean/sea ice processes from polar to global scales (Figure 1). Here, we discuss the cultural and scientific value of collaborative approaches to working across disciplines and sensors (Section 2), including best practices for writing open- source code, based on the authors' experiences in developing this workflow. Our software (Section 3) is object- oriented and written with flexibility so future datasets of interest can be included with ease (Section 4) for improved scientific application. We close with recommendations for future software capabilities, and we invite those interested to join our community and participate in ongoing efforts.

FIGURE 1 | Location of ICEsat- 2 reference ground tracks (RGTs, green lines), Argo floats equipped with physical (i.e., temperature, salinity) sensors (blue), and Argo floats with both biogeochemical and physical sensors (BGC, orange) globally. The time period for each dataset shown corresponds to ICESat- 2's Cycle 20 (20 June 2023–19 September 2023). ICESat- 2 produces data from September 2018 to present, Argo (physical parameters) from 1999 to present, and BGC- Argo from 2016 to present. Note the increase in ICESat- 2 track density near the poles.

2 | Approach to Programming and Teamwork

2.1 | Open Science

The United States White House Office of Science and Technology Policy (OSTP) and National Science and Technology Council (NSTC) formally define “open science” as “The principle and practice of making research products and processes available to all, while respecting diverse cultures, maintaining security and privacy, and fostering collaborations, reproducibility, and equity” (U.S. OSTP and NSTC, 2023). Released in January 2023, this federal definition coincided with the recognition of 2023 as the Year of Open Science, a concept galvanised and promoted through NASA's Transform to Open Science (TOPS) Mission (https:// scien ce. nasa. gov/ open-scien ce/ trans form-to-open-science) which is part of the agency's broader Open- Source Science Initiative (OSSI) (https:// scien ce. nasa. gov/ open-scien ce-overview). While necessarily broad, this definition highlights the overarching principles that lead to many practices long ago adopted by many communities, and the open- source software community specifically. Here we highlight one of the many scientific achievements enabled by this type of trans- disciplinary, cross- platform, collaborative approach and hope to persuade readers to learn about and adopt relevant open science practices in their own teams and workflows. Our motivation stems from wanting to enable more cross- disciplinary discoveries through open science, in part because some of our previous work was not open. Developing QUEST provided a space to learn and exercise open science practices.

2.2 | Our Team

Our team met at the University of Washington's ICESat- 2 2020 Virtual Hackweek (Arendt et al. 2020; Huppenkothen et al. 2018). During this event, project teams formed to collaborate on a pressing technical or research challenge. We identified a need for simultaneous access of ICESat- 2 and complimentary data sets, yet such a task was challenging with existing software. We quickly created a proof of concept for combining Argo and ICESat- 2 data using Python- based software. With no previous collaborations and hailing from different academic cultures, disciplines (ocean biology, glaciology, sea ice physics, physics), and time zones (from Pacific Time to Central European Standard Time), working together as a project group during the week- long event catalysed a practice of virtual collaboration and support. At the time, only a few team members had experience working in Python and/or using version control tools (e.g., git, GitHub) to write code collaboratively. After the hackweek, the group continued meeting to create what ultimately became the QUEST module presented herein. To minimise the burden on already full schedules, we intentionally met for only an hour weekly, setting appropriately rigorous benchmarks for success while performing most of the work during these meetings. Importantly, during these supportive co- working online sessions, we not only wrote software but engaged in coding and collaboration best practices, building skills and learning from one another. In this way we created a culture of trust and transparency that enabled us to share our skill sets, make research and personal progress, and address challenges in real time.

2.3 | Object- Oriented Development Overview

A first step of our team's collaborative work was reformatting existing code to fully leverage the benefits Python's object- oriented structure has to offer. Details of changes to icepyx's architecture are outlined in Section 3.3. Object- oriented programming (OOP) is a common implementation feature of many popular open- source languages, including Python and JAVA, that organises code through an object- centric perspective. An object is any “entity” possessing unique attributes and behaviours (Figure S1). For example, a “person” object might include “name,” “age,” and “eye colour” attributes and “sleep,” “eat,” and “express joy” behaviours. In the context of oceanography, a “water column” object would have “temperature,” “salinity,” and “chlorophyll,” among other attributes. Structuring code in this object- oriented way has several benefits, most notable of which is modularity. Independent segments of code can be written simultaneously (“orthogonality” as defined by Thomas and Hunt 2019) and then brought together like building blocks that interlink. This modularity enables multiple developers to individually write code segments independently and combine them later so long as there is an agreed upon input and output format (“Design by contract,” Thomas and Hunt 2019) between them. The modularity of OOP is conducive to easy maintenance because if one code segment needs to be modified, changes can be made without also propagating revisions through other segments, as long as the input/ output criteria are met (see Section 3.3).

2.4 | Unifying Oceanographic Data Access

Oceanography often involves the use of vast quantities of data that is collected by multiple organisations and is stored across various repositories. Manual access to large quantities of data is impractical, so generally access to these data is best done programmatically. An Application Programming Interface (API) allows the user to request information without detailed knowledge of how it is stored by the source. However, each data source has its own unique API, leaving it to the user to be familiar with how a request should be formatted for each dataset they would like to access. QUEST serves as a common interface between the user and multiple data sources. Using human- readable Python syntax, QUEST formats the appropriate request to retrieve ICESat- 2 and Argo data, removing the burden from the user to learn each API separately. The modularity with which QUEST was designed also allows support for other datasets to be incorporated in future releases.

3 | Icepyx and QUEST: Open- Source Software for ICESAT- 2 and Argo 3.1 | What Is Icepyx?

icepyx is an open- source Python software package and community designed to enable collaboration and work with the large and complex data products from ICESat- 2. icepyx was created at the first ICESat- 2 Hackweek held in June 2019, less than a year after the launch of the satellite. During that event, data access methods were presented ad hoc, with new users required to carefully format tens of lines of code to submit a valid data access request or manually download individual files through a web browser. Since then, the package's capabilities have expanded as more users contribute their work. It now provides data access via download or in the cloud, visualisation, and read- in capabilities. Critically, the software package provides a citable, tested, shared development framework that is publicly available and easily installable via GitHub (https:// github. com/ ), PyPI (the Python Package Index, PyPI 2024), and Conda (Anaconda Inc. 2020), while the community provides a safe, supportive, communal learning space to build the skills required to effectively collaborate on code.

3.2 | Specific Software Functionality

The entire process of querying and downloading (or accessing in the cloud) ICESat- 2 data can be achieved with icepyx in three steps: (i) initialize the search with the ‘Query’ class, (ii) log into NASA Earthdata, and (iii) call the download functionality (or begin cloud reading). Below, we describe a few key programmatic features with which the user can interact. We encourage potential users to explore the icepyx documentation (https:// icepyx. readt hedocs. io/ en/ latest/ ) and examples (e.g., https:// icepyx. readt hedocs. io/ en/ latest/ examp le_ noteb ooks/ IS2_ data_ access. html) to explore the full range of functionality available within the software. Users need a free Earthdata account (https:// www. earth data. nasa. gov) to download any ICESat- 2 data from the National Snow and Ice Data Center Distributed Active Archive Center (NSIDC DAAC) or access it in the cloud; icepyx provides multiple authentication options for an individual to enter their credentials, including an in- notebook login. These options are showcased in the documentation and are not further addressed here.

The Query data object within icepyx allows the user to define their study parameters. Input variables include a string for the ICESat- 2 product of interest (e.g., ‘ATL03’, ‘ATL07’), a spatial extent that can be represented as a bounding box or polygon (coordinates or geospatial polygon file), and a time window. A maximum of one spatial bounding box or search polygon is allowable per Query object instance, a limitation imposed by the data archive center but easily addressed with multiple Query objects. Additional search filters can be added for ICESat- 2 queries if the user wishes to search for a specific product version, cycle, or reference ground track. The user can generate a map of their search region and view summary information about the data product using the methods available on the Query object (https:// icepyx. readt hedocs. io/ en/ latest/ examp le_ noteb ooks/ IS2_ data_ access. html).

Configuration parameters required to search for and access data products are automatically generated by the software. The user can manually create, view, and update these parameters, but it is not required. After creating a Query object, the user can view the search results and metadata (e.g., avail_granules()). During data ordering and downloading, the user can additionally subset the file for specific parameters of interest (Supporting Information—Data S1) and supply options to change the file type (e.g., HDF5 to NetCDF4- CF (see show_custom_options() in the Query object for more details on available subsetting options)).

3.3 | Quest

Here we present the Query Unify Explore SpatioTemporal (QUEST) module, which is an expansion of the icepyx Query class (Section 3.2). From the original icepyx Query object implementation, we modified the architecture to create a super class object called GenQuery. Parameters not specific to ICESat- 2, such as spatial and temporal information, were isolated to be handled instead by GenQuery, making this information directly accessible to the QUEST module independent of the ICESat- 2 Query functionality. In turn, QUEST uses this super class GenQuery to handle spatial and temporal data while also housing basic properties and functionalities common to all datasets (such as preparing data for plotting). These underlying changes are invisible to the user and take advantage of OOP's ability for high- level organisation.

The QUEST module is designed to easily query, download, and perform simple operations on datasets complimentary to and including ICESat- 2. Users specify spatiotemporal bounds for their investigation through creating a QUEST object. The user then utilises this higher- level framework to call on subsets of the framework defined specifically for each type of dataset, providing any additional parameters important for obtaining or manipulating their dataset of interest (e.g., variables of interest). Attributes and behaviours that are common to all datasets and required by this higher- level framework are indicated in a template- like Dataset class and its per-d ataset subclasses, with which the user is not intended to interact directly. This hierarchical system defines a structure for future developers to add functionality for additional datasets (Section 4, Figure S1).

3.4 | QUEST Use- Case: Argo

Argo data are available for physical (pressure, temperature, salinity) and biogeochemical (chlorophyll- a, nitrate, dissolved oxygen, particulate backscatter, downwelling irradiance) parameters and in a range of data modes (i.e., real- time vs. delayed). Real- time data are automatically quality- tested and flagged accordingly to warn users of blatant data issues, likely resulting from sensor malfunction or corrupted transmission (Wong et al. 2020). Delayed- mode data are visually inspected by experts who will re- flag the data if necessary. Further statistical analyses are also performed, checking for sensor drift; adjustments are made if required (Wong et al. 2020). A good starting- point for Argo information is the FAQ page: https:// argo. ucsd. edu/ data/ data-faq/ . There are approximately 4000 Argo floats at present, and the full dataset can be downloaded from two Global Data Assembly Centers (GDAC); GDAC data access does not permit a user to search and download for particular floats of interest unless the specific float number is known a priori (https:// bioge ochem ical-argo. org/ data-access. php). Downloading the entire Argo dataset is not feasible for users working locally on their computers due to size constraints, and working with numerous individual files is less efficient than working within a merged dataframe. Graphical selection tools do exist (e.g., https:// datas elect ion. euro-argo. eu/ , https:// argov is. color ado. edu/ ); however programmatic data access via QUEST allows researchers to streamline and automate the data access process within their processing pipeline.

Recently, Tucker et al. (2020) developed an application program interface (API) to query and download Argo data programmatically based on space/time windows through their web interface, Argovis. Here, we utilise the Argovis API within QUEST to query, download, and format the Argo data of interest with minimum effort from the user. By default Argovis returns delayed mode data if available and real time data if not. At the time of writing, a feature- request is open to add an optional flag to search for real- time profiles. Currently, Argovis synchronises daily with the GDAC, providing near- real- time data (Tucker et al. 2020). In this way, the user does not need to download Argo separate from their ICESat- 2 Query, nor does the user need to download a static dataset from the GDAC. We present an example use case in the North Pacific, where ICESat- 2 and Argo data are available < 5 days apart (Figure 2). In this case, the depth information available from ICESat- 2 appears representative of the rough mixed layer depth (given by the temperature profile). While ICESat- 2 has been used to generate vertical profiles in the ocean, it is not clear that these signals can be wholly attributed to phytoplankton, because particles, bubbles, and surface glint also have a role. By coupling nearby Argo observations with ICESat- 2 data, one can more rigorously assess both datasets in tandem, improving the use of ICESat- 2 to address ocean biology and biogeochemistry (ATL03), to identify the presence of sea ice (ATL07/ATL20), and to measure changes in sea surface height (ATL12/ATL19) (Table 1). In the future, it may also be possible to assess stratification in the upper water column from ICESat- 2 photon clouds, but ancillary data such as Argo are needed to facilitate these comparisons and identify uncertainties. A detailed example of using QUEST to access co- located ICESat- 2

and Argo data is located in the documentation: https:// icepyx. readt hedocs. io/ en/ latest/ examp le_ noteb ooks/ QUEST_ argo_ data_ access. html.

4 | Steps and Scientific Value of Adding A New Dataset to icepyx

FIGURE 2 | (Top left) Map of ICESat- 2 (blue) and Argo (green) data within the icepyx bounding box (yellow). (Top right) Zoomed in view of spatial area with closest Argo profile selected in the yellow triangle. (Bottom left) Height versus latitude of ICESat- 2 photons in the subsurface, with Argo location (black dashed line). (Bottom right) Approximate Argo depth, as estimated from water pressure, versus temperature from Argo profile, with ICESat- 2 vertical extent highlighted in red.

TABLE 1 | List of ICESat- 2 products relevant for ocean studies.

Product

What is it?

Used for?

References (ocean focus)

ATL03

Global geolocated photon data

• Deriving optical information (light attenuation coefficient, bbp) in coastal and global waters

• Bathymetry in shallow waters

Lu et al. (2020, 2021), Eidam et al. (2024), Parrish et al. (2019)

ATL07 (ATL20)

Polar sea ice elevation (gridded sea ice freeboard)

• Sea ice freeboard

• Sea ice lead identification

Bisson and Cael (2021), Horvat et al. (2022)

ATL12 (ATL19)

Ocean Elevation (gridded sea surface height)

• Sea surface height

Bagnardi et al. (2021), Buzzanga et al. (2021)

We anticipate many current and future datasets can be included within QUEST to greatly amplify the opportunity for scientific discovery at the nexus of disciplines. For example, PACE (the Plankton, Aerosols, Clouds, Ocean Ecosystems) mission (Werdell et al. 2019) will supply hyperspectral and polarised data on global scales, and GLIMR (Geosynchronous Littoral Imaging and Monitoring Radiometer; Salisbury 2022) will provide hourly data and thereby increase the likelihood of synergies with ICESat- 2 in the Gulf of Mexico region, where GLIMR is targeted to observe. Future progress may be enabled by cloud computing and subsetting procedures (described herein) that minimise the computational fluency required by the user to access data. We designed the QUEST module of Icepyx to leverage object- oriented strengths in large part so that additional datasets can easily be added so long as an API is available, and a roadmap for adding a new dataset is provided in Figure 3.

The software we describe herein can be used to facilitate a number of targeted and exploratory studies across the interface of cryosphere and ocean studies (Table 1). For example, Argo profiles provide temperature and salinity that can be used to contextualise and test suspected sea ice melting events, and the optical sensors on Argo floats can be used to quantify glacial silt in tandem with ICESat- 2 measurements of glacial activity. Argo floats also provide an important link between sea ice physics and ocean biology, which is needed given the rapid rate of Arctic warming (Rantanen et al. 2022) and associated biological changes (Ardyna and Arrigo 2020). ICESat- 2 and Argo data could also be used in tandem to generate vertical profiles of light attenuation or particulate backscattering in the ocean, which would enable fine scale exploratory studies in the upper- ocean. Fundamentally, icepyx facilitates direct comparison with ICESat- 2 and Argo observations, which will only become more plentiful in the coming years.

5 | A Note on Best Practices

FIGURE 3 | Workflow illustrating steps of adding a new dataset to QUEST module.

Python is one of the more forgiving languages in which to code, and this increased flexibility reduces both learning barriers and development time; however, sometimes more rigidly formatted code can benefit a project. Access modifiers are one such element that offer more rigidity but are not formally supported in the Python language. As the name suggests, access modifiers are syntax which modify access to objects. An object may be public, protected, or private. Public objects may be accessed anywhere in the program. Protected objects are only accessible within a class and its subclasses. As an example within the context of icepyx, “Dataset” is a high- level object from which more specific datasets extend including “Argo” and “ICESat- 2”. An attribute common to all datasets is the geographical location at which the data were collected. The region of interest is an attribute that the user will specify, regardless of the dataset being queried. API calls require geographic boundaries to be formatted in a specific way. Requiring the user to manually reformat the geographical region for each API call would be both tedious for the user and leave unnecessary room for error. This reformatting is best done on the backend via a function _fmt_coordinates(), with which the user should never interact. It is therefore best practice to designate this function as protected. That is to say, the higher- level “parent class”, Dataset, possesses a generic _ fmt_coordinates() function that is inherited by its “child classes”, ICESat- 2 and Argo. The specific child classes have access to the generic functionality, though the developer may also override _fmt_coordinates() within the child class itself to cater the formatting to the API being called. The take- away from this is that _fmt_coordinates() can be inherited by children of a class, but should not be called outside of the (sub)class itself.

The most restrictive access modifier is “private”. This prohibits access to an object outside of a class. There are no private variables in icepyx at this time, in part because objects in Python are public by default and there is no true way of restricting access to objects. Access modifiers are built on a type of “honour system” in which the programmer is expected to respect access recommendations. Protected objects are prefixed with a single underscore, and private objects are prefixed with a double underscore. The end user is expected not to interact with objects with private or protected designations.

The best practices used in the development of icepyx extend beyond those visible in the code. Test Driven Development (TDD) is a school of software development whereby the program is written in response to test cases. This process begins with establishing the desired functionality, writing test cases to reflect that functionality, and finally writing code to achieve that functionality. Test cases are often thought to simply verify the program is behaving as expected; however, TDD encourages the developer to consider how the end product will be used. “Design by contract” and “orthogonality” are among the recommendations presented by Thomas and Hunt (2019) used explicitly in icepyx's QUEST module. The term “orthogonality” signifies segments of code which are independent of one another. That is to say the inner workings of one segment should not affect the behaviour of another segment. “Design by contract” offers a framework though which orthogonal code segments may interact. The developer decides on a contract of preconditions and post conditions to which the program should adhere. In the context of QUEST, ICESat- 2 and Argo objects are independent of one another. There is, however, an agreed upon contract established by the higher- level “Dataset” class that exists solely on the backend which enforces input and output types expected by each of the two specific datasets.

6 | Summary, and the Value of Open- Source Science to Facilitate Cross- Disciplinary

Collaborations

Here we have introduced and described our efforts to build the QUEST module within icepyx, including architectural modifications to meet software development best practices and provide a superclass structure to readily accommodate future geophysical datasets. We have illustrated the science possibilities enabled by QUEST by incorporating physical and biogeochemical Argo data with ICESat- 2 tracks as a case study. Future advancements will come by adding other datasets to QUEST and expanding upon this initial exploration of coincident data. The science community needs to embrace the philosophy that integrating technologies is required for ground- breaking advances, not only to achieve closure in the measured parameter of interest, but also to greatly extend what is possible from any one sensor alone. ICESat- 2 and Argo are the only platforms that offer near real- time, global scale, vertically- resolved subsurface information about ocean biology and biogeochemistry at present; future missions will be easily included through our creation of shared, open computational pipelines and infrastructure.

Open- source science is a powerful concept offering free and unlimited data access, fully documented open software and algorithms, fully transparent processes and reproducibility, and a teaching culture (https:// www. earth data. nasa. gov/ esds/ open-science). Open- source science and its adoption catalyses cross- disciplinary conversations surrounding best practices for collaboration, ultimately enhancing community and scientific rigour. Proprietary software, lack of code sharing, and ambiguous methodologies hurt our potential for meaningful collaborations. As more technologies are developed and innovated, the need for transparency and data sharing will only grow. As we have described here, the QUEST module within icepyx provides a generalised framework such that future studies incorporating multiple sensors are not only possible, but could become routine and accessible even for novice developers.

References

Anaconda Inc. 2020. “Anaconda Software Distribution.” https:// docs. anaco nda. com/ .

Antoine, D., J.- M. André, and A. Morel. 1996. “Oceanic Primary Production: 2. Estimation at Global Scale From Satellite (Coastal Zone Color Scanner) Chlorophyll.” Global Biogeochemical Cycles 10, no. 1: 57–69. https:// doi. org/ 10. 1029/ 95GB0 2832.

Ardyna, M., and K. R. Arrigo. 2020. “Phytoplankton Dynamics in a Changing Arctic Ocean.” Nature Climate Change 10, no. 10: 892–903. https:// doi. org/ 10. 1038/ s4155 8-020-0905-y.

Arendt, A., J. Scheick, D. Shean, et al. 2020. “2020 ICESat- 2 Hackweek Tutorials.” https:// zenodo. org/ recor ds/ 3966463.

Argo. 2024. “Argo Float Data and Metadata from Global Data Assembly Centre (Argo GDAC).” https:// www. seanoe. org/ data/ 00311/42182/ .

Bagnardi, M., N. T. Kurtz, A. A. Petty, and R. Kwok. 2021. “Sea Surface Height Anomalies of the Arctic Ocean From ICESat- 2: A First Examination and Comparisons With CryoSat- 2.” Geophysical Research Letters48, no. 14: e2021GL093155. https:// doi. org/ 10. 1029/ 2021G L093155.

Behrenfeld, M. J., P. Gaube, A. Della Penna, et al. 2019. “Global Satellite- Observed Daily Vertical Migrations of Ocean Animals.” Nature576, no. 7786: 257–261. https:// doi. org/ 10. 1038/ s4158 6-019-1796-9. Behrenfeld, M. J., Y. Hu, K. M. Bisson, X. Lu, and T. K. Westberry. 2022. “Retrieval of Ocean Optical and Plankton Properties With the Satellite Cloud- Aerosol Lidar With Orthogonal Polarization (CALIOP) Sensor: Background, Data Processing, and Validation Status.” Remote Sensing of Environment281: 113235. https:// doi. org/ 10. 1016/j. rse. 2022. 113235.

Behrenfeld, M. J., Y. Hu, C. A. Hostetler, et al. 2013. “Space- Based Lidar Measurements of Global Ocean Carbon Stocks.” Geophysical Research Letters 40, no. 16: 4355–4360. https:// doi. org/ 10. 1002/ grl. 50816 .

Behrenfeld, M. J., L. Lorenzoni, Y. Hu, et al. 2023. “Satellite Lidar Measurements as a Critical New Global Ocean Climate Record.” Remote Sensing 15, no. 23: 5567. https:// doi. org/ 10. 3390/ rs152 35567 . Bisson, K. M., E. Boss, P. J. Werdell, A. Ibrahim, and M. J. Behrenfeld. 2021a. “Particulate Backscattering in the Global Ocean: A Comparison of Independent Assessments.” Geophysical Research Letters 48, no. 2: e2020GL090909. https:// doi. org/ 10. 1029/ 2020G L090909. Bisson, K. M., E. Boss, P. J. Werdell, A. Ibrahim, R. Frouin, and M. J. Behrenfeld. 2021. “Seasonal Bias in Global Ocean Color Observations.” Applied Optics 60, no. 23: 6978–6988. https:// doi. org/ 10. 1364/ AO. 426137.

Bisson, K. M., and B. B. Cael. 2021. “How Are Under Ice Phytoplankton Related to Sea Ice in the Southern Ocean?” Geophysical Research Letters 48, no. 21: e2021GL095051. https:// doi. org/ 10. 1029/ 2021G L095051.

Bisson, K. M., P. J. Werdell, A. P. Chase, et al. 2023. “Informing Ocean Color Inversion Products by Seeding With Ancillary Observations.” Optics Express, OE 31, no. 24: 40557–40572. https:// doi. org/ 10. 1364/ OE. 503496.

Buzzanga, B., E. Heijkoop, B. D. Hamlington, R. S. Nerem, and A. Gardner. 2021. “An Assessment of Regional Icesat- 2 Sea- Level Trends.” Geophysical Research Letters 48, no. 9: e2020GL092327. https:// doi. org/ 10. 1029/ 2020G L092327.

Eidam, E., K. Bisson, C. Wang, C. Walker, and A. Gibbons. 2024. “ICESat- 2 and Ocean Particulates: A Roadmap for Calculating Kd From Space- Based Lidar Photon Profiles.” Remote Sensing of Environment 311: 114222. https:// doi. org/ 10. 1016/j. rse. 2024. 114222.

Hague, M., and M. Vichi. 2021. “Southern Ocean Biogeochemical Argo Detect Under- Ice Phytoplankton Growth Before Sea Ice Retreat.” Biogeosciences 18, no. 1: 25–38. https:// doi. org/ 10. 5194/ bg-18-25-2021.

Horvat, C., K. Bisson, S. Seabrook, A. Cristi, and L. C. Matthes. 2022. “Evidence of Phytoplankton Blooms Under Antarctic Sea Ice.” Frontiers in Marine Science 9: 942799. https:// doi. org/ 10. 3389/ fmars. 2022. 942799.

Hostetler, C. A., M. J. Behrenfeld, Y. Hu, J. W. Hair, and J. A. Schulien. 2018. “Spaceborne Lidar in the Study of Marine Systems.” Annual Review of Marine Science 10, no. 10: 121–147. https:// doi. org/ 10. 1146/ annur ev-marin e-12191 6-063335.

Huppenkothen, D., A. Arendt, D. W. Hogg, K. Ram, J. T. VanderPlas, and A. Rokem. 2018. “Hack Weeks as a Model for Data Science Education and Collaboration.” Proceedings of the National Academy of Sciences 115, no. 36: 8872–8877. https:// doi. org/ 10. 1073/ pnas. 17171 96115 .

Lacour, L., R. Larouche, and M. Babin. 2020. “In Situ Evaluation of Spaceborne CALIOP Lidar Measurements of the Upper- Ocean Particle Backscattering Coefficient.” Optics Express, OE 28, no. 18: 26989–26999.

https:// doi. org/ 10. 1364/ OE. 397126.

Lu, X., Y. Hu, Y. Yang, P. Bontempi, A. Omar, and R. Baize. 2020. “Antarctic Spring Ice- Edge Blooms Observed From Space by ICESat- 2.” Remote Sensing of Environment 245: 111827. https:// doi. org/ 10. 1016/j. rse. 2020. 111827.

Lu, X., Y. Hu, Y. Yang, et al. 2021. “New Ocean Subsurface Optical

Properties From Space Lidars: CALIOP/CALIPSO and ATLAS/

ICESat- 2.” Earth and Space Science 8, no. 10: e2021EA001839. https:// doi. org/ 10. 1029/ 2021E A001839.

Markus, T., T. Neumann, A. Martino, et al. 2017. “The Ice, Cloud, and Land Elevation Satellite- 2 (ICESat- 2): Science Requirements, Concept, and Implementation.” Remote Sensing of Environment 190: 260–273. https:// doi. org/ 10. 1016/j. rse. 2016. 12. 029.

Parrish, C. E., L. A. Magruder, A. L. Neuenschwander, N. Forfinski- Sarkozi, M. Alonzo, and M. Jasinski. 2019. “Validation of ICESat- 2 ATLAS Bathymetry and Analysis of ATLAS's Bathymetric Mapping

Performance.” Remote Sensing 11, no. 14: 1634. https:// doi. org/ 10. 3390/ rs111 41634 .

PyPI. 2024. “PyPI The Python Package Index.” https:// pypi. org/ .

Rantanen, M., A. Y. Karpechko, A. Lipponen, et al. 2022. “The Arctic Has Warmed Nearly Four Times Faster Than the Globe Since 1979.” Communications Earth & Environment 3, no. 1: 1–10. https:// doi. org/ 10.

1038/ s4324 7-022-00498 -3.

Salisbury, J. 2022. “The Geosynchronous Littoral Imaging and Monitoring Radiometer (GLIMR): NASA's Newest Ocean Color Mission. Vol. 44. 44th COSPAR Scientific Assembly, p. 95, Conference Name: 44th COSPAR Scientific Assembly. Held 16–24 July ADS Bibcode: 2022cosp.44.95S.” URL. https:// ui. adsabs. harva rd. edu/ abs/ 2022c osp. 44. 95S.

Scheick, J., W. J. Leong, K. Bisson, et al. 2023. “Icepyx: Querying, Obtaining, Analyzing, and Manipulating ICESat- 2 Datasets.” Journal of Open Source Software 8, no. 84: 4912. https:// doi. org/ 10. 21105/joss. 04912 .

Tang, W., J. Llort, J. Weis, et al. 2021. “Widespread Phytoplankton Blooms Triggered by 2019–2020 Australian Wildfires.” Nature597, no. 7876: 370–375. https:// doi. org/ 10. 1038/ s4158 6-021-03805 -8.

Thomas, D., and A. Hunt. 2019. The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition, 2nd Edition. Addison- Wesley. https:// www. oreil ly. com/ libra ry/ view/ the-pragm atic-progr ammer/97801 35956 977/ .

Tucker, T., D. Giglio, M. Scanderbeg, and S. S. P. Shen. 2020. “Argovis: A Web Application for Fast Delivery, Visualization, and Analysis of Argo Data.” Journal of Atmospheric and Oceanic Technology 37, no. 3: 401–416. https:// doi. org/ 10. 1175/ JTECH -D-19-0041. 1.

Werdell, P. J., M. J. Behrenfeld, P. S. Bontempi, et al. 2019. “The Plankton, Aerosol, Cloud, Ocean Ecosystem Mission: Status, Science, Advances.” Bulletin of the American Meteorological Society 100, no. 9: 1775–1794. https:// doi. org/ 10. 1175/ BAMS-D-18-0056. 1.

Wong, A. P. S., S. E. Wijffels, S. C. Riser, et al. 2020. “Argo Data 1999– 2019: Two Million Temperature- Salinity Profiles and Subsurface Velocity Observations From a Global Array of Profiling Floats.” Frontiers in Marine Science 7: 1–23. https:// doi. org/ 10. 3389/ fmars. 2020.

.