Add salt flux computation option

[dabail10]

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

• [X] Short (1 sentence) summary of your PR: This adds the option to use the prognostic salinity in the salt flux computation.
• [X] Developer(s): dabail10 (D. Bailey)
• [X] Suggest PR reviewers from list in the column to the right.
• [X] Please copy the PR test results link or provide a summary of testing completed below. https://github.com/CICE-Consortium/Test-Results/wiki/icepack_by_hash_forks#7c33d8ebeaa42d3d76767b7825730a9c2a555ec2
• How much do the PR code changes differ from the unmodified code?
  • [X] bit for bit
  • [ ] different at roundoff level
  • [ ] more substantial
• Does this PR create or have dependencies on CICE or any other models?
  • [ ] Yes
  • [X] No
• Does this PR add any new test cases?
  • [ ] Yes
  • [X] 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/.)
  • [X] Yes
  • [ ] No, does the documentation need to be updated at a later time?
    • [ ] Yes
    • [ ] No
• [X] Please provide any additional information or relevant details below: This adds saltflux_option to the namelist for icepack. The options are '4psu' or 'prognostic'. I also removed the if (ktherm == 1) condition around the code for update_ocn_f in ice_therm_itd.F90 (add_new_ice). We need to compute these fluxes regardless of the ktherm option. I'm not sure where in MPAS-SeaIce the salt and fresh water fluxes are computed. Can we use update_ocn_f here? Related to issue #390 Added test results comparing to cheyenne baselines.

[njeffery]

@dabail10 : Should saltflux_option be added to Icepack_in at this point?

[dabail10]

Yes! Good catch.

[dabail10]

Technically, it should also be added to the Icepack driver as well.

[njeffery]

Okay, I'll wait for that.

Also, do any of the Icepack testcases verify salt conservation?

[dabail10]

Unfortunately, there are no conservation diagnostics in Icepack. Something on my to-do list.

[dabail10]

We do check salt conservation in CICE.

[njeffery]

I noticed that there's a conserv_check option. Would I see additional diagnostics in the log with this true?

[dabail10]

Good question. I've never turned that on.

[eclare108213]

I think conserv_check is for checking algorithms like incremental remapping or ridging -- it used to be hardwired in the code for debugging during development, and was later moved out to the namelist for easier automated testing.

[apcraig]

Just want to confirm everything is bit-for-bit in Icepack and CICE? Do you have a link to any test results?

[njeffery]

@dabail10 : Removing ktherm <=1 for update_ocn_f = true would be a problem for the MPAS-seaice implementation. This is because the freshwater and salt fluxes from the freeze melt potential are computed originally by the ocean model and corrected to be consistent with mushy-layer in the driver, ice_comp_mct. If the correction is done in add_new_ice instead of the driver then it should look like the update_ocn_f = false version dfresh = -rhoi(vi0new-vi0tmp)/dt , not dfresh = -rhoivi0new/dt.

[njeffery]

Maybe a flag that specified (ktherm == 1) or (ktherm ==2 and saltflux_option == prognostic) would work

[dabail10]

My understanding of your use case is that update_ocn_f would be .false.? That's why we only apply the correction when update_ocn_f is .false.

[njeffery]

@dabail10 : Do you know of any other code that's impacted by update_ocn_f? Right now E3SM runs with update_ocn_f = true and switching to false would break mass/salt conservation without some code change.

[dabail10]

I guess I am not understanding correctly. I'm not sure about other coupled models using update_ocn_f, maybe NOAA ... my understanding is that update_ocn_f = .true. means that the sea ice component computes the fluxes of freshwater and salt due to frazil formation. The ocean component computes it when update_ocn_f = .false. and then the sea ice component sends a correction for the "extra" frazil. The rationale for this is that the sea ice component would compute the freshwater and salt and use the ktherm == 2 actual salinity.

[njeffery]

That all makes sense to me. I'll look into why it's done differently in MPAS-seaice and make sure update_ocn_f hasn't taken on additional meaning.

[dabail10]

Thanks for your feedback @eclare108213 ! I was following the example of tfrz_option as you mention. Here we do minus1p8 instead of constant. I agree that it makes more sense to have a constant option for both and let the user assign the value. The issue with saltflux_option is that it is needed in the frazil ice (add_new_ice) in icepack_therm_itd.F90. It is also needed in the zap routines. The way I have it set up now is that update_ocn_f and saltflux_option are independent. You could imagine someone wants to actually do a prognostic salinity flux whether or not the ocean component is doing the freshwater and salt for frazil or not. Also, I would imagine that you could even want a prognostic salinity flux with ktherm == 1 or maybe a different constant value. I thought about doing something like only computing the prognostic salt flux when ktherm == 2.