Add GEOS coupling capability including heatflux and massflux modifications#518
Conversation
|
This supercedes #491. I think this contains all the changes in #491. I have renamed the incoming shortwave fluxes from druvr to swuvrdr to be more consistent with the Icepack naming convention. I have also modified some of the calling structure to pass arguments down the calling tree. Some open questions,
|
eclare108213
left a comment
eclare108213
left a comment
There was a problem hiding this comment.
This is just an initial glance through the code changes, which raised several questions.
Has this new heat/massflux coupling approach been tested in GEOS using both BL99 and mushy thermo?
Have the radiation changes been tested for both ccsm3 and dEdd?
| is still set to true, allowing ice surface and internal temperature to be updated | ||
| implicitly. The resultant surface temperature change is passed back to the | ||
| atmosphere model via coupler to complete the full update of its temperature profiles. | ||
| This middle-ground approach, enabled by ``enforcing_heatflux=true``, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. |
There was a problem hiding this comment.
change the wording slightly, to "...it does not need effective conductivity limiting as in the explicit case."
There was a problem hiding this comment.
Similar to enforcing_massflux, I think there needs to be a more specific label for the enforcing_heatflux option. In this case, perhaps semi-implicit_Tsfc? Probably the whole atm-ice coupling logic should be refactored (later, not this PR), similar to what we've been doing with ocn-ice.
There was a problem hiding this comment.
This has been updated.
| model which assumes vapor deposits or sublimates at 0 degC. In this case, mass | ||
| conservation is enforced and the resulting discrepancy in energy is resolved by | ||
| another term ``sblx`` and passed to ocean. This option is only on when | ||
| ``enforcing_massflux = true``. |
There was a problem hiding this comment.
The enforcing_massflux flag probably needs to be more specific, since this is only for this particular type of atmo/ice coupling.
There was a problem hiding this comment.
I'm thinking that changing enforcing_massflux to vapor_flux_correction might work better here, removing 'mass' because it also affects the energy exchange.
| ! if false, Tsfc is computed elsewhere and | ||
| ! atmos-ice fluxes are provided to CICE | ||
| geos_heatflux = .false.,&! geos heatflux option | ||
| geos_massflux = .false.,&! geos massflux option |
There was a problem hiding this comment.
We do need to name these something more descriptive, not using geos. I'll think about this.
The mass flux is only associated with evaporation and sublimation. Is that also true for the heat flux here? Or does it also include contributions from conduction etc?
There was a problem hiding this comment.
The mass flux is only relevant for evap/sublimation. There is no connection to conduction.
There was a problem hiding this comment.
So then, are both geos_massflux and geos_heatflux only associated with evaporation and sublimation? (Later you include deposition, right?) Why are both of these options needed? Do you ever need to run (in production mode) with one of them true and the other one false?
There was a problem hiding this comment.
I'm leaving the previous comment to illustrate my confusion here. Such parallel nameing implies (to me) that they are mass and heat fluxes associated with the same process.
Apparently (correct me if I'm wrong), the 'massflux' option is about the assumed temperature of water vapor deposition/sublimation, and the 'heatflux' option is entirely different, having to do with the coupling strategy for for calculating the surface temperature. If so, then perhaps we could change geos_massflux to vapor_flux_correction or something like that. But I suggested the same thing for enforcing_massflux in sg_thermo.rst. They are both logicals. What is the difference between geos_massflux and enforcing_massflux? Actually, I don't see enforcing_massflux (or enforcing_heatflux) in the code, only in the docs, so that might be left over from a previous iteration.
Would it make sense to change geos_heatflux to semi-implicit_Tsfc? (I suggested that instead of enforcing_heatflux)
There was a problem hiding this comment.
@eclare108213, sorry about the enforcing_heatflux and geos_heatflux confusion. It is just that the documentation is not synced with the code.
I really like semi-implicit_Tsfc as the replacement of geos_heatflux as it captures the nature of GEOS coupling. And vapor_flux_correction is also appropriate name for its purpose.
We do need these two flags as they are associated with two different processes (all related to coupling).
Thanks for these suggestions.
| hstot , & ! snow thickness including new snow (m) | ||
| Tmlts ! melting temperature (deg C) | ||
| Tmlts , & ! melting temperature (deg C) | ||
| sblx ! flux error due to cond/sub inconsistency |
There was a problem hiding this comment.
what do the letters in the symbol sblx represent? I prefer to use intuitive names for things, even if they are highly abbreviated.
There was a problem hiding this comment.
I think sblx was initially coined to be sublimation flux, i.e., the energy difference introduced by sublimation/condensation. Sorry, it is not a particularly good name. Any suggestions are welcome.
There was a problem hiding this comment.
sblx units are J m-2 -- add this to the comment. Since sblx itself isn't a flux, let's rename it and correct all comments associated with it. If I understand correctly, sblx is an energy correction associated with the assumed temperature of water vapor deposited onto or sublimated from the surface. So perhaps a better symbol would be de_vapor.
There was a problem hiding this comment.
changed sblx to de_vapor. done.
| fresh = fresh + frain * aice | ||
| if (.not.geos_heatflux) then ! include rain drainage | ||
| fresh = fresh + frain * aice | ||
| endif |
There was a problem hiding this comment.
What does rain draining from the ice have to do with geos_heatflux? This drainage is required if the level-ice or (new) sealvl pond schemes are used. (The topo pond scheme is a bit more complicated.)
There was a problem hiding this comment.
This is more of legacy in GEOS coupling. We pass full rain flux directly to ocean, unlike other models doing the split (aice, 1-aice). geos_heatflux flag is just to limit this to GEOS. If this is not considered good practice, we may think about changing it in our coupler.
There was a problem hiding this comment.
With this rainwater treatment, then you should never turn on topo ponds (or in the future, any pond scheme that assumes rain water is collected). I recommend aborting the run if this combination occurs.
There was a problem hiding this comment.
Thanks, @eclare108213. We sure don't want to lose the capability to use the topo pond scheme or others in future. I will consult with my team about how to move forward with it.
There was a problem hiding this comment.
Do we need another namelist variable to specifically control the fresh water coupling like "couple_rain" which is true by default and false for GEOS? So rain does not fall on the sea ice but snow does? It seems like some ice processes will be lost by doing this, right? Would this be a good time to fix this in GEOS so rain is passed to CICE like snow? Are there other sea ice models in GEOS that would be impacted by this coupling change?
There was a problem hiding this comment.
@apcraig, changing the rain partition is the way going forward, pending final approval. So I think here it can revert back to without if block.
There was a problem hiding this comment.
OK, I have updated the implementation and removed the if test. The rain passed to sea ice will be passed to the ocean model in the ice-ocean coupling step now in all cases. If this is not what's desired, let me know.
| fswthru_uvrdr,& ! vis uvr dir shortwave penetrating to ocean (W/m^2) | ||
| fswthru_uvrdf,& ! vis uvr dif shortwave penetrating to ocean (W/m^2) | ||
| fswthru_pardr,& ! vis par dir shortwave penetrating to ocean (W/m^2) | ||
| fswthru_pardf,& ! vis par dif shortwave penetrating to ocean (W/m^2) |
There was a problem hiding this comment.
The new radiation parameters need to be explained in the documentation. What are uvr and par? Are they associated with particular bands?
There was a problem hiding this comment.
uvr: ultraviolet radiation > 700nm
par: Photosynthetically active radiation: 400-700 nm
dr/df: direct and diffuse
in GEOS, there are jus referred to as UVR and PAR beam flux.
Will fix the comments with more detailed information
There was a problem hiding this comment.
I have updated the documentation in the code and in the user guide. done.
coupled system where a semi-implicit thermodynamic coupling scheme is introduced. Similar to the explicit case, the fields fsurfn are provided by the coupler, along with their derivatives with respect to surface temperature dfsurfn_dTs. In this case, calc_Tsfc is still set to true, allowing ice surface and internal temperature to be updated implicitly. The resultant surface temperature change is passed back to the atmosphere model via coupler to complete the full update of its temperature profiles. This middle-ground approach, enabled by geos_heatflux=true, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. In addition, in GEOS, the atmsophere model assumes vapor deposits or sublimates at 0 degC. In this case, mass conservation is enforced and the resulting discrepancy in energy is resolved by another term sblx and passed to ocean. This option is only on when geos_massflux=true. - Add 4 new shortwave terms, uvrdr, uvrdf, pardr, pardf to the coupling. These terms represent a breakdown of the direct and diffuse visible shortwave terms into two components, par = photosynthetical active radiation and uvr = rest of the visible shortwave term. The current visible shortwave is exactly represented by these two components. Includes adding atm forcing and terms associated with radiation passthru to the ocean. - Add calculation of GEOS heatflux. In GEOS, surface and latent heat flux is computed in the atmosphere at 0degC. The sea ice model has to respect that calculation, but then computes the d(dh)/dTs terms to correct the heatflux for the sea ice temperature which is then applied conservatively in the coupled system. Implementation includes turning off some of the heat flux calculations in Icepack. - Add calculation of GEOS massflux term. An equivalent correction is needed to the mass and enthalpy terms to take into account the GEOS coupling. - Add geos_heatflux and geos_massflux to parameters and namelist input - Update discover port - Update documentation
eclare108213
left a comment
eclare108213
left a comment
There was a problem hiding this comment.
These changes are pretty confusing to me, so I've made some suggestions for names that might help (assuming I understand the code correctly). These might not be the best choices -- let's discuss.
| hstot , & ! snow thickness including new snow (m) | ||
| Tmlts ! melting temperature (deg C) | ||
| Tmlts , & ! melting temperature (deg C) | ||
| sblx ! flux error due to cond/sub inconsistency |
There was a problem hiding this comment.
sblx units are J m-2 -- add this to the comment. Since sblx itself isn't a flux, let's rename it and correct all comments associated with it. If I understand correctly, sblx is an energy correction associated with the assumed temperature of water vapor deposited onto or sublimated from the surface. So perhaps a better symbol would be de_vapor.
| ! if false, Tsfc is computed elsewhere and | ||
| ! atmos-ice fluxes are provided to CICE | ||
| geos_heatflux = .false.,&! geos heatflux option | ||
| geos_massflux = .false.,&! geos massflux option |
There was a problem hiding this comment.
So then, are both geos_massflux and geos_heatflux only associated with evaporation and sublimation? (Later you include deposition, right?) Why are both of these options needed? Do you ever need to run (in production mode) with one of them true and the other one false?
| call icepack_warnings_add(warnstr) | ||
| write(warnstr,*) subname, 'zTin=',zTin(k) | ||
| call icepack_warnings_add(warnstr) | ||
| !tice_high = .false. ! GEOS, do we need this, what about tice_low and tsno?? |
There was a problem hiding this comment.
This appears to be a comment left over from development. Please remove.
| is still set to true, allowing ice surface and internal temperature to be updated | ||
| implicitly. The resultant surface temperature change is passed back to the | ||
| atmosphere model via coupler to complete the full update of its temperature profiles. | ||
| This middle-ground approach, enabled by ``enforcing_heatflux=true``, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. |
There was a problem hiding this comment.
Similar to enforcing_massflux, I think there needs to be a more specific label for the enforcing_heatflux option. In this case, perhaps semi-implicit_Tsfc? Probably the whole atm-ice coupling logic should be refactored (later, not this PR), similar to what we've been doing with ocn-ice.
| model which assumes vapor deposits or sublimates at 0 degC. In this case, mass | ||
| conservation is enforced and the resulting discrepancy in energy is resolved by | ||
| another term ``sblx`` and passed to ocean. This option is only on when | ||
| ``enforcing_massflux = true``. |
There was a problem hiding this comment.
I'm thinking that changing enforcing_massflux to vapor_flux_correction might work better here, removing 'mass' because it also affects the energy exchange.
| ! if false, Tsfc is computed elsewhere and | ||
| ! atmos-ice fluxes are provided to CICE | ||
| geos_heatflux = .false.,&! geos heatflux option | ||
| geos_massflux = .false.,&! geos massflux option |
There was a problem hiding this comment.
I'm leaving the previous comment to illustrate my confusion here. Such parallel nameing implies (to me) that they are mass and heat fluxes associated with the same process.
Apparently (correct me if I'm wrong), the 'massflux' option is about the assumed temperature of water vapor deposition/sublimation, and the 'heatflux' option is entirely different, having to do with the coupling strategy for for calculating the surface temperature. If so, then perhaps we could change geos_massflux to vapor_flux_correction or something like that. But I suggested the same thing for enforcing_massflux in sg_thermo.rst. They are both logicals. What is the difference between geos_massflux and enforcing_massflux? Actually, I don't see enforcing_massflux (or enforcing_heatflux) in the code, only in the docs, so that might be left over from a previous iteration.
Would it make sense to change geos_heatflux to semi-implicit_Tsfc? (I suggested that instead of enforcing_heatflux)
Rename geos_heatflux to semi_implicit_Tsfc Rename geos_massflux to vapor_flux_correction Rename sblx to de_vapor Add check to not allow semi_implicit_Tsfc with tr_pond_topo Update documentation
|
I just updated the Icepack code,
I think that takes care of several of the outstanding tasks. I still have a question about what, if anything, we should do about the rain term in the fresh water coupling. Please review the changes and let me know if anything else needs to change in code or documentation. |
water coupling flux. This will require modifications to the coupling system in GEOS, in particular, the partitioning of rain between sea ice and ocean.
|
I completed a full suite of testing on derecho, tests look fine. Some answer changes with some compilers, but this seems to be due to compiler optimization. I tested a few cases manually with the debug flags and those are bit-for-bit. I think this could be ready to merge after final review. https://github.com/CICE-Consortium/Test-Results/wiki/icepack_by_hash_forks#be5757df4ffa79e6bd283445892ce5c31c054780, https://github.com/CICE-Consortium/Test-Results/wiki/cice_by_hash_forks#c98b212136e9a716c4d89212f5459fcc4ee9453b |
|
There are still two outstanding questions from my initial code review:
Neither of these should hinder merging this PR, but if the code has not been tested and validated with some of these combinations, then we should abort if it's attempted and make a note in the documentation about what configuration is trusted. |
@apcraig, thanks for these updates. @eclare108213, the two coupling flags and radiation changes has all been tested before this latest updates by @apcraig. Please let me do a final test with a pull of geos branch before merging. Sorry I am a bit behind with some other issues. |
@zhaobin74 sorry to keep harping on this, but let me ask for just a bit more clarification.
It looks like the code has changed for all of these options, and I want to make sure that they have all been tested. |
@eclare108213, we have used both BL99 and mushy schemes in our tests, although currently the default is mushy as it is also used by NOAA/EMC which we try to align with. Both BL99 and mushy have code changes to support the GEOS coupling.
Similarly, both cssm3 and dEdd are supported in geos branch and tested with GEOS coupled model. We also chose dEdd as default these days.
In my next round of tests, I'll make sure both BL99/Mushy and ccsm3/dEdd are tested to be functioning properly. |
|
I have tested the latest |
|
@zhaobin74, do you feel these Icepack and CICE changes are ready to merge? If so, please "review" the code and approve. @eclare108213, could you also do a review and see if there are any outstanding issues that need to be addressed and approve if not. I'm not pushing for this to be merged, just want to keep things moving and if it's ready, we should merge. Thanks! |
@apcraig, sorry for the delay. I had another walk through of the code and think it is ready. Thanks. |
|
@eclare108213, could you review and approve this and the CICE GEOS PR if you think they are ready. Otherwise, let us know what may still need to be updated. Thanks. |
eclare108213
left a comment
eclare108213
left a comment
There was a problem hiding this comment.
@zhaobin74 thanks for testing BL99/Mushy and ccsm3/dEdd.
| use icepack_parameters, only: Tliquidus_max | ||
| use icepack_parameters, only: rhosi, conserv_check, rhosmin, snwredist | ||
| use icepack_parameters, only: kitd, ktherm | ||
| use icepack_parameters, only: kitd, ktherm, semi_implicit_Tsfc |
There was a problem hiding this comment.
semi_implicit_Tsfc might not be used in the module now
| "fswthru_pardf", "visible photosynthetically active shortwave diffuse radiation 400-700nm penetrating to ocean", "W/m\ :math:`^2`" | ||
| "fswthru_pardr", "visible photosynthetically active shortwave direct radiation 400-700nm penetrating to ocean", "W/m\ :math:`^2`" | ||
| "fswthru_uvrdf", "visible ultraviolet shortwave diffuse radiation > 700nm penetrating to ocean", "W/m\ :math:`^2`" | ||
| "fswthru_uvrdr", "visible ultraviolet shortwave direct radiation > 7000nm penetrating to ocean", "W/m\ :math:`^2`" |
There was a problem hiding this comment.
should probably be 700 nm rather than 7000
|
Sorry I wasn't fast enough -- looked back while reviewing the cice PR and saw a couple of other things. Not super important and can be corrected later (but soon, before we forget!). |
|
See #526 |
…tions (CICE-Consortium#518) Add GEOS coupling updates. This allows coupling to the GEOS coupled system where a semi-implicit thermodynamic coupling scheme is introduced. Similar to the explicit case, the fields fsurfn are provided by the coupler, along with their derivatives with respect to surface temperature dfsurfn_dTs. In this case, calc_Tsfc is still set to true, allowing ice surface and internal temperature to be updated implicitly. The resultant surface temperature change is passed back to the atmosphere model via coupler to complete the full update of its temperature profiles. This middle-ground approach, enabled by semi_implicit_Tsfc=true, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. In addition, in GEOS, the atmosphere model assumes vapor deposits or sublimates at 0 degC. In this case, mass conservation is enforced and the resulting discrepancy in energy is resolved by another term, de_vapor, and passed to ocean. This option is only on when vapor_flux_correction is true. Add 4 new shortwave terms, uvrdr, uvrdf, pardr, pardf to the coupling. These terms represent a breakdown of the direct and diffuse visible shortwave terms into two components, par = photosynthetical active radiation (400-700nm) and uvr = rest of the visible shortwave term (>700nm). The current visible shortwave is exactly represented by these two components. Includes adding atm forcing and terms associated with radiation passthru to the ocean. Add support for GEOS semi-implicit coupling of surface temperature. In GEOS, surface and latent heat flux is computed in the atmosphere at 0degC. The sea ice model has to respect that calculation, but then computes the d(dh)/dTs terms to correct the heatflux for the sea ice temperature which is then applied conservatively in the coupled system. Implementation includes turning off some of the heat flux calculations in Icepack. This is controlled by the semi_implicit_Tsfc namelist. Add check to not allow semi_implicit_Tsfc with tr_pond_topo. Add calculation of a vapor flux correction. A correction is needed for GEOS coupling to compute a mass and enthalpy correction for evaporation and sublimation. This is controlled by the vapor_flux_correction namelist. Rename sblx to de_vapor Update treatment of rain coupling for GEOS, include rain in fresh water coupling flux. This will require modifications to the coupling system in GEOS, in particular, the partitioning of rain between sea ice and ocean. Update discover port Update documentation --------- Co-authored-by: bzhao <Bin.Zhao@nasa.gov>
3 participants
PR checklist
Add GEOS coupling capability including heatflux and massflux modifications
zhaobin74, apcraig
Standalone model is bit-for-bit, testing continues.
Add GEOS coupling updates. This allows coupling to the GEOS coupled system where a semi-implicit thermodynamic coupling scheme is introduced. Similar to the explicit case, the fields fsurfn are provided by the coupler, along with their derivatives with respect to surface temperature dfsurfn_dTs. In this case, calc_Tsfc is still set to true, allowing ice surface and internal temperature to be updated implicitly. The resultant surface temperature change is passed back to the atmosphere model via coupler to complete the full update of its temperature profiles. This middle-ground approach, enabled by semi_implicit_Tsfc=true, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. In addition, in GEOS, the atmosphere model assumes vapor deposits or sublimates at 0 degC. In this case, mass conservation is enforced and the resulting discrepancy in energy is resolved by another term, de_vapor, and passed to ocean. This option is only on when vapor_flux_correction is true.
Add 4 new shortwave terms, uvrdr, uvrdf, pardr, pardf to the coupling. These terms represent a breakdown of the direct and diffuse visible shortwave terms into two components, par = photosynthetical active radiation (400-700nm) and uvr = rest of the visible shortwave term (>700nm). The current visible shortwave is exactly represented by these two components. Includes adding atm forcing and terms associated with radiation passthru to the ocean.
Add support for GEOS semi-implicit coupling of surface temperature. In GEOS, surface and latent heat flux is computed in the atmosphere at 0degC. The sea ice model has to respect that calculation, but then computes the d(dh)/dTs terms to correct the heatflux for the sea ice temperature which is then applied conservatively in the coupled system. Implementation includes turning off some of the heat flux calculations in Icepack. This is controlled by the semi_implicit_Tsfc namelist.
Add calculation of a vapor flux correction. A correction is needed for GEOS coupling to compute a mass and enthalpy correction for evaporation and sublimation. This is controlled by the vapor_flux_correction namelist.
Update discover port
Update documentation