A new sea level pond scheme. #515
Conversation
… icepack_shortwave
Fixes debug run issue and fixes implementation of fixed hypsometry
latest fixes to be bfb on intel compiler
Added science guide documentation for sealvlponds
| ice freeboard constraint, drainage during ice deformation, and pond lid | ||
| refreezing. Meltwater is also lost when the ice melts. Unlike in the | ||
| level or topo schemes, the sealvl scheme does not use the 'runoff' | ||
| (``rfrac``) parameterization. Physically, runoff is the same as drainage |
There was a problem hiding this comment.
The rfracmax and rfracmin parameters bound the fraction of meltwater entering the ponds (rfrac). 1-rfrac would be the drainage of meltwater that doesn't make it into the ponds, so saying "the 'runoff' (rfrac) parameterization ... runoff is the same as drainage" might be confusing to users. Perhaps say something like "Instead of draining a portion of the total meltwater before it reaches the ponds via rfrac as in the topo and level-ice schemes, this water is handled by the macro-scale drainage in the sealvl scheme."
There was a problem hiding this comment.
I like the rephrasing, we'll plan to update this with the next commit.
|
It will take a bit more time for me to go through all of the changes -- I started with the documentation to understand what's happening. This PR is BFB since the parameterization is turned off by default, but has anyone done a QC comparison to see whether this might be climate-changing? I would expect not, but with strong albedo influences you never know. |
@dabail10 has been doing some testing in CESM3 development runs. We don't have an apples-to-apples comparison yet but we do have some comparisons with CESM1 and CESM2 large ensembles (LENS). In the plots below, the red line is the sealvl pond run and ignore the dark blue line. Overall, the climatology of northern hemisphere for the CESM3 pond run tends to fall in between the CESM1-LENS and the CESM2-LENS during summer months. The ice extent is greater in the winter, although I expect that is related to changes other than the pond parameterization. The CESM3 pond run also has a more pronounced seasonal cycle than either the CESM1-LENS or CESM2-LENS. I wouldn't interpret too much from these comparisons due to the other changes in the model, but they suggest that the sealvl parameterization is not dramatically climate-changing. Theoretically, the sealvl parameterization should produce a similar ice area-averaged albedo for ice that is ~1-3 m thick as the level pond parameterization. However, with the sealvl parameterization we should see higher transmission/solar heating of the mixed layer and reduced surface melt relative to the level parameterization. The sealvl parameterization should also result in lower albedo for thin ice in the summer, which may have impacts in the marginal ice zone and in recent and future sea ice states. I will update here when we have a better comparison, but here are some summary figures comparing the CESM3 sealvl pond run (red line) with the large ensembles (and ignore the dark blue line):
|
|
I will do a CICE QC test. |
|
Amazingly this passes the QC test.
|
|
Thank you, @dabail10. I am relieved that this modification of the melt pond scheme is not judged to be climate-changing in the QC tests. If it were, it would call into question all of the simulations we've done to date! That said, passing the QC test doesn't mean that it can't have a significant effect in a coupled system. It looks like @davidclemenssewall's tests are also showing that it's not climate-changing but is significant in some sense. |
|
I would agree with that assessment. |
|
@dabail10 Thank you for running the test! @eclare108213, I didn't put this in the documentation, but the inspiration for these melt pond developments were the observations that CESM2 produces ice-area average albedo that is consistent with MOSAiC and SHEBA observations (Light et al., 2022) while simultaneously producing ponds with greater than observed albedo (Light et al., 2022) and area fraction (Webster et al., 2022). Our goal was to still produce reasonable ice-area average albedos while making the ponds more consistent with observations. The QC test confirms that we didn't totally throw off the albedo (which was consistent with other testing we did). I anticipate that we will see bigger impacts in coupled tests, especially in areas/climate states with thinner ice. But Dave is still running those tests. |
There was a problem hiding this comment.
This looks very good: clean, straightforward coding, and a terrific improvement to the physical system. Thank you!
My only major question is whether the sealvl ponds are virtual or 'real'. If they strictly follow the level-ice pond scheme, then they should be virtual. There are a bunch of new fields representing various processes, which I believe are only diagnostic and therefore consistent with virtual ponds, but that needs to be clarified.
| @@ -295,28 +296,36 @@ end subroutine rebin | |||
|
|
|||
| subroutine reduce_area (hin_max, & | |||
| aicen, vicen, & | |||
| aicen_init,vicen_init) | |||
| aicen_init,vicen_init, & | |||
| mipnd, trcrn) | |||
There was a problem hiding this comment.
I don't believe reduce_area is used with any regularity. Was this new bit of pond code tested? It might be better to get rid of this routine altogether (not in this PR), if it's not needed by anyone anymore.
| if (tr_pond_lvl) then | ||
| mpond = mpond + ardg1n * trcrn(nt_apnd,n) & | ||
| * trcrn(nt_hpnd,n) * trcrn(nt_alvl,n) | ||
| endif |
There was a problem hiding this comment.
I question this change. Topo ponds incorporate the full water cycle, i.e. melt water is stored in them until it is released to the ocean by various processes. Level-ice ponds are virtual, i.e. meltwater runoff is sent immediately to the ocean, and the ponds are only used for radiation calculations. It would be GREAT if the sealvl ponds were also "real" rather than virtual, which would require the water fluxes to follow the topo scheme rather than the level-ice scheme throughout the code. Regardless, the level-ice scheme should not be changed here, and I'm not sure why the tests still turn out BFB except that they are not coupled with a full ocean model.
| pndhyps = 'sealevel' , & ! pond hypsometry option | ||
| pndfrbd = 'floor' , & ! over what domain to calculate freeboard constraint | ||
| pndhead = 'perched' , & ! geometry for computing pond pressure head | ||
| pndmacr = 'lambda' ! driving force for macro-flaw pond drainage |
There was a problem hiding this comment.
For clarity, I recommend pulling the parameters that are only for sealvl ponds into their own block, so you could have
! level-ice ponds
level-ice parameters
! level-ice and sealvl ponds
common parameters (if any)
! sealvl ponds
sealvl parameters
| if (tr_pond_lvl) then | ||
| mipnd = mipnd + da0 * trcrn(nt_apnd,1) & | ||
| * trcrn(nt_hpnd,1) * trcrn(nt_alvl,1) | ||
| else |
There was a problem hiding this comment.
Is mipnd only a diagnostic, or is this eventually used as a 'real' water flux?
| rfpnd, & ! runoff rate due to rfrac (m/step) | ||
| ilpnd, & ! pond loss/gain (+/-) to ice lid freezing/melting (m/step) | ||
| mipnd, & ! pond 'drainage' due to ice melting (m / step) | ||
| rdpnd ! pond drainage due to ridging (m / step) |
There was a problem hiding this comment.
Noting that these variables are all listed under the ! diagnostic heading.
| @@ -79,7 +83,7 @@ subroutine history_write() | |||
| real (kind=dbl_kind),allocatable :: & | |||
| value1(:), value2(:,:), value3(:,:,:), value4(:,:,:,:) ! temporary | |||
|
|
|||
| integer (kind=dbl_kind), parameter :: num_2d = 32 | |||
| integer (kind=dbl_kind), parameter :: num_2d = 33 | |||
There was a problem hiding this comment.
why is this change necessary?
| tr_pond_topo = .false. | ||
| tr_pond_lvl = .false. | ||
| tr_pond_sealvl = .true. | ||
| tscale_pnd_drain = 0.5d0 |
There was a problem hiding this comment.
For completeness and user-friendliness, I recommend including apnd_sl here also, even if it's the same value as in icepack_in.
|
|
||
| perm = 3.0e-8_dbl_kind * (minval(phi))**3 | ||
|
|
||
| end subroutine brine_permeability |
There was a problem hiding this comment.
It's not necessary for this PR, but I wonder how much of this code duplicates what's in the other pond schemes. It would be good to reduce duplication, if possible without circular dependencies.
| other categories. If necessary, pond water is drained such that the | ||
| mean ice surface of the category is at sea level. I.e., the mean | ||
| category ice freeboard is constrained to be greater than or equal to | ||
| zero. The level pond scheme has the same constraint, except in the |
There was a problem hiding this comment.
Here and everywhere, please use "level-ice pond" scheme rather than "level pond" scheme, for consistency.
| @@ -149,6 +157,12 @@ subroutine compute_ponds_lvl(dt, & | |||
| + melts*rhos & | |||
| + frain* dt)*aicen | |||
| endif | |||
| ! Track lost meltwater dvn is volume of meltwater (m3/m2) captured | |||
| ! over entire grid cell area. Multiply by (1-rfrac)/rfrac to get | |||
There was a problem hiding this comment.
I don't understand "Track lost meltwater" in this comment.
| level pond scheme the ponded area of the category is assumed to be | ||
| mechanically uncoupled from the surrounding ice. So in the level pond | ||
| scheme, the freeboard constrains pond depth to be no greater than 10% | ||
| of the category ice thickness. |
There was a problem hiding this comment.
I suggest removing the last sentence here, since 10% is an approximate value that depends on the seawater, freshwater and ice density parameter values.
For detailed information about submitting Pull Requests (PRs) to the CICE-Consortium,
please refer to: https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index#information-for-developers
PR checklist
This is meant as an alternative to the level ponds. Documentation of the new scheme is included here.
@davidclemenssewall @dabail10
https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#fa1b1b4101773826bc748e9f9da89df764e323c9
This is bfb with tr_pond_sealvl = .false. Separate CICE tag to come.