Frazil ice temperature limiting

[eclare108213]

(in add_new_ice)

Icepack/columnphysics/icepack_therm_itd.F90

Line 1565 in f645855

Ti = min(liquidus_temperature_mush(Si0new/phi_init), -p1)

The limiting of mush temperature to -0.1C for small salinities (less than 1.844 ppt, I think) "significantly influences year-to-year variations in AMOC" as noted in an E3SM PR where @proteanplanet removed it from add_new_ice and the mct coupler (it also appears in FSD calculations not yet available in E3SM):
E3SM-Project/E3SM#4295

I'm not sure if and how much this matters for coupling approaches different from E3SM's, but it seems worth taking a look.

[TillRasmussen]

I/we have not been too focused on the AMOC in our operational setup. But yes it could be interesting to see the effect.

[dabail10]

This is interesting. I had not noticed this before. So, we do not use this method for setting the salinity and temperature of frazil. However, I am currently working on code that will do this better.

[dabail10]

Sorry, I read this backward initially. The maximum value of the temperature here is set to -0.1C. I wonder if this is motivated to be similar to the "correction" that we make when the shortwave is still penetrating the sea ice at warm temperatures. I guess we don't want it too close to 0C. Has anyone done simulations where this is set to -0.01 or something? I wonder if the liquidus curve gets wacky near 0psu?

I read the E3SM PR comments a bit. I see that the max was removed completely. Is there something in the liquidus computation that sets it to a max of 0C at least?

[eclare108213]

The fundamental issue is that things aren't well defined for 0C. You could have phi (porosity)=0 before melting, or phi=1 after melting, and it's all at 0C. I do not remember why we added the -0.1C limit. Dave, do you have a record of that in CESM, i.e. did it come in with changes from LANL, or did we get it from you? Maybe it came from somewhere else altogether.

E3SM does remove it altogether, with no apparent detrimental effects, but their coupling strategy is different. There are limits in the mushy code to keep temperature in bounds.

[dabail10]

The E3SM PR indicates this came in in 2013 into CICE. In fact, it was introduced in the 5.1 series.

CICE-Consortium/CICE-svn-trunk@b973671#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947d

[eclare108213]

Yes. My question is whether it was in CESM first, or somewhere else. Just trying to understand the motivation.

[dabail10]

This did not come from CESM. This looks like it was part of work that Adrian was doing when coupling CICE to MPAS-O. I received this document from Andrew last year. The document is from 2015. We did not even use CICE5.1 until 2016 I believe.

frazil_formation_in_mpas-o.pdf

So, the bottom line is that we can probably remove the upper limit on temperature, but I will have to do some tests in CESM to see if it causes a problem. We can add back in a limit if that causes us a problem. So, I can change this on the Consortium main.

[eclare108213]

Okay, thank you. I'll go back to Adrian!

Can you test it in CESM before changing it in the repo? I think it should be changed, but I don't want to jump too quickly. Better to understand what impact it has.

[dabail10]

Good plan.

[eclare108213]

Fixed in E3SM-Project#13