Add an option to be able to update ice concentration (from data assimilation or retrievals/products)

[sanAkel]

For detailed information about submitting Pull Requests (PRs) to the CICE-Consortium,
please refer to: https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index#information-for-developers

PR checklist

• Short (1 sentence) summary of your PR:
  This feature is being ported from CICE4, that is used in RTOFS:
  • We use the sea ice concentration from data assimilation (DA), performed using RTOFS-DA.
  • In this (CICE6) version usage is turned ON (default: OFF) via a logical: insert_sic variable.
  • See similar/same implementation in the old (CICE4) version of ice_restart.F90, search for insert_ssmi.
  • @awallcraft ported the code he wrote (and is used in CICE4) to CICE6.
  • This PR was originally sent to the NOAA-EMC/CICE fork and following @NickSzapiro-NOAA's recommendation, being redirected here; that PR is now closed.
  • All the comments and conversations (@NickSzapiro-NOAA and @awallcraft) can be read via , however, for the sake of self-completeness

A brief text/description follows:
One of the main goals of a data assimilation (DA)/prediction system that strives to provide close to observed sea ice concentrations and ice edge is to be able to reconcile the differences in modeled and observed sea ice concentrations derived from space borne instruments. Posey et al., 2025 implemented such a method with CICE4, it is hereby ported to CICE6. By default this feature is turned OFF. To turn it ON, set insert_sic to .true. in ice_in (input) namelist file and provide sic.nc to be able to nudge the modeled ice concentration to that from data assimilated (or observed) concentration.

• Developer(s):
  @awallcraft

• Suggest PR reviewers from list in the column to the right.
  I'm unable to do that. Alerting @apcraig for his help.

• Please copy the PR test results link or provide a summary of testing completed below.

  • Tested against the develop branch of the NOAA-EMC CICE fork: https://github.com/NOAA-EMC/CICE.git

  • Test was datm_cdeps_mx025_gefs. At orion/hercules, paths:

    • Baseline (develop branch): /work/noaa/stmp/santa/stmp/santa/FV3_RT/rt_3352132/datm_cdeps_mx025_gefs_intel/BASL/
    • Control (sanAkel:alan_ssmi branch, i.e., this PR) with insert_sic= .false. : /work/noaa/stmp/santa/stmp/santa/FV3_RT/rt_3352132/datm_cdeps_mx025_gefs_intel/CTRL
    • Experiment (Same as above Control, but with insert_sic= .true.): /work/noaa/stmp/santa/stmp/santa/FV3_RT/rt_3352132/datm_cdeps_mx025_gefs_intel/EXP

  • Results:

    • Control and Baseline: No change in answers, i.e., bit wise identical RESTART/iced.2011-10-02-00000.nc.
    • Experiment and Control: Answers changed in regions as expected. See below for details.

• How much do the PR code changes differ from the unmodified code?

  • bit for bit; identical results (when inputs are kept same as now with their default values).
  • different at roundoff level
  • more substantial

• Does this PR create or have dependencies on Icepack or any other models?

  • Yes; Icepack.
  • No

• Does this PR update the Icepack submodule? If so, the Icepack submodule must point to a hash on Icepack's main branch.

  • Yes
  • No. (No update to Icepack is needed.)

• Does this PR add any new test cases?

  • Yes
  • No

• Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)

  • Yes
  • No, does the documentation need to be updated at a later time?
    • Yes
    • No

• Please document the changes in detail, including why the changes are made. This will become part of the PR commit log.

Further details on results:

• All experiments were run for 1-day.
• Used a stock case p025 ice-ocean case of the UFS Weather Model.

Exp	insert_sic	Remarks
BASL	N/A	Feature not available/implemented; see Fig.1
CTRL	.false. (default value)	No change in answers from BASL
EXP	.true. See test SIC data in Fig.2	Changes in sea ice concentration that correspond to those in Fig.2, see Fig.3.

• Fig.1 Sea Ice Concentration (SIC): Initial (left) and Final - Initial (right) after 1-day integration.
• Fig.2 Test SIC data. See both Arctic and Antarctic, where SIC values have been set to 1 and 0.5 respectively.
• Fig.3 Difference in final restart SIC: EXP - CTRL; note the correspondence to regions that were modified in the test SIC data (Fig.2).

Remarks:

• With this proposed addition, an ability to insert data assimilated sea ice concentration is provided. Implementation is similar/same as in CICE4; see https://github.com/NOAA-EMC/RTOFS_GLO/blob/develop/sorc/rtofs_hycom.fd/src_2.2.99DHMTi-dist2B_relo_cice_v4.0e/source/ice_restart.F90 ; search for insert_ssmi. @awallcraft ported the code he wrote (and is used in CICE4) to CICE6.
• There is an acknowledgement that the coupler and/or MOM6 will need some modifications, but that is beyond the scope of this (CICE) repository. Such work will be taken up in future.

[TillRasmussen]

The assimilation scheme moves modeled ice towards observed ice when some requirements are fulfilled. It is implemented in the restart driver and acts as a correction to the restart file.
It has similarities to what is done at DMI. The requirements are to some extend hard coded and I think that the inclusion would benefit from namelist control of for instance when observations and modeled values are close enough in order not to be changed. This may result in some namelist parameters.
I have also added some specific comments in the text.

[sanAkel]

The assimilation scheme moves modeled ice towards observed ice when some requirements are fulfilled. It is implemented in the restart driver and acts as a correction to the restart file. It has similarities to what is done at DMI. The requirements are to some extend hard coded and I think that the inclusion would benefit from namelist control of for instance when observations and modeled values are close enough in order not to be changed. This may result in some namelist parameters. I have also added some specific comments in the text.

Thanks @TillRasmussen for your comments and suggestions. I'll improve to the extent possible with a few commits.
Meanwhile,

It has similarities to what is done at DMI.

Is the code/option as used at the DMI already available to use? If so, I will close this PR and use that instead.

FYA: @NickSzapiro-NOAA if @TillRasmussen confirms this is the case, can you please help?

[TillRasmussen]

My point with the similarities is that both your system and the DMI system has a lot of if conditions that determines whether or not to assimilate. These are based on experience and test with the system and the type of observations. It would be nice to be able to have these as a common set of namelist parameters, however I think that others should have a say in that as it will easily add ~5 namelist parameters (or more).

An example could be:
assimilate concentration when abs(obs-mod) larger than.

The DMI code is not by default public available but we can probably share it. We jut have to entangle a few DMI modifications away from it that is not related to this.
It is heavily inspired by HYCOM and how it nudges baroclinic boundary conditions into the system.
There is at least one principle difference

1. Your correction is applied immediately after the read of the restart file, whereas DMI applies a time window where the observation is nudged into the system.

My suggestion would be that you have something that works or almost works and get it into the system. I would like opinions from others on how to deal with the namelist parameters etc.
@apcraig @eclare108213 others: Opinions?

[sanAkel]

My point with the similarities is that both your system and the DMI system has a lot of if conditions that determines whether or not to assimilate. These are based on experience and test with the system and the type of observations. It would be nice to be able to have these as a common set of namelist parameters, however I think that others should have a say in that as it will easily add ~5 namelist parameters (or more).

An example could be: assimilate concentration when abs(obs-mod) larger than.

The DMI code is not by default public available but we can probably share it. We jut have to entangle a few DMI modifications away from it that is not related to this. It is heavily inspired by HYCOM and how it nudges baroclinic boundary conditions into the system. There is at least one principle difference

1. Your correction is applied immediately after the read of the restart file, whereas DMI applies a time window where the observation is nudged into the system.

My suggestion would be that you have something that works or almost works and get it into the system. I would like opinions from others on how to deal with the namelist parameters etc. @apcraig @eclare108213 others: Opinions?

@TillRasmussen, thanks for reviewing and suggestions.
Summary and comments are following:

• Summary:

1. I marked all the ⬆️ conversations resolved. If anything is not satisfactorily resolved, please unresolve and appreciate your suggestions.
2. We'll continue experimentation with this new option (insert_sic) in our system and work on the connections/concerns/suggestions (SST change and ktherm=1 - mushy thermodynamics; former will be most likely handled in our coupler; any experience from there, will be reported this repository in a future update).

• Comments:

1. Consolidation of namelist parameters/options that relate to bringing in observational information is really a good step. Such an effort within the MOM6 consortium has been very helpful. There we use an incremental analysis update IAU; @DmitryDukhovskoy has expressed his interest in extending such an approach or related to it, that he/others implemented in SIS2. Your approach in the DMI seems to be close to an IAU, so if there is a larger buy-in towards an IAU, we can all advance in that direction.
2. Personally I have tried (but never finished- yet!) to read in brightness temperatures and on-line physically retrieve properties of ice and ocean. Tagging @lbertino and Francois with whom I had similar/related discussions.

[lbertino]

Hi @sanAkel

1. I am generally not recommending an IAU unless you really need to avoid instabilities. The IAU is inherently diffusive so it defeats the purpose of the - otherwise excellent - model.
2. We have a project with MET Norway (Marina Duran-Moro) to assimilate passive microwave Tb for sea ice, so there is a Radiative Transfer Model in Python you can use convert CICE data to Tb here: https://github.com/marinadmo/rtm_da/blob/main/rtm_enkf_notebook.ipynb Our plan is to use data assimilation to invert Tb into CICE model variables.
   Hope that helps!

[sanAkel]

Hi @sanAkel

1. I am generally not recommending an IAU unless you really need to avoid instabilities. The IAU is inherently diffusive so it defeats the purpose of the - otherwise excellent - model.

@lbertino Glad to hear from you and thanks for chiming in.
AFAIK, we do not have an IAU for CICE anyway- good to you know your opinion. We can have further discussion based on the planned course of action suggested by others- @TillRasmussen, @eclare108213, @apcraig, @DmitryDukhovskoy, ..

2. We have a project with MET Norway (Marina Duran-Moro) to assimilate passive microwave Tb for sea ice, so there is a Radiative Transfer Model in Python you can use convert CICE data to Tb here: https://github.com/marinadmo/rtm_da/blob/main/rtm_enkf_notebook.ipynb Our plan is to use data assimilation to invert Tb into CICE model variables.
   Hope that helps!

This is great progress at your end! 🏆 👏
I'll take a look at this and as time permits revive my (old/archived) repository. Thanks for pointing me to it.

[sanAkel]

Checking if anything is pending on this PR: @apcraig ?

[apcraig]

The implementation looks pretty clean to me at this point. I appreciate the updates that were done and resuse of existing infrastructure. Thanks for all the earlier comments from others and all the work. The new subroutine, direct_insert_sic, does have a lot of hardwired logic. I'm not the right person to suggest what "science" parameters should become namelist. If there is consensus about what to do, that's great, maybe do it now. It could also come in as a separate PR.

My only comment might be that insert_sic as a logical namelist might be limiting. Do we want to have a string instead of a logical, basically supporting multiple options via a single namelist. So false would be "none" or "off" and true would be "adjust_aice" or similar. "sic" isn't really a CICE term, but I'm OK using it if others like it, but maybe aice is the better term for CICE? And maybe the namelist could be "modify_restart" instead of "insert_sic" as well? So modify_restart = "adjust_aice" instead of insert_sic = .true. providing extensibility in the future? With the idea that we might have "adjust_aice_hi" or "adjust_aicev2" or other options later. It's better to implement flexible namelist now to avoid changing namelist later, especially if that namelist needs to be removed.

The other thing is that maybe we want a namelist to specify the input file instead of hardwiring it in the code to 'sic.nc'. Maybe that namelist could be called "modify_restart_filename"? This is less critical because we could also add it later without any backwards compatibility issues.

[sanAkel]

Thanks @apcraig for reviewing and suggestions.

The implementation looks pretty clean to me at this point. I appreciate the updates that were done and resuse of existing infrastructure. Thanks for all the earlier comments from others and all the work. The new subroutine, direct_insert_sic, does have a lot of hardwired logic. I'm not the right person to suggest what "science" parameters should become namelist. If there is consensus about what to do, that's great, maybe do it now. It could also come in as a separate PR.

👍

My only comment might be that insert_sic as a logical namelist might be limiting. Do we want to have a string instead of a logical, basically supporting multiple options via a single namelist. So false would be "none" or "off" and true would be "adjust_aice" or similar. "sic" isn't really a CICE term, but I'm OK using it if others like it, but maybe aice is the better term for CICE? And maybe the namelist could be "modify_restart" instead of "insert_sic" as well? So modify_restart = "adjust_aice" instead of insert_sic = .true. providing extensibility in the future? With the idea that we might have "adjust_aice_hi" or "adjust_aicev2" or other options later. It's better to implement flexible namelist now to avoid changing namelist later, especially if that namelist needs to be removed.

If other reviewers ( @TillRasmussen, @eclare108213 ?) also suggest same/similar, to move this PR along,

(1) I can change the logical (still boolean flag, unless someone asks for otherwise): insert_sic to adjust_aice.

The other thing is that maybe we want a namelist to specify the input file instead of hardwiring it in the code to 'sic.nc'. Maybe that namelist could be called "modify_restart_filename"? This is less critical because we could also add it later without any backwards compatibility issues.

(2) Instead of hard coded read of sic.nc, I can read a file name character :: data_aice_file ⬅️ user can then set whatever file they want.

Please let me know if should proceed with (1) and (2)?