markusritschel / oceanpack Goto Github PK

The shift parameter adds kind of a buffer after each detected non-operating phase. It would make its purpose more intuitive if it's getting renamed.

Originally, the data are only time dependent.
That is, longitudes and latitudes are coordinate but no dimensions.
It would be helpful to have a method (an XArray accessor) that allows gridding the data into a pre-defined grid.
Check out:

• xoak
• https://traja.readthedocs.io/en/latest/gallery/plot_grid.html
• https://www.fatiando.org/verde/latest/index.html

The extra package might become a dependency or a sub-repo from the oceanpack package/repo.

For proper quality control, create a new module with QC routines and integrate it in the processing workflow.

Such a module could include:

1. checking the waterflow
   Waterflow should be around 6 or 7 L/min. Find phases, where it is below a certain threshold (e.g. 2 below median or < 5.5) and mask the CO2 data (possibly including the next 20 minutes or so).
2. checking the sensor temperature
   Sensor temperature should be approximately +50°C.
3. checking the sensor pressure
   Sensor pressure should be approx 990–1050 mbar.
4. correlations with vessel speed --> discuss with Peter
5. response time checks
   e.g. check the lengths of the response times

Also, similar to set_nonoperating_to_nan, mask the affected CO2 data including a given buffer after each phase.

For a start, compare the QC routines I did for the ICOS project in 2021.

Consider if adding a pre-processing routine is helpful that transforms raw log data from the OceanPack to a netCDF file.?
Having a netCDF file would make it much more comfortable to read-in the data. One would have all the attributes already by hand. Also plotting routines (form XArray, for example) could already make use of the attributes.

For this to be implemented, we should check:

• How does the file size differ? Perhaps use compression for netCDF
• How does the loading differ?
• Are there better suited file formats?
• (How) would we rename the variables?
• Should the data be simple 1D time series (with lon/lat being coordinates but not dimensions) or should they be gridded (with time, lon, lat as dimensions) --> if gridded, how does file size change? (compare sailors' routine)

One needs to differentiate between the different systems (and maybe even different versions of the systems?)

The response time after a shock (e.g. induced via calibration or by crossing a front) may differ depending on the amplitude of the shock etc.
Use the results from ICOS alongside other methods to recover the true signal.

Determine the time step of the shock with gradient-based detection and the value at which equilibrium is reached again.
Then, determine the "time constant", i.e. the time span at which 1/e of the equilibrium value is reached starting from the shock.

For example, a map with the coordinates from the GPS, maybe including first plots of the measurements.

A flow chart could help understand the data processing, considering different data inputs and quality checks on the way.

Documentation should be tagged with the same version as the package code. I.e. on the documentation page, the respective version should be selectable.

To check:

• How can one integrate deprecation warnings?
• How can this be implemented in Github's CI workflow?

Update documentation and add simple examples to most docstrings.