-
Notifications
You must be signed in to change notification settings - Fork 6
Adds the thermo coupling #461
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
base: develop
Are you sure you want to change the base?
Changes from all commits
7bb8d3e
d5168b7
8c5db79
2f9696f
d00bcd2
f9d77f5
b99c94d
ff48c66
96c15a7
2e13052
69ca6c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,6 +5,7 @@ | |
| This page documents the user-facing configuration and behavior for current forcing in Omega: | ||
|
|
||
| - Surface stress forcing (e.g. wind stress) | ||
| - Coupled tracer flux forcing (mass, energy and salt) | ||
| - Surface tracer restoring | ||
|
|
||
| ## Surface stress forcing | ||
|
|
@@ -39,6 +40,74 @@ Surface stress forcing uses surface stress input fields: | |
| These are stored in forcing variables and used to form edge-normal stress | ||
| (`NormalStressEdge`) that enters momentum tendencies. | ||
|
|
||
| ## Surface thickness and tracer flux forcing | ||
|
|
||
| Surface thickness and tracer flux forcing applies ocean-atmosphere and ocean-sea ice fluxes from the other model | ||
| components (atmosphere, sea ice) to the thickness and tracer equations. This enables | ||
| the ocean to respond to heat, freshwater, and salt exchanges at the surface. These fluxes can be from data or (active) coupled components. | ||
|
|
||
| ### Surface thickness and tracer flux forcing configuration | ||
|
|
||
| Surface thickness and tracer flux forcing is controlled by two configuration flags: | ||
|
|
||
| ```yaml | ||
| Omega: | ||
| Tendencies: | ||
| SfcThicknessForcingTendencyEnable: false | ||
| SfcTracerForcingTendencyEnable: false | ||
| ``` | ||
|
|
||
| - `Tendencies.SfcThicknessForcingTendencyEnable`: enables coupled freshwater and salt flux forcing on thickness | ||
| - `Tendencies.SfcTracerForcingTendencyEnable`: enables coupled heat and salt flux forcing on tracers | ||
|
|
||
|
|
||
| ### Required input fields | ||
|
|
||
| Coupled tracer flux forcing uses 13 auxiliary fields organized by type: | ||
|
|
||
| **Freshwater mass fluxes (kg m⁻² s⁻¹):** | ||
| - `SnowFlux`: precipitation from snow | ||
| - `RainFlux`: precipitation from rain | ||
| - `EvaporationFlux`: evaporative water loss | ||
| - `SeaIceFreshWaterFlux`: freshwater mass flux from sea-ice melt or formation | ||
| - `IceRunoffFlux`: runoff from land ice | ||
| - `RiverRunoffFlux`: runoff from rivers | ||
|
|
||
| **Heat fluxes (W m⁻²):** | ||
| - `LatentHeatFlux`: latent heat transfer | ||
| - `SensibleHeatFlux`: sensible heat transfer | ||
| - `LongWaveHeatFluxUp`: upward longwave radiation | ||
| - `LongWaveHeatFluxDown`: downward longwave radiation | ||
| - `SeaIceHeatFlux`: heat/energy from sea-ice interaction (incl. enthalpy of meltwater) | ||
| - `ShortWaveHeatFlux`: shortwave (solar) radiation | ||
|
|
||
| **Salt mass flux (kg m⁻² s⁻¹):** | ||
| - `SeaIceSaltFlux`: salt flux from sea-ice formation/melt processes | ||
|
|
||
| These fields are populated by external coupling components (typically atmosphere | ||
| and ice models). Omega assumes the incoming values match the documented units. | ||
| For now, there are assumed to come from a `forcing.nc` file, but later will be provided | ||
| by the equivalent `ocn_comp_mct.F`. | ||
|
|
||
| ### Notes | ||
|
|
||
| - Coupled fluxes are applied only at the surface layer (top active layer) for each cell. | ||
| - Pseudo-thickness tendency is computed from the (six) freshwater mass fluxes and the salt mass flux | ||
| `SeaIceSaltFlux`, converted to a pseudo-thickness change. | ||
| - Temperature tendency is computed from direct heat flux plus | ||
| mass-flux enthalpy terms, converted to conservative-temperature tendency via | ||
| $H_{\text{FluxFac}} = 1.0 / (\rho_{sw} c^0_{p,sw})$ where $c^0_{p,sw}$ is the reference | ||
| specific heat of seawater defined by TEOS-10. The enthalpy associated with mass fluxes is currently hard-coded to SST for liquid fluxes and the freezing temperature for solid fluxes (which are melted using a constant latent heat of fusion). Note that the enthalpy of liquid meltwater from sea ice is already included in `SeaIceHeatFlux`. | ||
| - Salinity tendency from `SeaIceSaltFlux` is scaled by | ||
| $S_{\text{FluxFac}} = 1.0e3 / \rho_{sw}$ to account for unit conversion from | ||
| kg/(m²·s) to salinity units (g/kg). | ||
| - Fluxes are assumed to be in the documented units (i.e. net mass fluxes); | ||
| any unit conversion should be performed by the coupling component before providing flux | ||
| values to Omega. | ||
| - The reference density used here ($\rho_{sw}$) is not a Boussinesq density, it is the | ||
| conversion factor from mass to pseudo-thickness. | ||
| - No iceberg fluxes are included for now. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. would the iceberg flux be a modification to iceRunoffFlux?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The iceberg fluxes are their own additional terms. It's not hard to add an extra term, but given that we clearly stated that icebergs were out of scope for Omega, I thought I could skip defining/including them for now.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes you can for sure. I was mostly curious |
||
|
|
||
| ## Surface tracer restoring | ||
|
|
||
| Surface tracer restoring applies a piston-velocity tendency, or damping, at the ocean | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
somewhere, I don't think it needs to be in this PR, but we should separate out salinity restoring (or explicitly call it out) and note we plan to do this in the coupler instead of the framework from mpas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plan is to do restoring in the Forcing infrastructure too, as its own tendencies. I was planning to do a simple port into Forcing like I did for winds. With the timeline getting a little tight, I decided to prioritize implementing the new capability rather than spending time on the port.
The original PR (#418) had all the terms moved over but it was too big to test and review cleanly.
Are you thinking that you'd prefer a different design?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep this sounds right, not saying it needs to be higher priority. And I was wanting us to note when we do restoring that the time varying salinity will come from the coupler not from a Omega forcing framework like we have for MPAS. I don't think that changes anything you plan, just where you get the restoring target from.