Need to correctly process ice and snow thickness from history files

[shlyaeva]

Several places in soca assume that hi_h and hs_h in the history ice files are ice and snow thicknesses. They are not, they are ice volumes and need to be divided by aice_h to get ice thicknesses.

From @NickSzapiro-NOAA:

Yes, hi,hs are ice, snow volume
They are "per unit grid cell area"
call define_hist_field(n_hi,"hi","m",tstr2D, tcstr, &
"grid cell mean ice thickness", &
"ice volume per unit grid cell area", c1, c0, &
ns1, f_hi)
https://github.com/CICE-Consortium/CICE/blob/8e3ef7c4cb657705ceff5bfec3e12b49dec4973e/cicecore/cicedyn/analysis/ice_history.F90#L742
To make over the ice, divide by aice

We assume that hi_h and hs_h are the thicknesses in:

• soca read code. Since we don't yet update ice/snow thickness in the analysis it will currently only matter during soca2cice.
• gdas-marine-viz.

[shlyaeva]

For the fix to soca (as well as some plots demonstrating what this inconsistency means for soca2cice), see JCSDA-internal/soca#1206. Once that's reviewed and comments are addressed, we'll need to update the fields_metadata.yaml that are used in gdas.

[shlyaeva]

I have merged the soca fix. I also ran some more tests with forecasts, and with the default soca2cice settings (min hice: 0.5, min hsno:0.1) CICE sometimes throws its hands up in the air and says it can't handle this (those settings were used for ice/snow volume before; now that it's thickness, apparently that's not enough). In the meantime, @DmitryDukhovskoy has been working on direct insertion of ice/snow thickness, and has an approach that may work better than what we do now in soca2cice. I'll start looking into adopting it for soca2cice.
I am proposing not to update fields_metadata.yaml in the meantime (this would mean that the code runs as on soca develop before the fix was merged) and not to wait for this fix before running the retros. FYI: @CatherineThomas-NOAA @JessicaMeixner-NOAA @RuiyuSun

[JessicaMeixner-NOAA]

If this is already merged into SOCA, then we just need this in the GDAS app and then G-W. Is there a scientific reason not to move forward with this or is it just a timing issue/concern?

[CatherineThomas-NOAA]

Thanks @shlyaeva. So you're recommending to leave SOCA and GDASApp as is with no updates for retros and v17, and then aim for yours and @DmitryDukhovskoy's updates in a future implementation?

[shlyaeva]

@JessicaMeixner-NOAA: scientific reason: until we either tune configuration and test it extensively, or rework soca2cice (perhaps based on Dmitry's approach) and also test it extensively, I expect that if we adopt the fix we'll have CICE blow up every once in a while the model forecast.

@CatherineThomas-NOAA yes, that's what I recommend.

[shlyaeva]

@JessicaMeixner-NOAA basically the buggy version was tuned well to avoid CICE problems (which is why it's run pretty reliably in the past months), but debugged version exposes other issues that need fixing.

[shlyaeva]

@CatherineThomas-NOAA one correction to my previous comment: it's OK (if it happens to make it) but not necessary to update soca. Without changing a configuration file in gdasapp the soca fix wouldn't be applied. I just recommend not applying the fix for the retros.