feature request: support for explicit thermo coupling in ICEPACK

[bzhao]

Hello all,

I am trying to bring CICE6 in our coupled model framework (GEOS-5). Given certain constraints, we have to use the explicit thermo coupling approach, previously supported in BL99 thermo solver in CICE4/5 and ICEPACK. However, I don't see that option in the new mushy layer solver. Am I missing something? Also I have found some issues in the way the current explicit solver specifying the boundary conditions. I am wondering whether that can be customized as well.

All in all, I hope to get some help from the consortium members regarding these issues, which may not be of interest to the general CICE users. Is it proper to start the discussion at github with more details?

Thank you.

Regards,

Bin Zhao

 

[eclare@lanl_gov]

Hi Bin,
This is the right place to start. The explicit coupling approach has not been implemented into the mushy thermo code - that's a science project in itself! I will add it to my list of capabilities that the community would like to have, and I will ask whether anyone working for the Consortium plans to do it. I expect that the implementation will need to be done in the community, though, and we can help bring it into the repos.

Please provide more details about your boundary condition issues.
Thanks,
Elizabeth

 

[bzhao]

Hi Elizabeth,

Thanks for the reply. I appreciate the consortium's support for this request.

Regarding the boundary conditions in the current BL99 explicit solver, I found the solution has problems when surface is close to the melting point. Specifically, the top layer snow/ice temperature showed some oscillations while the Picard solver was not converging within prescribed iterations. This is a CFL violation. I tried two remedies: 1) limiting effective conductivity as suggested in CICE doc. It got rid of oscillations and the solver converged. However, the resultant temperature and fluxes are quite different from that the implicit solver gave. 2) I also tried the UK Metoffice approach in which the conductive flux itself, instead of the conductivity, was capped. For some reason, it didn't work out either.

I think the ultimate cause is that the explicit solver employs the Neumann BC at the top interface. I am wondering whether that can be relaxed. How about imposing a Dirichlet BC, i.e, fixing Tsf since it is given from AGCM in our case? Then the conductive flux can be iteratively recomputed along with the top layer temperature. I found this approach gave a better solution matching the implicit solver. Of course the difference between conductive and surface fluxes needs to be reconciled afterwards.

For above investigations, I used the customized CICE4 code generously released by Metoffice. The explicit solver code looks like the same as in ICEPACK. I can provide the code and related results if you are interested in more details.

Best,

Bin

 

[whlipscomb]

Hi Bin,

I worked on this a long time ago, but I'm very rusty now. I remember talking with Met Center folks about solving this problem implicitly, doing a tridiagonal solve from the atmospheric boundary layer through the sea ice column, via the coupler. We decided that although this was possible in theory, it was too complex in practice because of the atmosphere and sea ice being on different grids, with multiple categories of sea ice.

So we were left with ad hoc solutions that degrade the accuracy. I think my preferred solution was to limit the effective conductivity. I don't remember implementing what you describe as the Met Office approach--this may have been done by Alison McLaren or someone else in the UK.

For the BL99 solver, I don't think it would work to fix Tsf to values below freezing. By making Tsf part of the solution, we allow transitions from Tsf < 0 to Tsf = 0. Holding Tsf fixed would break this logic. The mushy layer thermo might have similar logic, but I don't know the method well enough to say for sure.

I do think it would be useful to support the explicit coupling with the mushy layer solver. Someone who knows the numerics better would need to decide whether a BL99 approach (limiting the effective conductivity) would work, or if some other kind of limiting would be better. Some loss of accuracy is probably inevitable with explicit coupling, but it might be less for mushy layer than for BL99.

Bill

 

[bzhao]

Hi Bin,

I worked on this a long time ago, but I'm very rusty now. I remember talking with Met Center folks about solving this problem implicitly, doing a tridiagonal solve from the atmospheric boundary layer through the sea ice column, via the coupler. We decided that although this was possible in theory, it was too complex in practice because of the atmosphere and sea ice being on different grids, with multiple categories of sea ice.

So we were left with ad hoc solutions that degrade the accuracy. I think my preferred solution was to limit the effective conductivity. I don't remember implementing what you describe as the Met Office approach--this may have been done by Alison McLaren or someone else in the UK.

For the BL99 solver, I don't think it would work to fix Tsf to values below freezing. By making Tsf part of the solution, we allow transitions from Tsf < 0 to Tsf = 0. Holding Tsf fixed would break this logic. The mushy layer thermo might have similar logic, but I don't know the method well enough to say for sure.

I do think it would be useful to support the explicit coupling with the mushy layer solver. Someone who knows the numerics better would need to decide whether a BL99 approach (limiting the effective conductivity) would work, or if some other kind of limiting would be better. Some loss of accuracy is probably inevitable with explicit coupling, but it might be less for mushy layer than for BL99.

Bil

Hi Bill,

Thanks for chiming in.

The MetOffice approach was described in this paper (GMD - The sea ice model component of HadGEM3-GC3.1 ) which is based on an earlier 2016 study (GMD - The location of the thermodynamic atmosphere–ice interface in fully coupled models – a case study using JULES and CICE). It was not clear to me why limiting flux not conductivity was preferred.

What I am proposing is only for cases when the Picard solver fails to converge without limiting flux or conductivity. So far I only identified 2 cases where fixing Tsf is needed (there may be more which I haven't found):

1. Tsf = 0. When surface is melting, the oscillation is easy to be triggered. In fact, in this case the explicit and implicit schemes collapsed into one.
2. Tsf < 0 but very close to 0 and there is downward conductive flux. Here again we can fix Tsf and let Fcond adjust. After the solver converges, the difference between Fcond and Fsurf needs to be reconciled because Fsurf = Fcond since Tsf < 0. We can put the difference in ocean flux as MetOffice model did.

Note in the above case 2, we only switch from Neumann to Dirichlet after the solver do not converge after a few iterations. For all other cases, the explicit solver functions as usual with Neumann BC. Hopefully with these measures implemented, no limiting is required.

As to Tsf itself, it is completely out of CICE's hand due to the main constraint of GEOS-5 coupled model. Tsf is determined by a surface energy balance module in AGCM. Once AGCM's time step is finished, Tsf is fixed and cannot be altered except for advection.

I hope this paints a more clear picture.

Bin

 

[eclare@lanl_gov]

Bin, has this thread answered your questions, or is there more that you'd like to discuss here?

 

[bzhao]

Hi Elizabeth, I appreciate your and Bill's helpful comments. To me, there are two items:

1) the long term one to add explicit coupling in mushy layer code. We can coordinate on this effort and GMAO can lead along with any other center who may need this capability.

2) some changes to the current explicit code in BL99 solver as I outlined above. These changes are relatively straightforward and can be implemented as options one can turn on or off. Once these are done, at least we can start the CICE6 coupling work using BL99 solver. The remaining question is, would the consortium consider this kind of mods to be acceptable?

Thanks,

Bin

 

[eclare@lanl_gov]

1) the long term one to add explicit coupling in mushy layer code. We can coordinate on this effort and GMAO can lead along with any other center who may need this capability.

Sounds good. As I said above, I do think this is a research project. I'm not sure how easy it will be to do.

2) some changes to the current explicit code in BL99 solver as I outlined above. These changes are relatively straightforward and can be implemented as options one can turn on or off. Once these are done, at least we can start the CICE6 coupling work using BL99 solver. The remaining question is, would the consortium consider this kind of mods to be acceptable?

These kinds of changes should be fine, especially if they can be implemented with an off/on option. To make this easier to incorporate into our repos, we suggest that you follow the workflow guidelines for working with Icepack and CICE. It's a little more complicated because these changes will have to be made in both repos, including testing for both of them. We can help you with this process, as needed. Also, it's helpful if you can write a small document describing the changes you plan to make in the code - sometimes we can catch potential problems at that stage, before you spend a lot of time changing the code.
e

 

[bzhao]

Sounds good. As I said above, I do think this is a research project. I'm not sure how easy it will be to do.


These kinds of changes should be fine, especially if they can be implemented with an off/on option. To make this easier to incorporate into our repos, we suggest that you follow the workflow guidelines for working with Icepack and CICE. It's a little more complicated because these changes will have to be made in both repos, including testing for both of them. We can help you with this process, as needed. Also, it's helpful if you can write a small document describing the changes you plan to make in the code - sometimes we can catch potential problems at that stage, before you spend a lot of time changing the code.
e

Hi Elizabeth,

That sounds a good plan. I'll start with the document for the proposed changes to the BL99 solver and report back.
Many thanks,

Bin

 

[bzhao]

Hi Elizabeth,

I have finished a short write-up of my proposal. Please see it here. Let me know if you have any questions.
Thanks,

Bin