search

CICE-Consortium / Icepack

Development repository for sea-ice column physics
Other
25 stars 131 forks source link

calc_dragio functionality #463

Closed eclare108213 closed 10 months ago

eclare108213 commented 11 months ago

The option to calculate ice-ocean drag based on a (variable) under-ice ice roughness and the thickness of the ocean layer was added to icepack_parameters.F and the documentation, but apparently the actual calculation is done outside of icepack and the resulting value is sent in as the parameter iceruf_ocn. Is that correct? So setting calc_dragio=.true. in Icepack does nothing? Maybe we should write a warning in the Icepack driver to make that clear. Why is thickness_ocn_layer1 needed in Icepack? And a final question: what would a non-Canadian user need to do in CICE or somewhere else in their coupled model to make this work? A little more documentation on that point would be helpful, e.g. a sentence in layman's language that outlines the calculation. If someone is looking at Icepack without CICE, then it needs to be clear that this capability must be implemented outside of Icepack, that Icepack only ingests the results. I've been exploring it for E3SM, and it appears to be a bit of a science project. Thanks!

phil-blain commented 10 months ago

Hi Elizabeth,

The option to calculate ice-ocean drag based on a (variable) under-ice ice roughness and the thickness of the ocean layer was added to icepack_parameters.F and the documentation, but apparently the actual calculation is done outside of icepack and the resulting value is sent in as the parameter iceruf_ocn. Is that correct?

That's not correct. In the documentation (which I added in #366), we have (last paragraph of https://cice-consortium-icepack.readthedocs.io/en/main/science_guide/sg_boundary_forcing.html#ocean):

https://github.com/CICE-Consortium/Icepack/blob/a80472b547aa6d7a85f8ae5e1449273a323e0371/doc/source/science_guide/sg_boundary_forcing.rst#L305-L320

and this is implemented in icepack_recompute_constants:

https://github.com/CICE-Consortium/Icepack/blob/a80472b547aa6d7a85f8ae5e1449273a323e0371/columnphysics/icepack_parameters.F90#L1648-L1653

So under calc_dragio=.true., we do this computation, and when it's false, we use the value of dragio (default or set via icepack_init_parameters).

So setting calc_dragio=.true. in Icepack does nothing?

No, it does not do nothing. It computes dragio from iceruf_ocn and thickness_ocn_layer1, instead of taking the dragio value directly from the Icepack parameters.

 And a final question: what would a non-Canadian user need to do in CICE or somewhere else in their coupled model to make this work?

I guess the same as a Canadian user :P That is, set calc_dragio=.true., and set iceruf_ocn and thickness_ocn_layer1 as needed.

I hope that's clear ? Let me know how you think the documentation could be improved. I guess the section I link to above would be clearer if the text also mentioned the corresponding code variables...

phil-blain commented 10 months ago

I started https://github.com/CICE-Consortium/Icepack/pull/466, I'll update if we want more details.

eclare108213 commented 10 months ago

My question is a little different from the one you're answering -- sorry for not being clear. My assumption is that iceruf_ocn is different for each grid cell (thickness_ocn_layer could also be different for each one). If those are constants everywhere, then this functionality doesn't really do much, right? Isn't the value in it that they can vary? But how they vary must be calculated outside of the sea ice model, or at least outside of Icepack. Does that make sense?

phil-blain commented 10 months ago

OK, yes I understand better now.

It's true that it does not do much if they are constant. Currently both iceruf_ocn and thickness_ocn_layer are indeed constant in our setup. So, we could have simply computed dragio externally, and set its value using icepack_init_parameters.

I went back to my PR (#366) and it turns out we quite a long discussion about it :) In fact, it seems you suggested the current approach (having the option to do the computation in Icepack itself).

I'm not opposed to removing it and computing it outside Icepack (and CICE) if we feel it's more natural this way.

One motivation for the current approach was that it added iceruf_ocn to Icepack, and we had some other in-house code that made use of this value for the form drag parameterization. It turns out I still haven't reimplemented those changes as they are not used in operations. I don't know if we will revisit them eventually.