-
Notifications
You must be signed in to change notification settings - Fork 13
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
Integrate sea ice in the flux computation #294
base: main
Are you sure you want to change the base?
Conversation
…into ss/one-degree-take3
Co-authored-by: Gregory L. Wagner <[email protected]>
idealized_atmosphere.mp4 |
@simone-silvestri can you hold commits on this branch for a bit? I'm working on it. Just got a bunch of conflicts. |
As part of this PR we have some important design decisions to make regarding how fluxes are computed and stored. These decisions are not numerical in nature (we know what to do for the physics) but more questions of the user API and internal code design. I'll start by noting that the way fluxes are currently computed is not correct. This PR will require 3 types of fluxes: atmosphere-ocean, atmosphere-sea-ice, and sea-ice-ocean. (A fourth flux, land-ocean, is implicitly included in atmosphere-ocean for now but we may need to break this out eventually too.) Right now we do not explicitly store these three types of fluxes. Instead we have an object that represents the total flux into the ocean, which combines the atmosphere and sea-ice fluxes. For example, when we compute atmospheric fluxes, we store the result in the total ocean surface flux fields, then multiply those by ClimaOcean.jl/src/OceanSeaIceModels/CrossRealmFluxes/atmosphere_sea_ice_fluxes.jl Lines 23 to 27 in e1d0066
The next step is to add the sea-ice contribution to the total ocean flux, multiplied by
In proceeding we have a choice to make. We can proceed along the current path, and fix the sea-ice-ocean fluxes to incorporate concentration correctly. This will necessarily assume that the atmosphere-ocean fluxes have been previously computed, and therefore add the sea-ice contribution to them (rather than overwriting the values as we do now, which assumes that the previous values are from a prior time step for example). Note that currently, the sea ice does not require explicit fluxes at the ice-ocean interface, because the ice-ocean interface is assumed to be in thermal equilibrium at the melting temperature. Therefore, we do not functionally require storing the ice-ocean fluxes; merely adding them to the total ocean flux is sufficient. (This could change in the future though.) One advantage of this design is that we do not store unnecessary data in memory. Another possibility is to explicitly store each interface flux separately. This requires more memory allocation (12 extra 2D fields, I think, in the worst case scenario). For a model that's high resolution in the vertical this is fairly trivial extra storage. But it might represent a lot of memory for a low-vertical resolution in the vertical, nearly tantamount to an extra 3D field. But perhaps even that is not a huge price to pay... To spell this out, consider that the computational model for the coupled system is effectively like this:
Consider the flux of some quantity denoted by The total flux into the top of the sea ice is just Our current strategy is to avoid allocating memory for
Another option though is to explicitly compute Finally note that there are at least 4 fluxes of the form |
I also think explicitly computing |
This PR is a tentative implementation for atmosphere-sea-ice computations to be able to integrate sea-ice in the
OceanSeaIceModel
.The objective is trying to reuse as much as possible of the infrastructure in place for atmosphere - ocean fluxes
I think everything is roughly in place, we just need to change the surface properties and implement a way to limit the surface temperature to the melting temperature in the surface temperature computation