Skip to content

Proper vertical reference in GOTM #26

Open

Description

@bolding

Until now we have used the mean sea level as vertical reference in GOTM - which has been sufficient when doing ocean applications without massive amounts of ice on top.

Now two different use cases requires at least some thought.

Hans is working on melting under glacial ice where the ice thickness can be several 100 meters thick. One reference for the water/ice interface would be Hice*rho_ice/rho_0. For convenience it might still be useful to operate with a thickness of the water layer and have all calculations of e.g. temperature - like specification of two layer structure - or reading in profile data use this thickness as reference. The advantage is that making studies with the effect of ice thickness is easy as just one variable needs to be changed - Hice - and not have to change all depth values in the profile data file. But I don't know how these under ice observations are carried out in reality.

Another use case is with lakes - where it might still be possible to use the mean water level - even it is not well defined for some lakes. An alternative would be to use e.g. the z-coordinate of the deepest point in the lake relative to mean sea level (or geoid) - in this case z - the water level would be the total water depth.

In addition to the implications inside GOTM - it also have relevance when importing GOTM simulations into GIS - as a proper reference is mandatory.

Does anybody have ideas how we shall do this in a proper way to include all uses cases. As a side note - we are in the process of changing to TEOS-10. Here many subroutine calls use dbar (where a good proxy is depth) for pressure - but importantly minus the standard atmospheric pressure 101325 Pa. For a proper density calculation in alpine lakes there should actually be a correction - as we also use the surface pressure (and not mean sea level pressure) in air/sea flux calculations.

Here is a plot of the salinity of a sub-ice plume study - note the y-axis.
image

Comments are most welcome.

Activity

  1. jornbr commented on Oct 11, 2021

    @jornbr
    Contributor

    As far as I'm aware, GOTM is currently essentially agnostic about the vertical reference being used. It is essentially defined by the location/depth setting in gotm.yaml, which is interpreted as the distance of the chosen vertical reference and the bottom. The initial water depth of the column is set by the combination of that value and the initial water level (mimic_3d/zeta). Having these two settings seems to allow full freedom to pick an arbitrary vertical reference already. It's true that most setups use the mean sea level as reference - but that's only convention, not something that GOTM internally depends on, as far as I can tell. The only thing to keep an eye on is that any depth referenced observations use the same depth reference as implied by location/depth.

    So if we would now explicitly define e.g. location/depth as the distance between bottom and geoid, for instance, that seems to place a restriction on users without much justification (GOTM's internals still do not depend on this). The only (?) benefit would be that we could add some attribute that GIS tools can understand - but it that worth it?

  2. hburchard commented on Oct 13, 2021

    @hburchard
    Contributor

    I agree that we should define the orign of the z-axis in a way that it is collocated with the ea level, as Karsten shows in his plot. Feeding this depth into the equation of state should then give the correct pressure for models where the sea surface is at mean sea level and for models with a cover of glacial ice. But for Alpine lakes, it would not really work, since a surface situated at z=1000 m would result in a pressure of -1000 hPa, plus atmospheric pressure at sea level. That would certainly not work. Or am I lost here?

  3. knutaros commented on Oct 13, 2021

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions