Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper vertical reference in GOTM #26

Open
bolding opened this issue Oct 11, 2021 · 3 comments
Open

Proper vertical reference in GOTM #26

bolding opened this issue Oct 11, 2021 · 3 comments

Comments

@bolding
Copy link
Collaborator

bolding commented Oct 11, 2021

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.

@jornbr
Copy link
Contributor

jornbr commented Oct 11, 2021

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?

@hburchard
Copy link
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?

@knutaros
Copy link
Contributor

knutaros commented Oct 13, 2021 via email

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

No branches or pull requests

4 participants