plans for adding nonhydrostatic?

[vtamsitt]

I see it's mentioned briefly at the end of the Readme as in scope for ClimaOcean, but I'm wondering if expanding <ocean_simulation> to include nonhydrostatic is on the roadmap at all for the near future or not? For smaller scale/higher resolution realistic regional applications this would be very useful!
At the surface level this looks like simply having an option to call instead of within <ocean_simulation> but I am assuming there would be changes needed in the physics parameterizations and maybe reasons to have a separate function for nonhydrostatic models?

[glwagner]

I think this isn't too difficult in principle. But the main question is exactly how to compute air-sea fluxes. For example, one could interpret an LES as a "single column model", and compute fluxes between JRA55 and the ocean state after averaging the ocean state horizontally over the whole domain. One could also compute fluxes instantaneously for every surface cell, but I'm not sure bulk formula are valid at such small scales.

[vtamsitt]

Got it. I'll think about the validity of bulk formula question.

[glwagner]

I think could pretty easily come up with a NonhydrostaticModel set-up that's compatible with the way ClimaOcean computes fluxes now though. That could be a starting point and then we could work on embellishing it. My hunch is that one would want to do at least a bit of averaging for the purpose of computing fluxes... both in space and time. But exactly what one would need is totally application dependent, so more a question of what you might want than a question of what I think is best!

[vtamsitt]

Yeah, I think that would be a great starting point, and maybe there's a way to ultimately support both options/optionally support averaging for the purposes of computing fluxes? It really depends on scale/application as you say. There are coastal high resolution applications where if you want a grid resolution getting down in the range of 10-100 m then you might want to run non-hydrostatic, and in this case bulk fluxes for every surface cell could make sense for some applications, although maybe still want averaging in time. But for a nearfield LES model with order 1 m resolution or less then it makes much less sense. I'm thinking about the first situation right now, FWIW.

[glwagner]

For sure supporting both would have to be done. Because we still want to retain the simple option of computing fluxes every time-step + every grid cell for coarse resolution global models. So computing an "averaged near-surface state" could be an optional abstraction to use.

One little extra puzzle is to figure out how to "locate" / compute the lat-lon of a RectilinearGrid in order to interpolate from some atmospheric data product on the sphere. Not intrinsically difficult but something to keep in mind.