Add support for disabling thermodynamics

[phil-blain]

PR checklist

• [X] Short (1 sentence) summary of your PR: title
• [X] Developer(s): @phil-blain
• [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.
  • ran a test case with the default settings, it completed successfully
  • ran a test case with ktherm=-1 modified in the namelist, it completed successfully
  • used these modifications in CICE+NEMO over the last months to debug my runs
  • we (ECCC) used equivalent modifications in our in-house CICE4/5 for several years to debug our runs.
• How much do the PR code changes differ from the unmodified code?
  • [x] bit for bit (when not using ktherm=-1)
  • [ ] different at roundoff level
  • [ ] more substantial
• Does this PR create or have dependencies on CICE or any other models?
  • [x] Yes: the CICE drivers need to be updated with the same logic (always running step_therm1)
  • [ ] No
• Does this PR add any new test cases?
  • [ ] Yes
  • [x] No should I add one ? maybe create set_nml.nothermo ?
• 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/.)
  • [ ] Yes
  • [x] No, does the documentation need to be updated at a later time?
    • [ ] Yes
    • [x] No ktherm=-1 is already documented
• [X] Please provide any additional information or relevant details below:

See commits messages.

This MR is best viewed with "hide whitespace changes" since I adjusted the indentation.

[phil-blain]

@JFLemieux73 asked me to PR that sooner than later so here it is :) A CICE PR will follow, maybe to apcraig/cgridDEV I guess?

[phil-blain]

I had forgotten a use statement, I've just pushed a fixed version.

[apcraig]

In terms of implementation, I wonder if this will be confusing. I assume when ktherm=0, we will want to call into icepack_step_therm1 from CICE, but we do NOT call into the other icepack routines from CICE? It seems like we should be consistent. If icepack can be called when ktherm=0, then all the icepack methods should be able to handle a value of ktherm=0 and return cleanly. What we're doing here is creating a situation where some parts of icepack can (should) be called when ktherm=0 and others cannot. In terms of options, we could

• update all the relevant icepack interfaces to handle calls when ktherm=0. That might be as simple as adding one line at the start of the icepack interfaces like if (ktherm=0) return
• add a new icepack interface that can be called when ktherm=0 to compute air/ice stress (and other things we may want) that is not called when ktherm/=0. We would call the new interface when ktherm=0 but we would still call icepack_step_therm1 and all the other icepack routines when ktherm/=0.

Then in terms of the implementation in icepack_step_therm1, we have lots of "if (ktherm==0)" logic added. Should we just have a block at the top that is

if (ktherm==0) then
  ! just the calls we need
else
  what's there now
endif

Finally, are the changes in icedrv_RunMod just to make the code run faster? Are we calling subroutines now that we don't need to be? Should this also be implemented in CICE or is it already done there properly?

One other thing. Since the variable ktherm lives in Icepack, we probably should update the icepack implementation so when icepack is called when ktherm=0, it behaves correctly. As currently implemented, I think we rely on the caller (i.e. CICE or E3SM) to manage calls to icepack when ktherm=0. That can still exist, but not requiring that logic is probably a good thing to do.

[apcraig]

@dabail10, that's a valid approach as well.

[eclare108213]

What's the status and consensus on this PR? still thinking about it?

[apcraig]

I think there is more discussion to be done before we merge. I think the implementation needs to be a bit more robust than what's implemented in this PR.

[phil-blain]

Sorry, I was doing other stuff and have not had time to circle back to this. I agree that it might be too hacky as-is. I'll think of a cleaner approach and make this PR WIP in the meantime.

Thanks to all of you for taking a look :)