Skip to content

Add support for vertical obs#597

Open
otzi5300 wants to merge 13 commits intovertical-skillfrom
add_support_for_vertical_obs
Open

Add support for vertical obs#597
otzi5300 wants to merge 13 commits intovertical-skillfrom
add_support_for_vertical_obs

Conversation

@otzi5300
Copy link

@otzi5300 otzi5300 commented Mar 3, 2026

Closes #595

First step of 4 in implementation of vertical skills

General idea of vertical skill is to store data for model and obs in 1d (see below). Depth information is stored in auxilary coordinate z. Befinit of this compared to storing in 2d:

  • Similar to current data structures and current matching workflow can be used
  • Allowing varying z coordinates for obs and sigma layered models

Steps:

  1. Support vertical obs
  2. Support vertical model items
  3. Matching to get comparer
  4. plotting/skill etc on vertical

This PR per commit

(see vertical skill notebook for more info)
VerticalObservation class
Stores timeseries data for vertical profiles.

Validate timeseries with geomtype=vertical.

  • Adds vertical geometry type
  • Adds additional check for zcoord if gtype is vertical

parse input for timeseries with vertical coordinate.
Very similar to parsing of tracks (_track.py) but z-coordinate is now needed.

  • remove duplicated (time,z) pairs. Note, duplicated time allowed ( obs with same time on multiple depth)

data structure:
time(time) = [t1, t1, t1, t2, t2, t2, t3 ...]
z(time) = [z1. z2, z3, z4, z5, z6, z7 ...]
data(time) = [d1, d2, d3, d4,d5,d6,d7....]

Testdata

  • 3d sigma model (cut to very small domain)
  • observations (2 locations) stored as dfs0 and csv

Tests of new features

otzi5300 added 7 commits March 3, 2026 16:21
* Adds vertical geometry type
* Adds additional check for zcoord if gtype is vertical
Very similar to parsing of tracks (_track.py) but z-coordinate is now needed.

* remove duplicated (time,z) pairs. Note, duplicated time allowed ( obs with same time on multiple depth)
Stores timeseries data for vertical profiles.

data structure

time(time) = [t1, t1, t1, t2, t2, t2, t3 ...]
z(time) = [z1. z2, z3, z4, z5, z6, z7 ...]
data(time) = [d1, d2, d3, d4,d5,d6,d7....]
Copy link
Member

@ecomodeller ecomodeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks promising.

@otzi5300 otzi5300 linked an issue Mar 4, 2026 that may be closed by this pull request
Copy link
Collaborator

@ryan-kipawa ryan-kipawa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, very clear and easy to understand. Only a few comments:

  • add pyproj to pyproject.toml notebooks dependency group
  • the tests seem a bit light compared to other existing observation types

ds.time.to_index().is_monotonic_increasing
), "time must be increasing (please check for duplicate times))"

if "gtype" not in ds.attrs:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep this in the # validate attrs section?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gtype is used right below in validation of the coordinates ( validate if VerticaObservation contains a z-coordinate). I will move the validate attrs section to the top

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at it a bit more i would like to keep the gtype validation at the top and other attributes at the bottom. Gtype is like a overall parameter that needs to be validated before going forward. The attributes validation is more about setting stuff if not exists. Also, other attributes are validated in the "data validation" part so i think it is fine to split it like this. Hope you agree, otherwhise i can off course rearrange to be more strict about the sections


Parameters
----------
data : VerticalType
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the user know what a vertical type is?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notices afterwards that it's in types.py. While I appreciate the DRY aspect of this, I also noticed that all other observation types repeat the actual types in the docstring. I would suggest keeping that style for now

@ryan-kipawa
Copy link
Collaborator

@jpalm3r you had mentioned cross-reviewing with @otzi5300 ... this is probably a good PR for that

@otzi5300
Copy link
Author

Nice, very clear and easy to understand. Only a few comments:

  • add pyproj to pyproject.toml notebooks dependency group
  • the tests seem a bit light compared to other existing observation types
  • removed unused pyproj import from notebook so no need to add it to pyproject.toml
  • I will see if any more tests are needed. However, several features in VerticalObservations are tested in the tests for Point- and trackObservations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add possibility to read and store vertical observations

3 participants