hyo2.ssm2 2024.1.0

A library and an application to manage sound speed profiles.

HydrOffice Sound Speed Manager

• Code: GitHub repo

• Project page: url, download

• License: LGPLv2.1 or IA license (See Dual license)

General Info

The HydrOffice’s Sound Speed package provides a library and tools to manage sound speed profiles. The package is part of HydrOffice, a research development framework for ocean mapping. HydrOffice aims to provide a collection of hydro-packages to deal with specific issues in the field, speeding up both algorithms testing and research-to-operation (R2O).

Among the tools developed in the package, Sound Speed Manager (SSM) is a software application that provides the user with a streamlined workflow to perform accurate processing and management of sound speed profiles for underwater acoustic systems.

SSM has been designed to ease integration into existing data acquisition workflows. The liberal open source license used by the project (specifically, GNU LGPL) provides for understanding of the chosen processing solutions through ready inspection of the source code, as well as the ability to adapt the application to specific organization needs.

This adaptation is eased by the modular design of the application, with the NOAA-specific functionalities organized so that they can be easily deactivated for non-NOAA users.

The main functionalities include:

• Wide support of commonly-used sound speed profile formats

• Compatibility with various data sources

• Integration with common data acquisition/integration applications (e.g., Kongsberg SIS)

• Profile enhancement based on real-time and climatologic models

• Database management of the collected data with built-in functionalities for analysis and visualization.

With a long-term support and development plan, Sound Speed Manager is a turnkey application ready to be used (and extended) by professionals and institutions in the hydrographic community.

The package is jointly developed by the Center for Coastal and Ocean Mapping, UNH and NOAA Coast Survey Development Laboratory (CSDL).

For further information, visit the manual.

---

History

2024.0.0

2024-01-26

• Started migration from PySide2 to PySide6

2020.0.0

2020-04-09

• Started migration from Basemap to Cartopy

2019.0.0

2018-11-30

• Started migration to PySide2 and hyo.abc

2018.0.5

2018-01-10

• Added automated processing setup and other improvements

2017.3.0

2017-07-31

• Added Survey Data monitor

2017.0.0

2017-03-18

• First stable release.

2016-03-27

• Initial commit.

---

Credits

Authors

The package developers and maintainers are:

• Giuseppe Masetti

• Barry Gallagher

• Chen Zhang

Contributors

Other past and present contributors are:

• Hugh Barker

• Jonathan Beaudoin

• Brian R. Calder

• Lindsay Gee

• Sam Greenaway

• Kevin Jerram

• Paul Johnson

• Damian Manda

• Jean-Guy Nistad

• Collen Peters

• Patrice Ponchant

• Glen Rice

• Jack Riley

• Matthew Sharr

• Michael Smith

• Matthew J. Wilson

Please add yourself here when you submit your first pull request.

---

How to contribute

Every open source project lives from the generous help by contributors that sacrifice their time and this is no different.

Public Repositories

The source code is available on both GitHub and BitBucket.

To propose changes to Sound Speed Manager, you can follow the common Fork & Pull Request workflow. If you are not familiar with such a workflow, a good starting point may be this short tutorial.

Coding Style

To make participation as pleasant as possible, this project adheres to the Code of Conduct by the Python Software Foundation.

Here are a few hints and rules to get you started:

• Add yourself to the AUTHORS.txt file in an alphabetical fashion. Every contribution is valuable and shall be credited.

• If your change is noteworthy, add an entry to the changelog.

• No contribution is too small; please submit as many fixes for typos and grammar bloopers as you can!

• Don’t ever break backward compatibility.

• Always add tests and docs for your code. This is a hard rule; patches with missing tests or documentation won’t be merged. If a feature is not tested or documented, it does not exist.

• Obey PEP 8 and PEP 257.

• Write good commit messages.

• Ideally, collapse your commits, i.e. make your pull requests just one commit.

Note

If you have something great but aren’t sure whether it adheres – or even can adhere – to the rules above: please submit a pull request anyway! In the best case, we can mold it into something, in the worst case the pull request gets politely closed. There’s absolutely nothing to fear.

Thank you for considering to contribute! If you have any question or concerns, feel free to reach out to us.